Quote: Original post by Estok
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.

My comment was not misleading, because that _is_ what I meant. It is your analogy which is misleading because flour and raw eggs are not tasty by themselves, whereas both story and gameplay are 'tasty' alone. Here's a better analogy: a bowl of fruit. Now, if we have a bowl of fruit we can eat it one whole fruit at a time, which would mean reading novels for story and playing arcade games for gameplay. But I personally get bored of the taste of apple before I can eat a whole one. We can follow your suggestion and blenderize all the fruit into a fruit smoothie where story is conveyed through gameplay and they story and gameplay overlap completely. Again, I am going to get bored of the homogenous taste before I drink it all. What I prefer to do is make fruit salad. Each bite has a nice pure taste of one fruit, every bite is a different taste of a different fruit, and I am not bored. A story scene here, a mini-game there... I will repeat, "Variety is the spice of life."

s/s you are not getting it. Synergy is not mixing of the ingredients. It is not related to modifying the variety of the components. Think about how a restaurant is designed. The designer of the restaurant needs to know about the location, the customers, the food, the chefs, the competitors, and so on. From the stove to the food to the chairs, are all customized to maximize the effect of the customer's experience. This is what it means by an integrated design. It has nothing to do with permitting or denying variety of the components.

Another closely related example is hotel design.

Integration between game and story means to create an experience that cannot be achieve by gaming or story alone. It is the variety of color that cannot be achieved by just looking at the yellow ball or the blue ball. The yellow ball is still yellow and intact. So is the blue ball. And you missed the major topic about the lines and the patterns (you chopped off the amazing part, the interlacing of the properties on the balls to create rhythm and patterns).

Think of the design of a figure skating performance. The music, movement, lighting, and costume are all related to enhance one another. Homogenity is not even related to the topic. Synergy and integration is to create property in a dimension unreachable by the components along.

If story is the x axis and game is the y axis, integrating them means to introduce the points on neither axes. It is not about taking the average of the values on a single axis.

You are correct that the baking example is lopsided. I forgot to bake the flour and egg. So this is the corrected analogy:

You bake flour and you get bread. You bake egg and you get baked egg.
If you combine the ingredients, then you can bake more varieties. No one says that you should never eat baked egg alone or even the raw version. Even if you just make a baked egg sandwich, the experience is already different from eating the egg alone and then eating the bread.

Salad is a form of integration. Think about designing a salad. What decisions do you make when you choose the ingredients? Is it simply that the more variety of ingredient the better? What is the meaning of having different types of salad? why not just put them in the same bowl?

A salad is design in such a way that components taste different yet together create a distinctive experience. It is like a well designed flower arrangement. You don't just pick any variety of flower to put in the vase. Just as you don't start drawing on the yellow ball when you receive it, because the patterns on one has to work with the patterns on the other, to create a pattern that neither can produce by themselves.

I don't object your belief that "variety is the spice of life". But in the context of design, life is not just a series of random spikes. The spice comes in a pattern. And that pattern is the result of an integrated design.


Integrated designs


When you said that you saw some half-assed 'integrated' designs, I was not sure what kind of design you were referring to. Can you give a description of such design.




It is really easy to come up with integrated game-story. For example, take Racing as the genre, simply putting theming the races as a grandpix is a form integration, where the order of the races and the fact that there is an ending creates an overall emotional arc for the player. If you want more integration, you can introduce AI for the car, such that how you handle it and what you do during the races determines what the car thinks about you.

For example, if you keep raming the other competitors until they crash and burn, the interface would become cold and harsh, and the handling with get adapted to support brutal manuvers. Tied back to the story, this has to do with how the car allocates the size of its energy buffers for different kinds of boosters and its built-in ANN control system. Therefore, to 'level up' the car in a certain way, you have to perform in certain way. Note that if you are a pacifist driver, you can still manually allocate energy to suddenly ram someone. But your car will be more prepared if you have been doing this all the time.

From the perspective of the player, after getting enough price money the PC can buy more models and level up different styles of racing. When you compare this to systems where your pets/mags evolve simply by feeding it different treats, the car system I am describing is a more integrated design. When you play on-line, and let people look at your car, niched cars are very hard to come by. Because it means that your car survived more and more intense situations, and situations where the competitors tried specifically to destroy your car to stop it from advancing.

This is a more integrated design than normal 'level grinding' and 'getting rare items'. The story is embedded and delievered through gameplay in such a way that it may seem that there is no story. It is not delivered through annoying dialogues or cutscenes. There is certainly no dialogue box that pops up:

