Moteur de jeu et conception pilotée par les données

J'ai entendu parler de la conception axée sur les données et j'effectue des recherches à ce sujet depuis un certain temps. J'ai donc lu plusieurs articles pour comprendre les concepts.

L'un des articles est Data Driven Design écrit par Kyle Wilson. Comme il l'a décrit, il me semble que le code d'application (c'est-à-dire le code de contrôle des ressources telles que la mémoire, le réseau ...) et le code logique de jeu doivent être séparés, et le code logique de jeu doit être piloté par des sources de données externes. À ce stade, je peux imaginer que le développeur écrirait une sorte d'éditeur de jeu qui accepte des données externes sur les objets du jeu (telles que les informations sur les personnages, les informations sur les armes, les informations sur les cartes ...). La conception du scénario sera scriptée par un langage / outil personnalisé écrit par le programmeur pour permettre au concepteur de jeu de créer une interaction entre les objets du jeu. Le concepteur du jeu utilisera soit un langage de script existant / personnalisé pour écrire le script du jeu, soit un outil glisser-déposer pour créer le monde du jeu. Un exemple d'approche d'outils auquel je peux penser est World Editor, qui est généralement fourni avec les jeux de Bliizard.

Cependant, un autre article est contre l'utilisation de Data Driven Design, The Case Against Data Driven Design . L'auteur suggère de ne pas laisser la conception du jeu axée sur les données, car cela prendrait plus de temps pour développer un jeu, car le concepteur de jeu a le fardeau de la programmation. Au lieu de cela, il y aura un programmeur de jeu pour programmer le jeu librement à partir de la conception de l'esquisse et sera vérifié par le concepteur du jeu une fois la programmation du jeu terminée. Il appelle cela un programme. Ce que je pense de cette méthode est similaire à la façon dont je le faisais auparavant: la logique du jeu est l'application elle-même, comme apposée sur l'idée ci-dessus, l'application est l'éditeur de jeu et le jeu réel est conçu en fonction de l'outil.

Pour moi, la première méthode semble plus raisonnable, car les composants du jeu peuvent être réutilisés pour de nombreux projets. Avec la deuxième méthode qui s'oppose à la conception basée sur les données, le code du jeu n'appartient qu'à ce jeu. C'est pourquoi je pense que Warcraft a tellement de genres de jeux, comme le Warcraft original et diverses cartes personnalisées, et l'un des plus célèbres: DOTA qui définit en fait un nouveau genre. Pour cette raison, j'ai entendu des gens appeler World Editor est le moteur de jeu. Est-ce vrai à quoi devrait ressembler un moteur de jeu?

Donc, après tout cela, je veux juste vérifier s'il y a un défaut dans ma compréhension de ces idées (piloté par les données, le programmeur, les scripts, etc.)?

Faire en sorte que votre jeu (ou tout produit logiciel) soit piloté par les données est presque toujours un avantage. Le seul véritable inconvénient est que vous pouvez passer un peu plus de temps à construire les systèmes concernés à l'avance; cela sera payant pour le reste de votre carrière de programmeur (même si vous ne réutilisez pas ces mêmes systèmes pendant tout ce temps, vous réutiliserez les techniques que vous avez utilisées pour les construire).

Le défi, et où la déconnexion dans ces deux articles que vous avez liés entre en jeu, est ce que vous choisissez de mettre dans les données et qui vous choisissez de donner accès à ces données. Fondamentalement, la conception et le développement basés sur les données signifient simplement que vous placez des informations dans un stockage externe, chargez ces informations au moment de l'exécution et agissez en conséquence. Votre code d'application fait ce que les données externes lui indiquent, plutôt que d'écrire du code d'application qui fait directement ce que vous pensez que le résultat final devrait être. Ce n'est pas une idée complexe.

Vous n'avez pas besoin de construire des "architectures pilotées par composants" complexes (comme c'est la mode de nos jours). Mettre des constantes pour peaufiner la physique (force gravitationnelle, coefficients de restitution) dans un fichier texte est piloté par les données. Les scripts (en Lua ou autre) sont pilotés par les données. Décrire vos données de niveau en XML. Quelque chose comme ça.

