Quelles fonctionnalités appartiennent au moteur et lesquelles à un jeu?

En ce moment, je me retrouve à implémenter et tester de nouvelles fonctionnalités pour mon moteur de jeu 2D, en les codant directement dans le moteur. Simultanément, j'ai un jeu de démonstration avec prise en charge des scripts, qui devrait appeler les fonctions moteurs. J'attache par exemple un mouvement de tuile fixe à la classe Entity dans le moteur, plutôt que de l'écrire spécifiquement pour le jeu. Cela brise définitivement l'idée d'un moteur général utilisé pour plus d'un jeu.

Existe-t-il des meilleures pratiques pour continuer à se concentrer sur la mise en œuvre correcte dans les bonnes parties (c'est-à-dire le moteur contre le jeu)?

2d software-engineering

— Christian Ivicevic
source

Eh bien, il y a deux façons de penser à ce sujet. La première consiste à répertorier les fonctionnalités spécifiques que le moteur devrait avoir (ce que vous avez demandé ici.) Cependant, l'autre méthode consiste à commencer à créer des jeux sans trop se soucier du "moteur", puis les fonctionnalités que vous trouvez sont réutilisées entre plusieurs jeux (en particulier, les fonctionnalités utilisées dans chaque jeu), vous devez migrer de la source pour un jeu spécifique vers une base de code partagée appelée "moteur".

Parce qu'au final, pourquoi vous voulez une fonctionnalité donnée dans le moteur plutôt que dans le jeu, c'est qu'elle est partagée entre plusieurs jeux. En règle générale, il s'agira de commandes de dessin, de contrôleurs d'entrée et de code réseau. Un moteur de jeu 2D aura de nombreuses fonctionnalités graphiques 2D, comme le chargement d'images, une hiérarchie d'affichage avec ordre z, la gestion des feuilles de sprites, l'interpolation, etc. Beaucoup de jeux ont besoin d'une simulation physique, mais en revanche beaucoup n'en ont pas. Pendant ce temps, plus de choses sous le capot utilisées dans presque tous les jeux incluent des minuteries, des messages d'événements et même des fonctions mathématiques spécifiques au développement du jeu (par exemple, distanceToTarget ()

Longue histoire courte:

A) Le moteur devrait avoir des fonctionnalités partagées par la plupart des jeux.

B) Vous apprenez quelles fonctionnalités sont partagées en créant un tas de jeux.

— jhocking
source

+1 -just start making games without worrying too much about the "engine"

— JCM

Eh bien, just start making games without worrying too much about the "engine"c'est certainement une belle suggestion.

— Christian Ivicevic

Je suis d'accord avec les deux commentaires ci-dessus, mais la remarque "juste faire des jeux sans se soucier du moteur" a été sortie de son contexte et est inutile sans le reste: "puis les fonctionnalités que vous trouvez sont réutilisées entre plusieurs jeux (en particulier , fonctionnalités utilisées dans chaque jeu), vous devez migrer de la source d'un jeu spécifique vers une base de code partagée appelée "moteur". En bref, créez autant de jeux que possible afin de savoir ce qui doit passer sous un moteur et ce qui ne devrait pas ' t.

C'est une excellente idée car elle vous empêche également d'implémenter des fonctionnalités de moteur dont vous n'avez pas réellement besoin dans vos jeux.

— Zachary Yates du

+1 pour garder l'esprit de la Règle de trois .

— Joshua Drake