You guys were talking about the bottleneck caused by a simulation in a bottom-up approach. I was telling you how to avoid it altogether.

"My system as it stands at the moment (only on paper at the moment) does take a bottom up approach as well, but the basic building blocks aren't characters but plot fragments (due to the nature of the game the bottom up approach is the only one that will work, but that's because my game is a hybrid of a number of genres)."
I have a working model using plot fragments. Therefore I am interested in knowing the boundary of your system and its problem statement. Can you explain why a bottom up approach is the only viable option? Since you believe that it is not an effective approach, what are you doing to test the more effective counterpart?

It was sad to see the discussion get dragged down to generic discussion about bottom-up AI that had been discussed nth times. Of course everything will work if we are able model and simulate every single thing.

Quote:Original post by Estok
I have a working model using plot fragments. Therefore I am interested in knowing the boundary of your system and its problem statement. Can you explain why a bottom up approach is the only viable option? Since you believe that it is not an effective approach, what are you doing to test the more effective counterpart?

The reason why my present design has to consider the bottom up approach is because it isn't really a pure story generator, and has to incorporate interactivity. It's a bit hard to explain, as the design isn't finalised and I haven't yet thought through all the gameplay considerations, but in essence the player is not really part of the story, but more a storyteller piecing together plot fragments, but who also does not have complete control over the story.

In a way, I'm considering a top down approach while I'm designing, as I have to make sure I have the right types of plot fragments. However, as the game progresses, the logic that pieces them together will be bottom up. I'm not really caring so much if there's a few gaps in the stories as they are pieced together, as the player will not be directly involves but acting as an overseer. Plus I expect there will be several stories running at the same time.

The whole game is really just a testbed for some storytelling ideas I've had, but I'm turning it into a complete game because I think it will be more fun to write that way.

Your comment exposed some potential paradigm blocks. Choosing top-down or bottom-up has nothing to do with whether the game is a pure story generator or not. Also, when we talk about a plot fragment in the context of a game, it is implied that there is interactivity. A plot segment is not a passive presentation, to be precise, a 'plot segement' is a configuration of the game states such that the resulting message is delivered through interactivity. Whether the player is part of the story, or whether the player has complete control over the story are independent considerations to choosing a bottom-up or top-down approach.

Top-down simply means that the engine coordinates the story at an abstract, over-seeing level. Bottom-up somply means that the engine simulates the thoughts/reactions of each interacting components in order to create the essence of overall changes.


This line in particular does not make a lot of sense:

"However, as the game progresses, the logic that pieces them together will be bottom up. I'm not really caring so much if there's a few gaps in the stories as they are pieced together"

In a top-down simulation, suppose at a particular point a character needs to be a helper, then the character will help the hero. The character did not choose to help the hero. There is minimal notion of individual choice in a top-down simulation. The helper helps because the engine told it so. From the player's point of view, the act of the helper is logical, it seems that the helper had been thinking and changing, but the presentation of such changes is staged by the engine. A top-down simulation does not have gaps, the same goes for a well-designed bottom-up simulation. The engine won't present the character as a helper if it does not satisfy the prerequists of being one. If the engine needs a helper, it will shape a character into a helper. That is a function of a top-down story engine to prepare its own ammo.

Quote:Original post by Estok
Top-down simply means that the engine coordinates the story at an abstract, over-seeing level. Bottom-up somply means that the engine simulates the thoughts/reactions of each interacting components in order to create the essence of overall changes.

