Éviter les états impossibles dans un jeu d'aventure


15

Je cherche à créer un style de jeu d'aventure assez complexe, mais je recherche une technique ou une méthode pour aider à la conception du jeu.

Ce sera une histoire multi-branches, et parfois les branches se replieront sur elles-mêmes, et vos principales actions seront mémorisées et les objets seront collectés. Par exemple, si le joueur se rend dans le marais et la forêt avant d'aller au château, il a ramassé un os de dinosaure, tué une licorne et développé un bras supplémentaire. Si un joueur arrive au château via les grottes et la crypte, il a ramassé un vélo et une odeur étrange. Maintenant, lors du développement d'énigmes pour le château, je ne veux pas créer une situation où deux impossibilités sont nécessaires, par exemple - un bras supplémentaire et l'odeur sont nécessaires pour tuer un ogre.

À part documenter très soigneusement les événements et les éléments, y a-t-il un processus, une technique que je peux utiliser dans un tableur ou un logiciel qui peut m'aider?

Réponses:


11

Cela ressemble un peu à un problème de graphique dirigé.

Commencez au début, pour chaque branchement dans l'histoire, enregistrez les éléments que vous avez actuellement, puis branchez le graphique. De là, suivez chaque branche et faites de même, une fois dans une autre branche, enregistrez vos éléments actuels et branchez le graphique. Cela se terminera par un graphique assez dense avec beaucoup de nœuds dupliqués (mais chaque nœud est arrivé à partir d'une séquence graphique différente) mais vous ne devriez pas avoir de boucles.

À la fin, vous devriez avoir un graphique de tous les éléments que vous pouvez avoir à un moment donné de votre histoire et de toutes les façons possibles d'y arriver.

Maintenant, avec votre graphique terminé: pour chacun de vos problèmes qui nécessitent des éléments X + Y + Z, trouvez tous les nœuds qui ont ce problème et voyez si les éléments enregistrés peuvent satisfaire cette condition. S'il y a un échec, remontez simplement le graphique pour trouver toutes les décisions qui vous y ont mené sans les éléments appropriés pour résoudre ce problème.

Avec un peu de chance, votre conception originale est déjà présentée comme ça, au moins conceptuellement, donc le code devrait refléter la réalité et être facile à vérifier.

Le temps de traitement des recherches de graphiques peut devenir un peu lourd si vous construisez un grand jeu, alors construisez-le comme un utilitaire qui peut prendre un certain temps à s'exécuter et qui génère les résultats dans un rapport que vous pouvez utiliser.


cela signifie développer un outil. Je laisse cela en dernier recours.
Ali1S232

6
L'outil sera soit votre propre cerveau, la tenue de registres et la capacité de mémoire, soit ce sera quelque chose d'automatisé qui ne se fatiguera pas et ne manquera pas de problème =) Je suppose que cela dépend de la taille de votre jeu et de votre volonté jamais construire un autre à partir du même moteur, pour décider si le temps passé en vaut la peine ou non.
Patrick Hughes,

La meilleure façon de le faire peut être de créer un arbre de dépendance de haut en bas (revenir en arrière), et si deux éléments de l'arborescence partagent la même dépendance (et la dépendance nécessite un choix entre eux), alors vous avez une violation.
deceleratedcaviar

0

cela peut sembler une réponse étrange mais vous pouvez facilement vérifier les événements impossibles en utilisant des compilateurs (par exemple c ++)! laissez-moi vous expliquer comment: vous avez exactement un fichier d'en-tête pour chaque étape. et le jeu se termine dans un main.cppfichier. chaque fois que vous pouvez aller de stage aà stage b, il vous suffit d'inclure le fichier relatif à stage ain stage b. chaque fois que vous obtenez un nouvel élément dans une étape, vous définissez simplement une valeur pour cet élément. chaque fois que vous perdez ou utilisez un article, il vous suffit de le défaire. à la fin de chaque étape, il vous suffit d'utiliser toutes les valeurs définies pour les éléments nécessaires à cette étape. voici un exemple d'utilisation de ce code:

ah

#define itemA

bh

#include <a.h>
#undef itemA
#define itemB

ch

#include <a.h>

itemA;

#include <b.h>

itemB;

main.cpp

#include <c.h>
int main()
{
}

bien qu'il puisse avoir besoin de quelques changements avant d'être vraiment utilisé, mais je suppose que vous pouvez créer du code comme celui-ci. vous pouvez également utiliser l'héritage et utiliser des classes pour chaque étape au lieu de l'approche que j'ai suggérée. à part cela, je pense que vous devez développer vous-même un outil.


2
c'est une vraie mauvaise utilisation du compilateur!
Ali1S232

3
C'est intéressant mais ce serait assez fragile et ne fonctionnerait que si j'avais une classe par objet / événement / section dans mon histoire. J'allais plus d'une approche basée sur les données, la lecture de xml ou quelque chose. Merci pour votre suggestion.
DanDan

3
Ce n'est pas une bonne idée de forcer une recompilation à chaque fois qu'une quête change, et cela n'autoriserait pas les mises à jour des données pour les utilisateurs finaux (DLC par exemple), ou si exécuté à partir d'un serveur et appliquant des correctifs sans forcer les téléchargements.
Patrick Hughes

2
cet exemple de code n'est pas lié au code qui va sortir, et ce code ne fait vraiment rien. il s'agit simplement de vérifier si votre scénario et vos quêtes sont valides ou non. (si ce n'est pas le cas, vous obtenez simplement une erreur de compilation, sinon vous pouvez implémenter cet arbre de quête dans votre jeu!
Ali1S232

Oh je vois, j'ai mal interprété. Je soupçonne qu'une personne pourrait passer plus de temps à s'assurer que ce code reflète les données réelles que ne le seraient les erreurs de logique de quête de débogage, c'est un jugement que l'auteur du jeu doit faire.
Patrick Hughes
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.