Considérations sur un jeu de simulation

Question

Le type de jeu de simulation auquel je pense est celui où vous avez des choses à construire dans divers endroits et des travailleurs / transporteurs qui les connectent.

Quelque chose de plus semblable à la série Settlers.

Supposons que je ne souhaite pas de graphisme pour le moment, cela , je pense pouvoir le gérer.

Mes doutes sont donc les suivants:

1. Chaque entité doit-elle être une classe et avoir un fil?
2. Les entités doivent-elles être regroupées dans des listes à l'intérieur de classes et chacune d'entre elles doit avoir un fil?

Si vous prenez l'implémentation 1, il sera très difficile de fonctionner sur des machines à spécifications réduites et ne s'adapte pas bien aux grands nombres.

Si l’on prend la mise en œuvre 2, les ressources seront meilleures, mais ensuite ...

Comment dois-je grouper les entités?

1. Vous avez un cours pour les maisons en général et une liste d’interface pour gérer cela?
2. Vous avez une classe pour des groupes de maisons spécifiques et une liste d'objets pour la gérer?

et qu'en est-il des discussions?

1. Dois-je avoir la boucle de jeu simpliste?
2. Dois-je avoir un fil pour chaque groupe de classe?
3. Quelle est la place des travailleurs / transporteurs dans l’image?

Answer 1

L’approche normale n’utilise pas du tout le thread, mais implémente plutôt des entités en tant que machines à états. Ensuite, votre boucle principale ressemble à ceci:

 while( 1 )
{
    foreach( entity in entlist )
    {
        entity->update();
    }

    render();
}

Answer 2

Le MMORPG Eve Online utilise python sans pile et le modèle d'acteur pour émuler un système thread-per-entity sans la ressource affectée.

Consultez ce lien pour plus d'informations: http://harkal.sylphis3d.com / 2005/08/10 / script-multithread-game-with-stackless-python /

Answer 3

Je suis presque certain que vous ne voulez avoir qu'un seul thread exécutant la logique de jeu. Avoir plusieurs threads n'accélèrera rien et rendra le code déroutant. Avoir une boucle de jeu principale est parfaitement correct, bien que les choses deviennent un peu plus difficiles si le jeu est multijoueur.

Je suis un peu confus quant à la partie de votre question relative aux cours. Si je comprends bien votre question, je suggérerais de créer une classe pour chaque type de maison (ferme porcine, moulin à vent, etc.) dérivée d'une classe de base abstraite commune Maison . Vous devez ensuite stocker toutes les maisons du monde du jeu dans une liste de maisons.

Answer 4

Pensez à utiliser Erlang. Avec Erlang, vous pouvez générer beaucoup plus de processus (= threads légers) qu’un thread système normal. En outre, si votre système n’est pas assez performant, ajoutez un autre noeud.

Une autre alternative serait le python sans pile (ou l’alternative actuelle pour Python), car il prend également en charge un type de thread léger, ce qui est très pratique pour les moteurs de jeux. Eve Online l'utilise pour ses serveurs. Mais cela n’est pas distribué, mais cela peut être facilement réalisé manuellement.

Answer 5

Bien que la réponse de @Mike F soit généralement correcte, vous devez garder à l'esprit que l'itération sur les entités dans un cycle foreach rend l'ordre d'évaluation significativement déterministe, ce qui a des effets secondaires indésirables. . Par ailleurs, l’introduction de threads ouvre un potentiel de problèmes de heisenbugs et de concurrence, de sorte que le meilleur moyen que j’ai vu et utilisé repose sur la combinaison de deux cycles: le premier regroupe les actions des agents / ouvriers état, le deuxième cycle compose les résultats des actions et met à jour l’état de la simulation. Afin d'éviter d'éventuels biais, l'ordre d'évaluation est randomisé à chaque cycle. Ce BTW passe à une évaluation massivement parallèle, soumise à une synchronisation à la fin de chaque cycle.

Answer 6

J'éviterais de créer une classe distincte pour chaque entité car vous risqueriez de répéter le code pour les fonctionnalités partagées ou de créer un arbre d'héritage génial.

Je dirais que ce que vous voulez, c'est une classe unique et des objets avec des fonctionnalités composées dessus. J'ai vu un article sur un blog parlant de ce concept même dans une RTS ... attendez, je pense que c'était une visite guidée de modèles de conception que quelqu'un écrivait .

Utilisez le modèle Visiteur générant un filetage sur la méthode DoEvents (faute d'un meilleur mot) de chaque objet pour indiquer à chaque objet de faire ce qu'il va faire au cours de cette boucle donnée. Synchronisez les threads à la fin de votre boucle, car vous ne voulez pas que certains objets dotés d’une logique complexe fassent leur travail à partir de dix boucles alors qu’en réalité, il avait été détruit il y a cinq boucles.