Quote: Original post by Estok
The plot and play dual visualization is a sign that you are not heading toward the designing of an integrated game story--a game where the story is the game, and a story where the game is the story.

Just so it's clear, I have never been in favor of games which have no delineation between story and gameplay. My personal opinion is that gameplay and story use very different methods to fulfill very different psychological needs in the audience, and trying to force total integration of gameplay and storytelling usually results in doing both half-assedly. Also, I think it encourages the clearest thinking about each element of game design if you can split them up and work on them one at a time rather than having everything lumped in together.

I'm afraid you're more of an expert than I am Estok. You'll have to forgive me cause I don't see exactly what you're trying to explain. Am I right in saying that you would like a 'tool' that could take a few scribbled notes and put them into an organized plot structure with branching nodes, transistions, and event triggers for a game story.

I modified the prototype so that there is functionality for the buttons although I haven't added in all the information and fields that I want I am working on it. Things go slowly when you don't have a lot of time to work on it.
I also modified the program so you can connect Nodes and so that you can view the node connectivity in the note editor. The note editor is just a place holder for the level or plot arc editor. I will also want to add event triggers, and transition rules/conditions. I think!

That is if I'm understanding you guys correctly?

Quote: Original post by 5MinuteGaming
I'm afraid you're more of an expert than I am Estok. You'll have to forgive me cause I don't see exactly what you're trying to explain. Am I right in saying that you would like a 'tool' that could take a few scribbled notes and put them into an organized plot structure with branching nodes, transistions, and event triggers for a game story?

Estok, I kind of understand what you are saying, but I don't understand why minimizing the cost function is the most desireable goal and 5MG should build the whole software around accomplishing it. I would think the most desireable goal would be helping the software user create a complete design document which could easily be used to produce a game.

Re: Integrated design

At a certain higher level design there is something called synergy, where the components become interdependent, and the value of the whole is greater than the summed values of the components. This is integration, it is immersion. To say that it is better to split the development of plot and play is like split the dialogues and the music in an opera.

There are something conceptually wrong in your comment.

1) A major objective of a design tool is to expand the limit of what the designer can accomplish. It is clear that an integrated design is superior. In your situation, the design tool should allow you to complete what you could only complete half-assedly on your own. The existence of tools allows designer to think better. And designer with better thinking process allows the design of better tools. This is the basic perpetual cycle between technology and design. There is no reason to retreat from it. Attacking these weakness is a major d'etre of CAD tools.

2) No one ever talked about forcing total integration. If you think that you are forcing it, you are not doing it. A designer never trade off integration if the cost permits. Look at how disneyland design a theme ride. Do you see how they use every single part that they can control to enhance the experience? You are supposed to design your own stage for your play if the budget permits. If you don't know how to do this you can think in discrete steps, where you first design the story, then design the gameplay for it, then based on how the gameplay works, modify the story to take advantage of the gameplay, and then modify the gameplay to better suit the new story,.... When you think like this at 1GHz you might as well not separate the two at all. There is nothing being forced. This is the natural consequence that a design becomes integrated.

3) Story design in an integrated game-story design is not storytelling in the common sense. I have explained this many times and I am running out of new ways to describe it. There is an explanation to it even if you believe that "gameplay and story use very different methods to fulfill very different psychological needs". Imagine there are two small balls in your right hand, one blue and one yellow. Juggle them clockwise and you see the two balls with distinctive color following each other. Now imagine that you can levitate the balls and allow to spin on its own at high speed. Now you see a green donut. Now imagine that you can put a green dot in the yellow ball, and a red dot on the blue ball, and you are trying to spin it with a rotation frequency such that a distinctive brown line appears on the green donut. Now, you tune the frequency to achieve different patterns. At this level, it is an integrated design of game and story. As a designer, you no longer talk about the components separately, because the goal of cannot be described by either component alone. This is a basic concept of design and strategies. It is closely related to how you use the resources to achieve something unachievable by the components alone. You are at a very slow-mo in terms of this kind of big picture at the overall designs to see this. When I give you the yellow ball, you begin to draw details on the surface. I say you don't need to do that. You ask why. I say, because I am going to spin it with the blue ball.


Re: Functionality

Quote: Am I right in saying that you would like a 'tool' that could take a few scribbled notes and put them into an organized plot structure with branching nodes, transistions, and event triggers for a game story.

This description runs the risk of identifying the CAD design as one of the impractical magical story creation tools. The design is a very concrete implementation with a well-posed problem and the corresponding existing algorithms and heuristics. I presented it by framing it as the travelling sales man problem to show you that operations of the software are well studied. It is not a fantasy.

