programmation d'événement histoire de jeu

28

J'ai développé un moteur de jeu en c / c ++ et DirectX.

J'ai un moteur de tuiles pour les cartes, les sprites animés joueur / npc, parler au npc, les menus et le changement de niveau mais il n'y a pas de jeu, il semble juste vide.

J'ai regardé autour de moi et j'entends toujours les réponses des mots à la mode, mais je veux savoir comment mettre en œuvre une histoire dans mon jeu.

Certaines personnes ont dit qu'un fichier de sauvegarde contenant des drapeaux régissant chaque action / état possible disponible dans le jeu, mais cela semble ridicule.

C'est un peu ambitieux mais je vise à obtenir un jeu comme les anciens jeux Pokemon / Final Fantasy.

Est-ce que quelqu'un sait comment ces jeux fonctionnent ou la théorie utilisée?

Je cherche depuis un certain temps et j'apprécierais vraiment toute contribution des gens.

Skeith
la source

Réponses:

19

L'histoire de votre jeu devrait probablement prendre la forme d'un automate à états finis (ou d'une sorte de FSA étendu). Lorsque certains événements se produisent, vous devez passer à un nouvel état. De cette façon, vous n'avez qu'à stocker l'état actuel et toutes les informations nécessaires pour savoir où aller ensuite dans la FSA (avec les détails du joueur comme la position, la santé, etc.).

Par exemple, si nous simplifions absolument les jeux Pokémon, les badges de gym constituent la branche principale de la FSA. Vous commencez dans l'état 0 où vous n'avez pas de badges et lorsque vous battez les leaders du gymnase, vous vous déplacez à travers les états, à l'état 1, à l'état 2, etc. Pour que vos entités de jeu se mettent à jour à l'état actuel, il vous suffit d'obtenir qu'ils regardent l'état actuel. Par exemple, un PNJ en dehors de la 3e salle de gym vérifierait dans quel état vous vous trouvez, voyez que vous êtes dans l'état correspondant à 3 badges et répondra en conséquence (peut-être avec un "Bien joué!").

Vous n'avez pas besoin de stocker l'état de tout dans le monde; juste l'état de l'histoire. Les entités elles-mêmes savent réagir en fonction de l'état actuel.

Joseph Mansfield
la source
approche intéressante et j'aime qu'il faudra l'essayer, mais comment suivriez-vous les quêtes secondaires qui ne dépendent pas de la progression de l'histoire?
Cela dépend vraiment de la complexité de votre histoire. Il peut être plus facile d'avoir plusieurs FSA (un pour chaque sous-étage) ou vous pourriez avoir besoin de branchements complexes. Vous devez vous asseoir et dessiner votre histoire comme une feuille de route. Lorsque vous comprenez comment tout s'entrelace, réfléchissez à la façon dont vous pouvez stocker l'état actuel (ou indiquer s'il peut être dans plusieurs états à la fois). Certaines choses devront être stockées séparément, telles que les positions des PNJ (si vous avez besoin qu'elles soient enregistrées) et la santé de certains personnages, car elles ne dépendent pas de l'histoire.
cette FSA dont vous parlez, où pourrais-je trouver une explication à cela, de préférence simplifiée et sans autres théories entrelacées.
Skeith
Vous pouvez tout savoir sur les machines à états partout mais 99,9% du temps, il ne parlera pas de jeux. Un livre d'introduction sur le calcul vous en apprendra plus mais vous n'avez vraiment pas besoin de beaucoup de détails. Vous avez juste besoin de comprendre le concept d'être dans des états et de vous déplacer entre eux lorsque certains événements se produisent. La réponse de @ pwny est simplement de dire la même chose d'une manière différente. La lecture des FSA sera cependant un excellent moyen d'apprendre les concepts des machines à états. Juste Google pour une introduction aux machines d'état!
Joseph Mansfield
7

Vous pouvez utiliser un ensemble d'états possibles dans lesquels se trouve votre jeu. Vos PNJ et votre monde seraient au courant de ces états et réagiraient / s'afficheraient en conséquence. Vous pouvez également définir un ensemble de déclencheurs qui seraient activés par certaines actions / événements.

Par exemple, battre un certain adversaire activerait le déclencheur A, ce qui ajouterait l'état S à votre monde et dans l'état S votre personnage est électrocuté lorsqu'il sort de l'antre de son adversaire. Ou il pleut dehors. Ou vous trouvez un bonbon rare. Tu obtiens le point.

Avec ces deux ajouts simples à votre jeu, vous pourriez le rendre beaucoup plus "vivant".

Assurez-vous de créer également un arrière-plan riche pour votre monde, vos personnages et votre scénario et assurez-vous que le jeu est cohérent avec cet arrière-plan. Planifiez d'abord votre histoire.

Essayez également Gamedev

pwny
la source
c'est possible, mais je suis sûr que les professionnels ont un meilleur, car ce que vous suggérez implique des centaines de milliers de booléens et d'ts (je l'ai essayé). Je ne le vois tout simplement pas comme une approche réaliste d'un jeu à grande échelle. merci pour le lien
Pas nécessairement, imaginez 5 états superposables indépendants. Vous obtenez 32 branches possibles pour 5 booléens. Je pense que c'est raisonnable. De plus, les systèmes de déclenchement sont utilisés dans de nombreux jeux professionnels, en particulier parce que vous pouvez ensuite modifier le comportement du script à l'aide d'une série de déclencheurs.
pwny
2

Comme l'a mentionné sftrabbit, il s'agit d'une application parfaite pour une machine d'état.

Essentiellement, vous avez une sorte de structure arborescente. Chaque feuille / nœud contient des informations sur l'état actuel et des règles pour passer à l'état suivant. Chaque nœud peut contenir plusieurs sorties, selon la complexité dont vous avez besoin pour votre intrigue / flux de lecture.

Un bon analogue très lâche à ceci est un livre Choisissez votre propre aventure . Chaque page contient du texte décrivant une partie de l'histoire et les décisions que le joueur peut prendre. Chaque décision mène à une autre page. Certaines pages peuvent renvoyer vers des pages précédemment visitées, etc.

Les vieux jeux d'aventure textuels comme Zork et Leather Goddesses of Phobos , et les fameux jeux Sierra * Quest ( SpaceQuest avec Roger Wilco, le concierge de l'espace est l'un de mes favoris ) utilisaient une version très simple de ce type de système. Chaque pièce sur une carte était un état, avec des sorties liées à d'autres états ou pièces. L'acquisition d'un élément définit un indicateur dans un objet d'état global. Chaque pièce vérifierait ces drapeaux pour déterminer quels personnages ou objets étaient disponibles dans chaque pièce.

Ainsi, vos états peuvent être implémentés en tant que classe ou structure, chacun avec des propriétés pour:

Liste des ressources - liste des pointeurs vers les graphiques d'arrière-plan et tout ce dont vous avez besoin pour afficher la pièce / l'état / le niveau.

Conditions d'entrée - réalisations qui doivent déjà avoir été atteintes pour accéder à un niveau

Sorties - liens vers chaque sortie "suivante" possible. Le nord, le sud, l'est et l'ouest en sont quelques exemples, mais vous pouvez également inclure Door1, Teleport, etc. Lorsque vous tentez de quitter une pièce ou que la détermination d'une sortie / porte est "ouverte", votre jeu peut vérifier l'état suivant pour voir si ses conditions d'entrée sont remplies et modifier la façon dont la sortie est affichée à l'écran, ou tout simplement ne pas permettre au joueur de se déplacer dans cette direction.

Si vous voulez avoir de la fantaisie, vous pouvez inclure une version différente d'un état avec différentes conditions d'entrée, ce qui modifierait la façon dont la salle est présentée au joueur, ou les actions disponibles dans cette salle.

Votre écran de démarrage, mort / sur-écran, etc. peuvent tous être des états du système, similaires à la manière dont vous pouvez naviguer entre les écrans de menu. En fait, si vous disposez d'un tel système de menus, vous pouvez l'utiliser pour cela. Au lieu de flèches haut / bas et «entrer» pour naviguer dans un menu, vous rechercheriez des événements spécifiques dans la zone de jeu, comme marcher sur un pavé de téléportation, marcher du côté droit de l'écran, etc.

D'un point de vue administrateur, demandez-vous si vous pourriez ou non bénéficier de la création d'un outil d'administration qui vous permettrait de créer la machine d'état. Ajoutez des pièces à une carte, créez des liens entre elles, attribuez des ressources comme des images d'arrière-plan, etc. C'est probablement exagéré pour votre première tentative; il est trop facile d'être absorbé par la création d'outils d'administration et de ne jamais terminer le jeu. N'oubliez pas - vous n'écrivez pas de middleware, mais un jeu.

J'espère que cela t'aides.

3Dave
la source
pour cet exemple imagne une ville. j'ai un fichier qui contient la disposition des tuiles ainsi que le graphique et la taille, des listes de npc et des trucs généraux comme ça. en ajoutant un fichier, une nouvelle caméra de ville peut être ajoutée au jeu permettant aux autres de contribuer ou tel était le plan, mais le fichier devient un peu plein et complexe. si je vous comprends, je mettrais les événements qui peuvent avoir lieu dans ladite ville dans ce fichier avec des drapeaux pour suivre les progrès?
Skeith
@Skeith oui, cela ressemble à une approche raisonnable.
3Dave
0

J'ai utilisé ce moteur de jeu appelé VERGE . Jouez avec cela et voyez comment cela gère les événements, j'aime vraiment ça. Il est également open source, vous pouvez donc voir comment ils l'implémentent ici . Voici une brève description.

Chaque carte a une variété de couches. Les couches graphiques, dont il peut y en avoir plusieurs. La couche d'obstruction. Et puis il y a la couche de zone. La couche de zone est ce qui est important ici. *

Chaque tuile a un numéro pour indiquer de quelle zone elle fait partie. Chaque zone peut être activée de deux manières de base. Soit la zone est activée lorsque le joueur y entre, soit elle a ce qu'on appelle l'activation adjacente. L'activation adjacente signifie que lorsque le joueur se tient à côté d'une des tuiles de la zone et appuie sur une touche spécifiée comme clé d'activation, la zone est activée.

Ce qui se passe lorsqu'une zone est activée, c'est qu'elle appelle une fonction à partir d'un script. Vous devez donc intégrer une sorte de langage de script. VERGE a son propre langage appelé VergeC, et il permet également lua. Je préfère moi-même utiliser python.

Une fois que vous avez surmonté cet obstacle, vous disposez désormais d'un pouvoir énorme dans la création de scripts d'événement. Vous disposez d'un langage de programmation à part entière dans lequel vous pouvez stocker et agir sur des données telles que les statistiques des joueurs, les indicateurs d'histoire, etc.

* Il existe également une couche Entité. Les entités agissent comme des zones activées adjacentes mobiles.

Benjamin Lindley
la source
cela ressemble au type de système utilisé dans la série des jeux de rôle rpg. mais que se passe-t-il si cette tuile a 5 événements différents en fonction de votre parcours dans l'histoire?
Skeith
@Skeith Ça ne peut pas. Chaque tuile n'a qu'une seule zone qui lui est associée. Et chaque zone n'a qu'une seule fonction de script qu'elle appelle. Ce n'est pas un problème cependant. N'oubliez pas que vous disposez ici d'un langage de programmation à part entière. Les informations sur la distance parcourue dans l'histoire sont stockées dans une variable (ou plusieurs). Décider quoi faire est donc une simple question de tester cette variable dans le script et de prendre les mesures appropriées en fonction de sa valeur.
Benjamin Lindley
@Skeith: Bien que vous puissiez ajouter l'option de changer la zone à laquelle appartient une tuile.
Benjamin Lindley