choice 1: Push the car a little harder, it can handle it
choice 2: This is it, safety first, there is always the next time if I don't destroy the car.

In this context, you should see that there is a story. And the choices are integrated to the gameplay. The thematic intensity is controlled by the player's desire to evolve the car during a race (i.e. the player will create situations in order to level the car, such as deliberately choosing to ram someone instead of to pass someone). But the story is clearly the PC's journey as a racer.

The objective of the story component is to make the player see himself as a racer instead of a gamer, by integrating all aspects about the game and the game world. The fact that your car is your lifeline and it can die, models the emotion of racers. If you push it too hard it dies. If you don't push it hard enough you lose.

Together, this is a holistic design that considered all three aspects of thematic, emotional, and semantic engagement, where Victory lies in the fine line between defeats.

Ok Well, this is just another update for the Writing Util Prototype underway and also if anyone has any experience in Java let me know and I will set up a Sourcefourge page.

Download Page Here!

5MG - I got to try a new writing aid program today, StoryBase, and it's an awesome collection of plot ideas - uses madlibs-style keyword replacement to put your charactrs' names in the examples, is sortable by various catgories, and is keyword searchable - you may want to check it out for some feature ideas. :)

Estok - I had a busy weekend and am currenly having internet problems, but I'm trying to find time to read through your last two posts and respond to them.

Re: Comparing design objectives and demands

The advertisement suggested that it is a brain storming tool. Ideas is probably the least I would need personally. The target of my design is not to generate more ideas, but to integrate ideas faster. I am not trying to say which one is better, because they are not used for the same purpose. What I am looking for is not a brain-storming buddy.

A second difference is that StoryBase is not designed for designing interactive stories. Non-interactive stories are not control systems, and do not suffer from run-time deadlocks and saturations (i.e. the plot turns repetitive, or not advancing toward a climax due to ill sequence of user input). These are terms unconventional to story writing, but relevant to game story design. In a nutshell, the CAD tool I described is the underlying structure that runs StoryBase, where the plot elements are not drawn from the database, but are defined by the designer using dependency and plot stages.


Cocospace:

In terms of my own personal software, it is now called Coconut Space. I am only going to upload it if someone wants to see it. Because I am using it to simultaneously log the plot ideas for several designs, while programming its engine along the way. (I don't like the idea of designing a tool that I can't use until day n, so I have been using and evolving it all along). In order to post it, I might need to document what it does and how to use it. Due to the speed of its growth, such documentation has no value in the long run (Because, of course I know what it does myself.) Other reasons that I don't want to just upload it is because it contains personal informations because it functionality doubles as a personal planner and calendar.

Screenshot

Legend:
1) CocoSpace is an excel Add-In. It is a .xla file, that you can use no matter what .xls you opened. The design of the Add-In supports multiple projects opened at the same time. In terms of interface, the .xla adds the CocoMenu toolbar, which allows you to access the Coco functions and the customized editing forms.

2) The only data structure that Coco has is the Node. It doesn't matter how you use it however. In the screenshot, every box is a node. A node can be used as a notepad, to represent a plot element, or to prototype processing units.

Node structure - Drawn using cocospace. Every shape you see (including the connectors) is a node that you can click on to read the expanded description. Some nodes point to the same rom entry. For example, clicking either blue nodes will access the same information. The ghetto way to archive nodes is to select them, group them, and shrink them. The funny thing is, no matter how small you shrinked them, the tiny shapes are still clickable. You can zoom in to 400x and editing them.

3) For the sake of a group screenshot, I clamped everything together on the same screen. However, in reality you can space out as much as you want. Following a TDM-style design, the nodes can be group by their level in the hierarchy. Each level can be organized in their own sheet. This means that you can click on the Lv1 sheet to edit the high level connection and documentations, then click on the Lv2 sheet to edit the first level details, and then click on the Lv3 sheet to edit the second level details. The targeted story system is not a branching story, so each level contains networks and flowcharts at different scopes. Because nodes can be shared, editing interface can be done at any level. (If you are smart enough, you will connect the nodes in a way such that when you edit the interface at Lv1 scope, you don't need to make any additional changes at other levels.) This is a TDM design, so it is unlikely that you would reroute the upperlevel networks. The expected operation is to refine the lower level designs. But the interface does not assume you to do things a certain way. You are free to use sheets to organize the nodes however you want.

4) This is a vector of characters with the character names blocked out. Because Excel is a spreadsheet program, it makes no immediate sense to support additional templates for characters. The dynamic variables related to characters such as emotional states are store in the customized ram with custom data structures. For example, the affinity from character A to character B can be stored in a text matrix in the ram. You can view the matrix directly through the ram page, through the debug screen, or by setting up a node as a 'report' node that shows the specified info in the specified format when you click on it. You need to know a little bit about syntax and datastructures to do this. But if you are involved in designing an interactive story, you probably know how to program anyway. Assigning and accessing variables will be a piece of cake. And I am not even talking about VBA, but the scripting support of Cocospace, which is as easy as typing #GameTime# to access and display the game time variable within a story passage.

