quote: Original post by Impossible
Most game plots are not much more complex than "3rd battle." Most general plots are pretty simple, the problem is filling out details (which needs to be done in a more traditional way, by a writter.) The problem isn''t complexity, you can create abitrarily complex plots, but a system like this has a good chance of generating generic plots.

I agree that state machines (or regular expressions, which are essentially the same thing, just more compact) are a good representation of much of the problem. But I disagree with what you said above. I believe that the reason games have "pretty simple" plots is because it is difficult to write anything more complex for a game. I think this is largely because it''s hard to represent and work on such plots, and difficult to communicate them to a development team. So a system, tool, methodology or whatever to help with production of such plots would help everyone.

Of course, this also hinders the use of state machines. How does a state machine cope with concurrent states? In a story where the possibility of finding a key is in State 1 and using the key is in State 10, do I need State2a and 2b, 3a and 3b, and so on, where the ''a'' states are when you have the key and ''b'' states are when you don''t? There could be an explosion of states which is no more manageable than a flowchart.

quote: Events don''t really need an implicit connection (event 1 leads to event 2), they take place if the world is in the right state.

You still need a way of representing that precondition though. Ideally it should be a standardised way, so that you can use some tool (whether it is a bespoke package, or find in files in a text editor) to find all the events made possible by a previous event, and all the events required for a future event. Being able to see the sequence is important for the designers and programmers, and also for anyone who needs to write relevant and believable narrative. You might also want to be able to verify that a given situation is indeed possible to reach! Or identify ''plot bottlenecks'' through which all players must pass, and which should merit most writer and designer time accordingly. I know much of this is about the practical considerations rather than the artistic considerations, but I firmly believe that making it more practical will help to get the ''art'' into the system, if you like.

Just on another note, I would like to add that although I have used the terms interchangably in the past, there probably needs to be a distinction made between a situation and an event (even though they mean the same thing in most cases). A situation would be a state you find yourself in, which would usually be summed up by a verb phrase ("wandering the castle", "destroying orc stronghold"). Events would be the possible outcomes of these situations ("player leaves castle", "stronghold destroyed") and which signal the transitions between situations. The programmers and designers would have to work out ways of ''spotting'' player events. It would be possible to speak just in terms of events (as Impossible did), which gets around the concurrency issues, providing you don''t mind the fact that the player''s ''path'' through the game is not really represented explicitly.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]

quote: Original post by Kylotan
Of course, this also hinders the use of state machines. How does a state machine cope with concurrent states? In a story where the possibility of finding a key is in State 1 and using the key is in State 10, do I need State2a and 2b, 3a and 3b, and so on, where the ''a'' states are when you have the key and ''b'' states are when you don''t? There could be an explosion of states which is no more manageable than a flowchart.

You shouldn''t have to have a million variations of a single state if you design your plot and your game correctly. In the key example, if you State 2 is you get robbed, 2a is you get robbed with the key and 2b is getting robbed without the key, state 2 should be general enough that it can handle the player being in any state. In that case, state 2 should handle any set of items, but the state could examine any military rank or another character''s disposition toward to player.

Once you leave a state it is no longer in effect, but it should set up everything correctly so that other states run properly. I think this would solve some of the flow chart problems (you don''t have to create a million branches at each level) if you write every event at a small enough complexity. If every state handles only a few different possiblities you should end up with a lot of small states, as opposed to a whole lot of complex states. It''s possible to write events so an event can affect another event without directly changing it''s trigger. In the previous example, the rob state (2) would remove all items from the player which would affect the "Enter the dungeon state" (3) because the player no longer has a key. If the player slays a powerful dragon it may impress the entire kingdom which in turn affects the princess and lets the player trigger the "marry princess" state. The player could anger another character, and due to close relations, that character''s best friend would get angered also, perhaps triggered some other state. I don''t think this kind of behavior is possible in a flow chart or a branching story, without multilevel branches. If you use the state machine method you have the potential for a pretty complex (and perhaps unexpected, which is exactly what we want) chain of events.

Good tools and a formal language\writting style are definitely important. I think the problem is solvable with current hardware and methods if you design event the right way (whatever may be.)

In my RPG-in-progress, some major villains can be captured rather than killed, resulting in bonus XP and the possibility of having them come after you again, ad nauseum.

Also, to create an RPG with limited plot branching, you can create a plot tree in which most diverging branches eventually re-merge with the main plot again, thus terminating an unwanted plot divergence.

Sorry if I repeated something: long posts make me dizzy.

