Creating Your Game's Story - Event Plots

Game development specific discussions.
Pritchard
Posts: 5425
Joined: Sep 12, 2005 20:06
Location: Ohio, USA

Creating Your Game's Story - Event Plots

Postby Pritchard » Dec 31, 2007 16:56

Alright, so you have this great idea for a story for a game, but you just can't figure out how games like Final Fantasy manage to be so big, and have such a great, vast story, but also have so many inner or side stories. Where in the world did the writers add that information? Well, more often than not, there's a group of people assigned wholly and completely to side quests, most-likely with oversight from the original script writer. You're probably wondering how they manage to write up side quests in a way that fits will with main story, but doesn't require any extra work from the lead writer.

Game Stories are often unlike novels - They're a lot closer to what we would see as outlining a novel, but far more detailed in some areas. They're closer to Time Lines than anything else. I like to consider most game story structure a part of what I call "Event Plots". This is the organization and detailing of action and reactions, rather than a novelized and narrated step-by-step story, we break things down into events that may or may not occur in order to make it possible to simply attach new events at any given point in the story.

In an Event Plot, we can have any number of levels or 'ranks' for events, but the three that are most-often used as as follows: Major, Minor, and Side Events. They're really more of guidelines for how an events reactions should affect other events, rather than strict guidelines. You'll rarely write a 'pure' Event Plot that follows their definitions completely, in order to suit the way your story is organized. They're naturally flexible to a generous extent.


Major Events are events in your game that absolutely have to happen, and will have an effect over everything. This is going to be the most strict and restricted of the events in your game, but also the most vital. When you play through a game and make it to the final boss, that's almost always a Major event. Eventually, you have to fight the final boss, either that, or the final boss is the 'farthest' event that the story has to offer.

Major Events are important because they define your game. A novel's written in all Major Events, because none of those events ever change, and they're all important. Each paragraph will rely on the last, and ones which were written many pages before. It is defined that whenever you make vital changes to Major Events, allow the player to choose another Major event, or skip a Major event altogether, you have now split the game into two branches. From here, you have two completely different story lines, which are almost never going to intertwine.

If you're thinking that you should be able to make Major Events intertwine easily, then you may have misunderstood the definition or the idea - Major Events are a necessity in that time line. They have such a strong affect on not only events below their level of importance, but also upon future Major Events, you really are writing a completely different story for each major event that you change. These are the events that are almost never changed within a game, because this truth is so strong, and game development is just that much more difficult (often near impossible) when you change Major Events. Entire series of "What-If" comics are collaborated on heavily and released solely to ask the question, "What if this major event never occurred?".


Minor Events are generally the most exciting ones found in a game. While they never change the fact that a Major Event will occur, or what the reaction of the Major Event will generally be, Minor Events can change how other events will play out - But remember, they do in fact play out. A change in the script, a new part of the story (Minor or Side, generally), new optional characters being available - These are the kinds of things Minor Events will add to your game.

Minor Events take many forms. From collecting pieces of a puzzle and saving X amount of people depending on how many pieces you collected, to talking to as many people are possible in order to get one on your side, who may remain on your side until the end of the game - although no Major Events will ever depend on this fact, but may merely mention it in the course of its life time (which honestly, is closer to another Minor or Side Event within a Major Event).

For the most-part, you want to tie these as heavily as possible into Major Events, making it *feel* like Major Events have changed by adding new elements, changing the script, or whatever else you do without actually destroying or fully changing the Major Event. Contrary to what you would think, Side-Quests are not generally Side Events, but in fact Minor Events.


Side Events are events which the story line does not care about in any way whatsoever. While any events above the level of Side Event may change how the Side Event plays out, Side Events -have an extreme minimal or no story-related reaction-. The advantage to side events is that you can create them without having to worry about how you're going to adjust the rest of the story or other events based on how they occur. User-Reactions still may occur in Side Events though, but no direct story-related, or guaranteed consequences, may come from a Side Event.