I agree with your top-down definition. Bottom-up in this case means the same as with programming design strategies (Wikipedia link); the plot fragments are described in detail and treated as atoms, and the system combines these together to make larger plot pieces. Due to the nature of the game the size of the plot pieces that will be used are very small from a story perspective (they may not be atoms, as of yet I haven't decided on that).

Quote:
This line in particular does not make a lot of sense:

"However, as the game progresses, the logic that pieces them together will be bottom up. I'm not really caring so much if there's a few gaps in the stories as they are pieced together"

In a top-down simulation, suppose at a particular point a character needs to be a helper, then the character will help the hero. The character did not choose to help the hero. There is minimal notion of individual choice in a top-down simulation. The helper helps because the engine told it so. From the player's point of view, the act of the helper is logical, it seems that the helper had been thinking and changing, but the presentation of such changes is staged by the engine. A top-down simulation does not have gaps, the same goes for a well-designed bottom-up simulation. The engine won't present the character as a helper if it does not satisfy the prerequists of being one. If the engine needs a helper, it will shape a character into a helper. That is a function of a top-down story engine to prepare its own ammo.

If I could accurately explain the vision of my game, that line would make sense. My game isn't really a traditional story based game; it's not an RPG, it's not an adventure game. It's actually a strategy game, similar to that of SimCity or RollerCoaster Tycoon, except with some elements of storytelling thrown in. From that perspective, I'm not caring too much if the stories aren't 100% perfect, or happen to be trite and unoriginal, as that won't matter.

But the problem with a top-down simulation, which I have considered before as a storytelling strategy, is that it is hard to put interactivity into the system. By the nature of top-down, the whole story has to have a level of planning already implemented before it begins. To take your example, your top-down system has ordained that a particular character has to be a helper; what happens if the hero decided to heavily insult the character enough to make him/her the hero's enemy? Or if the hero decides to kill the character? The top-down system will have to cope with that somehow.

Now there are ways I think a top-down system could react to interactivity, but they make the system more complex. A bottom-up system doesn't have that limitation as it doesn't have to have the same degree of planning ahead. The drawback is ensuring that the bottom-up system will lead to a valid story structure, of course, which is why hybrid systems are a good idea, too.

Quote:Original post by Trapper Zoid
the plot fragments are described in detail and treated as atoms, and the system combines these together to make larger plot pieces. Due to the nature of the game the size of the plot pieces that will be used are very small from a story perspective (they may not be atoms, as of yet I haven't decided on that).

The Wiki definition is correct, but your statement is confusing. In either approach, there are units and atoms. The difference is that in a bottom-up approach, the system relies on the interaction of the fragments to create a whole, while in a top-down approach, the system directs the fragments to behave such that the overall goal is satisfied.

In either cases, things are still made up of small elements, the difference lies in whose putting them together.

I don't see any conflict for you to adapt the top-down approach, or you may prefer to call it the hybrid approach:

Quote:The backbone of this approch does not require AI_BUCS (bottom-up character simulation). You can handle very complex scripts and stories elements, with substantial designer influence. There is no need to pray for the characters to come up with something interesting. At higher levels, you can use character AI to further automate the details, but those are for adding details and realism, not for the construction of the story. The story is already being told, character AI is used for adding variations in the presentation.

In terms of story organization, this is clearly top-down. It has character simulations, but those are not relied upon for the creation of the story.

The problem you considered does not exist the way you described. A top-down engine is like the AI running the strategy of an RTS. If the character is not available to become a helper, than the engine would simply choose to do something else, just as the RTS AI might choose to build an archery instead of building a barrack. More often than not, a player trying to screw up a top-down story engine ends up screwing up himself in style. If you kill your teammates, it just accelerates the hero's demise. It makes the engine's job easier. The more enemies the hero has, the easier it is to create a climax where the hero is tragically defeated due to his bad decisions. Part of the function of the engine is to create conflicts (for an RTS engine, to create an appropriate amount of actions), the player was helping the engine by killing his own villagers. The engine doesn't mind conflicts being introduced, it is afraid of having no conflicts.

You may be overrating the degree of planning required. Because top-down approach is a hierarchy structure, any planning (as a form of path-finding) becomes O(logn)ish. So planning actually scales pretty well in top-down approach. Your story will have to be exponentially complicated to see a linear increase in the cost of planning.

The processes of a top-down engine may not resemble planning-ahead. It may be a progressive elimination of choices. In the latter case, it means that there is no planning, the engine picks an element that belongs to a path not closed.

You can also use a hidden cards. For example, the character that the engine wants to turn into a helper can have a hidden story--a story that the engine never reveals until it wants to turn the character into a helper. The engine might hint to the player that there is such a possibility, but the player can't really do anything about it untill the time comes. Depending on how smoothly the engine executes the hidden cards, the player may feel it as either an anticipated revelation, a good twist, a surprise, or plain bs. To be on the safe side, the engine can also hint it first, and if it is not revealed, the player can play again.

[Edited by - Estok on August 30, 2005 4:27:44 AM]

Quote:Original post by Estok
The problem you considered does not exist the way you described. A top-down engine is like the AI running the strategy of an RTS. If the character is not available to become a helper, than the engine would simply choose to do something else, just as the RTS AI might choose to build an archery instead of building a barrack. More often than not, a player trying to screw up a top-down story engine ends up screwing up himself in style. If you kill your teammates, it just accelerates the hero's demise. It makes the engine's job easier. The more enemies the hero has, the easier it is to create a climax where the hero is tragically defeated due to his bad decisions. Part of the function of the engine is to create conflicts (for an RTS engine, to create an appropriate amount of actions), the player was helping the engine by killing his own villagers. The engine doesn't mind conflicts being introduced, it is afraid of having no conflicts.

I think we might just be quibbling over nomenculature here, as that sounds like a pretty good description of what my proposed system will do. The planning in this first version will be very light (to make it easier for myself), but I'm leaving the possibility of a more advanced planning system to be added later. That bit about the conflicts at the end is actually a very close description of the whole point of the storytelling part of the game, by the way; managing story conflicts is a big part of the design.

Quote:
You can also use a hidden cards. For example, the character that the engine wants to turn into a helper can have a hidden story--a story that the engine never reveals until it wants to turn the character into a helper. The engine might hint to the player that there is such a possibility, but the player can't really do anything about it untill the time comes. Depending on how smoothly the engine executes the hidden cards, the player may feel it as either an anticipated revelation, a good twist, a surprise, or plain bs. To be on the safe side, the engine can also hint it first, and if it is not revealed, the player can play again.

This reminds me of an idea I had with top-down storytelling systems: have you thought about leaving such hidden story elements in an undefined state? Taking the example of a mysterious backstory to a character, the system could hint that a character has a shady past, but not have to internally define what that is. Then when that past has to be defined more deeply, it can fill in the blanks with the specifics.

Or to use the example I had in my design; the choice of the antagonist in the story can be left ambigous until the story engine needs to decide. It knows that there has to be an antagonist, and can set up a confrontation at the end of an act. However the choice of who that is and why they oppose the protagonist can be left undefined until the player makes enough decisions for the story engine to decide who would make the best choice as the antagonist.



On an slightly unrelated note to this discussion, but relevant to the general issue of interactive storytelling, my copy of the book "Chris Crawford on Interactive Storytelling" arrived, and I'm reading through it this week. I'll post a review here when I'm finished. So far it's an interesting read.

You are correct that we are just discussing nomenculature. We have practically the same perspective, such as the understanding that intelligence is a work of illusion and that a bottom-up character simulation does not guarantee sound story structure. There is a class of bottom-up implementation that guarantees a story structure, however.

Quote:

Quote:You can also use a hidden cards...

This reminds me of an idea I had with top-down storytelling systems: have you thought about leaving such hidden story elements in an undefined state? Taking the example of a mysterious backstory to a character, the system could hint that a character has a shady past, but not have to internally define what that is. Then when that past has to be defined more deeply, it can fill in the blanks with the specifics.

I have though about these kinds of designs. I was referring to these as stories with varying past. A year ago, I posted a design concept under this premise. There were several potential traitors, and the engine leaves the real traitor's identity ambiguous. Such implementation makes it easier for the engine because it leaves some room for hidden cards. For example, the game may faintly hint that character A worked for a shaddy company, and the player may discover shaddy company B out of several shaddy companies, then character A is assigned by the engine to be a previous associate of company B, or somewhere else, for the sake of surprise. This may be a way for the engine to retain secrets. When a sufficient number of secrets are discovered, the engine closes in and connect all the dots within the framework. It is a way for the engine to stop the exploration phase of the game.

If the point of the game is to 'guess the murderer', too much evasion may be frustrating. In such designs, it is probably safer to set the backstory (the mystery) at the begining, and introduce further conflicts if the mystery is discovered by the player 'prematurely'. So if the player haven't figured it out, the player will fight against the mystery till the end, otherwise, the player will be trying to convice the others of the truth or the execution of the remedy to the mystery. This gives a more fair gameplay.

The engine can also present multiple grey areas intentionally to probe the player's interest.

I've skimmed through most of Chris Crawford's book now. It's a pretty good read if you are interested in interactive storytelling. I'll write a full review on the weekend. However reading through this book has helped me think a bit more about how to express my opinion on the whole debate Estok and I were having in the last few posts.

As I wrote in my second post at the start of this whole thread, from what I've seen I feel there's two main approaches to the interactive storytelling problem. The character based approach tries to model digital actors with the personalities and attributes of interesting dramatic characters. The plot based approach takes some higher order view of storytelling models or narrative grammars.

However, I don't think a pure character or plot based approach will work. A pure character based approach, attempting to model a realistic human being, will at best be a pure simulation, not a story. A pure plot based approach will treat characters as lifeless symbols, with no dramatic interest.

For example, Chris Crawford's Erasmatron engine takes what I'd consider a character based approach. The core of his system is based the actions that his characters can take. However, he injects plot sense into the mix by limiting the possible actions down to a minimal set of dramatically important events, and by occasionally imposing the laws of drama upon his characters. In other words, his characters aren't fully autonomous as they would be in a simulation; they have to obey the laws of the plot. It's about 75% character, 25% plot.

Another important point, which I think is a big danger for everyone trying to determine the design of such an interactive storytelling system, is that you can't rely on the miracle of emergent behaviour to save your system (note that this isn't directly to anyone in specific, except for perhaps myself, as I find my design to be increasingly the victim of this flaw). You can't just impose a whole mess of rules to define a whole bunch of little things with no overall design, such as low-level character interactions, then pray that it will all work out in the end. This is something that I am going to have to come to grips with myself once I get the time to properly sit down and nut out my design. You can't start on all the little details first, or work on fuzzy generalities. At the start you have to go straight for the guts of your system and plan how the core of the engine will work, as if you can't get that right the whole thing will fall apart.

Re:
There was no debate between you and me, we were on the same side. I was attacking bottom-up character simulation approach, because the thread was steering toward a trivial topic.

There are more variations on the implementation. A bottom-up approach is not limited to character simulation. The elements at the bottom level could be other abstract, objective vectors. For example a vector system that detects and characterise view responses and preferences. The autonomous vectors interact on their own to satisfy the player. The presentation is top-down, but the story creation is bottom-up.

Bottom-up does not mean character-driven. The bottom level interactive units can also be semantic, emotion, and thematic agents of different modes that combat and assimilate one another to compose the story thread. In this approach, a story is not a result of interactions of character. A story is a result of an interaction between semantic, emotional, and thematic threads. The basic units at the bottom level are the forces that fuel each of the threads. These forces fight it out based on the resources such as the available story state and the viewer's attention. The instinct of these forces is to deal as much content as they can with respect to the dominant thread to gain dominance for themselves. The existence of rising action and climax are guaranteed by the escalating power struggle between these forces to gain dominance.

This may sound like that either semantic, emotional, or thematic thread wiil 'win', but the effect is that you will get all three climaxes like a triple knock-out, because all three will be discharging for the last chance gain dominance. It is possible that one thread 'kills off' the others if the viewer only fuel one of them.

Quote:Original post by Estok
Re:
There was no debate between you and me, we were on the same side. I was attacking bottom-up character simulation approach, because the thread was steering toward a trivial topic.

Sorry, I used the wrong word. I meant "discussion" [smile].

Quote:
There are more variations on the implementation. A bottom-up approach is not limited to character simulation. The elements at the bottom level could be other abstract, objective vectors. For example a vector system that detects and characterise view responses and preferences. The autonomous vectors interact on their own to satisfy the player. The presentation is top-down, but the story creation is bottom-up.

That's exactly right, and that's what I want anyone else who has read this far in the thread to realise. You don't have to model a realistic character to get a dramatically interesting story. In fact, doing so would be counter productive. What you have to do is figure out exactly what elements of drama, plot or whatever it is about the story that you want to have in your game or storytelling system, and model that.

For example, take The Sims. The Sims are modelled after physicological and mental conditions, such as bladder, hygiene, entertainment etc. That's because The Sims is more of a household chore simulator. It is not the system to use for a storytelling system. How many times does the hero go to the bathroom in an RPG? Usually never, and if he does it is purely for plot reasons. If you are modelling characters for such as system what you have to do is figure out a set of dramatic properties that you want to include, and base the system on that. It doesn't matter if the result is not normal human behaviour, because you don't want to model normal human behaviour, you are modelling drama.