[edited by - DuranStrife on June 8, 2002 1:41:18 PM]

quote: Original post by Impossible
You shouldn''t have to have a million variations of a single state if you design your plot and your game correctly. In the key example, if you State 2 is you get robbed, 2a is you get robbed with the key and 2b is getting robbed without the key, state 2 should be general enough that it can handle the player being in any state. In that case, state 2 should handle any set of items, but the state could examine any military rank or another character''s disposition toward to player.

Anything is simple if you take it up to a higher level of abstraction. You could represent the whole story as a single circle labelled "Story" if you liked. The problem is being able to still get enough information across. If one state encapsulates too many contingencies, then it ceases to give you much information about the situation. You should be able to look at State 10, see that the outcomes of State 10 depend on the possession of a key, and be able to instantly see where that key was acquired. You should also be able to look at State 1, and see what the relevance of that key is, at a glance. In a branching diagram, you would be able to see that, and in a state machine that had separate states for having a key or not having a key, you would be able to see that. But by generalising all the interposing states, you would not. So how would you represent it?

(Note that talking about keys makes this seem like more of a programming problem with items than a writing one. It is not. The event in State 1 could be a conversation with someone, or a sighting of an opponent, or anything at all that gives the potential for different events later.)

I am not saying your method is wrong, but I am saying it is insufficient. It would need some other form of referencing to be useful.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]

Just to make things a little more concrete, and to provide another talking point, here's my first draft of a diagram notation for interactive storylines, based on UML state diagrams.



Quick explanation: basically, you start at the top and work downwards. Solid vertical lines are mandatory, except where they branch in which case one line from each branch should be followed. Dashed lines are optional. If there is a [condition in square brackets] then that condition must be met in order for that branch to be taken. Dashed lines without conditions are followed if the player wishes to. The thick horizontal lines are synchronisation or sequence points. All the solid lines leading into it are prerequisites, and all the lines coming out of it are consequences. And the diagrams are hierarchical, this entire diagram could represent the insides of a single state marked "Do Sword Quest" on a higher-level diagram.

Examples: when given the sword quest, the player MUST find the hilt, they MUST find a blade (although there are 2 mutually exclusive choices), and they CAN ALSO find a magical gem for the pommel. The first 2 must be completed - in any order, or at the same time - before the synchronisation point is reached and it becomes possible to enchant the blade or finish the quest. The "ask sage about sword quest" has no 'out' line, as it has infinite duration - any time after you have been assigned the quest, you can ask the sage about it (even if you've completed it). On the other hand, the "find magical gem" part is no longer possible once you have forged the sword or enchanted the blade. (For no good reason, I know - I'm just demonstrating notation here.) Finally, the "Enchant Blade" state is only possible if the specified condition is met, but is optional and may be avoided, as implied by the direct line to the "forge sword" state bypassing the "Enchant Blade" state.

I know this system doesn't get around all the problems I have mentioned earlier, but it is more descriptive than a simple flowchart, I feel. Any comments?

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]

[edited by - Kylotan on June 8, 2002 8:24:04 PM]

Yeah, I agree with the hierarchy thing. I was kind of getting at that with my earlier examples even though I didn''t say it. My simplier examples would have smaller elements within them, all the way down to individual actions (a single attack, a sentence, a single step, etc.) The state machine only needs to keep track of what''s important to the story though, so a group of attacks against a certain enemy would be treated as a fight event, a group of sentences exchanged between two people would be a conversation event, etc. The majority of detail within a given event can be self contained and higher level events just need a to know the outcome. The general plot only needs to know what''s happening with the major events, the major events only need to know what''s happening within minor events relavant to them and the minor events deal with specific actions. You can, of course, have a lot more levels than that, along with parrellel plots (plots that have a different hierarchy and can only indirectly affect other plots through affecting characters.)

One way to get past some of the problems with my method is to have characters, items, locations, relations, etc. that are affected by a given state hold state information themselves. So, in the key example, instead of having to reference the state the key came from to find it''s relavance, you can just have a state look at the key or the key look at a state.

The problem with your diagram (as far as I can tell), is that if the player gets a hilt from somewhere else for example you need to link that event to the build sword, or find hilt event (even though "find hilt" could just be an abstraction.) So, let''s say the "preffered" way for the player to find the hilt is to go to the Cave of Despair, but this player doesn''t go to the cave of despair, he robs a questing knight for it. There could be a million other ways to get the hilt, so it would best to have a "got hilt" intermediate state, or to have the hilt itself be a state. Basically, you need to handle different events with the same outcome, which simplifies the state machine a little bit.

