Existe-t-il des moteurs / cadres narratifs (ou du moins non spatio-temporels)? [fermé]

EDIT (2): Puisqu'il y a deux réponses et que je n'en ai accepté aucune, je me suis dit que je motiverais ce que je considérerais comme une réponse ici: Soit quelque chose suggérant fortement qu'une telle approche serait impossible / pas du tout utile ou , alternativement, une référence à une recherche (domaine) ou à des exemples d'un tel système au moins quelque peu général au-delà des jeux d'aventure texte / fiction interactive.

Bien que je ne prétende pas avoir fait une enquête plus approfondie, j'ai remarqué que tous les moteurs / cadres de jeu que j'ai examinés semblaient être quelque chose comme un moteur graphique glorifié dans le sens où ils parlent de formes / entités en deux ou un espace euclidien tridimensionnel avec, éventuellement, une certaine forme de modèle de concurrence "caché" permettant de spécifier une certaine forme de logique attachée à ces "entités".

Les «règles» et la narration du jeu sont ensuite écrites de manière quelque peu ad hoc (en ce qui concerne le moteur) au-dessus de ces primitives.

Évidemment, la description ci-dessus est plutôt simplifiée (prenez des moteurs plus spécialisés tels que le moteur infini qui inclut une certaine forme de système de quête / narration), et je me rends compte que ce modèle peut très bien fonctionner (beaucoup de gens semblent l'avoir utilisé) .

Je me demande, cependant, quelles tentatives ont été faites pour créer des moteurs / cadres qui prennent comme notions principales une description (de haut niveau) des règles de jeu / logique ou narrative (ou au moins un aspect non spatial du jeu) base?

EDIT (4): Cela ne signifie pas que le jeu n'inclurait aucun aspect spatial / graphique, juste que plutôt que d'avoir des entités spatiales auxquelles vous associez une logique, vous avez une notion d'intrigue (ou de gameplay ou de "règles du jeu de plateau" ) dont vous décrivez ensuite une interface graphique / réalisation.

Je serais particulièrement intéressé par toutes les approches déclaratives qui tentent de capturer une sorte de sémantique (semi-) formelle d'une classe de jeux assez importante, d'une manière utile pour la mise en œuvre réelle (par opposition à, par exemple, un cadre exclusivement pour analyse qualitative des jeux / narration).

Ce que j'ai vu, ce sont des recherches sur la modélisation / analyse de récits avec un modèle basé sur Petri Net et quelques approches intéressantes en langages pour écrire de la fiction interactive .

EDIT (1): J'ai pensé ajouter un exemple de jouet pour illustrer.

Imaginons que nous voulions créer des aventures de style pointer-cliquer (pensez aux jeux SCUMM). On pourrait les analyser comme reposant sur une notion de progression plus ou moins linéaire et discrète d'une situation de départ à une fin.

En se concentrant sur la notion de progression discrète et en permettant une certaine non-linéarité, on pourrait choisir la théorie des DAG (bornés) comme théorie de base. La spécification d'un jeu de ce type, dans sa forme la plus abstraite (par rapport à cette théorie) correspond donc à l'ajout d'axiomes supplémentaires à cette théorie (soit pour que la théorie spécifie un graphe spécifique soit simplement pour capturer tout ce que l'on pense nécessaire pour en capturer un) "terrain").

Transformer cela en un jeu réel se transforme maintenant en problème de conception HCI / Interface d'incorporer cette théorie dans quelque chose de jouable (c'est-à-dire construire un modèle de la théorie / trouver un morphisme homo (iso?) De graphiques à partir de la collection d'états d'interface utilisateur avec des transitions dans le DAG "spécifiant le jeu").

Dans le scénario hypothétique ci-dessus, je peux voir au moins trois choses qu'il devrait être possible de capturer dans les bibliothèques. Premièrement, il faut des outils pour transformer / raisonner sur les DAG ou les graphiques en général. Deuxièmement, une bibliothèque d'interface utilisateur suffisamment intelligente pour aider à vérifier que notre représentation de notre graphique en tant que jeu jouable modélise réellement le graphique (ainsi, par exemple, au moins partiellement / de manière informelle, prouvant que le jeu n'a pas d'états bloqués, en raison de la condition de délimitation) . Enfin, une collection de bibliothèques de niveau supérieur pour spécifier le graphique pourrait être donnée; comme une bibliothèque pour exprimer des personnages et leur interaction et générer des (parties de) graphiques en termes de tels.

