# Avoiding impossible states in an adventure game

I'm looking at creating a fairly complex choose-your-own adventure style of game, but I'm looking for a technique or method to help with the game design.

It will be a multi-branching story, and at times the branches will fold back in on themselves, and your major actions will be remembered and items will be collected. For example, if the player goes to the swamp and the forest before going to the castle he has picked up a dinosaur bone, killed a unicorn and grown an extra arm. If a player gets to the castle via the caves and the crypt he has picked up a bicycle and a strange smell. Now when developing puzzles for the castle I don't want to create a situation where two impossibilities are requires, for example - an extra arm and the smell are needed to kill an ogre.

Other than documenting the events and items very very carefully is there a process, a technique I can use in a spreadsheet or a piece of software that can help me?

-

## 2 Answers

Sounds kind of like a directed graph problem.

Start at the beginning, for each branching in the story record the items you currently have and then branch the graph. From there follow each branch and do the same, once you get to another branch record your current items and branch the graph. This will end up with a pretty dense graph with lots of duplicated nodes (but each node got there from a different graph sequence) but you should get no loops.

At the end you should have a graph of all the items you can have at any given point in your story and from all possible ways to get there.

Now, with your completed graph: for each of your problems that require items X+Y+Z find all the nodes that have that problem and see if the items recorded can satisfy that condition. If there's a failure simply walk back up the graph to find all the decisions that got you there without the proper items to solve that problem.

With any luck your original design is already laid out like this, at least conceptually, so the code should mirror reality and be easy to verify.

The processing time of the graph searches might get a bit heavy if you're building a large game, so build this like a utility that can take a while to run and outputs results into a report for you to use.

-
that means developing a tool. I let's put that a last resort. – Ali.S Jul 24 '11 at 16:29
The tool will either be your own brains, record keeping and memory capacity or it will be something automated that won't get tired and miss a glitch =) I guess it depends on how big your game is going to be and whether you'll ever build another from the same engine, to decide whether the time spent is worth it or not. – Patrick Hughes Jul 24 '11 at 17:00
The best way to do this may be to build a dependency tree from the top down (go backwards), and if two items in the tree share the same dependency (and the dependency requires a choice between them), then you have a violation. – dcousens Jul 25 '11 at 6:03

this may seem an odd answer but you can easily check for impossible events using compilers (for example c++)! let me explain how: you have exactly one header file for every stage. and game ends in `main.cpp` file. whenever you can go from `stage a` to `stage b`, you just have to include file relate to `stage a` in `stage b`. whenever you get a new item in a stage you just define a value for that item. whenever you lost or use an item you just have to undef it. in the end in each stage you just have to use all the defined values for the items needed in that stage. here is a sample how to use this in code :

a.h

``````#define itemA
``````

b.h

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

c.h

``````#include <a.h>

itemA;

#include <b.h>

itemB;
``````

main.cpp

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

although it may need some changes before really used but i guess you can create some code like this. you can also use inheritance and use classes for each stage instead of the approach i suggested. other than these i think you have to develop a tool yourself.

-
it's a real misuse of compiler! – Ali.S Jul 24 '11 at 15:23
It's interesting but it would be quite brittle and only work if I had a class per object/event/section in my story. I was going for more of a data driven approach, reading from xml or something. Thanks for your suggestion though. – DanDan Jul 24 '11 at 15:38
Not such a good idea to force a recompile every time a quest changes, plus this wouldn't allow data updates to the end users (DLC for example), or if run from a server and applying fixes without forcing downloads. – Patrick Hughes Jul 24 '11 at 16:04
that code sample is not any thing related to the code that is going to release, and that code doesn't really do any thing. it's just checking if your storyline and quests are valid or not. (if they are not you just get a compile error, otherwise you can implement that quest tree in your game! – Ali.S Jul 24 '11 at 16:28
Oh I see, I misinterpreted. I suspect that a person could spend more time ensuring that this code reflects the actual data than would be saved debugging quest logic errors, that's a judgement call the game author has to make. – Patrick Hughes Jul 24 '11 at 17:03