I have developed a game engine in c/c++ and DirectX.

I have a tile engine for the maps, animated player/npc sprites, talking to the npc, menus, and level changing but there is no game, it just feels empty.

I have looked around and keep hearing buzzword answers but I want to know how to implement a story in my game.

Some people have said a save file that holds flags governing every possible action/state available in the game but this sounds ludicrous.

It is a bit ambitious but I am aiming to get a game like the older Pokemon/Final Fantasy games.

Does any one know how these games work or the theory used?

I have been looking for a while and would really appreciate any input people have.


4 Answers 4


Your game's story should probably be in the form of a finite state automaton (or some kind of extended FSA). When certain events happen, you should move to a new state. This way you only ever have to store the current state and whatever information is needed to know where to move next in the FSA (along with player details like position, health, etc.).

For example, if we absolutely oversimplify the Pokemon games, the gym badges form the main branch of the FSA. You start in state 0 where you have no badges and as you beat the gym leaders you move through the states, to state 1, to state 2, etc. To get your game entities to update to the current state, you only need to get them to look at the current state. For example, an NPC outside the 3rd gym would check which state you are in, see you are in the state corresponding to having 3 badges, and respond accordingly (perhaps with a "Well done!").

You don't need to store the state of everything in the world; just the state of the story. The entities themselves know how to react depending on the current state.

  • \$\begingroup\$ interesting approach and i like it will have to try it out but how would you track side quests that are not dependant on on the story progression? \$\endgroup\$
    – Skeith
    Commented Apr 1, 2011 at 14:54
  • \$\begingroup\$ It really depends on how complex your story gets. It may be easiest to have multiple FSAs (one for each substory) or you might need some complex branching. You need to sit down and draw out your story as a roadmap. When you understand how everything intertwines, think about how you could store the current state (or states if it can be in more than one at once). Some things will need to be stored separately, such as the positions of NPCs (if you need them to be saved) and the health of certain characters, because these are not dependent on the story. \$\endgroup\$
    – sftrabbit
    Commented Apr 1, 2011 at 15:02
  • \$\begingroup\$ this FSA you talk about, where would i find an explanation of this, preferably simplified and without other theories intertwined. \$\endgroup\$
    – Skeith
    Commented Apr 1, 2011 at 15:38
  • \$\begingroup\$ You can learn all about state machines all over the place but 99.9% of the time it won't be talking about games. An introductory book on computation will teach you about them but you really don't need that much detail. You just need to understand the concept of being in states and moving between them when certain events happen. @pwny's response is really just saying the same thing in a different way. Reading about FSAs will be a great way to learn the concepts of state machines though. Just Google for an introduction to state machines! \$\endgroup\$ Commented Apr 1, 2011 at 20:10

You could use a set of possible states your game is in. Your NPCs and your world would be aware of those states and react/display accordingly. You might also want to define a set of triggers that would be activated by some actions/events.

For example, beating a certain opponent would activate trigger A, which would add state S to your world and in state S your character gets electrocuted when it walks out of its opponents lair. Or it's raining outside. Or you find a rare candy. You get the point.

With those two simple additions to your game, you could make it be a lot more "alive".

Make sure you also create a rich background for your world, characters and storyline and make sure the game is consistent to that background. Plan your story first.

Also try Gamedev

  • \$\begingroup\$ that is possible but i am sure that professionals have a better was as what you sujest entails hundreds of thousands of booleans and ints (i have tried it). i just don't see it as a realistic approach to a large scale game. thanks for the link \$\endgroup\$
    – Skeith
    Commented Apr 1, 2011 at 14:33
  • \$\begingroup\$ Not necessarily, imagine 5 independent superposable states. You get 32 possible branches for 5 booleans. I think that's reasonable. Also, trigger systems are used in a lot professional games, especially because you can then script behavior using series of triggers. \$\endgroup\$
    – anthonyvd
    Commented Apr 1, 2011 at 14:40

As sftrabbit mentioned, this is a perfect application for a state machine.

Essentially, you have a sort of tree structure. Each leaf/node contains information about the current state, and rules for progressing to the next state. Each node may contain multiple exits, depending on how complex you need your plot/play flow to be.