Pourquoi garder la théorie "moyenne" des DAG, plutôt que de simplement avoir l'implémentation de bas niveau avec quelques bibliothèques d'aide en haut? La réponse est toutes les raisons habituelles d'une sémantique formelle. Étant donné que nous avons décidé d'une fondation formelle, nous pouvons vérifier certaines propriétés du jeu permettant de raisonner sur des choses comme les optimisations dans la bibliothèque d'interface de bas niveau (tant qu'elle modélise le DAG, nous pouvons faire ce que nous voulons), sans avoir à s'inquiéter de l'incomparabilité avec la description de haut niveau (de personnages / dialogue, etc.), car ces descriptions doivent elles-mêmes décrire de telles structures.

Je n'implique nullement que l'approche ci-dessus en particulier fonctionnerait, et l'idée n'est pas qu'un DAG doit être ce qui est réellement gardé en mémoire (il forme plutôt quelque chose qui s'apparente à un formalisme informatique tel qu'un calcul lambda), mais j'espère que cela illustre le type d'approche qui m'intéresse.

En bref, je suppose qu'un titre alternatif à cette question aurait pu être: Comment Dijkstra aurait-il écrit des jeux informatiques?

Une note rapide sur le récit et les règles du jeu: dans la fiction interactive, on peut affirmer que le jeu est celui de traverser un graphique de récit ramifié, mais finalement le récit vit en dehors de la mécanique du jeu - vous pouvez remplacer tous les mots par quelque chose d'illisible et Pourtant, les étapes pour terminer le jeu (ou pour perdre en le jouant) seraient exactement les mêmes. Cela implique à son tour que le récit n'est pas pertinent pour le gameplay, sauf lorsqu'un développeur choisit de changer l'un pour l'adapter à l'autre. Dans les jeux, le récit est essentiellement une façade sur la mécanique qui peut rendre la mécanique plus convaincante pour un joueur qui aime ce récit, mais c'est tout. Il y a des jeux (bien que certains ne les appellent pas des jeux) où le récit est la principale forme de divertissement et les mécanismes de jeu sont principalement superficiels,Chère Esther , mais les développeurs n'ont pas besoin d'une méthode formelle pour raconter des histoires plus que les écrivains de fiction, donc je ne considérerai pas la narration plus loin. De manière générale, tout jeu qui ressemble à un «récit jouable» est un arbre ou un graphique d'événements de jeu qui peuvent exister et être discutés de manière significative sans le récit du tout.

J'ai remarqué que tous les moteurs / frameworks de jeu que j'ai examinés semblaient être quelque chose comme un moteur graphique glorifié dans le sens où ils parlent de formes / entités dans un espace euclidien à deux ou trois dimensions [...]

Oui, la plupart des "moteurs de jeux" sont évidemment des "moteurs de jeux vidéo", et leur principale responsabilité au fil du temps a été de faciliter le côté génie logiciel d'un jeu vidéo, pas le côté jeu. On peut dire que cela a du sens parce que c'est l'ingénierie logicielle qui est l'aspect le plus récent et le plus cher et donc le plus risqué. En comparaison, la conception de jeux dans un sens abstrait a été faite à la main pendant des milliers d'années sans l'aide d'outils, ce qui peut expliquer dans une certaine mesure pourquoi cela continue d'être le cas.

Quelles tentatives ont été faites pour créer des moteurs / cadres qui prennent comme base principale des notions telles que la description (de haut niveau) des règles / logique du jeu ou de la narration (ou du moins un aspect non spatial du jeu)?

Il y a eu peu de tentatives sérieuses, aucune réussie, pour autant que je sache.

Storytron en est un. "Contrairement à la fiction interactive traditionnelle, un Storyworld est plus concerné par la modélisation des actions et réactions des acteurs et de leurs émotions et inclinations plutôt que par la géographie du monde du jeu ou les objets banals qui le peuplent." Il fait suite à un effort précédent appelé Erasmatron, qui n'a pas vraiment réussi, et Storytron ne semble pas vraiment réussir non plus. L'article suivant est une bonne lecture à ce sujet: Chasing the Dragon

À un niveau moins ambitieux, il y a beaucoup de gens qui ont trouvé des façons simples de représenter des jeux simples. Un article parmi tant d'autres est le suivant: Multijeu - Un langage de très haut niveau pour décrire les jeux de société (le lien est derrière une connexion, mais vous pouvez peut-être le rechercher) mais tout ce que vous avez à la fin est un ensemble de états, transitions d'état et conditions de victoire ou fonctions de tenue de score - parfait pour les jeux de société discrets comme les échecs ou les jeux de cartes comme le poker, mais ils ne se généralisent pas aux jeux avec de grandes quantités d'état continu ou à ceux avec une sémantique qui sont plus comme des simulations (par exemple, des jeux de tir) ou des sports (par exemple, des jeux de course). De tels jeux ne peuvent pas être représentés de manière adéquate via un simple arbre d'états de jeu.