I think you''re on the right track. But I think you jumped into the details too quickly.

Classify your scenes (or is it situations) into some generic abstract types, based on how they serve a story. Confrontation might be a type, and combat being a sub-type of this. Another might be Exposition, which for an interactive medium would better be named Exploration. It would cover the player searching around a particular location or simple interaction (opening containers). And so forth.

I suggest using different shapes in your diagram for the different types. I think the generic scene types will help organize the plot elements and keep the focus on how the piece contributes to the whole. It also allows for re-use of some tiny-plot templates.

Generic scene types would have rules for transitions to other types, and rules for what can and can''t happen while they occur. Specific instances of the generic scene types may have specific restrictions as well. A particular fight scene might have the restriction Can''t Run Away, meaning one of the normal ways to exit the fight scene (running away) isn''t allowed.

Applying all of this to your diagram, I would toss out what you have labeled and focus on other pieces. After all, finding the hilt is just another type of key, one that is required to open the door to ''forge the sword''. The diagram doesn''t show how or why this is important to the story.

If instead you diagramed ''Explores Area - Museum'', with a note that player can acquire the hilt, you focus more on what the player is doing.

It indicates better the kinds of supporting things you need, like extra eye candy or sounds for different parts of the Museum (unless the player finds the hilt immediately).

Diagraming out the transitions from one scene to another, the plot is less likely to be linear. Continuing with the museum example (imagine this is a drawing):

Null node (outside the museum)
only leads to: Explore (Museum)

Null Node (success)
player has found hilt, this tiny plot is CLOSED

Null Node (fail)
Player has passed out and is discovered the next morning, and escorted out of the building. If the player gets endless tries then this is the same as Null node (outside the museum). The tiny plot stays OPEN.

Explore (Museum)
exits to Null node (success) when player finds hilt
exits to Null node (outside)
random chance of exit (spooky sounds/fx) to Confront (ghost)

Confront (ghost)
exits to Chase (Player Flee)
exits to Explore (Museum) if player drives away ghost
exits to Null Node (fail) if ghost wins (player faints)

Chase (player flee)
note: Might need special art
exits to Explore (Museum) if player successfully hides
exits to Null Node (outside museum) if player escapes
exits to Confront (ghost) if the ghost catches the player


Ta da! Something that I think looks more like a story than just a plot outline. The individual pieces get as much detail as the writer wants, while the player gets an interactive world where the story can be a little different each time. In any particular game, a player will not reach all of the possible scenes, but if the scenes of a given type are derived from some common templates, (if running from the ghost shares a lot with running from the dragon later) then there is less waste.

JSwing

Exactly, I was thinking along the same lines, a lot of events are general and can be used multiple times. Something like a fight event can just take an input of two characters, and has a few generic conditions. Any special effects the fight scene has on a character can be stored within the character. Some scenes are of course, very specific, but if you write most scenes in general terms you get a lot more flexibility

quote: Original post by JSwing
Classify your scenes (or is it situations) into some generic abstract types, based on how they serve a story.
...
I think the generic scene types will help organize the plot elements and keep the focus on how the piece contributes to the whole. It also allows for re-use of some tiny-plot templates.

I don''t see why you''d want to do that. Who does it benefit, and how?

quote: A particular fight scene might have the restriction Can''t Run Away, meaning one of the normal ways to exit the fight scene (running away) isn''t allowed.

This is getting closer to the gameplay details, and not the main thrust of what I was looking to represent (although certainly not irrelevant). In my diagram, the idea is that a writer might do a short treatment for each state box, possibly some ''concept prose'' (what is the written equivalent of concept art??), or whatever.

quote: Applying all of this to your diagram, I would toss out what you have labeled and focus on other pieces. After all, finding the hilt is just another type of key, one that is required to open the door to ''forge the sword''. The diagram doesn''t show how or why this is important to the story.

If instead you diagramed ''Explores Area - Museum'', with a note that player can acquire the hilt, you focus more on what the player is doing.

Remember it''s at an arbitrary level of complexity. I don''t think classifying everything into ''progress by combat'' or ''progress by key'' or whatever really helps the writer. I am looking for tools that help the writer show the general hierarchy of the story in a way that easily translates to code - not to do the translation to code for themselves. Which I accept is a subtle and fuzzy distinction. The example sequence you give in the museum is reasonable, but from my point of view it is too close to the actual actions for me.


[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]