The actual notes you would enter to the raw engine will not be scribbled notes. They are notes with defined conditions to occur and effects. The condition to occur is not the full condition, and the effects will have rooms for adjustment. The objective of the software is to connect the nodes (which IS defining the transistions), and elaborate on the triggers (creates the triggers based on existing triggers).


The followings are about your prototype, not the CAD tool I described.

For the sake of designing your prototype, it is beneficial to have a benchmark to work toward, so that you know what are useful what are not, and the priority of the useful features. It is recommended that you provide the benchmark so that there is no conflict of interest. However, in this whole thread you are asking us to provide the benchmark. So I will describe a benchmark based on the deserted island scenario you started previously (my island.xls used the same concept).

CastAway:

This is a story about a man stranded on a tiny deserted island with a coconut tree and several coconuts. Through the interaction of the man and his tiny surroundings, the game engine will interpret the emotion of the player, and to present various flashbacks and thoughts of the man based on those interpretations. Only through letting the man experience various kinds of emotion can the player see all the events leading to the current situation.


If you think that your utility should be able to describe this design, and that you want to use this design as a benchmark to work toward, I will provide further details on the targeted features of the story-game. There is a horde of high-level design concepts in this compact example, making it a high quality benchmark.

Well, I should state that my intentions are for this software to create a way of interfacing the Story and the Ideas surrounding the Writing elements and the programmer. So as to give both the Designer and the Programmer a tool in which to transition from Story development to Software Development instead of the Writer just creating some Word document or flowchart and saying, "ok here you go C/C++ programmer this is what I want". And I want to add in the Dialogue builder to help quickly enter dialogue and the plots and flowcharts so that you can see the level design and can create and edit characters. Also have a relationship diagram to show the conflicts between characters and how they change from one event to the next. Also have a Game Design Document Template so that you can export the whole project to a standard format and there you go you have one format you can give to the programmer or you can create your own exporting template using some xml stuff or what not. How does that sound?

Quote: Original post by Estok
3) Story design in an integrated game-story design is not storytelling in the common sense. I have explained this many times and I am running out of new ways to describe it. There is an explanation to it even if you believe that "gameplay and story use very different methods to fulfill very different psychological needs". Imagine there are two small balls in your right hand, one blue and one yellow. Juggle them clockwise and you see the two balls with distinctive color following each other. Now imagine that you can levitate the balls and allow to spin on its own at high speed. Now you see a green donut.

But what if I believe that the audience would rather be able to see the two destinctive colored balls then the green donut? Variety is the spice of life, homogenity is the easiest way to bore and audience.

Quote: Original post by 5MinuteGaming
Well, I should state that my intentions are for this software to create a way of interfacing the Story and the Ideas surrounding the Writing elements and the programmer. So as to give both the Designer and the Programmer a tool in which to transition from Story development to Software Development instead of the Writer just creating some Word document or flowchart and saying, "ok here you go C/C++ programmer this is what I want". And I want to add in the Dialogue builder to help quickly enter dialogue and the plots and flowcharts so that you can see the level design and can create and edit characters. Also have a relationship diagram to show the conflicts between characters and how they change from one event to the next. Also have a Game Design Document Template so that you can export the whole project to a standard format and there you go you have one format you can give to the programmer or you can create your own exporting template using some xml stuff or what not. How does that sound?

Sounds fine to me. Perhaps one more 'also' about music/storyboarding/animation concepts.

Let's keep things on track here Estok, we don't want to complicate the story writers life by intergrating a unique software gameplay idea. Rather we want to take common methods and practices that game designers and story writers use and allow them to perform those quickly and efficeintly within a program. The program will output their work as a Game Design Document or another type of format which can easily be read, understood, and used, by programmers of a Game Development Project. Keeping the Work done on the Program largely independant from the type of Software Development Lifecycle being used or the Programming Language or Library being used.

As far as the ability for the software to generate events, triggers, and transitional conditions to handle all the possible actions of the PC, I think that such a tool would be quiet useful if indeed it could accomadate a certain amount of independency from the games implementation requirements. Since you have expressed a vivacious affinity toward such a tool if indeed you mean 'tool' in the sense of part of a program and not its only capability. We would all be humbly greatfull if you would do the honors in coding such an addition to a Game Writers Utility Program.

If you want the utility to be able to describe gameplay you will need to let me know the common methods for designing gameplay so that I can add them into the design of a Writers Utility. I know that the prototype looks really crappy but I had to start somewhere and this is where I am starting so just bare with me and keep giving feedback. Thanks!

