Quote:Quote: Original post by Estok
But overall, putting a story writer at the designer seat is pretty sub-optimal.
I disagree, at least for story-based games such as RPGs. I think that the ideal setup is when the story writer's design comes first and is implemented by a gameplay designer. I see story as the strong structure which should be filled with a variety of gameplay.
The designer I was refering to is not the gameplay designer, but the overall designer. A story writer is unfit for the job because a story writer doesn't know how to take advantage of gameplay. You have a limited view of what a game is and what gameplay is capable of. You are also classified as a story writer. This is an example of why a story writer is unfit, because a story writer doesn't even see the possibilities, but rely on the assumptions of how the game works based on older designs. The role of gameplay is boarder than just to fillin the actions of the story. There is a big difference between 'a game designed for a story' and 'a game designed with both story and gameplay in mind from the beginning.'
You can check whether you are more of a designer or story writer by answering these questions (yourself):
- "How often do I think about the gameplay when I design the story?"
- "How much does the projected gameplay influence the development of the story?"
- "How much should the gameplay influence the flow of the story in the final product?"
- "Are the gameplay elements a natural consequence of the story?"
- "How much do I want to use gameplay to tell the story?"
- "How does gameplay experience reflect the mood of the story?"
- "How does the story dynamically change to reflect the gameplay experience?"
If you find yourself paying much consideration to these aspects, then your role is a designer, not just a story writer, and not just a gameplay designer
Quote: If we're imagining the ultimate game design too, I would think it would be a drag-and-drop IDE something like Microsoft Frontpage (only making playable games rather than webpages of course) which would completely eliminate a programmer implementing anything on any platform because this would all be done automatically. So the 'design document' would be the rough draft of the game itself.You are incorrect that programmers will be eliminated. But that is a minor and off-topic error. You are correct that the the resulting design document is a rough draft of the game. And we know that that is desirable because a demo is a more convincing form for a presentation, and that such demo comes with no additional cost. Think of it this way: you are just documenting what your story should be like, but it turns out that you can play it also.
Quote: Yeah, there's the difference between your goals ad my goals right there. I never need to integrate ideas faster, because they're already mostly integrated as they occur to me. I need aid making sure I have a solid plot/game structure to file my ideas into and help me identify holes where I need to come up with more ideas. I also need a brain-storming buddy to make sure I can find the right idea for every hole, which will do everything I need and want it to do.Just a reminder, the difference between our needs comes from the fact that we use different design methods. In TDM, the solid plot/game structure exists since day 1. Everything else are progressive elaborations. I choose this design method because I can play the design while designing it. In terms of design, this method should be very assuring because you know from day 1, that your design works. You are correct that ideas are mostly already integrated as they occur, because they are not random. When an idea comes, I already know where it should be because ideas come in the from: "I am going to add the part where when situation x occurs, the player can do y and z will happen instead of w." So I personally don't have a strong motivation to achieve the CAD objective. But then when you think about this:
- Action Z will need requirements A, B, and C, I know that all of these requirement can be satisfied at some point, but can they be all satisfied before situation x occurs? Am I adding a plot element that is impossible to reach?
A major design objective of interactive story is to diverge the plot, to allow possibilities. The general goal is not to leash the player to some set storylines. The effect is to create as much of an illusion as possible that the player is doing whatever he wants within the context of the story. A choice in a story is not as independent as choosing to use a hammer over a shovel to break a window. Each choice says something about what the player thinks, and determines how the story characters interpret the situation. This means that each additional set of plot elements entertains an additional line of thinking of the player. Imagine this design:
(Patlabor) In this episodic design, you play the pilot of a mobile police unit, engaging in various emergency missions as they occur. Some of the missions are related. In the game design, the occurence of the missions are related to how the pilot interpret the world, and the game engine selects missions that attacks the player's conviction if such conviction is detected. The pc's emotional state and believes will also determine the plan that the team will use in the missions. The presentation will not drive the game into an ethical or philosophical lecture, but will leave the player wonder, 'am I doing the right thing? are they really criminals? am I serving justice?'
* Note that this design IS an RPG, and it is integrated between story and gameplay. You should be able to tell that this is not the case where there is a story, and there is the game. Story and gameplay gang up to get the player through the subtle negative feedback system (negative because the player's conviction is contested, not promoted).
When you look at this design, you would ask what kinds of convictions can the system detect. You may begin with just the basic convictions: the police force is good/evil. Which just these to classfications, you can already finish the design. Now suppose you want to include more detailed convictions, such as American Imperialism (which is the default political view of patlabor, like many other animes), then you will be adding a set of plot elements to present and detect this aspect. The idea here is not about adding a mission that deals with the topic and ask the "What do you think about American Imperialism? choice a, b, c ..." It has to be a lot more subtle. A design goal can be to obfuscate the sensors so much that the player never realize that the game is collecting data about the player's political views. To the player, the story somehow bend toward a certain topic that the player is aware of.
Quote: I can't help but think that there must be a conceptual flaw in an interactive story engine where deadlines and saturations can possibly occur. It ought to be completely predictable from the player's choices and accomplishments within the game where the player should be in the game at any time, and the player should oly be able to make choices and achieve accomplishments which move the plot forwards, so deadlocks and saturations should theoretically be impossible.What you don't realize, is that in an interactive design, a general goal is to let the player customize the plot. Yes, the idea is to move the plot forward. But the plot is not defined before hand. The question is, are they enough operators for every situations to move the plot forward. Deadlocks and saturations are your concern in another part you post near the end below.
Quote: Even in an interactive game, the experience of playing the game is inherently linear because the player exists in time and must encounter the contents of the game in some order; the design of the game ought to control this order so as to create the best experience for the player.You are not getting the gist of the power of interactive story design. Of course the experience is linear from the perspective of the player, but that linear experience is not individually designed by the designer. You are correct that there is the notion of control. The design of that control IS the design of the rules that determine what plot element can occur and what can't.
Quote: A story's plot structure is the natural choice for organizing the game's contents to give the best gameplay experience because plot structure has evolved over hundreds of years under direct pressure from audiences to produce the most satisfying entertainment experience. And that's why I think story design should come before and be considered a level above gameplay design.You are correct that plot structure is very important. This is why when you look at Cryo, the gameplay is divided into gameplay stages to match the intensity of and plot arc. You are incorrect that the story design should come first. Even for a game without a story, you still have to entertain the thematic and emotional arcs of the gameplay. In a nutshell it means that the last boss/level has to be the hardest and most intense. The arcs are general properties to any shared by any presentation, they are not just for stories and plots per se.
I don't know Once Upon a Time, but Storybase and interactive story design are not conflicting tools. There is nothing that prevents you from using Storybase along side with an interactive design tool. From the look of it, Storybase is actually pretty trivial to code. We as a forum can probably come up with our own for free in no time.
My experience is that when I see the posts in the section of the forum, most of them are restricted in presenting their design as a linear story. TechnoGoth a while ago presented a flowchart for his story about the biomutant company. On that chart there were variables but no simulation capability to let the reader to simply experience the story. When I presented the idea of Dreambell, I had inevitably stop because there was no easy way to show how the story branches, how the plot elements interacts, and how the engine knows which plot element to present. We come to a point as a forum where we want to design and discuss interactive story structure, but at the same time don't have a tool that facilitate the exchange of ideas. This is what I think 5MG and I are trying to do.
Have you ever disected any interactive stories? Do you realize how primitive their structures are due to the limitations on design tools? They look like a linear story or a branching story with minor customization. If it has a basic structure of a tree, it is not deep becasue the number of branches is too large. If it is basically linear, the variations are few because each variation has to tie back to the same node, because there is insufficient representation power for the designer to keep track of the possibilities.
Re; Half-assed designs
After describing those designs yourself, doesn't make it obvious to you how to make them not half-assed? If you have to continue and improve the design, what would you do? It simply doesn't make sense that you would give up on integrated design just because you saw this bad designs. Does the idea occur to do you: "If I were to design this, I would do such and such instead." Don't let these crappy designs define what integrated design is.
If you haven't have enough better examples of integrated design here is another one:
Quote: LittleRedRidingHood and the WereWereWolves
This game design is based on the card game Werewolf. In this game you play LittleRedRidingHood who is skipping happily to the town to deliver the fresh bread as ususal when the mayor announced that the werewolves are back. During the day the werewolves look like normal villagers, but every night they will kill the villagers. The werewolves are invincible at night and are completely transformed in a way that it is not possible to recognize which villager it is. The village doesn't know what to do except to vote out (and execute) a villager every day hoping that they will get the werewolves among the villagers. LittleRedRidingHood and her friends may be on the chopping board. She must therefore tries to identify the werewolves and convince the villagers, while saving her own ass.
This is a fully integrated design. It should occur to you very clearly that there is no 'plot' that the engine tries to snap back to. The engine has to select the situations and interpretations to dramaticise the experience. It would be misleading to say that such design is 'story-driven' because the game is the story. The overall design is ridiculously joyful, where the villagers will accuse one another with ridiculously irrational or personal reasons. The whole game is a pack load of jokes and parodies one after another.
Re: Generating Climax
Quote: Wavinator and I had a big argument over this topic when we were working on a project to create a game which automatically generated story content. Wavinator wanted the story to be told completely by character actions and changes of state of characters and objects in the story world. I completely disagreed with this, arguing that to achieve a teleologically satisfying gameplay experience it was necessary to generate a plot structure, use this structure to direct the character actions and character/object state changes and organize them into a structure of rising action, climax, and resolution, and point out this organization through narration.Your view is not entirely correct. There are situations where climaxes naturally exist. For example, if the game story is based on a tournament, then a climax will inevitably exist because the contestants will no longer reserve their strengths, and use all of their secret abilities. This has nothing to do with the engine trying to drive the plot a certain way. It is based on pure strategy, based on simulation, like the way Wavinator described. This idea is the same as Plot Content Accumulation if you remember what it was, where the Intensity of the plot naturally accumulates due to the context of the situation. It is unclear whether you were correct or not, because the difference lies in the definitions of the words.
In a situation where Plot Content Accumulates naturally, the engine never really try to generate or to stick to a plot structure. But the very fact that energy and resources are accumulated for a point near the end of the game where all of it are released, shapes a plot structure. Did the engine generate the climax? Or is it the design that allows the climax to generate itself?
I would describe this situation as where "The climax generates itself due to plot content accumulation inherent to the design," instead of "The climax is generated by the engine to fit a desired presentation arc."
Therefore I would say that you are incorrect. An arc can exist without the engine actively trying to make that happen. The decisions made by the NPC can receive no influence from the engine to create a climax, yet a climax can naturally exist.
When every a character is trying to achieve any goal with discrete result, it is inevitable that a climax exists. The cause of rising action can always be satisfied if there is the distance between the character state and the goal state can only be decreased gradually. If your design satisfy these two requirements, then the arc (semantic, thematic, or emotional) will naturally occur without any intervention of the engine.
