Who does it benefit? the player, of course.

The short answer is that it benefits the writer by ensuring consistency and avoiding tunnel vision. It helps the programmer, artist, and designer by breaking the story into chunks they can use.


The long version:

I'm going to respond to your comments in reverse order. It was just easier to write it that way.

quote:
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.

I don't quite grasp the distinction, or how it applies to my suggestion. Yes, the writer is required to analyze and understand the text they create, but isn't that part of the craft of writing? Yes, it pushes the writer into a form that is useful for game creation (grouped by repeated and common elements), but I think the real benefit is a form suitable for interactive, player-controlled storylines. Could you elaborate?

quote:Original post by Kylotan
I don't think classifying everything into 'progress by combat' or 'progress by key' or whatever really helps the writer.

I strongly disagree. A lock-key setup is a problem with a single solution. Any scene can be reduced to a single problem-solution pair, by restricting it to (player win)->pass, (player lose)->fail and reload. 'Progress by combat' vs 'progress by key' is an oversimplification, because you've already reduced the situations to simple binary states. Single problem-solution pairs are usually a sign of weak writing, so I don't think there should be a generic 'Lock-key' template.

Compare the Confrontation template (which includes combat) to a generic Barrier template (which includes the prototypical locked door).

Confrontation:A Confrontation scene is two or more sides in direct opposition, where each is made of intelligent opponents. It doesn't matter if it's combat or a game of riddles, it has the same general structure. And a Confrontation scene ends *only* by one of the following:

a) One side is victorious in a contest
b) Only one side is left after the other(s) flee
c) All sides agree to a truce
d) An external event interrupts the conflict


Barrier: A Barrier (scene) presents the protagonist with a physical, unintelligent obstacle that prevents further direct progress. A character is free to leave the scene at any time. A Barrier scene requires that it is possible to pass the obstacle. If a obstacle cannot be opened or passed through then it doesn't qualify as a Barrier scene. The exits from a Barrier scene are:

a) character leaves area
b) destructive bypass
c) non-destructive bypass
d) correct key/switch

There are other ways to circumvent a locked door, but they don't involve the character dealing with a barrier. If the character enters through a window instead, then the locked door serves as a reason to use the window, but climbing in a window is not the same as dealing with the locked door.

To me, the Confrontation and Barrier are different things.

quote:
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.

Without any structure, the writer might write down 'The character uses the key to get past the door', and then spend the bulk of the treatment on other details. It might sound ok.

But if it was diagrammed by scene, and there is a node that can only be reached by passing a Barrier, and only a single correct key/switch is available, then it shows just how shallow the solution is.

A decent writer can write 'find (object)' a dozen different ways to make it seem like different things are going on. but if they have to constuct the scenes around player choices then the story, as experienced by the player, becomes more clear. If a scene cannot be handled by player action then it requires a cut-scene, and this needs to be obvious to the animators.

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

I believe the basic building block of a story is the scene. Whether movie or book, a story breaks down into a series of scenes. So this seems a natural place to start with computer game stories.

In constructing a story, the writer has to look at each scene and be able to tell what is going on, why it is going on, and what the significance of the scene is in the larger context.

Fortunately, scenes tend to fall into broad patterns.

When writing for a static medium (book, movie), these patterns might not be that useful. But in a computer game the player controls what happens. And players will try all kinds of crazy things. Some actions can be ruled out as dramatically inappropriate based on the type of scene. Others have to be handled by the writer, and having a generic template helps.

Example: A police interrogation scene. It fits the Confrontation pattern (it's a subtype of Confrontation). So immediately some actions can be disallowed. It would be inappropriate for the prisoner to open up a pack and start eating lunch. It would also be inappropriate for the prisoner to attack the police. But at a minumum the writer has to take care of the possibilites of the generic template.

a1) Police victorious - they get some crucial clue

a2) Prisoner victorious - demands a lawyer and then clams up; what happens next?

b1) Police flee - the police tire of getting nowhere and leave; what happens next?

b2) Prisoner flees - Not possible, *because the writer says so*

