programmation d'événement histoire de jeu

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.

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.

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

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.

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.