Comment dois-je modéliser un jeu basé sur l'économie en code?

Je voudrais créer un jeu d'économie basé sur une ancienne civilisation. Je ne sais pas comment le concevoir. Si je travaillais sur un jeu plus petit, comme une copie de "Space Invaders", je n'aurais aucun problème à le structurer comme ceci:

• Classe de contrôle principale
• Classe graphique
• Classe de joueur
• Classe ennemie

Je ne comprends pas comment je ferais cela pour des projets plus importants comme mon jeu économique. Dois-je créer une classe de pays qui contient un tas de villes? Les villes contiennent-elles beaucoup de classes de construction, la plupart contiennent des classes de personnes? Dois-je créer une classe de recherche de chemin à laquelle le joueur peut accéder pour se déplacer?

Dois-je créer une classe de pays qui contient un tas de villes?

Sûr.

Les villes contiennent-elles beaucoup de classes de construction, la plupart contiennent des classes de personnes?

Sûr.

Dois-je créer une classe de recherche de chemin à laquelle le joueur peut accéder pour se déplacer?

Sûr.

Tout ce que vous avez suggéré ci-dessus semble raisonnable. Ce n'est peut-être pas la meilleure façon pour vous à long terme, mais ça va. Il est évident que vous avez du sens, car c'est le modèle organisationnel qui vous est venu le premier. Il est important de prendre cela et de commencer une implémentation à partir de cela. Cela vous permettra à la fois de démarrer et de surmonter cette "paralysie de conception" initiale qui tourmente souvent les développeurs au début d'une tâche et (si elle s'avère défectueuse d'une manière ou d'une autre) vous apprendra une ou deux choses sur les avantages et les inconvénients. de cette approche particulière de la conception.

Vous avez naturellement pris les concepts en tête et les avez regroupés en code selon quelques règles simples:

• Ce concept diffère-t-il de manière significative dans le comportement ou dans les données d'autres objets que j'ai déjà? (Les pays et les gens partagent très peu, voire pas du tout, de données ou de comportements significatifs, ils doivent donc être représentés par des types distincts dans le jeu).
• Aurai-je même besoin de manipuler ce concept dans le code de manière significative (si votre jeu concerne des personnes individuelles, vous aurez peut-être besoin de cette Personclasse, mais si le jeu ne les concerne que globalement, comme dans les versions précédentes de SimCity, vous peut ne pas avoir besoin de ce type ni d'instances de ce type pour créer une cartographie 1: 1 de la population d'une ville. int populationCountpeut être suffisant).
• Ce concept nécessite-t-il un état ? Si c'est le cas, il devrait être encapsulé d'une manière ou d'une autre, ce qui me permet de stocker cet état (une classe) plutôt qu'un tas de fonctions libres. (Une implémentation de pathfinding n'a pas d'objet du monde réel analogue, mais elle nécessite de garder une trace des données telles que les nœuds de la carte qu'elle a déjà pris en compte, et cela est mieux fait via une classe qu'en le stockant dans un groupe des globaux cachés et des fonctions autonomes).

Bien que simple, répondre à ces questions peut vous être très utile lorsque vous essayez de décider si et comment transformer un concept mental en code source. Vous pouvez également lire les principes SOLIDES de la conception orientée objet .

Notez que la suggestion d'un système d'entité / composant faite dans les commentaires est également une approche valide, bien que je l'évite ici à moins que vous ne recadriez votre projet pour qu'il soit plus petit (simplement parce que relever deux nouveaux défis importants dans un projet peut être trop intimidant et peut diluer l'avantage éducatif que vous recevriez autrement en vous concentrant sur un seul). Dans un modèle orienté composant, le "type" dans les questions ci-dessus devient plus implicite: non pas le type concret dans le code, mais le type implicite défini par la collection de composants qui forment une entité. Les mêmes principes directeurs peuvent s'appliquer.

Ce que vous avez décrit (une classe pour chaque type principal d'objet de jeu logique) est parfaitement logique pour un jeu simple. Si c'est la première fois que vous écrivez un jeu de ce type, je vous suggère de le faire de cette façon.

Quelques conseils:

• Un joueur est-il vraiment différent d'un ennemi ? Une grande partie de la fonctionnalité est susceptible d'être la même, donc celles-ci devraient normalement être de la même classe ou étendues à partir de la même classe de base. Considérons une classe de base AbstractPlayer avec deux sous-classes HumanPlayer et AIPlayer - toutes les fonctionnalités courantes peuvent aller dans AbstractPlayer .
• Préférez la configuration des objets avec la composition plutôt qu'avec l'héritage. N'approfondissez pas vos hiérarchies d'héritage. Si vous commencez à appeler une classe ForgeWithSteelAnvil, vous devez vous inquiéter: une Forge peut être une sous-classe de Building , mais le type d'enclume utilisé doit être un objet contenu dans le bâtiment.
• De même, préférez les propriétés qui vous permettent de configurer des objets plutôt que d'ajouter des centaines de classes d'objets légèrement différentes.

Dans les jeux plus complexes, vous pouvez utiliser des techniques plus avancées, mais je vous suggère de ne pas les utiliser tant que vous n'êtes pas très à l'aise avec l'approche de base de la POO (c'est-à-dire que vous avez réussi quelques jeux terminés). Des approches plus avancées pourraient inclure:

• Modèles d'objets basés sur des prototypes - utilisez une seule classe pour tous les objets du jeu et modélisez tous vos objets via les propriétés / attributs et la composition. Beaucoup plus flexible / dynamique que la POO standard, mais plus difficile à gérer (en particulier, le compilateur ne vous aidera pas beaucoup si vous faites quelque chose de stupide). J'ai utilisé cela à bon escient dans mon petit jeu Roguelike Tyrant ( https://github.com/mikera/tyrant )
• Systèmes de composants d'entité - parfait si vous avez beaucoup de comportements complexes que vous souhaitez mélanger et assortir dans de nombreux types d'objets de jeu différents. Très puissant, mais difficile à obtenir correctement.

Il existe peu de méthodes que vous pouvez utiliser pour aborder l'organisation de vos entités et ensembles de données. Je préfère écrire un tableur et tester les données d'avant en arrière pour m'assurer d'être efficace. Si vous créez le jeu vous-même, n'oubliez pas qu'il doit avoir du sens pour vous. Parfois, la route la plus efficace consiste à être légèrement moins efficace dans le code pour simplifier le projet.

Si vous souhaitez avoir plus d'aide sur la structuration de votre contenu, recherchez un ancien code source de jeu qui utilise une structure ou un style similaire et trouvez leur solution. Ensuite, affinez-le et fixez-le à votre guise.