c) Truce - maybe the they strike a deal, a partial victory for both sides; definition must provided by the writer

d) External event - jailbreak? earthquake? Or maybe not allowed at all? The writer needs to answer this one too.


The writer avoids tunnel vision because he must consider these other possibilities. And the writer can balance how the scenes run into one another. Are five conversations in a row too much? Does the optimum path to the conclusion of the story avoid too many of the other pieces? Is the story too rigid?


The method I propose also benefits the other team members (artist, programmer, and designer) because it emphasizes the data they need. An Interrogation scene immediately requires some code for dialogs, some art for an interrogation room, some animations for arguing, and some game mechanics for an intimidation skill or somthing similar. And the writer can fill in the specific text of the dialog in parallel.

If the writer needs to change the text then it's no big deal. But if the writer needs to change from an interrogation to a warehouse search, then it causes major disruption downstream. Since that requires changing the scene type, it gets flagged.


The templates are owned and controlled by the writers. The most common ones can be reused from project to project, or even from one portion of a game to another. Writers would be free to derive new ones as needed, with the understanding that a new template will tend to increase the workload of the folks downstream. And the generic templates only serve as templates; the writers sill have to fill in the details.

JSwing

(minor edits for format)

[edited by - JSwing on June 12, 2002 6:09:22 PM]

quote:Original post by JSwing

The templates are owned and controlled by the writers. The most common ones can be reused from project to project, or even from one portion of a game to another. Writers would be free to derive new ones as needed, with the understanding that a new template will tend to increase the workload of the folks downstream. And the generic templates only serve as templates; the writers sill have to fill in the details.

I think this has been the reason for some of the disagreement in this thread. Kylotan seems to be more worried about the game filling out details (I could be wrong, but that seems like something you''re concerned with), which isn''t really practical or possible (it can be done to some extent, but...) You kind of need to think of the dynamic story as the code of the plot, the gameplay of the storyline. Details, like actual dialogue, locations, characters, etc. are like artwork. They are created by a writer. The purpose of a dynamic story shouldn''t be worrying about these details, but instead using and ordering them in an interesting way based on player interaction. Your actual plot (whether a state machine or a flow chart or branching or whatever) can consist of kind of generic events that happen with specific elements of the story (characters, places, objects, actions, etc.) That''s not to say that finding out a good way to generate a story''s details isn''t interesting.

It seems to me that JSwing is talking more about design issues - distilling the story down to the mechanical issues. That might be useful, but not to the writer. I don''t see at all how the templates you gave examples of help the writer in any way. You mentioned that it can highlight how "shallow the solution is", but the depth or shallowness is something I want to leave to the writer''s discretion. The main problem I''m addressing is how to communicate that to designers. I don''t think we''re talking about the same thing.

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

Oh... I thought the conversation was more about how to implement a dynamic story system. I guess I was thinking about it more from a designer\programmer perspective than a writer perspective (I guess this is the game WRITING forum, but you don''t see many conversations like this anywhere else.) Writers (in my opinion) can use a far less technical system. It seems like the writer could come up with a general plotline, and perhaps possible outcomes, and the designers or programmers come up with the more concrete system that works with the gameplay. Then writer''s use this framework to detail the storyline.

I guess a lot of it depends on how much the writer is doing. Is the writer just a guy doing some background story, dialogue and flavor text, or is the writter the person who defines the game (gameplay, artwork style, etc.)?

Hmm,

isn't a big part of the problem here that a lot of game writing tends towards special cases rather than systemic archetypes?

So when Superpig is talking about templates being limiting and repetitive, I feel like he is shooting himself in the trotter. Isn't the search for variety what leads us down the wrong path in the first place?

We are talking about writing events that are not scripted in the traditional sense but instead pass agency onto the player, so that play becomes more intentional (i.e. the player chose to do it rather than the sctructure demanded it).

Unless we are talking about preserving special cases and writing everything on a per instance basis, to me it sounds like we want to be creating an event heirarchy where we write something very similar to object behaviours by type rather than by instance. What I'm talking about is designing a behaviour system for narratives, rather than what basically would be just a set of puzzles, however complex and detailed those puzzles are.

