Story Management
David A. Cornelson
I'm thinking about collaboration again, but this time I'm focused on the
author's portion of work. Well, that's what I've been focused on all along,
but I want to narrow it down a bit.
If one were to create a story manager, what actions would one need
available, what data to be saved, and such?
I was thinking that if you were strictly authoring, you would need to be
able to:
1. Create Story
a. Manage Story Elements
i. Manage Scenes
1. Description
2. Synopsis
3. Locations
a. Descriptions
ii. Manage Puzzles
iii. Manage Objects
iv. Manage Interactions
v. Manage Playing Character
vi. Manage Non Playing Characters
I think I need to draw a line on what my idea of the author role is and what
it is not. Here's my example:
The author writes the beginning of a scene and it contains numerous objects
(scenery) and a few common things like doors, windows, trees. Normally, an
IF author would have to consider what these elements required within the
context of the scene so that they were taken care of during game play.
My thought is that the author should only be concerned with writing. Any
issues with objects and their interactivity implementation is beyond the
authors role. I see this as a designer's role and I'll get to that later.
Now, if the author is specifically concerned about writing something about
some objects, say for a puzzle, then they would need to explain in side
notes the workings of the puzzle. Such as, "(in order for the PC to get to
the back yard, they need to get past the dog. This is done by retrieving
some food. The food is located in scene xyz and notes on its retrieval are
there)." - So the author is explaining very generally how the interaction
functions, but they're not detailing the logic.
In the example of doors, the author may or may not wish to note that the
door is lockable and how it is unlocked, but they would only note this if it
were important to their story. Otherwise, they wouldn't be required to say
anything. The designer and then programmer would know to implement a
functional door in IF code and other refinements would take place later. Of
course a short-hand for authors might appear with something like a door,
where they note "(door is unlocked and never needs to be opened or
closed...the PC and NPC's can walk between locations without taking a turn
to use the door.)" - Of course the designer would determine how the door
actually functioned and relay this information to the programmer. The
programmer would implement the designed functionality and the designer would
approve it. Then the author would review it and make suggestions
accordingly.
My questions are about how this process might work in a real world
situation. How would you break up your story into managable elements and
where might you draw the line with a designer?
Your insight is appreciated,
Jarb
Cryptonomic
message news:J5Ocnclcdbt...@speakeasy.net...
> Hello,
Check out Writer's Forge for a similar idea, although not related to
Interactive Fiction. It is at:
http://sourceforge.net/projects/writersforge/
If nothing else, that may give some ideas. I was thinking of ideas along
these lines myself in terms of whether or not it would make sense to add
some component to IF Builder that would allow people to do "story
management" regarding what they are creating. First I think a good business
case, so to speak, needs to be determined. Would people actually want and
use something like this? Features for IF Builder that I thought would be
critical turned out to be features that people could not have cared less
about. Other features that I thought would be mere afterthoughts turned out
to take on paramount importance.
The other thing is the complete separation of role you mention. In my case,
if I write an interactive fiction story I am the author and the implementor
(most likely) and, as such, how does that correlate with how I would use a
tool like this? Many programmer's who are also the designer might see this
as just an extra step that they would not need to take (unless the story
manager also converted to a story file in a given language). So how much
separation of role does this tool demand? If so, is that separation of role
common in the development process for interactive fiction?
> My questions are about how this process might work in a real world
> situation. How would you break up your story into managable elements and
> where might you draw the line with a designer?
To me (and bear in mind, I have written no interactive fiction), I like to
think of it in terms of plot. I like to consider:
What is happening?
Who is it happening to?
Why should we care?
(You can also get into "Why it is happening [to me or to others]?" which
usually goes into the "Why should we care?" category.)
The real "problem" in stories is I think not the situation itself - it is
the resistance of the [player] characters to deal with the situation.
Problems can be crises (things the character did not choose) and/or
challenges (things the character did choose). Every circumstance in a good
story is a chance to make discoveries about the nature of the world model
and, potentially, the character, with the idea being that both should be
consistent - which a good story management system should probably help with.
The crisis or challenge might even have a moral or ethical dilemma that
explains the psychology of the character or even of the metacharacter (i.e.,
the player) but that is probably out of scope here. So for me "story
management" means recognizing that fiction creation is a process where you
have to get the reader/player to care about interesting people in
interesting situations that are presented with difficulties (puzzles,
perhaps). Then the resolution of those difficulties by the character (i.e.,
solving puzzles). The conception of situation and the invention of character
and incident relative to that situation is what I think makes good fiction.
The assemblage of the various incidents will speak to the plot. So I think a
good story management system has to operate according to those kinds of
principles. Or perhaps it should allow for certain styles of story or of
writing? Maybe even "patterns" of writing? After all, plot has its roots in
the concept of patterns. You choose a pattern for your plot and then you
adapt it to certain series of circumstances and conditions. So your puzzles
and objects speak to that along with the interactions between the objects
and the non-player characters and the player character.
I think a basic checklist for plot might help, at least as a basis of these
tools:
What is the basic idea of the story?
What is the central aim of the story?
What is the character's intent? (What do they want?)
What is the character's motivation? (Why do they want what they want?)
Who and/or what stands in the way of the character?
What is the character's plan of action to accomplish their intent? (Or what
possible plans of action can they formulate given the boundaries of the
world model?)
What is the story's main conflict?
What is the nature of the character's change during the story (if any)?
Is the plot character-driven or action-driven?
What is the point of attack of the story? (Where does it begin?)
How do you maintaining tension throughout the story? (Race conditions, for
example.)
How does the character complete the climax of the story?
> If one were to create a story manager, what actions would one need
> available, what data to be saved, and such?
I think you have to determine the nature of how people think about stories
during the creation process. I gave you a brief glimpse into my personal
vision of things but, of course, you have to take that with a grain of salt.
I would definitely want to have it be a basic repository of my locations,
objects that can populate those locations, and the event-driven nature of
those applications (what can happen there and via what trigger(s)). Those
triggers may be the player character, a non-player character, or an object
(either used or not by a player character or non-player character). But,
again, I am thinking as an author/programmer, not just as an author.
I have read that the biggest problem in interactive fiction writing is not
handling the main success path but handling the variations from that main
success path. So I almost wonder if a story management tool of any sort
would benefit from a type of specialized "use case" approach to it, perhaps
both narrative-based and graphically-based. I am not sure a "sidenote" based
approach would be any better or worse than simply writing things out in a
document as a series of requirements. That is often how I do things. I am
building up to writing some interactive fiction now that I have learned a
few of the languages sufficiently to actually do something, and how I am
looking at things is in terms of a main success path and then primary
complications along that main path and then path extensions - ways that a
player character could deviate from the main path. Some extensions lead to
(perhaps) dead ends, others lead to loops back to the main path, others
might lead to a different "main" path.
Anyway, none of this probably helped or made any sense. I just figured I
would throw some thoughts out there. It is an interesting idea. I will try
to think more on this since I am just thinking up some story ideas now and
so how I formulate them is very fresh in my mind.
David A. Cornelson
news:94rba.42953$eG2.7511@sccrnsc03...
<snip looong response>
Hmm. I'm not sure that's what I meant, but those are certainly good
thoughts. I think I'm interested in the mechanical breakdown of a story and
the management of those parts. So I'm not sure how "primary conflict"
relates to a designer task or programming task.
As for the audience of such a system, the IF community is probably not
interested in this sort of thing. Well, some might be interested in
discussing it, but the hobby's nature is that most of the community prefers
to do things all by themsleves. There are some collaborative efforts, but
those are rare.
My goal is the potential process model for commercial IF creation. The
problem is that I need a few authors to buy into my process model and help
me design it accordingly. That's my problem though.
I posted these thoughts to see if anyone had ideas on how to mechanically
break down a story. I think this is one of the critical aspects of IF
development and something most of us do "inherently" in the process of
writing a game. Whether a process can be described or not is my questions
and if so, how?
Jarb
Cryptonomic
> thoughts. I think I'm interested in the mechanical breakdown of a story
and
> the management of those parts. So I'm not sure how "primary conflict"
> relates to a designer task or programming task.
Well, to the designer I would think primary conflict would be important
because the ancillary elements of the story speak to how the primary
conflict is presented (trigger), maintained (state), and resolved. That
speaks to the design of the story, I would think. (I am not sure if you
equate designer with programmer.) The programmer may not be as concerned
about this if we assume a complete separation of programmer and author. But
you had also mentioned the author as part of this as well, and some authors
might be concerned about elements like that. "Primary conflict" is often
part of the general nature of writing and that is what you said the sole
concern of the putative author using this system would be.
> I posted these thoughts to see if anyone had ideas on how to mechanically
> break down a story. I think this is one of the critical aspects of IF
> development and something most of us do "inherently" in the process of
> writing a game. Whether a process can be described or not is my questions
> and if so, how?
I would still think up the core audience for the project. Is it an author of
traditional fiction who wants to do interactive fiction? Is it possible to
accomodate an author who is also capable of programming? Is it a strict
author who is schooled in various forms of writing or is it amenable to the
beginner as well, to help them guide their thoughts?
Regarding the above quote, I gave you my sort of process, admittedly in a
soft of piece-meal fashion. I know many authors look at stories as being
plot-driven or character-driven and then make desicions based on how they
are driving the characters or driving the plot in terms of how they think up
the elements of the story and string them together. That would speak to the
other characters they encounter or the objects they run into (doors,
locations), etc. For example, consider the "Pursuit Plot." This is a
physical plot (sort of like adventure) which means that the chase is more
important than the characters who take part in it. Usually this story has a
great deal of physical action as well as a variety of fast-paced scenes that
probably move along quite quickly and that are filled with clever
misdirections or ruses. If your putative author thinks that way, then that
is how you want to model some element of the system. Because that is perhaps
how they will be thinking as they put the story to form.
By contrast, consider the adventure plot. Here characters are swept up in
the events because the events are bigger than the characters, as a general
rule (saving the world; saving their family; etc). The characters are
defined by the events that happen to them. Like a quest-type story,
something should impel the character to leave on the adventure. The places
the character goes to on the adventures should not be unrelated. There must
be some correlation between place and event with the character. And speaking
of the quest-type plot, the object here of the search is everything to the
character - not simply an excuse for the action. The character is
specifically seeking something out. This means that the character should
somehow be shaped by the quest and by the success or failure at obtaining
the object of the search, whether that be a physical object or knowledge.
There should also be a motivation for the character to go on the quest in
the first place.
So one thing might be looking at these kinds of plots and determining the
common elements in building them up that authors might use and how they
might "mechanically break down" the story concept from that by dealing with
the common elements and then building off of those. You also have to deal
with the differences in how a putative linear author might approach an
interactive story. Generally the main character will shape events and, in a
good plot, will be shaped by those events. It is that last part that may be
more or less hard to model in terms of story management since, obviously,
that speaks to the player character. (Then again, I suppose an author could
consider his readers as "player characters" that he tries to draw in.)
Certainly, as to your question, I think you can break down some of the
elements of the process. (After all, I just broke down at a high level how I
tend to think of it.) But how to present that in a tool format that has some
osensible goal is another side of that question and, to a large extent, that
depends on the audience question.
Again, just my thoughts, for what they are worth. I am probably confusing
the issue even further at this point so I promise I will stop.
Gadget
cornelson at iflibrary dot com> wrote:
>
>My goal is the potential process model for commercial IF creation. The
>problem is that I need a few authors to buy into my process model and help
>me design it accordingly. That's my problem though.
>
If I understand you correctly, you are trying to standardize the way
to set up a design-document (which breaks down the game into
manageable nuggets of information) and how that document can be
worked on by different people in a dev team? If so, I have a few
thoughts on that. If not, then I'll stay out of the way ;-)
-------------
It's a bird...
It's a plane...
No, it's... Gadget?
-------------------
To send mail remove SPAMBLOCK from address.
David A. Cornelson
news:f5ms6vom9o29n12aa...@4ax.com...
> >
> If I understand you correctly, you are trying to standardize the way
> to set up a design-document (which breaks down the game into
> manageable nuggets of information) and how that document can be
> worked on by different people in a dev team? If so, I have a few
> thoughts on that. If not, then I'll stay out of the way ;-)
>
That sounds about right. Continue....
Jarb
Gadget
cornelson at iflibrary dot com> wrote:
>Hello,
>
>I'm thinking about collaboration again, but this time I'm focused on the
>author's portion of work. Well, that's what I've been focused on all along,
>but I want to narrow it down a bit.
>
>If one were to create a story manager, what actions would one need
>available, what data to be saved, and such?
>
>I was thinking that if you were strictly authoring, you would need to be
>able to:
>
>1. Create Story
> a. Manage Story Elements
> i. Manage Scenes
> 1. Description
> 2. Synopsis
> 3. Locations
> a. Descriptions
> ii. Manage Puzzles
> iii. Manage Objects
> iv. Manage Interactions
> v. Manage Playing Character
> vi. Manage Non Playing Characters
>
When I see this list, it occurs to me that what you are talking about
is script-writing, but it feels like you want to use a database-like
solution for this.
Wouldn't it work better if you organize it in a script-like manner?
The author could just use a word processor to fill in the following
sections (which are basically the same as your list)
1) Synopsis
One page outline (obviously)
2) Game-goals.
What should the player want to do at different times during the game?
So basically what you work out here is player motivation during
different sections, and how you reward the player.
4) Description of the different scenes
These could be written maybe like a movie script, or even as a
handwritten transcript if possible.
5) Description of puzzles and the objects needed to solve them.
Also in this section, the properties of the objects which are needed
for the solutions of the puzzles.
6) NPC's and all their 'lines'
These 'character designs' should be as detailed as possible, with
back-story, relations to other NPCs and the PC and also a description
of the main protagonist.
7) Map
8) Room descriptions
If you have all this, then the coder can get to work and basically
pour this info in the code.
When it comes to filling in details in locations, the coder can take
care of the different pieces of 'furniture' and how they interact. I
guess it would be silly to call in the author for every little
mechanical action that has no real bearing on the overall story. The
doors you mention for example. Or a bird singing in a tree, or
anything else that just needs solid coding and does not need to be
overly detailed by the author.
I think if you would do the above in a new piece of 'story managing
software', the authoring process would become a lot like coding.
Filling in a database of objects and room descriptions would, IMHO
encumber the writer, not free him to be creative. Writing in
script-form would. The author just hands over the 'book' and can be
called upon if the need arises.
One thing I would like to add, is that when it comes to creative
processes, the pitching process and the debating of game and story
ideas is invaluable. I have a theatre background, and one thing I
learned from this is that going back and forth over ideas with
colleagues is really time well spent. You are talking about changing
IF creation from a solistic process to a collaborative process. Then
you should also take advantage of the fact that several people are
working on a project and include this in the pre-production stage.
Cryptonomic
> On Tue, 11 Mar 2003 11:56:43 -0600, "David A. Cornelson" <david dot
> cornelson at iflibrary dot com> wrote:
> Wouldn't it work better if you organize it in a script-like manner?
> The author could just use a word processor to fill in the following
> sections (which are basically the same as your list)
That was what I was talking about with the writing out of things in a simple
word processor document. To wit, I was talking about how or whether this
"approach would be any better or worse than simply writing things out in a
document as a series of requirements." (I meant "requirements" in a sort of
broad form there, not meant to be so formal.) That also speaks to knowing
your audience, like I was talking about. Will a putative tool be worth it in
the sense that a given author will be willing to utilize the tool rather
than just writing things out? To me the benefit of a tool like this would
have to be that it does something to help out the process. If it does not,
why do I need it? It also presumes a willing collaboration between this
putative author and a programmer.
In the case of an author that wants to get into interactive fiction, but
does not want to learn the language fully, then it almost seems that a
better solution is to have a front-end tool to a given language where the
story can be constructed somewhat "visually". (Although, is that not
something like ADRIFT?) Then it could be converted to code. But the point
would be that the front-end does not force the author to deal with low-level
issues of code. They specify a "two-way door" or something and the front-end
knows various ways of implementing that.
> When it comes to filling in details in locations, the coder can take
> care of the different pieces of 'furniture' and how they interact. I
> guess it would be silly to call in the author for every little
> mechanical action that has no real bearing on the overall story. The
> doors you mention for example. Or a bird singing in a tree, or
> anything else that just needs solid coding and does not need to be
> overly detailed by the author.
And that becomes an issue as well, as I was trying to point out. As far as
what has a "real bearing" on the story, might an author and a programmer
disagree on that notion in some instances? If so, how does one go about
making that sort of decision? Obviously that means a great deal of
communication. The programmer needs to be just as well versed in a lot of
ways as the author. I suppose the author could specify the level of detail
when it is needed and if the author does not, one can assume it is a
"generic" object. Yet many authors I know tend to write pretty tightly
scripted stories and, as such, most objects are in there for a very specific
purpose. The point here would be that the author seems to be like a person
coming up with "Business Requirements". The programmer is then acting as a
sort of Designer and Developer and has to come up with different designs
that could potentially satisfy the Requirements. Then the development side
of that determines which of those designs can be reasonably implemented
given the constraints of cost and time.
> I think if you would do the above in a new piece of 'story managing
> software', the authoring process would become a lot like coding.
> Filling in a database of objects and room descriptions would, IMHO
> encumber the writer, not free him to be creative. Writing in
> script-form would. The author just hands over the 'book' and can be
> called upon if the need arises.
Yep. That is what I was wondering as well. Again: consider your audience.
Then consider how the tool helps them solve a problem they could not solve
(or not solve easily) without the tool. Or how it helps their creative
process in some way by supplementing their normal activities. Answering
those questions is key to stating the benefit of the tool. But first, of
course, is determining what those "normal activities" are, which is the
intent of this thread from what I understand. But I think those "normal
activities" (except for the common elements that I mentioned) might differ
from author to author or from story type to story type, at least in purely
linear fiction.
As David said:
"I posted these thoughts to see if anyone had ideas on how to mechanically
break down a story. I think this is one of the critical aspects of IF
development and something most of us do 'inherently' in the process of
writing a game."
That is probably how people should start to answer the initial query here.
How do you go about the process of writing a story/game? Do you script it
out? Do you write a success path first? Do you come up with a general
character that has a general goal and flesh out plot from that? Or do come
up with a towering edifice of a plot and only then figure out how a
character might have certain goals within that plot? When do you start
determining the obstacles the character will meet? When do you start
determining what objects can be utilized in removing or getting around those
obstacles? How do you constrain the geography? How do you determine what
alternate paths to success are worth allowing or handling? Etc. Etc. The
point is: start looking at this by coming up with a series of operational
questions rather than one general question that will be hard to focus on.
Then, once questions like that are focused on, one can say: "Okay, now how
do you organize that? What kind of tool would be helpful to keep all of that
straight?" That, it seems to me, is what a Story Management tool would be
about, at least to a large extent. The degree to which it keeps
implementation details from the author is the degree to which the authors is
presumed to be separate from any strict programming and/or implementation
tasks.
Just some more thoughts. (Yes, I know I said I would stop.)
Gadget
<cryptonom...@hotmail.com> wrote:
>Yep. That is what I was wondering as well. Again: consider your audience.
>Then consider how the tool helps them solve a problem they could not solve
>(or not solve easily) without the tool. Or how it helps their creative
>process in some way by supplementing their normal activities.
Well, Jarb is talking about a way to formalize design for commercial
IF. This means that the author and coder should work professionally.
For that, you need to plan as much as you can before coding, and be
able to show what you do and why you do it and why you deviate from
the set path.
I can understand what he means but I can't fit a software tool like
that in the design process. It's like a cross between a story-tool and
a prototyping tool. I wonder how Douglas Adams worked with Infocom? I
know there are some scraps of design docs on the net somewhere... I
think that is the best blue print I can come up with if you want to
have a writer and a coder cooperate on something. That and
movie-making.
David A. Cornelson
> On Tue, 11 Mar 2003 23:56:54 GMT, "Cryptonomic"
> <cryptonom...@hotmail.com> wrote:
>
> Well, Jarb is talking about a way to formalize design for commercial
> IF. This means that the author and coder should work professionally.
> For that, you need to plan as much as you can before coding, and be
> able to show what you do and why you do it and why you deviate from
> the set path.
Let's define the roles clearly then.
Author
The author's purpose is to define an interactive story including the world
model (map, player character including motive and details, npc's and their
motives and details), the story (overall concept, beginnings, middles,
endings), and such.
Designer
The designer's purpose is to desseminate the results of the authors writings
into functional requirements, writing tasks, programming tasks, testing
tasks, and such.
Programmer
The programmer's purpose is to implement programming tasks, with the extra
responsibility of notifying the Designer of holes in the current task list.
This includes unit testing.
Quality Assurance/Testing
The tester is responsible for verifying that the functional requirements are
implemented properly. This means that they go through both the authors
intent and the designers requirements to make sure things work as expected.
There should be a direct communication line between the designer and the QA
tester so that functional requirements are agreed upon and testing is
accurate.
So now we see that the "system" I would like to create doesn't necessarily
require that the author use anything but a word processor _at first_.
However, once they've submitted their initial draft, some round-tripping is
required between the author-designer-programmer-tester. But this can be done
using word processing change control (MS Word has in-document change control
if you turn it on) and then the designer can audit the differences. But I
think the author will still have to log into the change control _system_ to
help complete description tasks and possible refine details of a certain
part of the story. This might be best done with a forums tool where the team
can bring up topics and discuss them.
The relationship between the designer and programmer is much more
traditional in that the programmer has very specific tasks to complete. The
designer and programmer should provide estimates as well.
Now there also will likely be another role:
Product Manager
The product manager is responsible for making it all come together. From
concept to marketing, they're in charge of looking at the big picture,
guiding the author with potential hot topics, the designer with company
standards, and the QA tester with support.
This is how I view these roles. Now, more comments?
Jarb
Branko Collin
>So now we see that the "system" I would like to create doesn't necessarily
>require that the author use anything but a word processor _at first_.
>However, once they've submitted their initial draft, some round-tripping is
>required between the author-designer-programmer-tester. But this can be done
>using word processing change control (MS Word has in-document change control
>if you turn it on) and then the designer can audit the differences. But I
>think the author will still have to log into the change control _system_ to
>help complete description tasks and possible refine details of a certain
>part of the story. This might be best done with a forums tool where the team
>can bring up topics and discuss them.
How about a wiki? That would have the advantage that the author can
prototype (by using the Wiki as a sort of CYOA tool), can store
background information (what is known about object X, what is known
about the game world) and that the roles of the game makers need not
be so rigidly separated: if the programmer has got a good object
description, she can add it in and the author can refine it. Most
wikis have a very simple versioning system and support an overview of
texts changed since the last login.
The disadvantage is that wikis weren't primarily designed to
facilitate game design. Every object in a wiki is equally important
and has the same role. However, the few wikis I have seen are fairly
simple programs, written in perl or PHP, and it should be possible to
adapt them, so that you can separate the prototypes, strings, puzzle
tree and background database (if that were the type of separation you
would want to make).
--
Real Men Don't Need Anaesthetics
Andrew Plotkin
> Let's define the roles clearly then.
> Author
> The author's purpose is to define an interactive story including the world
> model (map, player character including motive and details, npc's and their
> motives and details), the story (overall concept, beginnings, middles,
> endings), and such.
> Designer
> The designer's purpose is to desseminate the results of the authors writings
> into functional requirements, writing tasks, programming tasks, testing
> tasks, and such.
> Programmer
> The programmer's purpose is to implement programming tasks, with the extra
> responsibility of notifying the Designer of holes in the current task list.
> This includes unit testing.
You don't mention the task of writing -- actually creating blocks of
text. Presumably that would go under "author".
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
David A. Cornelson
news:q66t6vgsbvha79olv...@4ax.com...
>
> How about a wiki?
Let's not jump the gun. I too have an urge to implement any one of the 100
_solutions_ for this system that are stored in my brain. I'm tired of diving
into something until it's _defined_ first.
So let's see if we can talk more about _what_ the system would do before we
firgure out _how_. The wiki suggestion _is_ a good one, so let's do what I
normally do in sessions at work. Let's "park" it and come back to it later.
Thanks,
David
David A. Cornelson
news:b4m5pr$fe7$1...@reader2.panix.com...
> Here, David A. Cornelson <david dot cornelson at iflibrary dot com> wrote:
>
> > Let's define the roles clearly then.
>
> > Author
> > The author's purpose is to define an interactive story including the
world
> > model (map, player character including motive and details, npc's and
their
> > motives and details), the story (overall concept, beginnings, middles,
> > endings), and such.
>
> text. Presumably that would go under "author".
Oh yeah it's not there. Yes, the author is responsible for "writing" all the
text in a game. Some text _may_ come from the designer and the programmer
may have some say over things, but the author should have final say on
everything.
This is where my change control system is important though. Anything written
by the designer and programmer has to go back into the change control or
notification system so that the author can yell and scream and change it.
David
PS: I believe my days of being named "Jarb" are ending...for some reason, I
wish to use my real name. Except of course on ifMUD, where it would be
impossible to change names. Maybe.
Gadget
cornelson at iflibrary dot com> wrote:
> But I
>think the author will still have to log into the change control _system_ to
>help complete description tasks and possible refine details of a certain
>part of the story. This might be best done with a forums tool where the team
>can bring up topics and discuss them.
So the members of the dev team can log into the system and check what,
for example, a certain room description looks like at the current time
in the project, so everyone is 'on the same page' as it were?
David A. Cornelson
> On Tue, 11 Mar 2003 19:43:57 -0600, "David A. Cornelson" <david dot
> cornelson at iflibrary dot com> wrote:
>
> > But I
> >think the author will still have to log into the change control _system_
to
> >help complete description tasks and possible refine details of a certain
> >part of the story. This might be best done with a forums tool where the
team
> >can bring up topics and discuss them.
>
> So the members of the dev team can log into the system and check what,
> for example, a certain room description looks like at the current time
> in the project, so everyone is 'on the same page' as it were?
>
Correct.
Dave
Benjamin Fan
the suggestion of a wiki as a tool to facilitate collaborative
projects. Also, I think that trying to define your system
beforehand might not be the best way to go about it.
I realize that this goes beyond the scope of the original
question (which was, "what information is needed to collaborate
on IF works, where each team member has a clearly-defined and
different role"). I think that I've mentioned to David the
desire to set up my own wiki... my intention was to use the
wiki as a tool for writing and documenting the specifications
for an IF work. Instead of having to figure out beforehand
how collaboration should work and what information is needed,
the wiki would allow you to find the answer organically and
empirically.
I suspect that the project lead would start by identifying
the elements that they thought were the most important-- the
rooms, themes, characters, major plot events, etc. Authors, or
other collaborators could draft their initial impressions, text
fragments, etc. Testers could add their interpretations of
how things should work. Programmers could add code fragments.
Any team member could clarify or correct any other member's
contributions. If there is anything that is missing, or if
the information could be arranged in a better way, any team
member would be able to add, delete, and change the wiki pages
to fulfill the needs of the project.
This is how IF might get developed using an agile
methodology like eXtreme Programming. For a project developed
using traditional methodologies (hierarchical team structure,
clearly-defined roles, etc.), this may not be as helpful.
Ben
--
To get my current email address, concatenate these three strings:
1. "benjamin_fan" 2. "_2002a" 3. "@yahoo.com"
It will look a lot like: xxxxxxxx_yyy_zzzzz @ yahoo . com
Quintin Stone
> Not meaning to "jump the gun", but I would agree with the suggestion of
> a wiki as a tool to facilitate collaborative projects. Also, I think
> that trying to define your system beforehand might not be the best way
> to go about it.
Sorry, but... what the heck is a wiki?
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/
David A. Cornelson
news:9ea00d5e.03031...@posting.google.com...
> Not meaning to "jump the gun", but I would agree with
> the suggestion of a wiki as a tool to facilitate collaborative
> projects. Also, I think that trying to define your system
> beforehand might not be the best way to go about it.
>
The whole point of opening this thread was to discuss what mechanations are
involved in the creation of an IF game from a potentially standardized
manner.
I have nothing against the Wiki paradigm, but it's not relevent at this time
because we haven't defined what problems a Wiki would solve.
This is not to say that it _couldn't_ solve some of the problems in a story
management system. Only that it is only one potential solution to an
undefined problem.
This is why software development processes fail so often. There's a new
idea! A new problem! And wait, someone has seen this really cool
idea/program/software/methodology that will solve this problem instantly!
But in the end, they really didn't understand all the complexities of the
problem and they fail because they have tried to shoe-horn a complex problem
into a solution that wasn't completely capable.
So this is why I suggest tabling the Wiki idea for now. It's not that it
couldn't be one way to go, it's just that the idea of story management is so
new that more thought is required before we jump in and pick or create a
solution.
I don't want to _do_ story management today. I want to think about what
elements make up story management..
Dave
Branko Collin
-0500:
>On 12 Mar 2003, Benjamin Fan wrote:
>
>> Not meaning to "jump the gun", but I would agree with the suggestion of
>> a wiki as a tool to facilitate collaborative projects. Also, I think
>> that trying to define your system beforehand might not be the best way
>> to go about it.
>
>Sorry, but... what the heck is a wiki?
Go to <http://www.wikipedia.org>, type the name of your home town in
the search box, click the Edit This Page link, and add some
information about your home town. Then you'll know. (If not, you can
always search for the term 'wiki' there, too.)
Branko Collin
>This is why software development processes fail so often. There's a new
>idea! A new problem! And wait, someone has seen this really cool
>idea/program/software/methodology that will solve this problem instantly!
Hey, it is not as if I mentioned XML! ;-)
>So this is why I suggest tabling the Wiki idea for now. It's not that it
>couldn't be one way to go, it's just that the idea of story management is so
>new that more thought is required before we jump in and pick or create a
>solution.
Another reason why processes fail so often is because first a
committee has to be started to study the problem, the committee then
finds that more study is required, a sub-committee is started, et
cetera ad infinitum.
The internet: started without a plan.
Linux: started without a plan.
The pyramids: well, they probably had a plan, but I doubt it was more
than a few rolls of papyrus worth. (After all, with more than a few
rolls you needed an infastructure for storing, retrieving, copying and
distributing those rolls, which probably required more papyrus, which
required more management an probably a library in Alexandria--OK, bad
example.)
I admit that these projects probably weren't of the complexity of a
game development system, but still...
Cryptonomic
message news:wpKdnZ6vmKi...@speakeasy.net...
> I don't want to _do_ story management today. I want to think about what
> elements make up story management..
From whose viewpoint? The author? The designer? Or the programmer? Obviously
the goal of this system is to accomodate all three. (What about if one or
more of them are the same person?) I would guess the elements that make up
story management first means come up with the elements that make up a story.
(After all, that is what you would be managing in the first place.) You
started on that path before:
Locations (Rooms, if you prefer)
Takeable Items
Non-takeable Items (Scenery?)
Non-Player Characters
Containers
Puzzles (Complications)
Events (triggered, random)
It depends how you want to break it down, I guess. Once you have those story
elements, consider what would potentially have to be managed with them. For
example:
Locations:
- Description (Long, Short)
- Exits
But understand that "managing a location element" in a system for a
programmer is a different thing than "managing a location element" for an
author. The author might just be concerned about the above but the
programmer might be concerned about Routines: (before, after, verification,
whatever). For an item or object, the author might just care that it exists
and has a name. The programmer might have to be concerned about any
properties or attributes that said item or object has. As such, what is
being managed from those perspectives is the same thing, but with different
concerns.
As you say: "The whole point of opening this thread was to discuss what
mechanations are
involved in the creation of an IF game from a potentially standardized
manner."
It would seem to me that the easiest way to at least get going on this is to
have people who have written works of Interactive Fiction state the general
process they follow in terms of creating the story/game. People all probably
have their own ways of doing "story management" right now when creating
works of Interactive Fiction. Maybe questions (like those I posed) to at
least get the answers you need are the way to go and then look for
commonalities in those answers. If this is not at least one way to approach
this, I am totally confused as to what is being sought.
Some of the questions I posed for a current author of Interactive Fiction:
How do you go about the process of writing a story/game? Do you script it
out? Do you write a success path first? Do you come up with a general
character that has a general goal and flesh out plot from that? Or do come
up with a towering edifice of a plot and only then figure out how a
character might have certain goals within that plot? When do you start
determining the obstacles the character will meet? When do you start
determining what objects can be utilized in removing or getting around those
obstacles? How do you constrain the geography? How do you determine what
alternate paths to success are worth allowing or handling?
Would those not help to at least determine the procedures that people go
through right now to create their stories? (Granted, this is more from a
programmer-as-author perspective but that is mostly what you have to work
with right now.) Then perhaps, once you have this starting point, one can
abstract from that those elements that a non-programmer author would be most
concerned with. Only after that process is done would I start thinking about
how the two processes (non-programmer author and programmer-author) could be
combined into a tool for managing stories.
David A. Cornelson
> "David A. Cornelson" <david dot cornelson at iflibrary dot com> wrote in
> message news:wpKdnZ6vmKi...@speakeasy.net...
> > I don't want to _do_ story management today. I want to think about what
> > elements make up story management..
>
> From whose viewpoint? The author? The designer? Or the programmer?
Obviously
I think for now I'm only concerned with the author and designer. The
programming aspect of this is cut and dried although the programmer has to
replay issues back up the chain.
I started doing a bit of a notation system in my own current collaboration
project and obviously I'll not know the results of that effort until we
complete the game and review how well it worked. I think using a word
processor, some standardized notation for interactivity, is the way to start
for authors.
The story management system is likely centered on the designer since this is
the role that I see managing the communication between the author and the
programmer. It's up to the designer to guide the author into detailing
interactivity from a story perspective and its the designer's responsibility
to dissect this information and build a functional specification for the
programmer.
So my goals are refined now. I'm currently working on a collaboration
notation system, which seems not to have interested too many people when I
brought it up in the past but I see as useful if I were to set some sort of
submission standard for commercial IF works. It would be nice to get a
community overview of this process though since some of the authors I would
like to see submit stories for commercial development come from this
newsgroup.
The other goal is a story management system that enhances a designer's
ability to communicate effectively with a programmer and possibly with a
product manager and marketing personnel. Let's say thay although the author
and programmer would access the story management system, it would not be
their primary communication tool. The author would use a word processor and
the programmer, well, they write code.
Make sense?
Dave
Mark W
> So my goals are refined now. I'm currently working on a collaboration
> notation system, which seems not to have interested too many people
> when I brought it up in the past but I see as useful if I were to set
> some sort of submission standard for commercial IF works. It would be
> nice to get a community overview of this process though since some of
> the authors I would like to see submit stories for commercial
> development come from this newsgroup.
Have you thought of simple Use Cases? These are fairly standard programming
communications tools and may translate well to IF.
Regards,
Mark
--
http://www.marktaw.com/
monty
wrote:
>
>The internet: started without a plan.
>
>Linux: started without a plan.
>
I hate to say it but I do believe that both the internet and linix
started with a plan,
first the internet was started off with a plan to find out more
information on the early beginings of the internet look up ARPANET
as for linix it did not have a formal plan but informally the plan was
to be the same interface as UNIX, I could be wrong but the main goal
in Linix has been to model the functionallity of Unix without the
cost. If linix was not modeled with a plan to be similar to unix then
why is it so similar.
I would have to agree that it does seem that the Internet has been
haphazard expecially in the past 5 years, but it was originally
researched and planned.
I would like to see a standardized templates for helping with writing
IF. the only hesitation I would have is that there are different
design tequniques that could be used to construct a game.
for instance writing sample transcripts, storyboards,basic maps,
detail maps, data flows, object templets, room templets,ect....
the complication with IF is laying out the land, populating the
locations with objects, and telling a story at the same time,
it is easy to draw a map and add lots of detailed objects, but the
hard part is how to get the story added in, and then if the ere are
many NPCs what kind of design would best define writing NPC
the last complication is how is the design portable between authoring
systems. does the design work well in both TADS, TADS3, HUGOS and
INFORM?
maybe the design tool should be more of a rapid prototyping tool for
IF so that authors can get there planning down and see how it feels,
looks or reads.
tony
Miguel
> story management first means come up with the elements that make up a story.
> (After all, that is what you would be managing in the first place.) You
> started on that path before:
>
> Locations (Rooms, if you prefer)
> Takeable Items
> Non-takeable Items (Scenery?)
> Non-Player Characters
> Containers
> Puzzles (Complications)
> Events (triggered, random)
This sounds a lot like lowly ADRIFT. In ADRIFT, you can create Rooms,
Objects, Characters, Tasks (triggered by player input or by other
Tasks or Events), and Events (triggered by Tasks or X turns after the
beginning of the game) by clicking on the icon for each. If you are
making a new Room, you write in the short description and long
description, etc.
Is this something like what you are thinking of, David? A program that
perhaps guides the writer's input a bit into the appropriate channels
(i.e. boxes for the short description and long description of a room)?
boa13
>
> as for linix it did not have a formal plan but informally the
> plan was to be the same interface as UNIX, I could be wrong but
> the main goal in Linix has been to model the functionallity of
> Unix without the cost. If linix was not modeled with a plan to
> be similar to unix then why is it so similar.
It's Linux, not linix. If I'm not mistaken, Linus's idea when
creating Linux was to create a new i386-based kernel for Minix;
he wanted to have some fun with is brand-new, top-notch i386 CPU.
The "same interface as UNIX" came later, and was done through the
use of GNU programs, which is why Richard Stallman is so
insistent on calling Linux "GNU/Linux".
--
spam....@free.fr
You have my nick and my hostname: you can mail me
Harry Hol
cornelson at iflibrary dot com> wrote:
>"Gadget" <gad...@SPAMBLOCKhaha.demon.nl> wrote in message
>news:vh1u6v0of16295m5j...@4ax.com...
>> On Tue, 11 Mar 2003 19:43:57 -0600, "David A. Cornelson" <david dot
>> cornelson at iflibrary dot com> wrote:
>>
>> > But I
>> >think the author will still have to log into the change control _system_
>to
>> >help complete description tasks and possible refine details of a certain
>> >part of the story. This might be best done with a forums tool where the
>team
>> >can bring up topics and discuss them.
>>
>> So the members of the dev team can log into the system and check what,
>> for example, a certain room description looks like at the current time
>> in the project, so everyone is 'on the same page' as it were?
>>
>
>Correct.
>
>Dave
>
Then it still feels like a 'master script' to me. The more I think
about it, the more it feels like 'ordinary' script-writing. I've done
it for the stage and I've seen how a team of people work off one
'master copy' (sometimes called the 'bible') which holds the 'One True
Text'. The director holds this and any change has to go by him. Also,
his word is final. So this implies that if you appoint a project
leader (which could be the author, I think) then you still don't need
a separate software tool for the storage of the design. But if I am
thinking in the wrong direction, please tell me.
Cheers,
Harry
-------------------------
"Hey, aren't you Gadget?"
"I was."
(To send e-mail, remove SPAMBLOCK from address)
Cryptonomic
news:Xns933DED51...@130.81.64.196...
> "David A. Cornelson" <david dot cornelson at iflibrary dot com> wrote in
> news:AYWdnZC5oPS...@speakeasy.net:
>
programming
> communications tools and may translate well to IF.
Yep. That is what I brought up before. I had said in one of my previous
posts: "So I almost wonder if a story management tool of any sort would
benefit from a type of specialized 'use case' approach to it, perhaps both
narrative-based and graphically-based." That is how many types of software
are "storyboarded" and it caters to different "types" of user or
implementor: in this case, designer, programmer, and author and the
interfaces between them. There might be something to this.
Cryptonomic
news:df5a4cbb.03031...@posting.google.com...
> This sounds a lot like lowly ADRIFT. In ADRIFT, you can create Rooms,
> Objects, Characters, Tasks (triggered by player input or by other
> Tasks or Events), and Events (triggered by Tasks or X turns after the
> beginning of the game) by clicking on the icon for each. If you are
> making a new Room, you write in the short description and long
> description, etc.
I had brought this up in a previous post. I had said: "In the case of an
author that wants to get into interactive fiction, but does not want to
learn the language fully, then it almost seems that a better solution is to
have a front-end tool to a given language where the story can be constructed
somewhat "visually". (Although, is that not something like ADRIFT?)"
But I think the idea here is different given the focus that the author is
presumed to be completely independent of the coding or implementation
details, even of the design. (I am not sure how eminently workable that
would be, but that is probably part of what is trying to be fleshed out
here.)
Cryptonomic
>
> The story management system is likely centered on the designer since this
is
> the role that I see managing the communication between the author and the
> programmer. It's up to the designer to guide the author into detailing
> interactivity from a story perspective and its the designer's
responsibility
> to dissect this information and build a functional specification for the
> programmer.
When you say you see this as the "role", upon what model are you basing
this, just out of curiosity? Is it often the case that there is an author,
designer, and programmer? (I know the answer to this; I am just putting the
question out there.) Given the presumed separation that this tool would
foster, I even more think the use case approach might be a way to go. Each
person of the troika interacts with the system in a given way, with certain
inputs and expecting certain outputs. I think starting at a lower level
might even be a way to approach this and then build up from there. Since we
know that most authors now are the programmer as well, perhaps provide a
base-level system that helps the programmer-as-author manage the elements of
a story. Then, as that gets built up, start abstracting out the elements
that a putative designer would be concerned with, separate from an author.
(As you say, the programming and/or implementation details are largely known
at this point.)
> So my goals are refined now. I'm currently working on a collaboration
> notation system, which seems not to have interested too many people when I
> brought it up in the past but I see as useful if I were to set some sort
of
> submission standard for commercial IF works. It would be nice to get a
> community overview of this process though since some of the authors I
would
> like to see submit stories for commercial development come from this
> newsgroup.
Along with use cases, this also brings up collaboration diagrams - another
element of good development practice and perhaps even sequence diagrams.
Given that UML is a standard notation, at least in some areas, might not
some modified or extended version of that help you with this? For example,
you could have a textual and a graphical based component to this endeavor.
That might also speak to your "submission standard" as well.
> The other goal is a story management system that enhances a designer's
> ability to communicate effectively with a programmer and possibly with a
> product manager and marketing personnel. Let's say thay although the
author
> and programmer would access the story management system, it would not be
> their primary communication tool. The author would use a word processor
and
> the programmer, well, they write code.
It is basically like a content management system coupled with a
collaboration tool coupled with a version and change control system. At
least that is what it sounds like. That is very interesting to me. I think I
have a better understanding of what you are striving for here and I think it
is a very interesting conceptual idea. I am not sure how or to what extent
it will re-ignite a commercial venue for Interactive Fiction but
conceptually I find it intriguing. (Your system idea actually reminds me of
something like NexPrise, which is an application server that acts as a
collaboration system for documents, executables, and ideas.)
David A. Cornelson
>
> When you say you see this as the "role", upon what model are you basing
> this, just out of curiosity? Is it often the case that there is an author,
> designer, and programmer? (I know the answer to this; I am just putting
the
> question out there.)
Another revision to this process:
The story management assumes that the author, designer, and programmer are
different people. Any other type of collaboration is not being explored
since these are already implemented in two party collaborations
(writer/programmer), of which I am a part of one.
My aim is to build a process where writers, in the strict sense, not
necessarily IF authors, can develop text that a designer can implement as an
IF system and then can be coded by a programmer. This process will also
assume that the programmer doesn't really understand how to write IF, only
how to code it.
There are many opinions that this is not possible. I'm not interested in
arguing the point. It's my goal to simply go ahead and develop such a
process in a workable manner with input from people that would find writing
only attractive, designing/product development only attractive, and
programming only attractive. I believe these personalities exist (actually,
I know they do), and I want to provide a focus for the interaction, thus the
story management system.
Personally, I think _I_ am a designer. I may or may not have the talent to
write good IF, but it's likely more appropriate to say that I'm more focused
on the product than on the writing or programming. I know of several people
that I have discussed these ideas with and they _love_ the idea of someone
managing the design process and leaving them to simply write the story.
There are also many people that love to code or could be paid to code and
those people would fit into this paradigm as well.
So this isn't really about how things are currently done (not even close).
It's about a model that I want to build and getting as much information as
possible to help guide the process. The thread is maturing and I appreciate
everyone's input.
Dave
David A. Cornelson
programming
> communications tools and may translate well to IF.
>
Yes, but you have to remember the roles. The author role is probably
marginally interested in design methodology. Their intent would be to
produce a submission that is acceptable to the designer yet is fluid enough
for them to manage as a writer. The notation that I have been using in my
own writing is very very simple and uses only a handful of markup items.
This would facilitate a writer in writing and yet providing the designer
with valuable design intent.
For the author's role, I would really sway more towards word processing
functionality.
Now with that said, Use Cases could be developed by the designer to clarify
details of the authors intent. It's possible that some UML diagramming would
benefit the relationship, but this also presumes that a designer knows and
understands UML, which I'm really not sure I want to throw in as a designer
requirement. I'd prefer to keep it IF-oriented and try to develop something
_like_ uses cases, but more appropriate for the story management system.
I would say "Uses Cases and UML" should be parked for now and leave that
door open for further discussion later. I'm open to more discussion about it
though because this does fall into a solid method for enhancing the
designer's ability to do their job well.
Dave
David A. Cornelson
This is correct and I'd add that I'm not looking to build a one person does
it all tool. The key here is that we are purposefully _separating_ the roles
of author, designer, and programmer. Something like ADRIFT has a different
intent, which is to let a lower common denominator of developer build an
interactive system. I'm not interested in lowering the barrier to entry. I'm
interested in managing the bar wherever it is.
A good way to look at this is in how a newer writer or non-programmer
approached IF. If they were to become involved in my proposed story
management system, they might feel more inclined to write out their story
and be less concerned with the implementation, which to be honest, is what
programs like ADRIFT do anyway. "I don't want to _code_, but I have this
cool little story that I think would work well in IF."
So instead of using a tool, this person grabs the submission guidelines I've
completed (someday) and they develop their story. We have forums so that
they can get feedback from a potential designer to solidify their story and
see if it has any interest. If it does garner enough interest, the writer
will be encouraged to continue writing. At some point, the story will be
"officially" submitted and be brought into the story management process and
implemented as a game. The writer has successfully completed something that
_potentially_ exceeds their capability as a designer/programmer, but most
certainly does it more quickly and with better results (although there are
obvious exceptions here, I'm focused on everything _but_ the exceptions).
So the potential for someones intent being implemented _well_ are far better
than had they picked up ADRIFT and tried to do it all by themselves. Now
they may have enjoyed developing the game from front to back, but I suspect
many people want to implement their ideas more than they want to actually
code them. This is my own opinion though and I'm not suggesting that it's
true or false.
Dave
Cryptonomic
> "Cryptonomic" <cryptonom...@hotmail.com> wrote in message
> news:6vkca.92856$qi4.54030@rwcrnsc54...
> >
>
> necessarily IF authors, can develop text that a designer can implement as
an
> IF system and then can be coded by a programmer. This process will also
> assume that the programmer doesn't really understand how to write IF, only
> how to code it.
It is an interesting idea because you might have many budding authors out
there who lack either the time or the inclination to learn a programming
language and yet are interested in the medium of Interactive Fiction. I am
not so sure about that last part though, as far as not really understanding
how to write Interactive Fiction, just how to code it. (I am not stating
this as an objection; just a general gut feel right now.) "Coding
Interaction Fiction", at least as I understand it, is "writing Interactive
Fiction". Are you more saying the programmer really does not understand how
to write "fiction" in general? I would think the programmer would have to
have a good concept of what it means to write interactive fiction since the
interactivity is what is being coded for. (I have often found in my work
that programmers that are too removed from the higher-level details are
counter-productive because they need to be able to raise red flags at their
end as well. Coming from a quality assurance background where I often have
to oversee teams of functional testers and unit-based or code-level testers,
I can testify that the programmers often have a pretty good handle on the
concepts behind design.) As we get more information on this, though, I agree
with you that the designer is really a critical element in this because it
is "project management" and "product management" role wrapped up into one,
with some elements of proactive quality assurance thrown in as well. (At
least that is the case if this is seen as a collaborative development
effort.)
> There are many opinions that this is not possible. I'm not interested in
> arguing the point. It's my goal to simply go ahead and develop such a
> process in a workable manner with input from people that would find
writing
> only attractive, designing/product development only attractive, and
> programming only attractive. I believe these personalities exist
(actually,
> I know they do), and I want to provide a focus for the interaction, thus
the
> story management system.
I think it is definitely possible. As you say, it is just a matter of
getting people to agree to try it out and contribute to the concept. If
those personalities that you mention exist (and I have no doubt at all that
they do), they should also actively participate in this discussion since
they are the focus on the effort. In fact, I myself would be interested
because while I have knowledge of how to write and while I think I have good
story ideas, I am not always sure how to implement. (I have been learning
Inform and TADS but in a piece-meal fashion simply because of time
constraints.)
Also, you had mentioned: "My aim is to build a process where writers, in the
strict sense, not necessarily IF authors, can develop text that a designer
can implement as an IF system and then can be coded by a programmer."
But then does that not go back to some of those plot-driven and
character-driven elements I mentioned? Some (many) writers do think in those
terms and, as such, that is how they will probably approach a tool like
this, at least initially. They might be concerned with elements of conflict
and narration and how setting interacts with character to drive plot. (Even
people like Stephen King, Dean Koontz, Isaac Asimov, Chris Carter, Ben Bova,
and David Gerrold, just to name a few, indicate in their various writings
that these kinds of things are how they approach stories. Thomas Disch did
"Amnesia" and I think there were some published musings of his on the
subject. I am not sure what notes, if any exist, on the Infocom-Douglas
Adams collaboration. I also wonder about the Frederick Pohl "Gateway" series
that was then put to form as Interactive Fiction by Legend Entertainment.)
So the question is how these authors approach the construction of their
stories. The tool will either have to accomodate that or constrain that
process down to some standards via which a putative designer can take the
author's concepts and provide a "design model" of some sort. (I guess the
author's work sort of serves as the business requirements, so to speak.) The
design model will speak to certain functional requirements that have to be
in place. The programmer then has knowledge of how to implement those
functional aspects.
It is sort of an Interactive Fiction Lifecycle Model (IFLM), to sort of
match the SDLC common in the software engineering world.
I go back to your previous statement: "The whole point of opening this
thread was to discuss what mechanations are involved in the creation of an
IF game..."
It sounds like that still really has to be answered, though, right? (I still
think those operational questions I posed at least give a good starting
point towards that. If not, then I truly do not understand the basis of
Interactive Fiction at all or I am going about it in the wrong way.)
You also said, in that same post: "I want to think about what elements make
up story management."
Part of this will fall from what has to be managed, i.e., the elements that
result from the "mechanized IF creation process". Also speaking to
"managing" a story, would be the versioning (perhaps) of ideas, documents,
and executables. Also perhaps a form of "defect tracking" and "change
control". One of the major factors that cause projects to fail is scope
creep. A good management system might have to accomodate that. Traceability
would also be another element, I would imagine, in this system because you
want to have a way to trace from "business requirement" (author), to "design
model / functional requirements" (designer), to "code" (programmer).
David A. Cornelson
Well I think it would be be beneficial if the programmer understoof IF
development sure, but I think I could teach that. I think what I was getting
at is that the programmer won't need to be concerned with 99% of the text
that goes into the system. They will implement preset blocks of text and any
logic that's associated with it.
So yes, the programmer will be able to read the story, be involved in the
design process, but is only _responsible_ for the code.
Obviously if you were to choose a programmer from a stack of resumes, you
would look for past IF or interactive game development as a criteria in
hiring.
Dave
David Myers
> couldn't be one way to go, it's just that the idea of story management is so
> new that more thought is required before we jump in and pick or create a
> solution.
This doesn't seem new to me. Louis XVI used to run a country the way
you want your author to "run the business" of writing a IF story. It's
purely an autocracy. Author shouts, everyone else jumps. The
programmer is a miserable little soul who gets to suffer (presumably,
for an awful lot of money, given how little creative work he does).
I'm glad this idea thrills you, but enunciating in intimate detail how
a peon is supposed to act and behave doesn't make being a peon any
more desirable.
Dave.
PS - Wikis are cool. Try writing a couple articles in the wikipedia
sometime. I didn't expect, for example, when polishing up the "iron"
article in the wikipedia, that I would learn as much Chinese history
as I did.
Harry Hol
cornelson at iflibrary dot com> wrote:
>So instead of using a tool, this person grabs the submission guidelines I've
>completed (someday) and they develop their story. We have forums so that
>they can get feedback from a potential designer to solidify their story and
>see if it has any interest. If it does garner enough interest, the writer
>will be encouraged to continue writing. At some point, the story will be
>"officially" submitted and be brought into the story management process and
>implemented as a game. The writer has successfully completed something that
>_potentially_ exceeds their capability as a designer/programmer, but most
>certainly does it more quickly and with better results (although there are
>obvious exceptions here, I'm focused on everything _but_ the exceptions).
>
What I really like about this approach is that it encourages 'thinking
outside of the box'. If all you do is write, then you don't worry
about the limits of coding too much. It's not your immediate problem.
If you code your own story you will (even subconsciously) evaluate
every idea for 'codeability'. Your approach could lead to some very
fresh ideas...
Mark W
> The author role is probably
> marginally interested in design methodology. Their intent would be to
> produce a submission that is acceptable to the designer yet is fluid
> enough for them to manage as a writer.
Perhaps it would be helpful if you defined the roles of author, designer,
and programmer. Where does the author end and the designer begin. Where
does the designer end and the programmer begin?
Mark W
This has me thinking of Unlimited Adventures. UA, as you may know, was
released by SSI after their Gold Box Games were replaced by something else.
UA was the design tool used by SSI to create Gold Box games.
The good thing about SSI is that it mapped out quests in very plain &
obvious steps, mostly in a door/key concept. "To open door, get key,
monster blocks key." It's worth your time to examime UA if you can find it.
I've said it before and I'll say it again - as important as the
goal/obstacle idea is to ordinary fiction, it's even more important in
video games.
Mark W
Michael Moorcock, the science fiction writer, worked with some game
developers to create a video game based on some of his works. He said that
they were the best collaborators he ever worked with because the understood
plot better than most writers.
Perhaps the tool you're looking for is a walkthrough/transcript. The writer
can read a few walkthroughs to get familiar with the genre, play a few
games. And then attempt to write a walkthrough, or even just write out a
session.
"Endless stair... blah blah blah nice prose, set up story.
>go south
there is a sword, etc.
>get sword
the sword glows etc."
Mark W
news:df75abd3.03031...@posting.google.com:
>> So this is why I suggest tabling the Wiki idea for now. It's not that
>> it couldn't be one way to go, it's just that the idea of story
>> management is so new that more thought is required before we jump in
>> and pick or create a solution.
>
> This doesn't seem new to me. Louis XVI used to run a country the way
> you want your author to "run the business" of writing a IF story. It's
> purely an autocracy. Author shouts, everyone else jumps. The
> programmer is a miserable little soul who gets to suffer (presumably,
> for an awful lot of money, given how little creative work he does).
You need to re-read that first paragraph.
David A. Cornelson
>
> Perhaps it would be helpful if you defined the roles of author, designer,
> and programmer. Where does the author end and the designer begin. Where
> does the designer end and the programmer begin?
>
I believe they are defined early in the thread and if it weren't so long,
I'd repost it. Just go back the 3/11 7:43PM post.
Dave
David A. Cornelson
>
> Perhaps the tool you're looking for is a walkthrough/transcript. The
writer
> can read a few walkthroughs to get familiar with the genre, play a few
> games. And then attempt to write a walkthrough, or even just write out a
> session.
>
That's exactly what I'm talking about although I would use different
notation than what shows in a transcript. The biggest reason is that in
writing the transcript, you want to have more script type notations and
instead of things like "examine tree", the writer may write, "x tree,
branches, leaves" to note which nouns are covered in the following
description.
I'm working on this with a collaboration I'm working on...
Dave
Mark W
sleightly redundant, or perhaps it's more of an "account executive." You
know, the guy from the software company that goes to the offices of the
company in need of software & gathers specifications from them in
roundabout ways.
It seems to imply that the writer can't understand programming and the
programmer can't understand what the writer wants. Is this a correct
assumption for this model?
David A. Cornelson
"Can't" is too strong. "Isn't responsible for" is more accurate. There
clearly has to be communication and understanding of IF between and within
all roles. That's not the question.
The question is, how can we define a system (or methodology) where the
author can do their job as efficiently as possible, the desginer can
facilitate, and the programmer can be as efficient as possible as well.
Dave
Mark W
how they differ from novel writing or screenplay writing. The variability,
the specific nature of the obstacles that are possible, etc.
Why don't you pick a sample game that everyone here is familiar with that's
in the same vein as what you're talking about and we'll walk through it and
see how it can be broken down into pieces that are digestible by each of
your types? HHGG might be a good choice as it's a cannonical Infocom game &
was actually written by a writer. (?)
David A. Cornelson
>
> Why don't you pick a sample game that everyone here is familiar with
that's
> in the same vein as what you're talking about and we'll walk through it
and
> see how it can be broken down into pieces that are digestible by each of
> your types? HHGG might be a good choice as it's a cannonical Infocom game
&
> was actually written by a writer. (?)
>
This is a fair suggestion. One of the weaknesses I have is that I do _not_
think like a traditional writer. I think probably more like someone writing
a movie script, but am not really studied on writing formulation in any way.
I'm a professional developer and a hobbyist writer (at best).
So let's dissect HH and see where it goes.
Dave
David A. Cornelson
news:df75abd3.03031...@posting.google.com...
>
> This doesn't seem new to me. Louis XVI used to run a country the way
> you want your author to "run the business" of writing a IF story. It's
> purely an autocracy. Author shouts, everyone else jumps. The
> programmer is a miserable little soul who gets to suffer (presumably,
> for an awful lot of money, given how little creative work he does).
>
> I'm glad this idea thrills you, but enunciating in intimate detail how
> a peon is supposed to act and behave doesn't make being a peon any
> more desirable.
I don't think this is fair at all. There is a great deal of good that comes
out of breaking up a complex task into roles. This is more of a team effort
than an autocracy. The author certainly would have there name up front, but
the programmer, designer, and all other contributors would be mentioned in
the material as well.
As for the author having the final say on something, this is open to
interpretation. I would hope that any potential authors would be open enough
to listen to suggestions from the rest of the team. It would be difficult to
work with an author that expected strict control anyway.
I have no interest in making one part of the team feel less important than
any other. I'm far more interested in a role-based model for more efficient
IF development. You can paint this negatively if you want, but that's
certainly not in my intentions.
Dave
PM Virgin
however, that I am new to Interactive Fiction as I have been a member of AGX
for a few years (but that is neither here or there).
This discussion piqued my interest as I have been working on a collaboration
for a while now and I thought my insight might be of interest.
I have been using the three-part (Writer, Designer, Programmer) organization.
But, instead of the Writer based orientation, I have orchestrated it as the
Designer - and, aside from interference from "Life", it has worked reasonably
well.
As you have noted, it works much more smoothly with the roles clearly defined
(realtively speaking). The primary goal of my Writer has been to focus on how
the world "looks" in the game. My Programmer has been responsible for seeing
that the world works the way that it should. And, as designer, my role has been
to balance the two areas with eye towards the finished product.
To start, I played the game in my mind step by step. I wrote down the
commands that I used, and the type of information that I "saw". If there was
something that I shouldn't be able to do (aside from passing through walls), I
wrote my attempt and the subsequent result.
Occasionally, I'd come to a point where a puzzle would be. If I knew what the
puzzle would be, I'd jot it down. If I wasn't sure, I would write down the
ideas I had about it and press on (with the intention of coming back to it
later). If, as part of a puzzle, I needed an item, I would make note of it
and, if necessary, add it in wherever it was to be found. In this way, I
created a skeletal version of the game.
With this template, I had something I could send to Writer and Programmer
alike. My writer knew what information was necessary for the description and
was given a realitively free reign of anything else to add. Likewise, my
programmer was able to see the (excuse the pun) bare bones of what needed to
happen.
Needless to say, I tried to keep myself available to my collaborators should
they have any questions. Also, I served as editor and QA tech to them, to help
them keep on track.
This has worked fairly well for me. I hope it is of some help for you...
PM Virgin
Mark W
news:20030328191436...@mb-fe.aol.com:
> With this template, I had something I could send to Writer and
> Programmer
> alike. My writer knew what information was necessary for the
> description and was given a realitively free reign of anything else to
> add. Likewise, my programmer was able to see the (excuse the pun) bare
> bones of what needed to happen.
> Needless to say, I tried to keep myself available to my
> collaborators should
> they have any questions. Also, I served as editor and QA tech to them,
> to help them keep on track.
>
> This has worked fairly well for me. I hope it is of some help for
> you...
Yeah, I would imagine the writer is responsible for the actual prose, the
descriptions of the places, objects, characters, the dialogue etc. In
addition, they could come up with the plot, subplots, and be the general
creative force and the final say on all things outputted to the screen.
"the room should be fucia and the door should be locked."
The designer is responsible for making sure everything happens in the form
of a game and as something that will be fun to players. They would be the
final word on things like puzzles, game logic, and ensuring the conventions
of gaming were properly implemented.
"If you lock the door, there must be a logical, but cleverly hidden way for
the player to get out of the room."
The programmer, of coure, would be responsible for implementing the game.
They would have the final word on whether or not something could or could
not be feasably done within the constraints of the project.
"No, you can't have 52 orcs all with distinctive personalities based on an
AI algorithm from an Emily Short game."
PM Virgin
> Yeah, I would imagine the writer is responsible for the actual
> prose, the descriptions of the places, objects, characters, the
> dialogue etc.
the description -- the bits that actually relate to the logic of the game. Then
my writer is pretty much free to elaborate as (s)he wishes (provided they don't
contradict the logic).
> In addition, they could come up with the plot, subplots, and
> be the general creative force and the final say on all things
> outputted to the screen.
Something about this chunk makes me think you may be either a writer with a
superiority complex or a troll (I wouldn't know, as I'm new to this group).
Regardless, I'll answer this as though it were a valid point.
It is true, that a writer could do the things that you suggest; but this
would then lend itself to a Two-part (Writer-Programmer) collaboration.
However, with the length and complexity of the game I am working on, my writer
has enough on his plate with the amount of prose needed for the game.
Therefore, it falls on me (as the Designer) to come up with the (sub)plot(s)
and maintain the balance between the realms of creativity and logic.
> "the room should be fuc[hs]ia and the door should be locked."
The room color would fall under the control of the writer (unless there is a
particular Need (i.e., puzzle/plot reasons) for it to be fuchsia. However, the
status of the door being locked would fall under the Designer (whether it be
locked due to plot/timing or being a puzzle). The question as to who is
responsible for how the door is locked, however, is up for grabs (usually
tending towards the writer).
> The designer is responsible for making sure everything
> happens in the form of a game and as something that will be
> fun to players. They would be the final word on things like
> puzzles, game logic, and ensuring the conventions of
> gaming were properly implemented.
I'd say this is a fair assessment. I would be tempted to add that they are
responsible for how things look when the finally get on screen -- but I guess
that would really depend on who initiated the collaboration.
> If you lock the door, there must be a logical, but cleverly
> hidden way for the player to get out of the room."
This goes without saying. However, there must be a logical
reason/justification for the door to be locking the first place. I don't see,
"We're kinda low on puzzles, so let's just go ahead and lock the door to draw
things out," generally being good design.
> The programmer, of cour[s]e, would be responsible for
> implementing the game. They would have the final word on
> whether or not something could or could not be feas[i]bly
> done within the constraints of the project.
This, I agree with.
> "No, you can't have 52 orcs all with distinctive personalities
> based on an AI algorithm from an Emily Short game."
Of course, it helps for the Designer to have some idea as to what is
possible. That way it takes some strain of the Programmer, so they don't have
to be so defensive about the code and are more open to tweaking (for things
that are seen by the player).
To summarize my view of the roles in a three person collaboration, I find it
helps to think of the game in terms of the anatomy of a person. The Designer is
responsible for the Skeleton of the game. The Writer is responsible for the
flesh and the hair. And the Programmer is responsible for the muscles and
internal organs.
Of course, it's important for all three to have the same/similar idea as to
how the final result should look (usually with one having the clearest idea) --
that way you don't have one person thinking it's supposed to be Frankenstein,
another thinking it's supposed to be Pam Anderson, and another thinking its
supposed to end up as a kangaroo.
PM Virgin
___________________________________________________________________
Abstinence makes the groin grow hornier...
Mark W
>> In addition, they could come up with the plot, subplots, and
>> be the general creative force and the final say on all things
>> outputted to the screen.
> Something about this chunk makes me think you may be either a writer
> with a
> superiority complex or a troll (I wouldn't know, as I'm new to this
> group). (snip)
I'm neither. I'm just assuming that by "writer" you meant "creative
force/creative direction." Sort of the way Hideo Kojima comes up with the
ideas, dialogue, etc. for the Metal Gear games... Or at least that's my
impression from the interviews I've read.
Maybe I'm over-emphasizig this role, I just imagined that this kind of
situation would come about because a writer had an idea for a game and
hired a designer & programmer, not that they'd all be part of a larger
studio.
In your version, how do each of these people get assigned to these roles?
PM Virgin
Previously, I had written:
>> [Snip] you may be either a writer with a superiority complex
>> or a troll (I wouldn't know, as I'm new to this group).
> "creative force/creative direction."
said "writer" I meant "the person that writes the prose".
> Maybe I'm over-emphasizig this role,
A wee bit. In my universe, creativity is expressed in many different forms --
some more obvious than others (depending on the situation).
> I just imagined that this kind of situation would come about
> because a writer had an idea for a game and hired a
> designer & programmer, not that they'd all be part of a larger
> studio.
Well, that might be how it traditionally happens. But, for my project, the
situation came about because I (the Designer) had an idea for a game and
enlisted the aid of a writer and programmer.
> In your version, how do each of these people get assigned to
> these roles?
In much the same way as your version, I presume. First, I (the Designer) came
up with an idea. After letting it simmer in my brain for a while, I sat down
and wrote out as much of my idea as possible.
I then went to a writing newsgroup and read some stories. When I discovered
some stories that I liked, I E-mailed their authors; telling them a little
about my game and asking if they would like to be involved. Once an author
accepted the role, I sent them the info I had. The writer then read the info
and we went back and forth, through a series of e-mails, discussing the game
until we felt we were on the same page.
Next, I went to my an IF newsgroup (AGX) and asked if there were any
programmers out there that wanted to work on a game (without having to be
responsible for the prose or design). I sifted through the responses and
selected a programmer. I then went through the same information sharing period
as I had with the writer.
The project then continued, with me serving as editor for the writer and QA
tech for the programmer -- helping direct their efforts and keeping them on
task. Some things that I believe have helped me is: my availability to answer
questions if they pop up; and my openness to suggestions (if either comes up
with an idea to improve the game).
Later,
PM Virgin
_______________________________________________________________
Abstinence make the groin grow fonder...
Mark W
> I then went to a writing newsgroup and read some stories. When I
> discovered
> some stories that I liked, I E-mailed their authors; telling them a
> little about my game and asking if they would like to be involved.
> Once an author accepted the role, I sent them the info I had. The
> writer then read the info and we went back and forth, through a series
> of e-mails, discussing the game until we felt we were on the same
> page.
Ahhh... See, if I were in that situation, I would've written the darned
thing myself. I'm not the best writer in the world, but I can hold my own.
Yours is probably a better model for "the real world" because a gaming
company is likely to assign a writer to a project the same way they'd
assign a programmer and a designer. I guess the big difference (besides
graphics folks) there would be that there would be a producer, responsible
for keeping it on-budget, right for the target market, etc.
Adam Thornton
I just want you to know that I'm physically restraining Mr. Makane from
approaching the keyboard.
Adam
PM Virgin
> Ahhh... See, if I were in that situation, I would've written the
> darned thing myself.
Dick and Jane") style version of the game. It contained all the basic elements
necessary to get an idea of the storyline and flow
> I'm not the best writer in the world, but I can hold my own.
My problem is that I have an editorial mentality -- when left to write out
anything, it ends up being rather concise (read "short"). Knowing that, it
necessitated me finding somebody with a generative mentality to flesh out the
concentrated bits I'd developed. That being done, I then swoop back in and
tighten things down a little (so as to avoid excess/running on).
> Yours is probably a better model for "the real world" because
> a gaming company is likely to assign a writer to a project the
> same way they'd assign a programmer and a designer.
Actually, that's kinda how I planned it to work - it seemed the most
efficient way to go about making a quality game given my specific strengths.
> I guess the big difference (besides graphics folks) there
> would be that there would be a producer, responsible for
> keeping it on-budget, right for the target market, etc.
The larger the project/goal, the larger the group needed to achieve it. One
thing I learned in my CSET (read "computer programming") program was that you
generally can have control over any 3 of 4 areas in a project: Scope, Quality,
Price, and Time. For my project I decided to create a good, full version of my
game with a staff of volunteers -- that definately explains why we're on our
fifth year :S
Mark W
>> I guess the big difference (besides graphics folks) there
>> would be that there would be a producer, responsible for
>> keeping it on-budget, right for the target market, etc.
> The larger the project/goal, the larger the group needed to achieve
> it. One
> thing I learned in my CSET (read "computer programming") program was
> that you generally can have control over any 3 of 4 areas in a
> project: Scope, Quality, Price, and Time. For my project I decided to
> create a good, full version of my game with a staff of volunteers --
> that definately explains why we're on our fifth year :S
I know that old maxim:
"You can have it good, fast or cheap -- pick any two."
Yours is more thorough, but mine is more fun to say... there are plenty of
variations on this though, and I think the first time I heard it, it was
with 4 variables like yours.
Are you familiar with The Mythical Man Month? A classic on how throwing
more warm bodies on a project won't necessarily increase the speed at which
it's done.... Maybe good fast and expensive don't go together.
PM Virgin
> I know that old maxim:
> "You can have it good, fast or cheap -- pick any two."
> Yours is more thorough, but mine is more fun to say... there
> are plenty of variations on this though, and I think the first time
> I heard it, it was with 4 variables like yours.
same as Time; Cheap is the same a Price; but Quality is 'good' from the angle
of one thing being done well, and Scope is 'good' from the angle of how many of
the "one things" are done.
Of course, I guess that's just a long, textual equivalent to nodding my head
;)
> Are you familiar with The Mythical Man Month? A classic on
> how throwing more warm bodies on a project won't
> necessarily increase the speed at which it's done....
I remember that being mentioned... And it does make sense. On one hand, it
doesn't matter how many construction workers you have helping if you're trying
to recreate the painting from the ceiling of the Cistine Chaple (ie, the people
don't have the right experience for the task). On the other, it slows things
down if you have several origami experts trying to make a paper swan when you
only have one sheet of paper (ie, not enough tasks/work to be done).
> Maybe good fast and expensive don't go together.
That's why they had to break good down into it's components -- either
everybody can work on making one thing work really well (Quality), or get
several things working to some extent (Scope [or Quantity]).
I wonder if anyone else is enjoying this discussion as much as we seem to
be...
Mark W
speed is difficult & how when you change the scope, say, from "a few
scripts," to "application," the time & difficulty increase exponentially
rather than multiplicitively.
> I wonder if anyone else is enjoying this discussion as much as we
> seem to
> be...
I think so. How many readers of this newsgroup do you think are
professional or semi professional programmers, or are at least interested
in programming?