Est-ce une bonne idée de simplifier un moteur de jeu basé sur les personnages au point où il n'est pas nécessaire d'apprendre le script / la programmation?

Je me souviens, et je pense toujours, qu'on ne peut même pas créer un jeu 3D prototypé pour tester des comportements simples sans utiliser des outils gigantesques comme l'unité ou connaître une programmation C ++ étendue, des modèles de conception, un moteur 3D décent ou basique, etc.

Maintenant, je me demande, puisque je connais la programmation, si je suis encore plus chanceux que ceux qui ont besoin d'apprendre la programmation avant de savoir comment faire quelque chose. Même les moteurs de script comme Unity ne sont pas pour les enfants, et à mon sens, ils ont tendance à dicter leurs façons de faire. Ce n'est pas le cas avec des moteurs comme Ogre ou Irrlicht.

Maintenant, je pense que les jeux axés sur les personnages occupent une grande partie du marché des jeux. Pensez-vous que c'est une bonne idée de créer un moteur de jeu orienté sur le contrôle des personnages qui ne permette que de construire l'IA à l'exclusion de toute autre chose?

Quand je dis prototype, je veux aussi dire "générique" dans le sens où l'on peut rapidement choisir parmi un ensemble de paramètres de gameplay tels que le gestionnaire de scène, la caméra POV du joueur, les commandes, certaines collisions / physiques très basiques et l'intégration de pilotage de base (OpenSteer par exemple). L'idée principale est de créer un bac à sable AI mais en 3D, afin qu'il puisse être démontré sans les contraintes 2D (et également le rendre plus adapté au prototype en 3D pour un projet 3D au lieu de 2D).

J'aime vraiment le moteur de jeu sous-estimé dans Blender. (http://www.blender.org) Le modèle capteur-contrôleur-actionneur est vraiment facile à suivre même pour les non-programmeurs, et il est possible de faire un jeu raisonnablement complet (déplacer un personnage animé, tirer une arme, détruire des cibles , afficher le score, garder une trace de la santé, réinitialiser le niveau ou passer à un nouveau) sans aucune programmation du tout.

Bien sûr, certaines choses nécessitent une programmation (en particulier l'obtention de la souris pour un FPS.) Cependant, Blender intègre déjà Python, et les scripts Python sont très bien liés au modèle, vous n'avez donc pas besoin de remplacer les capteurs-actionneurs par Python. Au lieu de cela, vous passez simplement d'un contrôleur `` pass-through '' très simple à un script Python complet qui peut lire tous les capteurs de la scène et passer le contrôle à tous les actionneurs.

Il est tout à fait possible de créer un prototype de jeu en quelques jours dans Blender (je l'ai fait pour un projet dans un musée pour enfants local l'année dernière.)

Bien sûr, rien ne remplace le bon vieux savoir-faire en matière de programmation et, éventuellement, un développeur doit comprendre la programmation.

Quel que soit le mécanisme d'entrée, à la fin de la journée, vous devez toujours mettre en place une sorte de façon de dire au jeu quelle est la logique. "Scripting" est un bon terme familier pour cela. Donc, fondamentalement, je ne suis pas d'accord avec l'affirmation selon laquelle vous pouvez simplifier quelque chose au point où vous n'avez pas besoin de connaître les "scripts".

Cela étant dit, tous les scripts ne doivent pas être effectués avec un langage de programmation basé sur du texte. Il y a eu un certain travail (mais pas beaucoup) pour créer un système de script visuel. L'outil de script de niveau d'Unreal, Kismet, en est un assez bon exemple. Le moteur source a un mécanisme similaire, mais il utilise des entités dans le monde plutôt que sur un plan plat.

Fondamentalement, vous avez des boîtes que vous faites glisser dans une sorte d'environnement qui ont des entrées et des sorties. Si vous avez besoin d'une sorte de sortie de branchement, vous avez une boîte qui a une entrée et plusieurs sorties. Ces sorties peuvent aller à des actions qui ont des données qui leur sont liées (c'est-à-dire "passer à ce point", "dire cette ligne", "poser cette question", etc.). C'est généralement une barrière beaucoup plus faible à l'entrée pour que quelque chose soit opérationnel dans un langage visuel car vous n'avez pas besoin de connaître les mots-clés ou la syntaxe, vous avez juste un ensemble limité de cases à choisir parmi lesquelles tous ont des comportements définis, et vous les connecter ensemble.

Cependant, je pense que les moteurs de script visuel ne valent pas vraiment la peine. Vous devez être capable de penser de manière structurée et logique afin de dire avec succès au moteur ce que vous voulez faire. Si vous pouvez penser comme ça, passer des boîtes avec entrées / sorties aux instructions de branchement de base et aux appels de fonction dans un langage de script n'est pas si grave. En fait, après un certain temps, la partie visuelle est probablement un obstacle. De plus, c'est beaucoup plus de travail du côté moteur. Vous devez faire des choses comme implémenter l'annulation, copier / coller, peut-être avoir des fonctionnalités de niveau supérieur pour organiser vos scripts. Avec une langue textuelle, vous pouvez laisser tout cela à l'IDE.

Ce sera en général un compromis. Si vous voulez vraiment supprimer la nécessité de faire n'importe quel type de script, vous allez généralement parler de créer une sorte d'interface qui assemblera les scripts en arrière-plan (ou connectera simplement des objets logiques ou autre). Il y a des jeux entiers où c'est tout l'intérêt pour eux, un environnement bien défini où vous faites glisser et déposez des fonctionnalités pour voir comment il interagit avec lui.

À la fin de la journée, cependant, ce sera toujours un compromis. Plus vous tentez de simplifier l'interface, plus les choses créées via cette interface sont simplistes.