Une façon d'approcher la compréhension de ces systèmes plus complexes est d'essayer de classer chaque mécanicien existant dans l'une des formes de base, puis de déterminer comment les formes de base peuvent être combinées pour former un gameplay plus complexe, en supposant que tout le gameplay peut être composé de ces unités fondamentales ou de leurs combinaisons. Dan Cook a un article intitulé " Que sont les mécanismes de jeu ?" et un suivi " The Chemistry of Game Design"qui tentent de documenter cette approche compositionnelle de la conception de jeux. En théorie, il pourrait être possible de construire un système déclaratif en plus de cela, mais dans la pratique, la mécanique ne forme qu'une petite partie du jeu et donc la sortie résultante serait vraisemblablement limitée dans un cadre de présentation qui ne serait pas assez flexible pour capter l'attention de la plupart des joueurs.

D'autres tentatives de formalisation des concepts de conception de jeux sont souvent appelées «grammaire du jeu» - un de ces articles est appelé « Atomes de jeu multijoueurs » mais cela renvoie à divers travaux antérieurs.

Imaginons que nous voulions créer des aventures de style pointer-cliquer (pensez aux jeux SCUMM). [...] on pourrait choisir la théorie des DAG (bornés) comme théorie de base. [...] Il faut d'abord des outils de transformation / raisonnement sur les DAG ou les graphes en général. Deuxièmement, une bibliothèque d'interface utilisateur suffisamment intelligente pour aider à vérifier que notre représentation de notre graphique en tant que jeu jouable modélise réellement le graphique (ainsi, par exemple, au moins partiellement / de manière informelle, prouvant que le jeu n'a pas d'états bloqués, en raison de la condition de délimitation) . Enfin, une collection de bibliothèques de niveau supérieur pour spécifier le graphique pourrait être donnée; comme une bibliothèque pour exprimer des personnages et leur interaction et générer des (parties de) graphiques en termes de tels.

Le problème ici est que l'ordinateur n'ajoute pas grand-chose au processus. Les concepteurs de jeux comme celui-ci élaborent souvent exactement cela, un graphique sous forme numérique ou physique, qui montre le déroulement du jeu. Il est trivial de voir si le jeu peut théoriquement être terminé ou non. Même l'encodage des différentes règles pour progresser dans une aventure pointer-cliquer est trivial. La partie difficile consiste à lui faire suivre un récit intéressant, à le placer dans un monde fascinant, à créer les ressources artistiques et sonores pour représenter correctement le jeu et l'interface, ainsi que les diverses tâches d'ingénierie logicielle qui les maintiennent ensemble. Le graphique dirigé des états significatifs à travers le jeu est généralement relativement trivial; c'est tout ce qui l'entoure qui est le problème. Et c'est pourquoi ça ne l'intéresse pas beaucoup,

Personnellement, je travaille actuellement avec une équipe sur un produit appelé Storybricksqui tente de permettre la construction d'un gameplay intéressant en spécifiant diverses règles, et ces règles peuvent indiquer l'état initial d'une personne, ses besoins, etc. Il est facile de prendre ces règles et de vérifier si les besoins d'une personne peuvent être satisfaits, et si oui, comment, et donc de créer de manière déclarative des tâches qui doivent être accomplies dans le jeu. Cependant, cela ne crée pas en soi un gameplay intéressant, car une fois que vous avez résumé les choses au niveau de "X a besoin de Y - récupérez-le pour eux", les joueurs commencent à repérer le modèle et cessent de l'apprécier. (Par exemple: les gens se sont lassés rapidement des quêtes auto-générées dans Skyrim, car ils pouvaient voir qu'il n'y avait pas de sens inhérent à une mission générée par la procédure, par rapport à celles conçues par le designer. Notre travail consistera donc à utiliser des méthodes d'IA pour rendre ces situations plus intéressantes, et c'est quelque chose sur lequel nous travaillons toujours. (Storybricks est encore à un stade alpha très précoce). Mais nos recherches indiquent que peu de gens tentent quelque chose comme ça, et que c'est un problème très difficile.