Otherwise we are talking about something that has to be so special-cased that it would be a nightmare.

Going back to Kylotan's original point - how does a writer effectively draw up a story that is suited to these games (where there is freedom/agency on the part of the player to choose his/her actions) - I think there needs to be a distinction made between story/narrative and game mechanics/objects, before we can have a meaningful discussion about this. Also I don't think it works for writers to write about the hierarchy of the story, without needing to attend to the structure of the game, game objects, and game mechanics, that are part of the story. And I don't think it works for writers to want to utilise game objects and mechanics if they are not going to deal with them in a way that is communicable to the designers.

If I try to take the 'key', 'hilt' and 'sword' elements out of previous examples they fall down. I may of course just be misunderstanding what people have been talking about :-)

Kylotan, can you be clearer about what you mean by:

**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.**

This would seem to suggest that the writer either deal with higher levels of story abstraction & stick to generalised diagrams, or get stuck into the specifics and use classes, objects, types etc.

My point being that the writer in this case doesn't seem to be a very useful guy to have around.

Paul

[edited by - doomhunk on June 13, 2002 3:50:50 PM]

[edited by - doomhunk on June 13, 2002 3:52:32 PM]

quote:Original post by Impossible
Oh... I thought the conversation was more about how to implement a dynamic story system.

Arrgh... no, not at all. This is just about how to represent a ''story'' when the idea of a story in a game can be so much more than a story in a book.

quote:Writers (in my opinion) can use a far less technical system. It seems like the writer could come up with a general plotline, and perhaps possible outcomes, and the designers or programmers come up with the more concrete system that works with the gameplay. Then writer''s use this framework to detail the storyline.

Well, I half agree with you. They still need some way of communicating the "possible outcomes" to the rest of the team. That''s where my diagram comes in, for example. But there''s no reason why the ''what if'' elements should come second to the ''main'' story, so I think it''s useful to have a system that treats all branches and outcomes as potentially equal.


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

quote:Original post by doomhunk
So when Superpig is talking about templates being limiting and repetitive, I feel like he is shooting himself in the trotter. Isn''t the search for variety what leads us down the wrong path in the first place?

We are talking about writing events that are not scripted in the traditional sense but instead pass agency onto the player, so that play becomes more intentional (i.e. the player chose to do it rather than the sctructure demanded it).

Unless we are talking about preserving special cases and writing everything on a per instance basis, to me it sounds like we want to be creating an event heirarchy where we write something very similar to object behaviours by type rather than by instance. What I''m talking about is designing a behaviour system for narratives, rather than what basically would be just a set of puzzles, however complex and detailed those puzzles are.

Well, I don''t agree. What I am looking for is a way to make the writing of numerous unique events more manageable. Not a way to genericise it, or to reduce the amount of scripted behaviour in favour of emergent behaviour. I believe that it''s only a "nightmare", as you describe it, so long as there is no good way of organising and describing the potential storylines.

quote:If I try to take the ''key'', ''hilt'' and ''sword'' elements out of previous examples they fall down. I may of course just be misunderstanding what people have been talking about :-)

I don''t agree. The game mechanics are irrelevant as long as the diagram makes sense. Collecting items could be replaced by speaking to various people, or visiting a certain place. Or any other event which the writer considers notable. The only game mechanics that matter to the writer are that it must be possible to track whether each condition has been satisfied or not.

quote:Kylotan, can you be clearer about what you mean by:

**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.**

This would seem to suggest that the writer either deal with higher levels of story abstraction & stick to generalised diagrams, or get stuck into the specifics and use classes, objects, types etc.

Let me try another angle on this: how is a usual story organised? Let''s take Lord of the Rings - it''s a list of 3 books, each of those books has several sections, and each section has several chapters. Each chapter generally contains one significant event, as I remember it. Now, other books will have a slightly different approach but essentially the whole thing is one big list.