Vous pouvez piloter à peu près n'importe quel composant de logiciel avec des données, et vous pouvez choisir ceux avec lesquels vous voulez le faire. Le temps de développement est cher; le temps du programmeur en particulier. Si vous pouvez gagner du temps, vous ou d'autres programmeurs, en mettant le comportement et les données dans un stockage externe et en n'exigeant pas que le jeu soit recompilé pour chaque petit changement, vous devriez. Vous économiserez de l'argent et accélérerez les choses.

De plus, vous courez un risque énorme en essayant de faire en sorte que les «concepteurs conçoivent» et en faisant en sorte que les programmeurs «concrétisent ces conceptions», forçant un programmeur à exister dans la boucle d'itération pour le travail d'un concepteur: vous courez le risque de donner au programmeur l'impression il est juste un singe de code, faisant constamment de petits ajustements triviaux pour la conception. Cela peut être extrêmement démoralisant pour une grande majorité de programmeurs, qui souhaitent travailler sur des défis techniques intéressants et non sur le rôle de proxy d'un concepteur.

Pour vos questions spécifiques:

Est-ce vrai à quoi devrait ressembler un moteur de jeu?

Un "moteur de jeu" n'a pas vraiment de définition fixe. Généralement, c'est la collection unifiée de technologie sous-jacente utilisée pour créer un jeu, généralement prise en charge par un tas d'outils connexes (et donc très axée sur les données). Mais cela varie assez largement d'un contexte à l'autre.

Donc, après tout cela, je veux juste vérifier s'il y a un défaut dans ma compréhension de ces idées (piloté par les données, le programmeur, les scripts, etc.)?

Vous semblez être plus ou moins sur la bonne voie, bien que vous compliquiez peut-être trop la conception et le développement basés sur les données en les associant à des systèmes basés sur des composants.

En tant qu'auteur du deuxième article, je voudrais clarifier quelques points.