Un autre problème avec l'approche déclarative est qu'elle n'est pas très utilisable. Les scientifiques l'apprécient car il est facile à traiter, par exemple pour prouver qu'une situation est résoluble ou qu'un ensemble de règles logiques sont cohérentes. Mais dans le monde réel, ni les programmeurs de jeux informatiques ni les utilisateurs finaux ne sont généralement aussi à l'aise avec une représentation déclarative qui se concentre sur les résultats qu'ils le sont avec une représentation impérative qui leur dit comment agir pour que les résultats se produisent. Les 10 principaux langages de programmation actuels sont tous impératifs , et les instructions du monde réel sont également généralement sous forme impérative, que ce soit la façon de cuire un gâteau ou de construire des meubles. Ce manque d'enthousiasme de part et d'autre du spectre signifie qu'il n'y a aucune incitation commerciale à produire des spécifications formelles pour les jeux modernes, et cela ne devrait pas changer dans un avenir proche.

Je réfléchis à la façon de répondre depuis un certain temps, et je ne sais pas trop comment le dire.

C'est une bonne question. Malheureusement, la réponse se résume à ce que cela n'a aucun sens de programmer quoi que ce soit et encore moins un moteur de jeu de cette façon, ou que c'est déjà ainsi que les choses sont.

Il semble que l'accent soit mis sur les graphiques, car il doit exister un moyen de définir l'existence physique des objets. C'est un peu là où les choses commencent à devenir existentielles parce que ce dont nous parlons vraiment est une représentation de la dimension, mais ignorons cela pour l'instant. Le point principal est, c'est quelque chose qui est vraiment très impliqué. Permettre la représentation de l'espace va être quelque chose qui absorbe intrinsèquement une grande partie de la programmation d'un moteur de jeu. Et si les concepteurs veulent créer de belles scènes, ils auront besoin de beaucoup de contrôle sur la façon dont les choses sont placées. Vous allez donc voir beaucoup de choses sur les graphiques.

C'est donc le côté bas des choses. Il faut que quelqu'un réfléchisse beaucoup à tous ces petits problèmes techniques.

En ce qui concerne les règles narratives et de jeu? C'est hors de portée de ce qu'un moteur de jeu est censé faire. C'est la partie où le groupe de développement intervient.

De plus, ce n'est pas comme si on n'avait pas beaucoup réfléchi à la façon de représenter les idées à travers la programmation. C'est vraiment ce que l'histoire de l'informatique est . Et, c'est pourquoi les moteurs de jeux ont souvent des interfaces vers des langages de haut niveau. Il est plus facile de représenter des pensées à travers eux.

Donc, dans cet esprit, un langage pourrait-il être créé spécifiquement pour les jeux avec une emphase narrative? Je dirais probablement que non. Encore une fois, tout se résume à la représentation. La langue doit pouvoir décrire des détails de telle manière que l'ordinateur sache quoi en faire. Si le but est de créer un langage spécifique à la création de jeux, toutes les décisions de conception doivent être centrées sur cela.

Et encore une fois, il y a beaucoup de choix de langues tels quels. Et plus de personnes que celles de l'industrie des jeux les ont développées. Il est généralement logique d'utiliser l'un d'entre eux.

En résumé, vous avez posé une question intéressante, mais très difficile. Et je ne suis pas tout à fait sûr de ce que c'est, ou si j'ai vraiment répondu.

* edit: Avec le recul, je me rends compte que je ne considérais que les moteurs de jeux 3D, comme s'ils étaient les seuls qui existent. Dans certains jeux, aucune personne n'agit dans un espace physique. Bien que dans de tels cas, je ne suis pas sûr qu'un moteur de jeu y contribuerait beaucoup.

Au début de l'histoire de l'informatique de loisir (c'est-à-dire les années 80), il y avait des kits de développement de jeux commerciaux disponibles pour les jeux texte et sprite. Les sprites étaient très similaires aux "moteurs graphiques" actuels.

L'autre type comprenait des choses comme les analyseurs en langage naturel. Ce type semble vivre dans les "éditeurs de niveau" modernes. La plupart d'entre eux semblent inclure la prise en charge de quelque chose comme les scripts Lua ou Python. Je voudrais également noter que je ne vois pas beaucoup d'activité dans l'édition de niveau open source, mais c'est parce que ces choses sont généralement très étroitement liées aux spécificités du jeu en question. Je pense ici à quelque chose comme les ensembles de construction Elder Scrolls.

Le Kinect peut ramener l'analyseur. En tant que fan de l'ancien jeu d'aventure basé sur du texte, je suis également enthousiasmé par la direction de Bethesda. C'est certainement propriétaire, mais peut-être un jeune génie ...