Re: homogenity

Your comment was so misleading. Gameplay is blue, and story is yellow. If you don't integrate them, all you see is a sequence of filler cutscenes followed by filler gameplays. You are saying that you would rather eat flour and egg raw instead of letting them be baked into a cake. Look at animal crossing.


Re: objective of the 5MG tool

I know what your objective is, but you are in an old paradigm. In terms of game-story design, there are three entities.

Level 1) the designer
level 2) the story writer and the programmer

The software you have in mind is for a writer to communicate with the programmer. My design is for the designer to communicate to the implementers. Story writer and programmer both work under the design goals and specifications set by the designer. The job of a story writer is not to create content, but to substantiate the design. (You don't need a writer to design a story, you don't need a programmer to design a game.)

I have nothing against your intention. But you should very distinctly know that a story writer is not the designer.

"So as to give both the Designer and the Programmer a tool in which to transition from Story development to Software Development instead of the Writer just creating some Word document or flowchart and saying, "ok here you go C/C++ programmer this is what I want"."

I understand your intention. I don't think this is the way that a design should work. The role of the software is more involved than to implement the story. Take a step back and look at the overall design. Both story and gameplay are just ingredients. flour shouldn't tell the eggs what to do and the eggs don't tell the flours what to do. both of them listen to the recipe. The one that designs the recipe needs to know how story works and how game works, at the same time not bogged down by the techinical details in either fields. The software that you are imagining is for level2-level2 communication, it is in itself a flaw because it ignored the role of level1 design. I accept the fact that you need to start somewhere. But overall, putting a story writer at the designer seat is pretty sub-optimal.

Quote: And I want to add in the Dialogue builder to help quickly enter dialogue and the plots and flowcharts so that you can see the level design and can create and edit characters. Also have a relationship diagram to show the conflicts between characters and how they change from one event to the next. Also have a Game Design Document Template so that you can export the whole project to a standard format and there you go you have one format you can give to the programmer or you can create your own exporting template using some xml stuff or what not. How does that sound?

I didn't get off track, I know that these are what you are trying to do. What I had been saying is that you don't seem to know the nature of dialogues in a game. This is why I recommend you to work toward representing a benchmark. At this moment you don't seem to know enough to judge what functions your software needs to support. The kidns of story you are thinking are too linear and simple. Instead of looking at the components of a the story such as dialogues, look at the flow of the story first.

Imagine that you are designing a mystery game, do you see that there are many controls and variables that even a story writer will need to understand? An ultimate idea of TDM-based design tool (Lv1 to Lv2 directive), is to allow any writer to pick any arbitrary node, and understand the flow and mood with minimal effort, and to implement the written parts of the dialogues or other passages. The same go for the programmers, that any programmer should be able to see all the affected variables and flows, and implement them on the actual platform. At that point, a 'design document' can be declared obsolete. (of course, ideally the same writers write the whole thing, i am just showing you the power of the design tool, and how it is beyond the tasks of a 'story writer')

You don't want to make a software that bounds the imagination of the designers and make the resulting designs cookies from the same cutter. This is why you need to work toward some high level designs to ensure that your software does not corner the users.

I am not trying to stop what you are doing. I am letting you know that there is a gap between what a designer needs and what you are providing. Finish this and version 2 is right around the corner.


There is no unique software gameplay idea here. A month or two from now, when you start mapping stories using your software, you will understand what I said.

"Keeping the Work done on the Program largely independant from the type of Software Development Lifecycle being used or the Programming Language or Library being used." You might have misunderstood me. Of course these has to be separate.

Quote: As far as the ability for the software to generate events, triggers, and transitional conditions to handle all the possible actions of the PC, I think that such a tool would be quiet useful if indeed it could accomadate a certain amount of independency from the games implementation requirements.

You misread what I wrote. The software does not generate events. It is not a fantasy auto-storymaker. It is an event scheduler, that uses the conditions defined by the designer to put the nodes in place. Example:

Source s = PC is happy (u)Sink t = PC is angry (v)Operators:r1 = from happy to surpisedr2 = from happy to embrassedr3 = from surpised to confusedr4 = from embrassed to revengefulr5 = from confused to angryr6 = from revengeful to angryJ(G) = #(s-t) // The number of source to sink paths(in this case, the least the better, to group the paths as tightly as possible)Output of the algorithm under Strong Problem Definition:   .- r1 - r3 - r6 -.s -+                +- t   '- r2 - r4 - r5 -'drives states u=happy at s to v=angry at t

