quote:Original post by ThoughtBubble
Well, I''ll share the method I used when I was working on an RPG 2 years ago. It''s not very organized, and was mainly tied in with the programming aspects, but it may be of some use to you.

It''s good that it''s tied in with the programming aspects. A large part of why I wrote this post is because I feel there''s a big gulf between the programming and the writing. Writers often feel they don''t have as much influence over the game as they deserve. I feel this is because, paradoxically, the traditional style of writing is ill-suited to many of the games that would best benefit from a well written story. Therefore there needs to be something in between - the writer''s equivalent of a level editor or a scripting language, that leverages their skills in a way more suited to games. I have often thought this would be a tool, but it doesn''t necessarily have to be so. It could be a language, a notation, a new way of thinking, or all of the above.

quote:Like everyone does, I came up with a basic plot, and a few locations, and places for the plot to branch with optional quests. To start with, I organized it as a flowchart of sets of events.

Ok, my first criticism is that I believe flowcharts are inadequate. I went over this last week with a friend doing an English degree to try and work this out. A flowchart is basically the logical evolutionary progression from a normal linear story. You take a prototypical story, and add some ''what if'' elements along the way, which are triggered by player choices. But this is only adequate as long as you have a pretty small number of subplots, and as long as those plots start and end in the same place (eg. there are no subplots that can be done either near the start or near the end of the game), and so on. It''s also not entirely clear just from looking at the flowchart which events are optional for the player, and thus the designer, should time constraints be a problem. (However, this could be overcome with some sort of clearer notation.) Also, how do you represent the difference between a branch that represents a player choice (eg. Do A or Do B), and a branch that represents doing both, but in your chosen order (eg. (Do A then B) or (Do B then A) ). The latter is common in games like Final Fantasy where you might split your party for a while. And Hundley''s talk of multiple viewpoints might need something like this, although this trivial idea does not fully do it justice. Either way, a basic flowchart does not give enough detail to the designer, programmer, or other writers as to what is going on here.

quote:From there, I''d map out each event that I could think of. Who''s it involve, what''s it for, what does the player gain, choices, setting, etc. For each event, I''d then sit down and map out the people and places it affected. In many cases, the effect was widespread. For example: Becoming a member of the king''s army had the majority of the kingdom either asking for help, or cheering you on.

I think this part is sound though. I personally tend towards expressing the effects in as formal a way as possible, as this would allow the effects to be easily classified by a tool (should one be created) and easily implemented by the designer or programmer as a flag or attribute. In fact, if you could specify the effects in a clear and precise way, a tool could automate the process of showing which events lead to other events by checking the dependencies. It could eventually produce your flowchart or diagram for you.

quote:Then, I started writing up the set of locations. After the basic description of the location, I''d include a listing of all the events that could alter the location, and a brief description of how. From there, I just wrote the dialog and events for each person in the location.

We also did similar stuff with the major characters, as they''d have to act and change more often than the normal ones, sometimes after every conversation.

I must admit I wasn''t thinking so much about location or characters, just about plot. In hindsight, it''s a grave omission But I am happy to try and crack one problem at a time. Locations and characters have the benefit of not really having temporal dependencies and so on, whereas plot events do. This is why I am focusing on plot for now. Characters and locations will still need writing up, but they are almost independent.

quote:Original post by gamesmaster2
In rpgs your towns should be like episodes or comic book issues.They have a certain problem for your hereo to solve or some vital information that must be retrieved.But what ever it is should be solved within that area.

You see, I fundamentally disagree with this, which is partly what I''m trying to address. You are advocating a model which is very linear at the top level, and only appears interactive at the more detailed levels of abstraction. Whereas your method may be fine for many console RPGs, I feel it is both limiting, and unsatisfactory for many gamers.

quote:Original post by MadKeithV
I think you''d need a combination of flowcharting (which handles actions, transitions and constraints well) and some sort of data description (which handles the description of the situation and its internal data).

I too believe that this is the essence of the problem - a decent method for drawing the diagrams, and a semi-formal way of storing the detailed information. The main problem facing me is that traditional media doesn''t address interaction very well, if at all, and programming notation isn''t versatile enough to cover all the different configurations of story states. In particular, programming notation likes to assume simple branching, nested, or concurrent structures, and doesn''t really like combinations of two or more of the above. Yet in an RPG or other freeform game, the player will start and end tasks as and when it suits them, without any consideration for how well ''structured'' their choices are. Yet somehow the writer should be able to represent this in a way that makes it easy to communicate to the other game developers, allowing the writer to have a more constructive input into the process.

If the non-programmers here will indulge me for a second, I find myself looking at regular expressions, UML diagrams, and relational/boolean algebra, and in each case they can describe 90% of what is needed, just not that last 10%. If I can figure out some decent way of unifying them, I''ll draw something up for you all to criticise.

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