Talking to a random civilian, reading signs, playing a mini-game, getting items from trunks, etc., etc., are generally Side Events. They're the things that 'hardcore' gamers will care about, or terrible gamers will seek help from. There's no effects on the story line from talking to them, although there may be game play effects from doing so on the user's end. In a sense, Side Events don't exist - Only your player will see them.


Putting It All Together:

We know how to use all of the most common event types now, so what do we do with them? Write out an Event Plot, just as the lead writer would - But only Major Events at the moment. Usually an Event Plot will have quite a larger number of items here, and you may personally wish to mark certain Major Events as "unimportant", which is to say that they can be changed or removed, as long as the game progresses to the next Major Event - otherwise the lead writer's story line would be broken and we'd have to split the game into two:

Code: Select all

Major Events Will Have No Tabbing
      
Hero awakens

Hero finds sword

Sword turns Hero into Savior, fulfilling a prophecy, but awakening a bad guy

Bad Guy fights Hero

Hero loses

Hero searches for bad guy

Hero fights bad guy again

Hero defeats bad guy

World is saved

Alright, that story's simple and lame, but it demonstrates the basics of plotting Major Events.

We are saying to any Minor Event writers: "These Events MUST happen. Whatever you do to my Major Events, MAKE SURE THESE HAPPEN!" - If they didn't listen, once again, they would send the paper back to the lead writer, he would look over everything, and he would split the story into two pieces from wherever they broke a Major Event, send it back to the Minor Event writers, and repeat the process if necessary. It should be noted that this never actually happens, as no one has the budget to do this in modern games.

Plotting Minor Events of course, isn't going to be as much story-related work as the Major Events are, but organizing Minor Events takes a little work, and honestly, it's sometimes tempting to write my own software to help me do these things. The main reason I haven't yet is because I'm not sure I could write a program to do this in an efficient amount of time. Here's what our outline will now look like with some Minor Events:

Code: Select all

Major Events Will Have No Tabbing
   [REQ - (reqkey):] Minor Events Will Be Tabbed Once [TRIGGERS - (reqkey)]
      
Hero awakens

Hero finds sword

Sword turns Hero into Savior, fulfilling a prophecy, but awakening a bad guy
   Old Man knows about the prophecy, begins to prepare the town for an attack from the bad guy if you talk to him TRIGGERS - (A)

Bad Guy fights Hero
   REQ - (A):  The traps which you and the Old Man had set up now activate, slowing down the bad guy.

Hero loses

Hero searches for bad guy
   Hero finds girl to help him on his search TRIGGERS - (B)

Hero fights bad guy again
   REQ - (B):  Girl joins in the fight against the bad guy with the hero.  Bad Guy makes note that the girl is his daughter.

Hero defeats bad guy

World is saved

Minor Events bring Flexibility into play, and optional events, so we designed a simple syntax to tell us that an event is either REQuired to run this Event, and if an event TRIGGERS another event. Game Triggers are pretty old, and I think that when we get down to actually coding things, a lot of us have stopped using triggers, but when it comes to writing, Triggers are a simple and easy form of event representation. It's not our job to think how this event will be implemented, that's up to the coders - We, are going to use triggers, thank you very much.

Side Events pretty much work the same way. Since Side Events have no TRIGGERS, we don't have to worry about giving them new syntax for that to make things easier to understand, but they may or may not have requirements, and they may have availability beyond the scope of the event they lie in. In fact, any events really could lie anywhere on the time line - The Minor Events we've written so far are all in relation with Major Events.

Generally, we don't need to note when an event can begin (that's what it's first written), but only when an event goes out of scope. However, if we want an event to remain in scope beyond the tabbing where we wrote it, rather than just its trigger living (meaning this event is available from now until we say it's unavailable), we need new syntax - LIVE and KILL seem to work well, but then we'll need new IDs in order to separate the event from its trigger (since any number of Minor Events can set a particular trigger).