1. Comme l'a suggéré Josh Petrie, structurer votre code pour utiliser des données au lieu de simplement coder en dur tout est toujours une victoire. Je ne suggérais pas le contraire. Je faisais remarquer que pousser tout sur le designer n'est pas une bonne idée. Le terme «conception basée sur les données» signifie différentes choses pour différentes personnes, donc j'aurais probablement dû être plus précis lorsque j'ai écrit l'article original.
2. À chaque endroit où j'ai travaillé, nous créons des structures de données modifiables dans le moteur. Pour faire un changement, nous n'avons pas besoin de recompiler le jeu. Nous pouvons changer le nombre dynamiquement lors de l'exécution. Les structures de données sont souvent stockées dans du code, mais selon qui les modifie, elles peuvent facilement être chargées à partir d'un "fichier de données".
3. La plupart des environnements de développement prennent en charge une certaine forme de modification et de poursuite ou de rechargement de module pour C / C ++.
4. La plupart des studios de développement de jeux ont des programmeurs de gameplay. Leur travail consiste souvent à travailler avec le designer pour créer une expérience amusante. Leur principale préoccupation n'est pas les défis techniques mais plutôt la création de plaisir à partir du code. Je travaille en tant que programmeur de gameplay depuis de nombreuses années, et je trouve cela plus intéressant que d'essayer de résoudre des problèmes techniques. Mes responsabilités ont varié, mais j'ai trouvé mon travail plus satisfaisant lorsque je suis en charge de la mise en œuvre et que je travaille avec les designers sur la création de quelque chose de cool. Le problème avec le codage ou le scriptage des concepteurs est que les programmeurs doivent souvent trier les bogues, ce qui est l'une des choses les moins amusantes que vous puissiez faire en tant que programmeur.
5. Ce qui fonctionne le mieux pour un studio dépend du jeu. Si vous avez beaucoup de temps pour créer un jeu et que vous souhaitez donner à votre communauté de modules les moyens de jouer et créer quelque chose d'énorme, alors créer un jeu entièrement basé sur les données est logique. Beaucoup de jeux n'ont pas cet objectif. Ils doivent produire un nouveau jeu dans deux ans, et à moins d'avoir une franchise à succès, c'est probablement un type de jeu différent de leur travail précédent.
6. Ce que fait un "designer" peut varier d'un studio à l'autre. J'ai entendu parler d'un studio de développement qui embauche des programmeurs de gameplay d'autres studios, les appelle des concepteurs et leur fait écrire le comportement du jeu. Cela évite le problème d'avoir des gens qui ne sont pas formés à la programmation du codage / script.
7. Il devrait toujours y avoir une délimitation entre le code logique du jeu et le code moteur. De plus, vous voulez normalement avoir une sorte d'éditeur visuel pour le placement des objets. Je n'ai jamais travaillé dans un studio où les emplacements ennemis sont codés en dur. Ils sont placés dans un éditeur. Permettez-moi de proposer un exemple de ce dont je parle. Disons que le designer invente un ennemi. Le concepteur a-t-il alors scripté le comportement de ce nouveau type d'ennemi? C'est ce que je considère comme une conception basée sur les données (en termes de ce que Tim Moss a écrit à ce sujet). Dans la façon dont je propose, le programmeur travaille avec le concepteur, ils se font un ennemi amusant avec peut-être des paramètres modifiables, puis ils sont placés dans le niveau.
8. Le code natif écrit par un programmeur va s'exécuter plus rapidement au moment de l'exécution qu'un script écrit par un programmeur, qui s'exécutera plus rapidement qu'un script écrit par quelqu'un avec moins de connaissances techniques. Cette performance peut être importante ou non selon le type de jeu que vous créez et ce que vous faites, mais c'est quelque chose à considérer.
9. Vous pouvez partager le code de jeu entre les jeux, quelle que soit la méthode que vous choisissez. Je ne suis pas vraiment sûr de ce que vous voulez en venir avec ce point. Même si vous n'utilisez pas de langage de script ou d'outil visuel pour définir certains comportements, vous devriez autant que possible architecturer votre code de gameplay en composants réutilisables. Il y aura toujours des choses qui ne s'appliquent pas à votre prochain jeu, mais à chaque endroit où j'ai déjà travaillé, lorsque nous commençons le prochain jeu, nous commençons avec la base de code du précédent - même si ce n'est pas une suite. Nous conservons ensuite les éléments qui ont du sens et supprimons les éléments spécifiques au jeu.

En fin de compte, il n'y a pas de bonne ou de mauvaise réponse. Il s'agit de savoir comment vous et vos collègues êtes à l'aise de travailler. Quand j'ai écrit ce blog il y a quelque temps, il y avait beaucoup de discussions sur la façon dont tout le travail devrait être poussé vers les concepteurs, et je voulais écrire sur le nombre de sociétés de jeux à succès que je connaissais ont trouvé un équilibre différent.

En outre, comme note latérale, mon entrée de blog a 5 ans. Il semble que beaucoup plus de studios se tournent vers les langages de script et ainsi de suite ces jours-ci, mais créent des outils matures pour les déboguer, ce qui était ma principale plainte. Quand j'ai écrit cela, je ne pense pas qu'Unreal Kismet existait, que je n'ai pas utilisé, mais il semble qu'ils essaient de simplifier les scripts et il a apparemment un débogueur. (Je ne sais pas si cela fonctionne bien)

Pour les jeux à plus petite échelle, je ne pense vraiment pas que vous souhaitiez essayer de déployer un langage de script ou des fonctionnalités similaires dans votre technologie, mais si vous avez une équipe énorme et beaucoup de temps à consacrer à la technologie, il est possible de le faire à droite et l'investissement en temps peut avoir du sens selon la façon dont votre équipe de développement aime travailler. Personnellement, je vais probablement m'accrocher au C ++ aussi longtemps que possible car pour moi, c'est le plus simple et le plus rapide car je dois souvent essayer de contourner les "fonctionnalités" comme le ramasse-miettes.

Vous devriez regarder le moteur technologique BitSquid . Il est construit à l'aide de concepts DOD. Le blog de Niklas Frykholm est très intéressant. Il existe de nombreux articles sur la conception de ce moteur.

Au GDC 2011, Niklas a fait une présentation sur le rendu basé sur les données .