La conception de jeu traditionnelle , telle que je la connais, utilise le polymorphisme et les fonctions virtuelles pour mettre à jour les états des objets de jeu. En d'autres termes, le même ensemble de fonctions virtuelles est appelé à intervalles réguliers (ex: par image) sur chaque objet du jeu.
Récemment, j'ai découvert qu'il existe un autre système de messagerie basé sur les événements pour mettre à jour les états des objets de jeu. Ici, les objets ne sont généralement pas mis à jour image par image. Au lieu de cela, un système de messagerie d'événements très efficace est construit et les objets de jeu ne sont mis à jour qu'après avoir reçu un message d'événement valide.
L'architecture de jeu basée sur les événements est bien décrite dans: Game Coding Complete de Mike McShaffry .
Puis-je demander de l'aide pour les questions suivantes:
- Quels sont les avantages et les inconvénients des deux approches?
- Où est-on meilleur que l'autre?
- La conception de jeux basée sur les événements est-elle universelle et meilleure dans tous les domaines? Est-il donc recommandé pour une utilisation même sur les plateformes mombile?
- Laquelle est la plus efficace et la plus difficile à développer?
Pour clarifier, ma question n'est pas de supprimer complètement le polymorphisme d'une conception de jeu. Je souhaite simplement comprendre la différence et bénéficier de l'utilisation de la messagerie événementielle par rapport aux appels réguliers (par image) aux fonctions virtuelles pour mettre à jour l'état du jeu.
Exemple: Cette question a suscité un peu de controverse ici, alors laissez-moi vous donner un exemple: Selon MVC, le moteur de jeu est divisé en trois parties principales:
- Couche d'application (communication matérielle et OS)
- Game Logic
- Vue du jeu
Dans un jeu de course, la vue du jeu est responsable du rendu de l'écran le plus rapidement possible, au moins 30 ips. La vue de jeu écoute également les commentaires du joueur. Maintenant, cela se produit:
- Le joueur enfonce la pédale de carburant à 80%
- GameView construit un message "Pédale de carburant de la voiture 2 enfoncée à 80%" et l'envoie à Game Logic.
- Game Logic reçoit le message, évalue, calcule la position et le comportement de la nouvelle voiture et crée les messages suivants pour GameView: "Dessiner la pédale de carburant de la voiture 2 à 80%", "Accélération sonore de la voiture 2", "Coordonnées de la voiture 2 X, Y" .. .
- GameView reçoit les messages et les traite en conséquence
la source
update). La seconde, vous pouvez le faire avec la messagerie pour diverses raisons.Réponses:
Je crois fermement à la nécessité d'être la mère de l'invention. Je n'aime rien coder sauf si son besoin est clair et bien défini. Je pense que si vous démarrez votre projet en mettant en place un système de messagerie d'événements, vous le faites mal. Je crois qu'une fois que vous avez créé et testé votre infrastructure et que tous les éléments de votre projet sont bien définis, des modules de travail doivent vous concentrer sur la façon dont vous allez connecter ces modules les uns aux autres. Essayer de concevoir un système de messagerie d'événements avant de comprendre la forme et les besoins de chaque module est hors service.
Quels sont les avantages et les inconvénients des deux approches?
Je pense que certaines personnes diraient qu'il existe de bons systèmes de messagerie prêts à être installés et utilisés. C'est peut-être vrai. Il est certain que les performances d'une solution personnalisée spécialement adaptée à vos besoins seraient supérieures à celles d'un bus de messages à usage général. La grande question est - combien de temps allez-vous passer à construire un système de messagerie plutôt que d'utiliser quelque chose qui a déjà été construit. De toute évidence, si vous pouviez trouver une sorte de système d'événements avec exactement l'ensemble de fonctionnalités dont vous avez besoin, alors c'est une décision assez facile. C'est pourquoi je m'assure de bien comprendre ce dont j'ai besoin avant de prendre cette décision.
Où est-on meilleur que l'autre?
Nous pourrions parler de mémoire et de ressources ici. Si vous développez pour n'importe quel matériel avec des ressources limitées, il est certainement difficile d'utiliser un système d'événement qui le réduira considérablement. Vraiment, cependant, je pense que le problème se résume à ce dont vous avez besoin, ce qui, comme je l'ai déjà mentionné, est quelque chose que vous ne savez pas jusqu'à ce que vous voyiez à quoi ressemblent toutes les pièces. Si vous avez suffisamment d'expérience dans la construction de ces systèmes pour savoir à l'avance à quoi ressembleront toutes les pièces, vous pouvez également répondre à cette question à l'avance. Je suppose que vous n'avez pas cette expérience, car vous ne poseriez pas cette question si vous en aviez.
La conception de jeux basée sur les événements est-elle universelle et meilleure dans tous les domaines? Est-il donc recommandé pour une utilisation même sur des plateformes mobiles?
Universel et meilleur dans tous les domaines? Une jolie déclaration générale comme celle-ci est facilement rejetée. Tout ce qui ajoute des frais généraux doit supporter sa part de la charge de travail. Si vous n'utilisez pas suffisamment d'événements pour justifier les frais généraux de la conception, c'est la mauvaise conception.
Laquelle est la plus efficace et la plus difficile à développer?
L'efficacité dépend de la façon dont elle est mise en œuvre. Je pense qu'un design traditionnel bien développé surpassera un système basé sur les événements n'importe quel jour de la semaine. En effet, la communication entre les pièces peut être micro-gérée et rendue super efficace. Bien sûr, cela rend également la conception plus difficile du point de vue de l'expérience et du temps requis pour la compléter et la rendre plus efficace. D'un autre côté, si vous manquez de cette expérience ou si vous n'avez pas le temps de bien développer l'application, il sera plus efficace d'utiliser une conception événementielle adaptée à vos besoins. Si vous avez des besoins d'événement personnalisés qui ne s'intègrent pas facilement dans une structure basée sur des événements, cela pourrait rendre la structure basée sur des événements très difficile à concevoir - en particulier pour garder la conception efficace.
la source
Je pense que vous comparez des pommes et des oranges ici. Le polymorphisme n'est pas du tout remplacé par la messagerie. Vous souhaiterez probablement que des événements / messages connectent des composants à couplage lâche. Par exemple. pour envoyer un message d'une entité en cas de collision, pour mettre à jour le score du joueur ou peut-être pour déclencher un effet sonore. Pour que ces classes individuelles ne connaissent pas les autres classes et envoient et / ou gèrent simplement des messages.
Mais votre jeu aura très probablement une boucle de mise à jour quelque part et puisque vous avez cette boucle de mise à jour, il peut facilement être utilisé pour mettre à jour toutes les entités de jeu qui doivent également être mises à jour à chaque image. Cela ne vous empêche pas d'utiliser la messagerie ...
Si vous avez une sorte de structure dans laquelle vous ajoutez / supprimez des entités de jeu, vous pouvez tout aussi bien les inclure dans votre boucle de mise à jour au lieu de leur envoyer un message de mise à jour à chaque image. Alors pourquoi ne pas appeler directement la mise à jour de vos entités de jeu pendant que vous utilisez la messagerie pour connecter différents sous-systèmes de votre jeu? J'aime aussi le concept Signal / Slot ( voir exemple qt ) pour les systèmes événementiels.
Conclusion: il n'y a pas de meilleure approche ni d'exclusivité.
la source
Cela a commencé comme un commentaire à la réponse de Bummzack, mais est devenu long.
À moins que vous ne le rendiez réellement asynchrone (répartissez les événements sur un nouveau thread), vos objets reçoivent toujours le mémo de manière synchrone. En supposant que votre répartiteur d'événements utilise une table de hachage de base avec une liste liée dans une cellule, l'ordre sera l'ordre dans lequel les objets ont été ajoutés à cette cellule.
En outre, sauf si vous décidez d'utiliser des pointeurs de fonction pour une raison quelconque, vous utilisez toujours des appels de fonction virtuels, car chaque objet recevant un message doit implémenter IEventListener (ou tout ce que vous appelez). Les événements sont une abstraction de haut niveau que vous créez à l'aide du polymorphisme.
Utilisez des événements où vous devez appeler une liste de méthodes pour divers événements dans le jeu afin de synchroniser différents systèmes dans le jeu ou où la réaction de divers objets et systèmes de sorte que ces événements ne peuvent pas être clairement définis ou que vous voulez pour ajouter plus de réactions à ces événements à l'avenir.
Ils sont un excellent outil, mais comme l'a dit Bummzack, ne supposez pas que le polymorphisme et les événements résolvent le même problème.
la source
Je dirais que choisir l'un ou l'autre est assez mauvais. Certains objets doivent appeler chaque trame, d'autres non. Si vous souhaitez rendre un objet, vous devez lui faire un appel de rendu à chaque image. Les événements ne peuvent pas faire ce changement. La même chose est vraie pour tous les objets physiques basés sur le temps - vous devez les appeler à chaque image.
Cependant, je n'appelle pas chaque trame vers mes objets de gestion d'objet, ou mes objets d'entrée utilisateur, ou quelque chose comme ça. Les appels virtuels de masse à chaque objet sur le cadre sont une idée terrible.
La conception utilisée pour un objet particulier doit être basée sur les besoins de ces objets, et non sur une idéologie pour le système dans son ensemble.
Modifié pour être plus clair sur ma première phrase.
la source