Note that even those Side Events are tabbed twice, only the REQ tag is meant to imply that an event is required to occur before this one can begin - That is to say, any Minor Events above a Side Event are not necessarily triggers for that Side Event, as you would usually believe when you see tabbing.

While Minor Events AND Side Events both accept the LIVE(lifekey) syntax, minor events should only refer to themselves when LIVEing or KILLing an event, in order to remain closer to the definition of Side Events not having an affect on other events. An empty LIVE() will imply that an event never dies throughout the progression of the story, telling readers of the plot not to worry about this event at all, as it is always available now - Although abusing this can cause a very large list of always running events, which can annoy someone trying to take full advantage of this.

Code: Select all

Major Events Will Have No Tabbing
   [REQ - (reqkey):] Minor Events Will Be Tabbed Once [TRIGGERS - (reqkey)] [LIVE(lifekey)] [KILL(lifekey)]
      [REQ - (reqkey):] *Side Events Will Be Tabbed Twice and marked with a star [LIVE(self-lifekey)] [KILL(self-lifekey)]
      
Hero awakens
      *Hero can walk to the town, and talk to its citizens LIVE()

Hero finds sword
      *Hero can read about the sword on a glyph that's appeared

Sword turns Hero into Savior, fulfilling a prophecy, but awakening a bad guy
   Old Man knows about the prophecy, begins to prepare the town for an attack from the bad guy if you talk to him TRIGGERS - (A)

Bad Guy fights Hero
   REQ - (A):  The traps which you and the Old Man had set up now activate, slowing down the bad guy.

Hero loses
      *Minigame occurs where the player takes the part of the old man and revives himself.

Hero searches for bad guy
   Hero finds girl to help him on his search TRIGGERS - (B)

Hero fights bad guy again
   REQ - (B):  Girl joins in the fight against the bad guy with the hero.  Bad Guy makes note that the girl is his daughter.

Hero defeats bad guy
      *Player is congratulated and given a boost to his weapon

World is saved
      *REQ - (B):  Girl and Hero get Married.
      *REQ - (A, B):  Hero falls into his own trap while walking down the isle

And there we have it, a basic event plot. Additional syntax for requiring that an event has NOT occurred isn't difficult to add. In general, you don't have to worry about event plots becoming too large. The more experienced of a writer you are, the smaller these things seem. Think of Event Plots as the Declarations of the time line, but the actual Definition doesn't necessarily have to be in the same document.

Turning a 'normal' story into an event plot isn't so hard, although you will have to remove a lot of events and only keep the most important ones as Major Events - Or perhaps not. I don't know. I haven't really played too many games that made a good transition between story/movie to game, and I haven't had time to look over why the good ones were good and why not, but the most flexibility with Side and Minor Events seems like it would help.


I hope this has been of some use,
Pritchard
notthecheatr
Posts: 1759
Joined: May 23, 2007 21:52
Location: Cut Bank, MT
Contact:

Postby notthecheatr » Dec 31, 2007 21:47

Interesting, I know a lot about this sort of thing already but there's some new information in there for sure.
danny
Posts: 5
Joined: Jan 14, 2011 8:38

Postby danny » Jan 20, 2011 4:20

I often wonder about the how the story is created when I play Final Fantasy. I am happy I bumped into this forum and thereby understood how the game stories are created. I like the concept of Event Plotting and I think that is the only way game stories can be created.
Pritchard
Posts: 5425
Joined: Sep 12, 2005 20:06
Location: Ohio, USA

Postby Pritchard » Jan 23, 2011 14:27

I'm fairly certain even the advanced plots of many games can be described using elementary game theory, and by basic structures resembling graphs or trees.

I'd search for the simplest, most direct method.

Return to “Game Dev”

Who is online

Users browsing this forum: No registered users and 0 guests