This is the basic operation of the algorithm. In this example, the operators oversimplified, but you should see that the operators are not just blank elements up to the algorithm to interpret. This is a more realistic operator that the designer would input to the algorithm under the Weak Problem Definition:

Designer comment description:
"while the PC is exploring the area under Tenrah, there can be a situation where the PC and frequency are trapped in a cell of rising water due to the melting ices of the cooling system of the TaraSuh processor. The bonding and the will of between PC and frequency will determine how frequency react to the situation."

A partial list of entrance conditions (typed or graphically set by the designer):
Stage3, Sub-Tenrah, Frequency, MeltingIceCore; (this list means that this node can only occur if the game is at stage 3, and PC is with frequency under Tenrah, and the icecore is melting)

After inputing this, the algorithm will find the place in the design where this situation may occur. The Prerequist of MeltingIceCore will greatly limit the search space. In this case, the algorithm may link this to the node where Shamila had been nuking the PC and Frequency above the frozen layer. The algorithm may also create links that don't make sense to the designer. For example, if the designer forgot to include the prerequist of MeltingIceCore, the algorithm may link this node to arbitrarily large number of nodes. This is a signal to the designer that the node may be too general.

It is not a 'capability' that the user can make use of it. It is a button the user can click on to generate the network. You select the new operators, click on the button, and the network is update and errors are reported. Select the newly included operator (plot element) in the catagory view, click on the dependency button, and check what plot elements may lead to the newly added plot element. Check whether all of the transitions make sense, and if not, redefine the variable that will discriminate the incoming nodes by draggin the new operator to additional sets of requirements. The software does not correct the errors, it doesn't know what the story is all about. But it helps the designer debug. This debugging at the design level, it is not a task for story writers or programmers.

To the eye of the player, a new possibility has been added. To the eye of the designer, the algorithm makes it easier for him to link the new content to the existing design. (In reality, Stage3 events are climaxes, and their existences are highly coupled to the meaning of the story, so there is no reason that the designer would be using an algorithm to link it. Imagine that you already have the structure down, and you are adding variety for the climaxes.)

Imagine how a designer would add the same climax using your software. What paths and states will the designer need to check before adding it? How does the software help the designer in the verification? How does it save the designer the trouble of editing the flowchart related to the plot element?

The designer should have a concept of how the game engine works. For the particular design, but the above shows that it is not required. The designer should also know how stories and story arcs work, but the writing of it is not required. The designer certainly does not need to know the exact dialogues, however, the software also provide tools for that documentation (and simulation).

Due to the existence of simulation, the result of the software is a proof that the design works. This provides a powerful incentive for people join the development. (You can already play the game, the only thing is that there are only place holders for the dialogues and it is written in the wrong platform. But given the complete design, you are correct that an exporter is not difficult to code for a generic engine or an engine customized by the programmers.) Another strong incentive is that story writers and programmers know that new contents are easy to add. So there is still a lot of room for more creativity.



Re: Describing Gameplay

I don't see the difficult of describing gameplay. In fact gameplay is a lot easier to describe, beacuse it usually just consist of a set of rules. All of it together is just a module in the eye of a common designer. I think this is the way you see gameplay so I don't see the difficulty.

For integrated game-story on the other hand, the story and the game are either the same thing, or that there is story element in gaming modules and vice versa. There is again no difficulty because they are the same anyway.



I don't mind the look of the prototype and you shouldn't either. At this early stage we concerns are the content ot he prototype. There is no argument on what you are implementing now, the argument is on what you had not thought about implementing.

The previous topic was CAD tools for designing multiplot stories. The next topic is multithread design. A linear story is a trace of a multiplot story. A multiplot story is a 2D trace of a multithread story.

Imagine a network as a statemachine for the PC, how imagine that the RNPCs have their own networks, interconnect them, and you get a stack of networks. At every heartbeat each layer of the network will transit, and their effects will influence one another. In the past people classify events as scripted or simulated. I am telling you how to design CAD tools to aid the hybrid implementation for the 3D story.

You should start seeing that this is really about design, not writing or programming. But each transition is part of the game, and also part of the story. To play the game is to drive the story to a desired state, and to experience the story is to play the game of driving the story. Well-designed CAD tools make it easier to represent and debug multithread designs, which in terms make it easy to create multiplot designs, which makes it trivial to create linear designs.

Well, now I understand where your getting at. You are saying that the tool is a designers tool and should encompass all the aspects of designing a game. Therefore, I should look at things from a designers perspective and not just a Story Writers, if I want to include this program for game development. I like your last comment it was very well put.