5) When you think of nodes, you think of cicles and graphs. However circles are not the efficient shape for displaying text. This is why all the nodes you see are rectangles. This part shows a representation of a game map using such rectangular blocks. Lines are not necessary for the map because edges do not cross like how they are connected in a network. The map you see here is not just for documentation. Each node (each box) is a processing unit that handles the event selections as the PC enters an area. In other words, all of them are switching nodes for triggers.

6) This section shows the Lv2 modular plot elements. Each Green box is a catagory for plot elements. For example, under the "Initialization" box are the plot elements related to the game stage initialization. Just like the location nodes, these green nodes are also switching nodes for triggers. Note that there is also a node called "Initialization" in section 3. The two nodes are the same and share the same rom entry, editing either is the same. This means that there are many ways you can index or to find a node, visually. For example, if you prefer drawing the full network, you can still set up columns of index or references on the side to help you locate the node in the enormous network.

A flowchart of a module - Heartbeat is not part of the module, but to avoid the connectors from crossing over it is drawn within. The structure of a module is parallel to the structure of a node. There is a node that handles the processes when a module is entered, following that is a selector that decides which event will occur. After the initial presentation the flow comes to the decision part where the player makes choices. Cs are the effect nodes that perform addition interactions with the player, and Exit is the node that ends the module. The Enter and Exit nodes are the interface of the module. Once they are defined, the content of the module will not affect the connections at the upper level. This is the basis of top-down approach for implementing the node network. Each node can be a module itself. For example, a node that is unrefined can be split into an Enter node and Exit node, where the operations can be elaborated by additional nodes within. After understanding the structure of a generic module, you can avoid the bulkiness of displaying a flowchart by adopting a compact convention such as this.

7) The sheet tabs. Use them any way you want to organize the nodes. Classify the nodes by levels; classifiy them by characters or other catagories; Draw flowchart on one sheet and and in list form in another. Doesn't matter, because all nodes in a project share the same rom sheet. editing it on one sheet is the same as editing it on another. It is just extra organization to help you to get to know your nodes.

8) Similar to section 6, these are the expanded representation of the location modules. Under each green location box are plot elements and events that can occur. The text of the boxes are coded using the abbreviation of the character letters. So "LD" may mean an event that is about character L, regarding subject D. If this seems too abbreviated, you can make the boxes larger to display more text, but usually it is sufficient to let you select those that are likely what you are looking for, so that you can click on it to check the summary box to verified that it is what you are looking for.

9) The prototype story display interface. The number of choices displayed is increated to 5, because there are the general 4 directions and an action button. You can customize the number of choices to model any console gamepad. The targeted product is a purely graphical-and-text story game, so the number of choices is set to 5, so that at any moment the player is not flooded with possibilities.

10) The Editor form. Edit the text, story, description and code all in one. In addition, it also has some testing and debuging utilities. The boxes you see now are for scripts related to a node. They are small because the script expected for each node is not long. However the scripting is powerful enough that you can easily program a complete blackjack using just one node by letting it loop back to itself. If you are really nutz, you can actually program the entire game using one node. Because each node is capable of carrying out the basic functions of input, output, and processing, and you can still access the ram. The script would just be really long.

11) The list form. Allows you to compose and save any list by clicking on the nodes. Also allows you to load the list related to a node and highlight all items in the list. For example, if you make a node called "cat" and use the list to store nodes, the stored list may be the plot elements related to the "cat".

12) The summary form that appears when a node is clicked. Click on it again brings up the Editor form. Because of the summary form, the text displayed on the node does not need to be fully meaningful to save space.

13) The FlexPad editing form that allows you to edit or view two fields from any node from any project. Recall that the boxes on the editor form for choices are small. Double clicking on them will bring up the FlexPad so you can edit the field in a larger pad. The Dual tab under the Editor form itself is a dual editing for the description and story text, So together, this makes 4 screens that you can simultaneously cross-reference edit:

Screen1: Node description
Screen2: Node story
Screen3: The global Todo List
Screen4: A reference from another node

If it is not enough, the Testing Tab of the editor form has an additional scratch pad, and you can also use the preview screen as a read-only reference.

To avoid frustration of using it while it is under-documented, I am not going to upload it until I map enough examples to show you what can do instead of letting you imagine what it can do (by coding small cute game modules examples and tiny benchmark interactive stories). Without the examples you might not comprehend how to use the same building block to so many different things.

I can post the un-documented version if anyone is interested.

Overall, this thing does not attack the problem that StoryBase attacks. It is not about brain-storming of writer's block at all. It is for prototyping and simulating interactive stories.

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.

Quote: 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')

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.

Quote: Original post by Estok
Re: Comparing design objectives and demands

The advertisement suggested that it is a brain storming tool. Ideas is probably the least I would need personally. The target of my design is not to generate more ideas, but to integrate ideas faster. I am not trying to say which one is better, because they are not used for the same purpose. What I am looking for is not a brain-storming buddy.

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.

Quote: Non-interactive stories are not control systems, and do not suffer from run-time deadlocks and saturations (i.e. the plot turns repetitive, or not advancing toward a climax due to ill sequence of user input)

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

I agree BTW that StoryBase is not intended for interactive story design, but I think it could be easily modified to make it useful for this purpose. Are you familiar with the card game Once Upon A Time? I think it represents a nice conceptual bridge between StoryBase and a flowchart/node system, since Once Upon A Time consists of cards which are nodes belonging to a few different classes: characters, objects, and plot elements.


You wanted some examples of what I mean by half-assed integrated designs. Please note that while these may be good games, they are never good games because of their stories.

The Sims/Creatures is the most obvious example. These games are based on the concept of a dollhouse, where the player creates characters and acts in a god-like role toward them. But the management-style gameplay of these games actually inhibits the player from regarding their characters as real people and acting out stories with these characters, totally defeating the dollhouse model. So here we have a good implementation of a half-assed design choice.

The game MonsterSeed is a more crude example. In this game you control monsters and send them into battle against the opponent's monsters. The monsters have one of 5 personality types, and get lines of dialogue when certain events happen to them in battle: begining the battle, acknowledging the player's orders, making an attack, getting hit, and dying. This did manage to superimpose some character development and character conflict on battles in an attempt to make them more meaningful, but between the randomness of the dialogue and the fact that none of the character development carried over into the main game, it was a half-assed implementation of an average design choice.

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.

Quote: Original post by 5MinuteGaming
Ok Well, this is just another update for the Writing Util Prototype underway and also if anyone has any experience in Java let me know and I will set up a Sourcefourge page.

Download Page Here!

Character name, age, height, and weight are exactly what I meant when I said the template needs to be overrideable/customisable. How can I explain this... do you know about databases? A character sheet should be a database entry, where Name, age, and other key pieces of info are keyword slots (or key paragraph slots for larger chunks of info like personality), where both the name of the slot and the contents can be edited, and then the outline and level editors can read the info out of the database and into templates, nodes, or madlibs.

Also, you badly need to have a gender and number associated with each character and object so you can automatically handle pronouns referring to them. Examples of this can be seen in the Dramatica demo.

Well SnS, I know what you meant and I was already planning on doing that. But I didn't want to just present that Designer with a blank TextArea or an Excel sheet I wanted to put the basic 'COMMON' Character attributes there for them to start somewhere. There will be options for adding 'CUSTOM' fields and character traits in as well as descriptions and overall feel for who the character is.

I am changing a lot about the Utility, currently and I will let you know when the first release comes out so that you can take a look at what I have implemented.

I will attempt to make it as flexible to game design as possible.

Okay - I agree that Name is common and basic, I just don't think the others are. Personally I would make the default slots: Name, Short Version Of Name, Gender (male/female/neutral), Number (singular/plural), Visual Description, and Ability. I picked these because the first 4 are integral to letting the program automatically discuss characters created by the user, and the last two because all characters, even inanimate object characters like a special magic sword, have soe sort of appearance and ability. Then you could have a Human template which has slots for things like Age, Weight, Race, Hair Color, Eye Color, Skin Color, Clothing, Profession, etc.

How would the program interpret the Number(singular/plural) 'slot'? I would think that you would define each Character individually and then you could group characters if you wanted to show interaction between groups of characters and their relation to each other.