What are the code structures for storyline based game?

Question

I am curious about how storyline-based games are written.

For example: if the character done Event A, then he meets an NPC and result in Event B.

On the other hand: if the character didn't do Event A, then he meets an NPC and result in Event C.

From the code structure that I've thought up, the NPC should be an object of a class, and there should be a status variable that mark if character have done Event A or not. However, what if there's thousand of similar type of Event as Event A? How'd I handle huge, complex storyline game in coding?

I just want to know exactly how the trick was done to keep in check of what Events have happened.

Another thing that I'm curious about is how Event is kept in. An object? or just a function?

For example: Event A might have some flashy effect played in non-fmv ,while maybe Event B is an fmv, and Event C might be a battle.

and there may be variety of them. Therefore, how would I handle variety of Events with a consistence method? or maybe, at the very least, contain them in a consistence way (function? or Object?) I just want to know how the trick was done.

Answer 1

Your question is very similar to mine and I think the answers here may help you understand.

Basically you use game states and have the npc run a switch on the current state.

Answer 2

In the past I used bit fields to keep track of quests/events which a player had experienced. I then had the (ie) NPC do a check against the player's set of acquired flags and respond accordingly.

One advantage is that you can encode a tremendous amount of flags in a small structure. Another was that multiple, independent story lines could be encoded in a few separate variables.

One disadvantage was that I was only able to encode pass/fail style results.

http://www.nwnlexicon.com/compiled/primer.bitwiseoperators.html talks about this exact sort of thing and might be helpful. The logic of story line direction is then controlled by the events on locations/characters.

I really like the idea of a directed graph, but, I don't really think it's needed beyond a planning tool.

Answer 3

You likely will want to model this as a directed acyclic graph (or DAG), a logical, traversable structure consisting of nodes representing your story events or points at which the story branches.

Pros:

• You have the perfect structure with which to model complexity and branching. In fact, a tree is just a special type of graph, but while a tree might work for your game, a graph will be better as it will allow you to come to "nexus" points in your story (eg. the end of a chapter) where all prior story branches come together, and a new set of choices begin.
• A graph is easy to visualise on paper or in your head. Simply construct your story as a branching/remerging sequence of nodes.
• There are many useful algorithms for graphs, allowing you to do many cool (but advanced) things with your story graph.
• Using a DAG, as long as you mark a node as traversed each time you finish the relevant part of the story, you will not be able to go back to an earlier point in the story.

Cons:

• You'll need to figure out how to use graphs.
• You'll need to get yourself a suitable graph library like JGraphT, Boost, or LEDA depending on what is available for your language (Java and C++ are the traditional "academic's languages" so most of the good ones will be found in these) or write your own simple implementation.

PS. I refer above to graph algorithm libraries, not graph drawing / "graphing" libraries. The former provide an abstract way of constructing a topology (which is what you want) vs the former which provide different ways to draw you graph -- which may prove useful for your own visualisation but is not going to help your game to traverse its story as the player progresses.

PPS. It is possible to use a directed cyclic graph, meaning your player could go around in "story circles", this is how the "choose your own adventure" books sometimes work. But it's probably not the most desirable way.