A good, very loose analog to this is a Choose Your Own Adventure book. Each page contains some text describing part of the story, and decisions that the player can make. Each decision leads to another page. Some pages may link back to previously-visited pages, etc.

The old text-based adventure games like Zork and Leather Goddesses of Phobos, and the infamous Sierra *Quest games (SpaceQuest starring Roger Wilco the space janitor is one of my favorites) used a very simple version of this type of system. Each room in a map was a state, with exits that linked to other states or rooms. Acquiring an item set a flag in a global state object. Each room would check those flags to determine which characters or items were available in each room.

So, your states may be implemented as a class or struct, each with properties for:

Asset list - list of pointers to background graphics and anything else that you need to display the room/state/level.

Entry conditions - achievements that must already have been reached to enter a level

Exits - links to each possible "next" exit. North,South,East and West are some examples of this, but you may also include Door1, Teleport, etc. When attempting to exit a room, or determining of an exit/door is "open", your game could check the next state to see if its entry conditions have been met, and alter the way the exit is displayed on the screen, or just not allow the player to move in that direction.

If you want to get fancy, you could include a different version of a state with different entry conditions, which would alter the way that the room is presented to the player, or the actions that are available in that room.

Your start screen, death/game over screen, etc could all be states within the system, similar to the way in which you might navigate between menu screens. In fact, if you have such a menu system in place, you could use it for this. Instead of up/down arrows and "enter" to navigate a menu, you would look for specific events within the game play area, such as stepping on a teleport pad, walking off of the right side of the screen, etc.

From an admin point of view, consider whether or not you could benefit from creating an admin tool that would allow you to create the state machine. Add rooms to a map, create links between them, assign assets like background images, etc. This is probably overkill for your first attempt; it's too easy to get absorbed in building admin tools, and never actually finish the game. Remember - you're not writing middleware, but a game.

Hope this helps.

  • \$\begingroup\$ fot this example imagne a town. i have a file which holds the tile layout as well as the graphic and size, lists of npc and general stuff like that. by adding a file a new town cam be added to the game allowing others to contribute or so was the plan but the file is becoming somewhat full and complex. if i understand you i would put the events that can take place in said town in this file with flags to track progress? \$\endgroup\$
    – Skeith
    Commented Apr 1, 2011 at 16:12
  • \$\begingroup\$ @Skeith yes, that sounds like a reasonable approach. \$\endgroup\$
    – 3Dave
    Commented Apr 1, 2011 at 18:29

I used to use this game engine called VERGE. Play around with that and see how it handles events, I really like it. It's open source too, so you can see how they implement it, here. Here's a brief description.

Each map has a variety of layers. The graphical layers, of which there may be several. The obstruction layer. And then there is the zone layer. The zone layer is what's important here.*

Each tile has a number to indicate which zone it is part of. Each zone can be activated in one two basic ways. Either the zone is activated upon the player entering it, or it has what's called adjacent activation. Adjacent activation means that when the player is standing adjacent to one of the zone's tiles and presses some key specified as the activation key, the zone is activated.

What happens when a zone is activated is it calls a function from a script. So you need to embed some kind of scripting language. VERGE has it's own language called VergeC, and it also allows lua. I myself prefer to use python.

Once you've gotten over this hurdle, you now have tremendous power in your event scripting. You have a full fledged programming language in which you can store and act on data like player stats, story flags, etc...

*There is also an Entity layer. Entities act like mobile adjacent activated zones.

  • \$\begingroup\$ that sounds like the sort of system the is used in the rpg game maker series. but what if that tile has 5 different events based on how far through the story you are? \$\endgroup\$
    – Skeith
    Commented Apr 1, 2011 at 15:38
  • \$\begingroup\$ @Skeith It can't. Each tile only has one zone associated with it. And each zone only has one script function that it calls. That's not a problem though. Remember, you have a fully fledged programming language here. Information about how far through the story you are would be stored in a variable(or several). So deciding what to do is a simple matter of testing that variable in the script, and taking the appropriate action based on it's value. \$\endgroup\$ Commented Apr 1, 2011 at 15:42
  • \$\begingroup\$ @Skeith: Although you might add the option of changing which zone a tile belongs to. \$\endgroup\$ Commented Apr 1, 2011 at 15:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .