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.

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.