Game stories are not necessarily like this. However, most attempts at writing stories for games do end up looking this way, which I think is largely because that is the way that most writers think, and because there is little encouragement to think in different ways. The term "branching" is often used to represent the non-linear nature of game stories, but even that is limiting in certain ways, as it doesn''t address concurrency (what was Aragorn doing when Frodo was travelling to Mordor?), or game-specific concepts such as preconditions before events can occur, or player choices between actions.

I believe that there needs to be a more formal way of looking at these (and other) aspects, so that they can be used more effectively to create a non-linear story that fits a game, rather than fitting a game around a linear story.

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

I think a lot of this has a similar feel to designing complex levels. Just with the idea that, in this level, you can go anywhere, at any time, unless restricted. And it''s up to the person designing the levels to determine the flow (and all the possible flows) of the level. And feel free to substute the word story in for level.

The question that comes up for me is "So, what tools do we have for shaping this flow?" And I guess those could be looked at like the different types of lines on Kylotan''s graphs.

1. Mutually exclusive paths: Only one of the following paths can be picked.

2. One way (single directional) paths: Once started down this path, you can''t go back.

3. Two way (multi directional) paths: You have the freedom to turn back at any time. Note that this is ambiguous about allowing re-choosing mutually exclusive paths. I''d say it should, but that''s just a gut reaction.

4. Conditional paths: These paths can only be done when a certian event has (or hasn''t) happened.

5. Single traversal paths: Actually a subset of 4, these paths can only be taken one time.

6. Multiple traversal paths: These paths can be taken forever or until some other constraint happens.

7. Free paths: Similar to two way paths. However, while two way paths only allow travel between the upper (previous) and lower (next) areas of the story, free paths allow the user to exit the entire event.

7. Static Free paths: A variant on the free path, that when the player returns to the event, they automatically re-take their previous position.

And that''s every type I could think of (except maybe free floating disembodied events that over-ride everything else, like in three days, the world blows up no matter what you''re doing then). Think that''s enough, or that the breakdown makes sense?

So, in your example, The connection from being given the sword quest from the sage would be a static free path (you can leave whenever you want, but it remembers the setup of all these events). Asking about the sword quest would be a multi traversal two way path (or maybe a one way that loops to the previous position?). Hmmm... Just hit a stumbling block. The thing about the diagram is that it really doesn''t quite flow from top to bottom. The layout seems to say that once you get a blade or decide on a hilt, you can forge the sword.

With solid lines being prerequisites for the horizontal stripes, it gives the whole thing the idea of automatically getting bouced back to the previous level. I think I get how that works, but what if, during the hilt quest, something basic gets changed about that first horisontal stripe? This is tough stuff to think about.

Oh! thought of one more type of path. Automated. Once the constraints are met for this type of path, it executes. IE: a cutscene of the sword being forged once the ingredients are assembled vs talking with a blacksmith and giving him the ingredients to make the sword.

Looking forward to a response.

quote:Original post by ThoughtBubble
3. Two way (multi directional) paths: You have the freedom to turn back at any time. Note that this is ambiguous about allowing re-choosing mutually exclusive paths. I''d say it should, but that''s just a gut reaction.

Nice... I think this is the main thing that my diagram fails to address. Maybe I would need to ensure that the arrows either point one way or both ways to distinguish between the flows.

quote:Hmmm... Just hit a stumbling block. The thing about the diagram is that it really doesn''t quite flow from top to bottom. The layout seems to say that once you get a blade or decide on a hilt, you can forge the sword.

With solid lines being prerequisites for the horizontal stripes, it gives the whole thing the idea of automatically getting bouced back to the previous level.

That''s maybe because you''re misinterpreting the diagram. The notation could be changed if there was something clearer, but essentially the horizontal bars mean that you must take all paths. So there''s no ''bouncing back'' as such because you can consider the different paths to be essentially separate. You can''t look at a path in isolation, as you need to see if it stems from a horizontal bar that implies it is one of several tasks.

quote:I think I get how that works, but what if, during the hilt quest, something basic gets changed about that first horisontal stripe? This is tough stuff to think about.

I''m not sure what you mean, because the idea is that the horizontal bar is an invariant. You must do everything below that line. If something is prone to change, then it could probably be represented by a conditional path.

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