I only sort of skimmed over the whole thread, so forgive me if I am being redundant. I am (attempting) to write a script to an RPG like game. My first thought was a flow chart but I soon discovered that it would end up being massive by the time i got anywhere with it. What I have been doing (I think Kylotan mention this) is creating different seperate event that are not in a particular order. Some of those events have condition (Im just making a large list of flags or bools or whatever) and they will or wont occur depending on what flags are set by earlier events. Also the entire map can change (to potray a change in time) after certain things are happening.

So I will just have Trellnor''s Square - Begginging of game, describe the area and then list all the events and the condition in which that event occours, and then there will be flow chart dialog contained in those events. Also certain areas are not accesable untill the manditory quests are completed. So you cant really run to the end of the game and beat it like that. So to put it in OOP terms, the map is a class and the events are all functions (belonging to that class) do nothing but set different variable to true or false. Some function will do nothing unless a condition is met. (but realistically, the events will probablly be contained in a scripts and not hard coded).
That method seems to work allright.

PHRICTION

Tacit, I will leave the issues of whether it is meaningful, interesting and fun down to the individual writers and designers. I am more interested in the language or structure that is used to communicate the concepts for now. You''re right in that it''s potentially very difficult and intellectual stuff, but it would certainly be helpful for people to come at it from the gaming angle too, I think. After all, on that MIT site only 2 or 3 out of over 30 special interest groups seemed to have any direct relevance to games.

Phriction - as you have discovered, the problems with a flow chart are numerous, but the largest problem for me is what I clumsily term the ''delayed branch'' problem. Imagine a story where a decision made early on only has an effect (ie. a story branch or fork) later on. A traditional flowchart expects the branch to occur at the point that the decision is taken. Whichever way you work around this, you lose some information and clarity on the chart.

I think describing situation or event preconditions as a boolean expression with previous decisions as the variables is one good method, which doesn''t rely on the decision being at the same point as the result to make sense. AND means you had to do both tasks, XOR means you had to choose one of the two tasks (ie. a branch), OR means you had to do at least one of the tasks, and so on.

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

Why not look at a story as a state machine instead of a flow chart? You have a bunch of events (states) that may or may not transition to other events when they''re finished. Characters also have states that determine how an event will affect them. Events can be triggered by anything, another event ending, character state, time, etc. For example, if you take your classic fantasy\RPG storyline:

Hero lives in a quiet farm town. He is approached by Powerful Wizard that tells him if he doesn''t kill Evil Badguy the world will be doomed.

In a traditional RPG you are forced to to kill all of the Evil Badguy''s henchman and then the Evil Badguy himself. However, the point of dynamic storytelling is to allow for players to take different paths. So while the event flow in the traditional story looks like this.

Talk to Wizard.
Leave town.
First battle.
Meet Princess.
Second battle.
Thrid battle.
Final Battle.
Marry Princess.

In a dynamic story, there''s no reason it couldn''t look like this:

Talk to Wizard.
Leave town.
Talk to Evil Badguy.
First Battle (against goodguys).
Kill Princess.
Second battle.
Thrid battle.
Final battle.
Betray and kill Evil Badguy.
Take over world.

or this:

Talk to Wizard.
Stay in Town.
Get slaughtered by Evil Badguy.

If you design your events so they can take place in any order, and are effected by previous events (states) you could in theory end up with a pretty dynamic plot. Things get even more interesting when you have subplots and parrellel plots not directly related to the main plot, but capable of influencing it indirectly, either through their effect on characters or their effect on the world. Maybe I''ll try to come up with a basic state machine-like script for the events that I listed, but I don''t have the time right now .

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. If you think about many strategy games, some RPGs and even online action games use a similar system. Games like Civilization, or Master of Orion or the Sims consist of a bunch of related events that can happen in different orders at different times. The problem with those games is the story usually ends up very generic. If you take a similar design and limit it for a more specific plot. You can add more detail, less abstraction, etc. at the cost of flexiblity in the plot line and events.

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. Events can trigger other events directly as well. The idea trys to get around some of the limitations of branching (flow chart) stories because there''s no set order for anything. Instead of having to write a million branches for every event you create a few events with different parameters that change the state of the plot and transition into other events.

The elements aren''t disparate. The events still have relations even though there is no implicit connection. Someone mentioned that we should look at stories in different ways, and this is a different way. If you think about it, a story is just a bunch of events pasted together in an interesting way.

The only way you can guarentee a good story is if it''s completely prescripted and linear. In any dynamic\emergent game there is a possiblity that the player will get a storyline that they don''t like, but then again they made most of the choices that lead them there.

If you have any suggestions on how I can improve my idea, or any good ideas of your own I''d like to hear them. My suggestion isn''t supposed to be the "perfect" solution to the problem, it''s just something that I think would work for a lot of games.