Techniques pour réduire la complexité de la programmation du jeu [fermé]

Question

Dans mon temps libre je programme des jeux comme un passe-temps, différentes sortes de choses et actuellement rien de très complexe. Les choses aime tireurs 2d, jeux sur tuiles, jeux de puzzle, etc ...

Cependant, comme le développement de ces jeux se poursuit, je trouve qu'il devient difficile de gérer la complexité des différents sous-systèmes au sein des jeux, des choses comme interface, World Afficher / modèle, la gestion des événements, des États (Menu, Pause, etc ... ), des effets spéciaux et ainsi de suite.

Je tente de garder les connexions au minimum et réduire le couplage mais bon nombre de ces systèmes ont besoin de parler d'une manière ou d'une autre qui ne nécessite pas la tenue de votre entière base de code dans votre tête à un moment donné.

À l'heure actuelle, j'essaie de déléguer différents sous-systèmes et fonctions de sous-système à différents objets qui sont regroupés ensemble mais je ne l'ai pas trouvé une stratégie de communication qui est assez découplé.

Quel genre de techniques puis-je utiliser pour me aider à jongler avec tous ces différents sous-systèmes et de gérer la complexité d'un système de plus en plus qui doit être suffisamment modulaire pour faciliter les changements rapides besoins?

Je trouve souvent me poser les mêmes questions:

• Comment les objets ne communiquent entre eux?
• Où le code qui gère les sous-systèmes spécifiques aller?
• Combien de ma base de code devrais-je penser à un moment donné?
• Comment puis-je réduire le couplage entre les entités de jeu?

Answer 1

Ah, si seulement il y avait une bonne réponse à votre question. Ensuite, le développement du jeu ne serait pas loin d'être aussi difficile, risquée, et prend du temps.

  

Je tente de garder les connexions à un   minimum et réduire le couplage cependant   beaucoup de ces systèmes ont besoin de parler   d'une façon ou d'une autre qui ne fonctionne pas   exiger la tenue toute votre base de code   dans votre tête à un moment donné.

Ils le font, mais souvent ils ne ont pas besoin de parler tout à fait une manière aussi directe que les gens croient d'abord. Par exemple, il est fréquent d'avoir l'état du jeu des valeurs de poussée dans son interface graphique à chaque fois que quelque chose change. Si, au contraire, vous pouvez simplement stocker des valeurs et de laisser l'interface graphique les interroger (peut-être via un modèle d'observateur), vous avez ensuite supprimé toutes les références de l'interface graphique de l'état du jeu. Souvent, il suffit de demander simplement si un sous-système peut tirer les informations dont il a besoin à partir d'une interface simple au lieu d'avoir à pousser les données.

  

  
• Comment les objets ne communiquent entre eux?
  
• Où le code qui gère les sous-systèmes spécifiques aller?
  
• Combien de ma base de code devrais-je penser à un moment donné?
  
• Comment puis-je réduire le couplage entre les entités de jeu?
  

Rien de tout cela est vraiment spécifique aux jeux, mais il est un problème qui se pose souvent avec des jeux, car il y a tellement de sous-systèmes disparates que nous avons pas encore développé des approches standard pour. Si vous prenez le développement web alors il y a vraiment juste un petit nombre de paradigmes établis: le « un modèle / fichier de code par URI » de quelque chose comme PHP, ou peut-être l'approche « modèle / vue-modèle / contrôleur » de RoR, Django, ainsi que quelques autres. Mais pour les jeux, tout le monde roule leur propre.

Mais une chose est claire: vous ne pouvez pas résoudre le problème en demandant: «Comment les objets communiquent. Il existe de nombreux types d'objets et ils ont besoin des approches différentes. Ne pas essayer de trouver une solution globale pour répondre chaque partie de votre jeu - entrée, réseau, audio, la physique, l'intelligence artificielle, le rendu, la sérialisation - il ne va pas se passer. Si vous essayez d'écrire une application en essayant de trouver une interface IObject parfait qui répondra à toutes les fins, alors vous allez échouer. Résoudre les problèmes individuels d'abord et ensuite chercher les points communs, refactoring que vous allez. Votre code doit d'abord être utilisable avant qu'elle ne peut même pas être considéré comme réutilisable.

sous-systèmes de jeu en direct à tous les niveaux dont ils ont besoin pour, non plus. En général, j'ai un haut niveau App, qui possède les graphiques, le son, l'entrée et les objets du jeu (entre autres). L'objet du jeu est propriétaire de la carte ou du monde, les joueurs, les non-joueurs, les choses qui définissent ces objets, etc.

Distinct états de jeu peuvent être un peu difficile, mais ils sont en fait pas aussi important que les gens pensent qu'ils sont. Pause peut être codé comme un booléen qui, lorsqu'il est activé, désactive simplement les mises à jour AI / physique. Les menus peuvent être codés comme des superpositions simples de l'interface graphique. Ainsi, votre «état de menu devient simplement un cas de pause du jeu et de montrer le menu, et le jeu quand La réactivation du menu est fermé -. Pas de gestion explicite de l'État requis

Réduire le couplage entre les entités de jeu est assez facile, encore une fois aussi longtemps que vous n'avez pas une idée amorphe de ce qu'est une entité de jeu est qui mène à tout besoin de parler potentiellement à tout. Les personnages du jeu vivent généralement dans une carte ou un monde, qui est essentiellement une base de données spatiales (entre autres) et peut demander au monde de le dire sur les personnages et les objets proches, sans jamais avoir besoin de tenir des références directement.

Dans l'ensemble si vous avez juste à utiliser des règles de bonne développement de logiciels pour votre code. La chose principale est de garder les interfaces petit, simple et concentré sur un et un seul aspect. couplage lâche et la capacité de se concentrer sur les petites zones du code découle naturellement de cela.