IF Collaboration Notation (long)

4 views
Skip to first unread message

David A. Cornelson

unread,
Nov 15, 2002, 12:38:06 AM11/15/02
to
Something occurred to me while beginning to collaborate with a fellow IFer
on a game.

Communication.

Up until a few weeks ago I had never really thought seriously about
collaboration because I always thought that the only way it could be
successfully done was to have physical proximity. Obviously this is not the
case since we have many instances of distant collaborations in the IF world.

I have partnered with someone else on a game and then began the task of
writing down what I want within the context of the game and all of a sudden
I started to build a notation for communicating various contexts of a real
game. Someone might consider this a "transcript", but I think it's probably
more similar to a script for a play. The only difference from a play though
is that it's more complicated because of the multi-dimensional nature of
action/response within IF.

In my mind, the separation of implementation and writing are critical to
future development of Interactive Fiction (though I may be the lone person
to believe in this theory). The question I pose is this: Is it possible to
develop a notation set that would allow an author to convey the working
details of an Interactive Fiction game/story without caring or understanding
programming at all? Well this is already true to some degree because we know
that the Zork text game that Whizzard implemented for Activision was
delivered in transcript form (I believe this is correct). Well, the
transcript _did_ come from a programmer so I may be off there. But my
question has a deeper condition in that I'm wondering if it were possible to
develop a notation that specifically helped a writer develop Interactive
Fiction in such a way that it could be handed to a programmer (with a clear
understanding of IF) and have their story be implemented relatively
accurately?

First we need to define the elements that one would convey in an IF
"transcript". The actual notation we use is probably incidental so I'm going
to focus on why and when we would use such notation:

Screenplay Elements
I would use typical screenplay headers such as Act, Scene, etc to convey
what part of the story is being told. I think it needs to be made clear that
locations, objects, and npc's, all may be written over and over again in a
transcript or screenplay style document. So forget about locations and maps
and concentrate on the story. Break the story into Acts and Scenes. Then
detail the interaction with the following elements:

Assumptions
An assumption would be given at the beginning of a Scene or Act that would
define the state of the game that allowed the coming defined behaviours.

Singular Commands
A singular command is one that is consistent throughout the entire play of a
game. These would include directional commands or commands that required
only one use within the game play.

Select Responses
A select response would be the result of a given command (not necessarily a
singular command) that has more than one potential response. The logic in
how one of the listed responses gets displayed probably should be noted
somehow as well (shuffle, incremental, loop).

Compound Responses
A compound response would be when a particular action is repeated so that
each response is an "elevation" from previous responses.

Ordered Responses
An ordered response would be when a set of actions is given in a particular
order and a response defined for each ordered command.

Logical Responses
A logical response is displayed based on criteria. The criteria for the
response is given in logical terms.

Score Response
For games that keep score, a score response would enable the writer to
convery how and when points are added/subtracted and how the player is
notified.

Multiple Commands
In a given situation, there may be multiple appropriate actions. A multiple
command would allow the writer to convey a given state or "focal point" and
present the actions available from that point. Various response notations
would follow each command.

* * * * *

So this all leads into what would make an effective editing tool for
Interactive Fiction. My first pass at this concept was a legacy styled
form-based computer display with text boxes to fill in and drop down lists
to choose from. I deem this a complete failure since it mutes the voice of
the writer _and_ the programmer almost entirely.

My next thoughts (unimplemented) were that a solid text editor with various
new-age functionality would be suitable. Make the programming "easier" and
the writer will be able to concentrate more blah blah blah. I think this
implementation would fail as well although I have no proof.

My new thoughts center on screenplay development systems and how these are
used to build accurate world models. The difference with a traditional
screenplay though is that it has a linear storyline whereas IF does not. IF
has a multi-dimensional storyline and the complexities in rendering this on
paper seem overwhelming.

But what if someone were to first develop and test a working set of
notations, then implement these notations within the context of a word
processor or text editor? I still sense that more technical detail is
required for great success since what I see is the ability to be able to
relate everything in notation (link locations in the transcript via title so
that the author can easily view any act, scene that the selected location
resides). The technical aspects of taking a transcript (linear writing) and
creating methods for relational notations seems non-trivial to me.

Anyway. These are my initial thoughts as I begin my first collaboration. I'm
already using some of the notations listed above and will likely identify
many more. When I'm done and the game is completed and tested, I will
publish my notations along with the final transcript so that we can have a
healthy discussion sometime in the future.

Jarb


Stephen L Breslin

unread,
Nov 15, 2002, 1:00:56 AM11/15/02
to
I recently wrote a little game for someone. I asked the fellow for a
transcript, and did my best to make the game output conform to the
transcript. No special notation was necessary.

I think you're going much further than practically necessary with
these formalizations. Just write a transcript, and put notes or
explanations in brackets. It's not that complicated.

I've done some collaboration with actual programming involved; this is
more problematic. I strongly recommend CVS if you're collaborating
with actually writing the code for the game.

Cedric Knight

unread,
Nov 15, 2002, 7:45:08 AM11/15/02
to
"David A. Cornelson" <da...@plover.net> wrote:
> Something occurred to me while beginning to collaborate with a fellow
IFer
> on a game.
>
> Communication.
>
> Up until a few weeks ago I had never really thought seriously about
> collaboration because I always thought that the only way it could be
> successfully done was to have physical proximity. Obviously this is
not the
> case since we have many instances of distant collaborations in the IF
world

Steve Meretzky on Douglas Adams and h2g2:
'It started out with him coming over here and we worked together in
Boston for about a week. Then we connected up a computer mail network
and communicated pretty much on a daily basis that way. We talked on the
phone once or twice a week and then about three months after that first
meeting, I went over to England and spent a week there. After that the
design was pretty much done and I was left alone to do all the testing
and bug fixing type of work and then Douglas came over here for another
week right before it went out, just to do some last minute polishing.
Basically I did all the programming and he did most of the writing and
we designed most of the puzzles working together.'
http://www.zzap64.co.uk/zzap13/four_minds01.html

They may not have needed such physical proximity if prototype games
could be exchanged as easily as they can now. Or if it involved writers
with a different attitude to deadlines than the late DA.

> ...game. Someone might consider this a "transcript", but I think it's


probably
> more similar to a script for a play. The only difference from a play
though
> is that it's more complicated because of the multi-dimensional nature
of
> action/response within IF.

A play or shooting script would be a form that both writer and
programmer may know well, and therefore a good model for collaboration.
How do a writer and stage director collaborate? (A rhetorical
question - I've done both in amateur circles.)

>
> In my mind, the separation of implementation and writing are critical
to
> future development of Interactive Fiction (though I may be the lone
person
> to believe in this theory).

There must be something in this, when the number of high-quality works
of IF produced depends on the number of high-quality writers who are not
just interested in the form, but also are willing to stoop to
programming. It would be great to attract more good writers into the
community given that there are probably many willing competent
programmers already.

...The question I pose is this: Is it possible to


> develop a notation set that would allow an author to convey the
working
> details of an Interactive Fiction game/story without caring or
understanding
> programming at all?

How necessary is a notation? The writer may be willing to provide a
(multidimensional) script and outline and allow the programmer free rein
regarding some of the minor details of human-machine interaction. For a
first 'draft' at least. I think your approach would be very useful for
ultra-formal contractual arrangements between the collaborators, but
some writers might be more interested in the dialogue than in a notation
that is approaching programming anyway.

> First we need to define the elements that one would convey in an IF
> "transcript". The actual notation we use is probably incidental so I'm
going
> to focus on why and when we would use such notation:
>
> Screenplay Elements
> I would use typical screenplay headers such as Act, Scene, etc to
convey
> what part of the story is being told. I think it needs to be made
clear that
> locations, objects, and npc's, all may be written over and over again
in a
> transcript or screenplay style document. So forget about locations and
maps
> and concentrate on the story. Break the story into Acts and Scenes.
Then
> detail the interaction with the following elements:
>
> Assumptions
> An assumption would be given at the beginning of a Scene or Act that
would
> define the state of the game that allowed the coming defined
behaviours.

Sounds very good so far, not forgetting a detailed Dramatis Personae
including motivations. A prop list (i.e. first- and second-level
descriptions) and stage directions are secondary to this, and a map
least important of all.

> Singular Commands
> Select Responses
> Compound Responses
> Ordered Responses

Perhaps most of these can be conveyed easily in script form without
special annotation, and the conditions for success given in natural
language 'stage directions'? IMHO the most important thing for the
writer to convey is points of the script that are critical points
(branches), to which the script may return many times - these
branch-points may need to be numbered or labelled separately from the
scene numbering.

...


> Anyway. These are my initial thoughts as I begin my first
collaboration. I'm
> already using some of the notations listed above and will likely
identify
> many more. When I'm done and the game is completed and tested, I will
> publish my notations along with the final transcript so that we can
have a
> healthy discussion sometime in the future.

I look forward to your results.

CK

A.P. Hill

unread,
Nov 15, 2002, 8:42:18 AM11/15/02
to
You are correct sir. It is not that complicated atall. The Santoonie
Corporation fine tunes communication through doughnut breaks.

We work off of scripts and we don't have any complications
understanding directives. If we did, we wouldn't have a job much
longer. Jarb's information is not totally useless, it could be used
as a recipe for success in telemarketing.

A.P. Hill
Santoonie Corporation

David Thornley

unread,
Nov 15, 2002, 11:09:28 AM11/15/02
to
In article <4O6dnSYcHMe...@giganews.com>,

David A. Cornelson <da...@plover.net> wrote:
>
>In my mind, the separation of implementation and writing are critical to
>future development of Interactive Fiction (though I may be the lone person
>to believe in this theory).

Whether or not it's critical, I don't know if it's possible. I suppose
that a programmer could take a set of specs, and a writer could
write all of the output text. (After the programming is done,
lest more output text be necessary.)

The question I pose is this: Is it possible to
>develop a notation set that would allow an author to convey the working
>details of an Interactive Fiction game/story without caring or understanding
>programming at all?

No.

A notation set that conveys the working details is a programming
language by another name. Anybody who describes something in this
notation set is writing a program.

This has been explored in mainstream computing for a long time.
COBOL came out around 1960, and was advertised in the early days
as removing the need for programming.

Well this is already true to some degree because we know
>that the Zork text game that Whizzard implemented for Activision was
>delivered in transcript form (I believe this is correct). Well, the
>transcript _did_ come from a programmer so I may be off there.

A transcript would be useful in implementation. So would a map.

But my
>question has a deeper condition in that I'm wondering if it were possible to
>develop a notation that specifically helped a writer develop Interactive
>Fiction in such a way that it could be handed to a programmer (with a clear
>understanding of IF) and have their story be implemented relatively
>accurately?
>

In the computing literature, this is usually looked at from the
programmer's perspective, and is called things like requirements
analysis. (Of course, my idea of an ideal Requirements Analyst
is illegal:

RA: Now, what happens if the person *isn't* in the database?
User: I don't know, that shouldn't happen.
<RA takes another turn on the wheel>
User: AAARGHH!
RA: So what *if* the user isn't in the database?
)

Since it is not a finished thing and part of the common wisdom
(judging by the books on it at the bookstore), I don't expect
the IF community to solve it.

>Anyway. These are my initial thoughts as I begin my first collaboration. I'm
>already using some of the notations listed above and will likely identify
>many more. When I'm done and the game is completed and tested, I will
>publish my notations along with the final transcript so that we can have a
>healthy discussion sometime in the future.
>

Sure. That'd be useful.


--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-

David Thornley

unread,
Nov 15, 2002, 11:11:23 AM11/15/02
to
In article <j26B9.4328$XN5.608646@wards>,

Cedric Knight <ckn...@gn.babpbc.removeallBstosend.org> wrote:
>
>There must be something in this, when the number of high-quality works
>of IF produced depends on the number of high-quality writers who are not
>just interested in the form, but also are willing to stoop to
>programming. It would be great to attract more good writers into the

s/stoop/aspire/

Quintin Stone

unread,
Nov 15, 2002, 11:26:07 AM11/15/02
to
On 15 Nov 2002, David Thornley wrote:

> In the computing literature, this is usually looked at from the
> programmer's perspective, and is called things like requirements
> analysis. (Of course, my idea of an ideal Requirements Analyst is
> illegal:
>
> RA: Now, what happens if the person *isn't* in the database?
> User: I don't know, that shouldn't happen.
> <RA takes another turn on the wheel>
> User: AAARGHH!
> RA: So what *if* the user isn't in the database?
> )

I find your ideas on requirements analysis intriguing and would like to
subscribe to your newsletter.

/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Weapons Master & Coder < 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 ||
\====================================================================/

Daryl McCullough

unread,
Nov 15, 2002, 5:41:47 PM11/15/02
to
thor...@visi.com (David Thornley) says...

>A notation set that conveys the working details is a programming
>language by another name. Anybody who describes something in this
>notation set is writing a program.

That's not completely true. A notation system is only a program
if it is executable. That is, if there is a mechanical process
to go from a specification to a program satisfying that
specification.

But I agree in spirit with what you've said. The hard work of creating
IF is figuring out in detail what your game is supposed to do---not just
for one path through the game, but for all possible paths. Thinking through
all these possibilities in a careful way is work comparable to programming.

--
Daryl McCullough
Ithaca, NY

Tommy Herbert

unread,
Nov 16, 2002, 7:39:13 AM11/16/02
to
> It would be great to attract more good writers into the
> community given that there are probably many willing competent
> programmers already.

Is this really true? I've been assuming it would be rather cheeky to
expect somebody else to do the dirty work for me, so I'm struggling
manfully with Inform...

David A. Cornelson

unread,
Nov 16, 2002, 11:18:48 AM11/16/02
to
"Tommy Herbert" <cave...@excite.com> wrote in message
news:9f28c10b.02111...@posting.google.com...

Not at all. Check out the IF Collaborator list (which I can't seem to find
at the moment).

Jarb


Stephen L Breslin

unread,
Nov 16, 2002, 11:28:26 AM11/16/02
to
On 16 Nov 2002 04:39:13 -0800, cave...@excite.com (Tommy Herbert)
wrote:

>> It would be great to attract more good writers into the
>> community given that there are probably many willing competent
>> programmers already.
>
>Is this really true?

You're right, it's not true. I don't know why Jarb would write this,
except in an attempt to boost the excitement for his ill thought out
plan for strict formalization of game transcripts, which to my mind
has no use whatsoever.

> I've been assuming it would be rather cheeky to
>expect somebody else to do the dirty work for me, so I'm struggling
>manfully with Inform...

I wrote a five room, five object game for a novice if'er a couple
months ago. It took a day or so, which isn't very much, but I doubt
anyone else in this group would have volunteered for the task. The IF
community does not consist of lots of programmers with few ideas;
quite the contrary.

David A. Cornelson

unread,
Nov 16, 2002, 11:58:04 AM11/16/02
to
"Stephen L Breslin" <bre...@acsu.buffalo.edu> wrote in message
news:3dd6707...@news.buffalo.edu...

> On 16 Nov 2002 04:39:13 -0800, cave...@excite.com (Tommy Herbert)
> wrote:
>
> You're right, it's not true. I don't know why Jarb would write this,
> except in an attempt to boost the excitement for his ill thought out
> plan for strict formalization of game transcripts, which to my mind
> has no use whatsoever.

I've been playing IF for 20 years, writing it for about 5 and involved in
other aspects of the IF community. I developed a mostly functionaly IDE and
have worked on several other programming related items. Nothing I do is "ill
thought out". I think I also made it clear that my question as to whether a
notation based system of writing IF was practical or not was just that, a
question. It was not a white paper, a thesis, a proof, a claim, or any other
sort of difinitive posting.

Whether you believe in my plans or not makes no difference to me, but to
blatantly say it has no use is, to me, ill thought out.

If you have reasons for not believing in it and a fact-filled contrary
opinion, by all means, share. Otherwise, save the flames for your
cheeseburgers.

Jarb


Stephen L Breslin

unread,
Nov 16, 2002, 1:03:27 PM11/16/02
to
On Sat, 16 Nov 2002 10:58:04 -0600, "David A. Cornelson"
<da...@plover.net> wrote:

>Nothing I do is "ill
>thought out".

Ya, sorry. I think I meant "ill-conceived". Your plan is excessively
detailed, which is my main problem with it. You're thinking it out way
too much, in fact.

Cedric Knight

unread,
Nov 17, 2002, 12:26:31 AM11/17/02
to
"Stephen L Breslin" <bre...@acsu.buffalo.edu> wrote in message
news:3dd6707...@news.buffalo.edu...
> On 16 Nov 2002 04:39:13 -0800, cave...@excite.com (Tommy Herbert)
> wrote:
>
> >> It would be great to attract more good writers into the
> >> community given that there are probably many willing competent
> >> programmers already.
> >
> >Is this really true?
>
> You're right, it's not true. I don't know why Jarb would write this,

Hold on. The top, triple quoted, speculation was mine, not Jarb's.

BTW I stand by it, qualified by the 'probably', and for that reason
started developing a front end to Inform (in Delphi) intending it to
require no programming skill, to be used by writers.

So maybe I should only speak for myself. If a published and talented
author made a proposal for a piece of IF, and I like their writing, I
would jump at a chance to code it. OK, maybe I don't fall under
'competent', but I'd make any mangled source the property of the author.

There's a continuing thread here called 'What do you do for a living?'
which IIRC turned up plenty of programmers, but no authors. Am I
mistaken perhaps in seeing a difference in quality in IF produced by
published writers (Adam Cadre, now perhaps Yoon Ha Lee, who else?). I
hope you're getting the distinction I'm making here between a writer and
someone who can string a sentence together.

[snip]


>
> > I've been assuming it would be rather cheeky to
> >expect somebody else to do the dirty work for me, so I'm struggling
> >manfully with Inform...

'Expect' might be a bit cheeky, but you could ask if you get stuck.

The IF collaborators list was at
http://www.ltlink.com/~jgoemmer/ifcollab.html
but seems to have vanished. There's still an ADRIFT one at
http://www.kf.adrift.iwarp.com/collaborate.html

>
> I wrote a five room, five object game for a novice if'er a couple
> months ago. It took a day or so, which isn't very much, but I doubt
> anyone else in this group would have volunteered for the task. The IF
> community does not consist of lots of programmers with few ideas;
> quite the contrary.

Everyone's got plenty of ideas. Ideas do not make a story, let alone a
writer. Not in non-interactive fiction, anyway.

OK, maybe I ought to go to bed before I start a flame war.

CK

Paul O'Brian

unread,
Nov 18, 2002, 10:46:59 AM11/18/02
to
On Sun, 17 Nov 2002, Cedric Knight wrote:

> There's a continuing thread here called 'What do you do for a living?'
> which IIRC turned up plenty of programmers, but no authors. Am I
> mistaken perhaps in seeing a difference in quality in IF produced by
> published writers (Adam Cadre, now perhaps Yoon Ha Lee, who else?).

Jim Aikin (sf novels). Neil DeMause (journalism). Brent VanFossen (nature
writing). Graham Nelson (poetry). Gerry Kevin Wilson (RPG materials,
though I don't know whether that'd fall into your definition of
"published writer"). I think Michael Gentry (Anchorhead) has had a story
or two published. I'd imagine that the academics among us such as Nick
Montfort and Dennis Jerz aren't strangers to publication, though I
haven't checked their c.v.'s to confirm this.

Also, back in the day, Robert Pinsky (Mindwheel), who would later become
poet laureate of the U.S., and Thomas M. Disch (Amnesia). Michael
Berlyn had some novels published, IIRC. And I think maybe Stu Galley, too,
though my memory's fuzzier on that one. And of course, Douglas Adams.

That's all I can come up with for the moment.

--
Paul O'Brian obr...@colorado.edu http://ucsu.colorado.edu/~obrian
S-P-A-G stands for Interactive Fiction News and Reviews, in a very
non-acronymic way. Check it out at http://www.sparkynet.com/spag

Greg Ewing

unread,
Nov 18, 2002, 7:45:07 PM11/18/02
to
On 15 Nov 2002, David Thornley wrote:

>
> <RA takes another turn on the wheel>
> User: AAARGHH!
> RA: So what *if* the user isn't in the database?

NOBODY expects the Requirements Analyst!

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

Plugh!

unread,
Nov 19, 2002, 3:40:13 AM11/19/02
to
"Cedric Knight" <ckn...@gn.babpbc.removeallBstosend.org> wrote in message news:<DRFB9.4634$XN5.687288@wards>...
>
> BTW I ...

> started developing a front end to Inform (in Delphi) intending it to
> require no programming skill, to be used by writers.

What happened? Did it die the death? is it still in development? does
it have a homepage? can you provide any further details?

Magnus Olsson

unread,
Nov 19, 2002, 7:56:08 AM11/19/02
to
In article <ar3t7...@drn.newsguy.com>,

Daryl McCullough <da...@cogentex.com> wrote:
>thor...@visi.com (David Thornley) says...
>
>>A notation set that conveys the working details is a programming
>>language by another name. Anybody who describes something in this
>>notation set is writing a program.
>
>That's not completely true. A notation system is only a program
>if it is executable. That is, if there is a mechanical process
>to go from a specification to a program satisfying that
>specification.

This is true in one sense. Programmers often specify algorithms in
pseudo-code; a notation that can be understood by a human and, to a
human, describes the algorithm in explicit detail, but is not parsable
by a computer (at least not without strong AI).

However, I think that in the context of this discussion, writing
pseudo-code should be consider the equivalent of programming. To put
it another way: I suspect that an author who knows nothing about
programming and doesn't care about learning anything about programming
can't be expected to describe, in a formal or pseudo-formal way,
exactly how a game is supposed to work. To do that, he'd have to get
into the programmer mindset to some extent.

>But I agree in spirit with what you've said. The hard work of creating
>IF is figuring out in detail what your game is supposed to do---not just
>for one path through the game, but for all possible paths. Thinking through
>all these possibilities in a careful way is work comparable to programming.

Exactly.

This doesn't mean, of course, that there's no point in collaborations
between an author and a programmer, but only that if the author is to
be able to communicate *exactly* how his game is going to work, he would
have to learn *something* about programming.

Of course, he wouldn't have to learn an actual programming language,
or the mechanics of coding; the programmer would take care of that;
and that would probably be a good thing for the author.

--
Magnus Olsson (m...@df.lth.se)

David A. Cornelson

unread,
Nov 19, 2002, 8:33:17 AM11/19/02
to
"Magnus Olsson" <m...@df.lth.se> wrote in message
news:ardcd8$mht$1...@news.lth.se...

Yeah, the problem with me putting together this notation and writing a
transcript for someone else to code is that I've been a programmer for 20
years and involved in IF coding for about 5 years. So I sort of break my own
rules, which is that the notation should be usable by a non-programmer.

We'll see what happens as I communicate with my partner and we have to
fine-tune the code as compared to my writings. If I find that the
fine-tuning is far more complex than simply writing a transcript and that in
order to truly communicate the logic of my thoughts I need to write
pseudo-code, then yes, this idea is fruitless.

But if it is possible to convey, say, 80%-90% of an IF game without
programming knowledge, there is still some benefit here. This means that a
writer could create most of the text, which is a very difficult part of this
process, a programmer could implement the code, and then potentially a third
person, some sort of hybrid writer/programmer could do quality assurance on
the end result (um, beta-tester).

If this were possible, then we have the model for process-oriented team IF
development with a written methodology.

Of course this could all be bollocks...

Jarb


Lucian P. Smith

unread,
Nov 19, 2002, 8:54:46 AM11/19/02
to

OK everybody, stand back: I'm about to invoke Erasmatron in a positive
context...


Magnus Olsson <m...@df.lth.se> wrote in <ardcd8$mht$1...@news.lth.se>:
: This is true in one sense. Programmers often specify algorithms in


: pseudo-code; a notation that can be understood by a human and, to a
: human, describes the algorithm in explicit detail, but is not parsable
: by a computer (at least not without strong AI).

: However, I think that in the context of this discussion, writing
: pseudo-code should be consider the equivalent of programming.

It was the premise of Chris Crawford, et al. that, essentially, that last
sentence is incorrect. That is, non-programmers could be taught/cajoled
into using a type of computer-parsable 'pseudo-code' that would enable
them to bring a creative vision to a computer. For that matter, that's
also the premise of 'Adrift' and other languages that promise to let you
program without really programming.

Now, while I think I disagree that modern computers have the capacity to
do such a job well, I *do* think it's possible for a human to bridge that
interface. In other words, a non-programmer may well have the capacity to
think logically and methodically about what they want to accomplish, and
convey that to a programmer, who can translate how to actually code that
up.

Then again, I have no idea whether a formalized system such as Jarb
suggested would help or hinder that process. My instinct is to answer
'hinder', but I can imagine an artist non-programmer who would be helped
by having to write their ideas in a formal system into thinking along
those lines.

To put it another way: we all agree that non-programmers can find bugs in
our games. You don't have to know the difference between if(obj in
player) and IndirectlyContains(obj, player) to be able to say, "Hey, the
mango was in my backpack but the game claimed I didn't have it." And that
level of thinking is all you need to have the concept for a game in your
head, even if you can't program to save your life.

Also, this would be a good time for people who have actually collaborated
in a programmer/non-programmer team to speak up ;-)

-Lucian

David A. Cornelson

unread,
Nov 19, 2002, 11:05:51 AM11/19/02
to
"Lucian P. Smith" <lps...@rice.edu> wrote in message
news:ardfr6$ndc$1...@joe.rice.edu...

>
>
> Now, while I think I disagree that modern computers have the capacity to
> do such a job well, I *do* think it's possible for a human to bridge that
> interface. In other words, a non-programmer may well have the capacity to
> think logically and methodically about what they want to accomplish, and
> convey that to a programmer, who can translate how to actually code that
> up.
>

I didn't even think this was part of the questioning. I work with Business
Analysts all the time. They have no programming experience at all, yet they
have a trained ability to examine and report the workings and logic of
business systems in english in organized formats.

I know this works in the business world and wonder why we all assumed that
it wouldn't work for IF as well and now it seems that maybe the issue here
is that many IF people don't even believe business analysts can function
properly without coding experience.

I'm confused.

Jarb


David Thornley

unread,
Nov 19, 2002, 11:59:24 AM11/19/02
to
In article <ardfr6$ndc$1...@joe.rice.edu>,

Lucian P. Smith <lps...@rice.edu> wrote:
>
>Magnus Olsson <m...@df.lth.se> wrote in <ardcd8$mht$1...@news.lth.se>:
>
>: However, I think that in the context of this discussion, writing
>: pseudo-code should be consider the equivalent of programming.
>
>It was the premise of Chris Crawford, et al. that, essentially, that last
>sentence is incorrect. That is, non-programmers could be taught/cajoled
>into using a type of computer-parsable 'pseudo-code' that would enable
>them to bring a creative vision to a computer. For that matter, that's
>also the premise of 'Adrift' and other languages that promise to let you
>program without really programming.
>
I believe that Chris Crawford was incorrect.

In practice, it is not possible for non-programmers to write things
in computer-parsable form in general. If you restrict the domain,
you can make it possible, but at the cost of expressiveness.
This is obviously useful in some contexts (many more people can
format using Microsoft Word than LaTeX, for example), but it
should not be taken too far.

>Now, while I think I disagree that modern computers have the capacity to
>do such a job well, I *do* think it's possible for a human to bridge that
>interface.

This is done all the time in real life, although usually not through
formal notations.

In other words, a non-programmer may well have the capacity to
>think logically and methodically about what they want to accomplish, and
>convey that to a programmer, who can translate how to actually code that
>up.
>

Again, this is done all the time. Most software is written to
satisfy in-house needs, and this means that a programmer who doesn't
know beans about how an HR department runs has to find out in some
manner from some HR people who don't know beans about programming.
(I've never had accountants as users, but my wife tells me they're
wonderful: they know what they want, and have no problems in telling
her, so she can write stuff for them confident that they're going to
like it if it's good.)

Frequently, you put some sort of analyst between the users and the
programmers, whose job it is to communicate (which often means
helping the users decide what they want - and in the case of
consulting companies means coercing the users to sign off on what
they want).

>Then again, I have no idea whether a formalized system such as Jarb
>suggested would help or hinder that process. My instinct is to answer
>'hinder', but I can imagine an artist non-programmer who would be helped
>by having to write their ideas in a formal system into thinking along
>those lines.
>

Constraints are sometimes good for art.

>To put it another way: we all agree that non-programmers can find bugs in
>our games. You don't have to know the difference between if(obj in
>player) and IndirectlyContains(obj, player) to be able to say, "Hey, the
>mango was in my backpack but the game claimed I didn't have it." And that
>level of thinking is all you need to have the concept for a game in your
>head, even if you can't program to save your life.
>

Right.

If you had an idea in your head, and couldn't program, you could
collaborate and wind up with a game. This is true. It is completely
analogous to real life, when a user may know something's a problem,
believe that the computer could solve it, and not know how to connect
the two.

I would think that the non-programmer could draw a map and describe
objects, for a start. He or she could write up puzzles as text
("The dragon is sleeping on the goblet, so the player can't reach
it. To get the dragon to move, it is necessary to have scales from
a dragon of the appropriate sex. If the player is holding the
scales, the dragon eats the player. If the scales are simply
left on the ground, the dragon won't notice them (dragons prefer
to hold their heads up). The scales need to form a trail that goes
far enough from the lair...."). NPCs strike me as a very difficult
problem in communicating the non-programmer's ideas to the programmer.

Magnus Olsson

unread,
Nov 19, 2002, 1:01:44 PM11/19/02
to
In article <ardfr6$ndc$1...@joe.rice.edu>,
Lucian P. Smith <lps...@rice.edu> wrote:
>
>OK everybody, stand back: I'm about to invoke Erasmatron in a positive
>context...
>
>
>Magnus Olsson <m...@df.lth.se> wrote in <ardcd8$mht$1...@news.lth.se>:
>: This is true in one sense. Programmers often specify algorithms in
>: pseudo-code; a notation that can be understood by a human and, to a
>: human, describes the algorithm in explicit detail, but is not parsable
>: by a computer (at least not without strong AI).
>
>: However, I think that in the context of this discussion, writing
>: pseudo-code should be consider the equivalent of programming.
>
>It was the premise of Chris Crawford, et al. that, essentially, that last
>sentence is incorrect. That is, non-programmers could be taught/cajoled
>into using a type of computer-parsable 'pseudo-code' that would enable
>them to bring a creative vision to a computer.

In which case I'd say that the (erstwhile) non-programmer has been
taught some programming.

But this is, of course, a matter of how you define "programming" and
"non-programmer". Perhaps it's a semantic way of cajoling
non-programmers into doing what they thought they couldn't?

--
Magnus Olsson (m...@df.lth.se)

Magnus Olsson

unread,
Nov 19, 2002, 1:10:21 PM11/19/02
to
In article <-RmdndfgqKM...@giganews.com>,

David A. Cornelson <da...@plover.net> wrote:
>"Magnus Olsson" <m...@df.lth.se> wrote in message
>news:ardcd8$mht$1...@news.lth.se...
>> In article <ar3t7...@drn.newsguy.com>,
>> Daryl McCullough <da...@cogentex.com> wrote:
>> >thor...@visi.com (David Thornley) says...
>> >
>> >>A notation set that conveys the working details is a programming
>> >>language by another name. Anybody who describes something in this
>> >>notation set is writing a program.
>> >
>> >That's not completely true. A notation system is only a program
>> >if it is executable. That is, if there is a mechanical process
>> >to go from a specification to a program satisfying that
>> >specification.
>>
>> This is true in one sense. Programmers often specify algorithms in
>> pseudo-code; a notation that can be understood by a human and, to a
>> human, describes the algorithm in explicit detail, but is not parsable
>> by a computer (at least not without strong AI).
>>
>> However, I think that in the context of this discussion, writing
>> pseudo-code should be consider the equivalent of programming.

(more discussion of this point snipped)

>Yeah, the problem with me putting together this notation and writing a
>transcript for someone else to code is that I've been a programmer for 20
>years and involved in IF coding for about 5 years. So I sort of break my own
>rules, which is that the notation should be usable by a non-programmer.

As I've pointed out elsewhere in this thread, I think this is a matter
of how you define "non-programmer". Has the person who's mastered your
notation been transformed into a programmer? Maybe, maybe not.

Anyway, I think your tool may be useful. I'm not sure if it's really
needed - perhaps the people who claim transcripts are enough are
correct - but if it can simplify the process of creating IF, enabling
people without a programming background to collaborate more easily
with programmers, then I think it will be a Good Thing.

>But if it is possible to convey, say, 80%-90% of an IF game without
>programming knowledge, there is still some benefit here.

Agreed.

--
Magnus Olsson (m...@df.lth.se)

Magnus Olsson

unread,
Nov 19, 2002, 1:23:44 PM11/19/02
to
In article <Sxqdnd_gNYL...@giganews.com>,

David A. Cornelson <da...@plover.net> wrote:
>I didn't even think this was part of the questioning. I work with Business
>Analysts all the time. They have no programming experience at all, yet they
>have a trained ability to examine and report the workings and logic of
>business systems in english in organized formats.
>
>I know this works in the business world and wonder why we all assumed that
>it wouldn't work for IF as well and now it seems that maybe the issue here
>is that many IF people don't even believe business analysts can function
>properly without coding experience.
>
>I'm confused.

OK. In your example substitute "trained ability to examine and report
the workings and logic of business systems" for "coding
experience". Both are complex skills that require training and
experience.

When it comes to IF, I think the question is: does an author with no
prior IF-writing experience have the ability to design a computer
game, and to express this design in a formal form?

Maybe, maybe not. But it doesn't necessarily follow from your business
analyst example.

--
Magnus Olsson (m...@df.lth.se)

Tommy Herbert

unread,
Nov 19, 2002, 4:17:35 PM11/19/02
to
> But if it is possible to convey, say, 80%-90% of an IF game without
> programming knowledge, there is still some benefit here. This means that a
> writer could create most of the text, which is a very difficult part of this
> process, a programmer could implement the code, and then potentially a third
> person, some sort of hybrid writer/programmer could do quality assurance on
> the end result (um, beta-tester).
>
> If this were possible, then we have the model for process-oriented team IF
> development with a written methodology.
>
> Of course this could all be bollocks...
>
> Jarb


I hope its not bollocks, because the kind of IF I like is not hard to
play, but it's good literature. I'm thinking of Cadre, Plotkin and
Short.

One thing about this kind of IF is that, while it needs good writing
(obviously) and thorough design, it also needs really quite competent
coding - since original ideas often need innovative implementation.
Galatea is an example of a game which would have been less good if the
programming was so-so, or if fewer user-responses had been
anticipated. I mean, look at The Visitor - an attempt at the same
kind of thing, entered in the same competition. So, apart from the
issue of some people being good coders and others being good writers,
there is the more practical problem of man-hours. If a lot of time
needs to be put into both the design and the code itself, then the way
forward must be teamwork.

But another thing about this kind of IF is that the code is often
integrated with the writing to a far greater extent than in lesser
games. I don't know how Shade was planned, but it looks to me as
though the code's innovations informed the storyline as well as vice
versa. This is a problem for teamwork.

Maybe Jarb's notation will reconcile the problem of specialisation
with the problem of integration, or maybe the answer is simply to
collaborate very closely, but if "team IF" remains bollocks then there
will only ever be a handful of games that I like...

Andrew Plotkin

unread,
Nov 19, 2002, 4:43:51 PM11/19/02
to
Here, Tommy Herbert <cave...@excite.com> wrote:

> But another thing about this kind of IF is that the code is often
> integrated with the writing to a far greater extent than in lesser
> games. I don't know how Shade was planned, but it looks to me as
> though the code's innovations informed the storyline as well as vice
> versa.

Not much. (But I still think the code is deeply integrated with the
writing!)

I had the storyline first. Then I worked out the list of goal actions,
and (simultaneously) the design of the apartment.

Then, since I wanted to keep the one-room concept, I implemented the
subroom/automovement system to make it work. (If that had turned out
to be impossible, I would have rearranged the game design into
separate rooms, but that didn't become necessary.) Then I implemented
the goal system. After that it was just event-by-event, object-by-
object coding.

The subroom code is an example of major library surgery that became
necessary in the course of game creation. But really, the value of
"working both sides of the divide" is evident in much smaller issues.
In _Shade_, for example, I have several sand objects which can be in
scope. Also two sinks -- and note that two of the sand objects are
named "the sand in the kitchen sink" and "the sand in the bathroom
sink"!

That required a lot of tuning of the object disambiguation system. And
this was not strictly mechanical tuning. I had to consider what
the player *wanted* to be doing; what the player *should* want to be
doing; which commands must flow fluidly, and which could be
interrupted with a disambiguation message.

Similarly, the room and subroom descriptions. Lot of fiddling.

When I write a game, I consider *every* output message to be code, not
a block of text. In most cases, the code only needs to *be* a fixed
block of text -- but the question must always be "How shall I code
this?", not "What text will I write?" Fixed message; cycle of N
messages; random choice of N messages; random choice of N constrained
never to repeat twice in a row; sequence of N messages followed by a
fixed message from N+1 onwards; any of the above modified by game
state; any of the above *modifying* game state... I have used all of
these options in various games, and I invent more every time I write a
new game.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.

David Welbourn

unread,
Nov 19, 2002, 4:19:31 PM11/19/02
to
Would an example help? Is this the sort of thing you're looking for?
[Minor spoilers for Balances ahead...]

//================================================
// LOCATIONS
// note: All places are lit except the Cave.
//================================================

@ Ramshackle Hut @
// ignorable junk: windows, grasslands, grass, hills
// what's here: broken furniture (hiding a locked cedarwood box,
// which contains Helistar's grimoire of spells)
// out,west: Grasslands

>look
Until quite recently, someone lived here, you feel sure.
Now the furniture is matchwood and the windows are glassless.
Outside, it is a warm, sunny day, and grasslands extend to the
low hills on the horizon.

>go (default)
There's only the one room: better go "out".

>x furniture | search it | look under it
(if first time)
[give box to player; +5 points]
Searching through the furniture, which is good for nothing
but firewood now, you come across an old cedarwood box,
which you pick up for a closer look.
(otherwise treat as normal scenery. Don't let the player take the
furniture.)


David A. Cornelson

unread,
Nov 19, 2002, 10:29:09 PM11/19/02
to
"David Welbourn" <dsw...@look.ca> wrote in message
news:utlaml7...@corp.supernews.com...

> Would an example help? Is this the sort of thing you're looking for?
> [Minor spoilers for Balances ahead...]
>
> //================================================
> // LOCATIONS
> // note: All places are lit except the Cave.
> //================================================
>
> @ Ramshackle Hut @
> // ignorable junk: windows, grasslands, grass, hills
> // what's here: broken furniture (hiding a locked cedarwood box,
> // which contains Helistar's grimoire of spells)
> // out,west: Grasslands
>
> >look
> Until quite recently, someone lived here, you feel sure.
> Now the furniture is matchwood and the windows are glassless.
> Outside, it is a warm, sunny day, and grasslands extend to the
> low hills on the horizon.
>

Dear god no. (sorry)

The above (and snipped) example is far more than I would expect from a
writer.

What I think is expected of the writer is possibly this:

ACT I - The Place Where You Do The Thing

Scene 1 - The Place
I am the author and I am setting the tone for the state of the game here as
well as what's about to happen. This is probably analagous to an "Overview"
in a technical functional design" or the background to a scene in a
screenplay.

:: (simple command that enters scene)

Location Title
This is the location description.

:1: (select command)

Response goes here.

:2: (select command)

Response goes here.

:3: (select command)

Response goes here.

Location Title
This is another location description, possibly even the same as another or
the same as another with changes.

:1: (select command)

Response goes here.

:2: (select command)

Response goes here.

* * * * *

Okay. So there's a lot of logic left to interpretation, but that's not the
writer's job. The writer's job is to convey a story. Then this would
probably go to a designer/architect who would lay out the object model and
such. Then a programmer would implement the object model and transcript.

(This is all very rough - continue excellent discussion!)

Jarb


Mike Sousa

unread,
Nov 19, 2002, 10:50:42 PM11/19/02
to
Lucian P. Smith wrote:

> Also, this would be a good time for people who have actually collaborated
> in a programmer/non-programmer team to speak up ;-)
>

Okay, I'll bite, with spoilers. (Also note that I'm not speaking for
Robb Sherwin or Jon Ingold, these be my thoughts only. I do think that
both collaborations were sort of successful in that a decent game was
produced -- yet both collaborations were created differently. Yes, I'll
elaborate, but first...)

My apologies to those participating in this thread, I haven't read all
the responses, skimming some and reading others -- so this may be off
target, especially since the team consisted of two programmers, though
only one of us coded, and based on how long this sentence is, you can
guess that the programmer was I, uh me, um, Mike.

After the 2000 comp I realized that not everyone will like every game.
However, if the game is well written and well coded, no one should hate
it (and if they do, it sucks for them -- maybe they were drunk?) That's
when I thought my next attempt should be a collaboration with a writer.
They do all the writing -- I do all the coding. Enter "No Time To
Squeal".

I had the story mapped out for NTTS, divided into the 5 scenes, a few
obstacle puzzles and not much more. I created a quick TADS game that
spit out each scene and there was nothing more to do than hit the space
bar. This allowed Robb to get a feel for the story. So far so good.

We had agreed to use fake transcripts of game play as our 'tool'. It
worked like a charm. He would send over his first cut. I would read
the transcript and pretend to play it and add alternate attempts at a
solution or examine/manipulating scenery that he described (I would try
to be a player but knowing code, I would also anticipate problem items).
For instance, he had described the bar in detail and briefly mentioned
champagne glasses. I would add >X CHAMPAGNE GLASSES to the script. In
the golf scene, I added >HIT DAN WITH CLUB and so on and so forth. When
he got the script back, he would respond to my attempts. This continued
for a couple of iterations until the script was good enough to implement
(code).

The script wasn't always this clean because certain actions (like
hitting Dan with the club) would cause the game to jump a couple of
scenes. Robb would identify these jumps with markers. His system
worked real well.

When the scene was completely coded, I would play through it and turn on
scripting. Any response that needed tweaking or just didn't work was
marked up and sent to Robb. He would then do the honors. This
continued to the end game.

The entire collaboration was done in email (I live in Massachusetts --
he lives in Colorado). We only needed to talk on the phone once (mostly
because it was the week of the deadline and there was no time for email
lag) to iron out an issue with the chess board scene at the end.

From a personal standpoint, I got to be good friends with Robb and
learned some neat things about writing. Sure I can't duplicate it, but
I still learned! Also, let me go on record as saying that the RESTART
gimmick was my idea and that J.D. Berry practically begged me to get rid
of it. Rule #3 -- listen to your beta-testers!!!

For Comp 02, Jon Ingold and I teamed up. A collaboration was attractive
to Jon since he knew he would have little time to code (he traveled more
this summer than our Sales staff -- combined). Unlike NTTS, I did not
have a complete storyboard for "Till Death...". I did have a premise
and a goal but it needed work.

The story to "Till Death..." was shaped through lots of emails, going
back to November of last year. (We planned on entering Adam's Spring
Thing but our schedules didn't click.) Once we had the premise, Jon
sent over the first transcript. Unlike NTTS, I didn't mock it up and
send it back to him -- I think because we were in a hurry and decided
that I code while he continues to write. It seemed to work.

Once a scene was completed, I would play it through, try a bunch of
stuff, fill in what I could and send the rest to Jon. He would then
respond accordingly. This continued to the end.

As a result of the collaboration, Jon and I have become good friends --
we even hooked up last month when he spent a week in the Mass/RI area.
As with NTTS, I learned some neat things from Jon and because "Till
Death..." didn't have a complete storyboard, I was able to brainstorm
with him during our email exchange. Cool stuff -- he's fascinating to
watch in terms of game play development.

For what it's worth, I'm working on my "Till Death..." web page and one
of the links I plan on adding is our email exchange for the entire
project -- unedited, um, as it relates to the game. Don't know if
that's something of interest, but I had planned on doing it with NTTS
but never got around to it... :(

So what do I really have to say about collaborations? They work. But,
there's always a but... the team has to click. Both Robb and Jon were
great to work with and extremely talented -- that combination made it
that much easier to complete the project.

As for tools, transcripts were it. They allowed scenery items to be
expanded (detailed), alternate solutions to puzzles to be identified and
showed 'game play' flow.

One member did all/most of the writing (I'll admit to writing the Hint
system in "Till Death..." and I'm assuming that's where all the bad
grammar/typo references are coming from) and one member does all the
coding. This also allowed for the team to work at the same time.

From a scheduling standpoint, it can be tricky and at times, hard to
manage. For instance, I don't recommend starting September 1 for a comp
entry -- collaborations take time. Life can get in the way and that
needs to be accounted for in the schedule. Though, on the flip side,
having a team can increases responsiveness.

I've been working on "At Wit's End Again", off and on, for 8 months.
There's no guilt if I go a month without opening up a single .t file.
In a collaboration, there was that slight "pressure" to respond to an
email or code a scene because the team was depending on you. Just my
observations...

I'll be happy to respond to any points or specifics regarding what I
wrote, that is if you've read this far. :)

-- Mike


T Raymond

unread,
Nov 19, 2002, 11:22:17 PM11/19/02
to
"Cedric Knight" <ckn...@gn.babpbc.removeallBstosend.org> wrote in
news:DRFB9.4634$XN5.687288@wards:

> The IF collaborators list was at
> http://www.ltlink.com/~jgoemmer/ifcollab.html
> but seems to have vanished. There's still an ADRIFT one at
> http://www.kf.adrift.iwarp.com/collaborate.html

There's still also the IF Assistance List, which I must admit I
haven't verified anything on since I started, but any info is
probably a bit newer than the IFC, whatever worth that might be.

Tom
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Raymond ab402 AT osfnDOTorg
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

David A. Cornelson

unread,
Nov 20, 2002, 3:02:02 AM11/20/02
to
"Mike Sousa" <mjsousa_R_...@attbi.com> wrote in message
news:3DDB06B7...@attbi.com...

>
> Okay, I'll bite, with spoilers. (Also note that I'm not speaking for
> Robb Sherwin or Jon Ingold, these be my thoughts only. I do think that
> both collaborations were sort of successful in that a decent game was
> produced -- yet both collaborations were created differently. Yes, I'll
> elaborate, but first...)
>
<snip really cool description of collaborations!>

Now...can we get one of the writers to put their perspective into this
discussion?

Jarb


David Thornley

unread,
Nov 20, 2002, 12:22:48 PM11/20/02
to
In article <ZN2dnTzdqqw...@giganews.com>,

David A. Cornelson <da...@plover.net> wrote:
>
>What I think is expected of the writer is possibly this:
>
>ACT I - The Place Where You Do The Thing
>
>Scene 1 - The Place
>I am the author and I am setting the tone for the state of the game here as
>well as what's about to happen. This is probably analagous to an "Overview"
>in a technical functional design" or the background to a scene in a
>screenplay.
>
>:: (simple command that enters scene)
>
>Location Title
>This is the location description.
>
>:1: (select command)
>
>Response goes here.
>
So, more of a transcript? That would be one thing I'd expect.

>Okay. So there's a lot of logic left to interpretation, but that's not the
>writer's job. The writer's job is to convey a story. Then this would
>probably go to a designer/architect who would lay out the object model and
>such. Then a programmer would implement the object model and transcript.
>

The problem is that this is a linear story, and any random action by
the player can derail the story (or at least the perceived continuity).
Somebody has to take this into account, presumably the designer/architect.
There has to be a good deal of additional communication going on, and
feedback (Architect: "Can we do without that rope in scene 2?").

So, we ask the writer to provide a map, a sample transcript, a list
of objects and what the writer expects them to be good for, the
designer/architect fleshes it out as possible (with plenty of
communication with the writer), and passes it on to the programmer.
Obviously, the programmer is going to be making a great many small
decisions along the way, some of which are going to be definitely
not what the writer wanted. The programmer may find things that
are unreasonably difficult to do, or (for media effects) impossible
with the chosen language.

These look to me to be reasonable roles, with the proviso that
separate roles do not necessarily mean separate people.

I suppose the next question is: If you were the designer/architect
here, what would you want from the writer at first? I propose
a map, list of objects, list of NPCs, descriptions, and a sample
transcript.

David Thornley

unread,
Nov 20, 2002, 12:28:09 PM11/20/02
to
In article <WM6dnTcnuP8...@giganews.com>,

David A. Cornelson <da...@plover.net> wrote:
I think you're missing something: Mike said that he was the programmer,
and also did much of the creative design role. In other words, it
looks like he did much of the "writer" role himself.

Mike Sousa

unread,
Nov 20, 2002, 7:27:56 PM11/20/02
to

David Thornley wrote:
>>Now...can we get one of the writers to put their perspective into this
>>discussion?
>>
>
> I think you're missing something: Mike said that he was the programmer,
> and also did much of the creative design role. In other words, it
> looks like he did much of the "writer" role himself.
>

I don't think so, unless the definition of "writer" in this sense
escapes me. As a specific example, the dialog between Jon and I went
something like this:

Mike: "Hey Jon, got this idea about the PC's conscience transmitted to
a corpse. The goal is to try to die but we won't allow it and
ultimately in some twist, the conscience is returned back to the PC."

Jon: "Hmm... Okay, how about some experiment, like this.... "

Mike: "... cool, and we can add this..."

Jon: "... and we can wrap it up this way. "

Mike: "Sounds great, send over the first transcript."

That was the extent of my "writer" role in the story. There were minor
objects and such that I implemented but Jon designed the puzzles and
wrote all the text.

-- Mike

LizM7

unread,
Nov 22, 2002, 1:08:24 AM11/22/02
to
"David A. Cornelson" <da...@plover.net> wrote:
> What I think is expected of the writer is possibly this:
>
> ACT I - The Place Where You Do The Thing
>
> Scene 1 - The Place
> I am the author and I am setting the tone for the state of the game here as
> well as what's about to happen. This is probably analagous to an "Overview"
> in a technical functional design" or the background to a scene in a
> screenplay.
>
> :: (simple command that enters scene)
>
> Location Title
> This is the location description.
>
> :1: (select command)
> Response goes here.
> :2: (select command)
> Response goes here.
> :3: (select command)
> Response goes here.
> Okay. So there's a lot of logic left to interpretation, but that's not the
> writer's job. The writer's job is to convey a story. Then this would
> probably go to a designer/architect who would lay out the object model and
> such. Then a programmer would implement the object model and transcript.

The problem with this format, I think, is that it *doesn't*
effectively convey a storyline - simply because when I think of an IF
story, I think of it in terms of sequencial order - goal A (involving
rooms 1, 2, and 3), then goal B (involving rooms 3, 2, and 4), then
goal C (w/rooms 4, 2, and 5), etc. To divide commands up based upon
what room they're in strikes me as counterintuitive, because then I'd
be forced to cut up the storyline. (Mind you, it happens eventually -
but if we're going to avoid programming, then this should probably be
avoided as well, because (in what little programming I've done) I've
generally tended to divide commands into rooms as I'm coding them.)

What I'm saying is, it's a whole lot easier for me to write out a
transcript (repetative as it may be) than it would be for me to sit
down and divide commands up into rooms - because *even if I were
including less information*, I would be including it in a way which is
counter-intuitive. The only way *I*, at least, could write in the way
that you're suggesting would be for me to write out the commands
sequencially, only skipping between rooms as necessary.

The method might work, I think, in something like a MUD, in which
there are few (if any) puzzles or stories, and thus rooms don't need
to be integrated with each other, but when it comes to IF, I think
this would be a bad idea, as it'd tend to encourage people to design
rooms separately, without thinking how they interact with each other.

(Besides, who wants to streamline IF programming? Commercial IF has
been dead for a decade plus - people do it for fun these days, so
there's really no need for an assembly line.)

- Liz

LizM7

unread,
Nov 22, 2002, 1:39:11 AM11/22/02
to
m...@df.lth.se (Magnus Olsson) wrote:
> David A. Cornelson <da...@plover.net> wrote:
> >I didn't even think this was part of the questioning. I work with Business
> >Analysts all the time. They have no programming experience at all, yet they
> >have a trained ability to examine and report the workings and logic of
> >business systems in english in organized formats.
> >
> >I know this works in the business world and wonder why we all assumed that
> >it wouldn't work for IF as well and now it seems that maybe the issue here
> >is that many IF people don't even believe business analysts can function
> >properly without coding experience.
> >
> >I'm confused.

(Wait a second, now *I'm* confused as well. Who said anything about
business analysts? And since when does their job require coding
experience? I think the analogy doesn't apply - but see below.)



> OK. In your example substitute "trained ability to examine and report
> the workings and logic of business systems" for "coding
> experience". Both are complex skills that require training and
> experience.
>
> When it comes to IF, I think the question is: does an author with no
> prior IF-writing experience have the ability to design a computer
> game, and to express this design in a formal form?

Hm. This raises a good point, which is, I think, that programming (at
least, of the IF variety) isn't just a language - it's a *state of
mind*.

Or (and it's late, so this is muddled), learning how to program in,
say, Inform isn't simply a matter of learning what routines to call,
etc. Today, at least, that information is generally integrated with
learning how to design a game. Sure, there can be a discussion of the
code which doesn't refer to various elements of game design, or an
abstract discussion of game design which doesn't refer to code, but
*most* of the time these two elements are integrated with each other.
Thus (e.g.) in the ID4 all but the most obscure routines (or whatever)
are demonstrated in the context of designing objects or commands or
rooms or what-have-you. And at the same time, virtually all of the
concrete examples of object design or room design that you'll come
across are going to be found using code - simply because it's the
easiest way to summarize things.

So learning how to program involves not only learning how to write the
actual code, but also how to design a game properly.

*frowns* This would be a lot clearer if it weren't past midnight.

I suppose this says I shouldn't bother trying to write my paper,
either. Hm.

- Liz

L. Ross Raszewski

unread,
Nov 22, 2002, 3:26:45 AM11/22/02
to
On 21 Nov 2002 22:39:11 -0800, LizM7 <hsel...@hotmail.com> wrote:
>
>So learning how to program involves not only learning how to write the
>actual code, but also how to design a game properly.
>
>

I have been saying this for years. The makers of Adrift, or AGT, or
any other "You don't need to program to write programs" system labor
under a delusion which is this:

They believe that the hard part of programming is learning syntax and
usage. They think that it's things like having to put a semicolon at
the end of a statement that makes programming hard. (I am a
programmer. With the possible exception of INTERCAL, there is
progrably *no programming language* whose syntax is so bizarre that I
couldn't work out the basics of it with a language reference and a
couple of hours of looking at code. All the hard things to learn I
learned back in CS201 learning C)

It's not. The hardest thing about programming is learning how to
*think like a programmer*. The reason programming languages seem hard
isn't because they have things like '->' in them -- it's because they
require you to be *explicit* and actually *say what you mean*. The
novice doesn't have trouble because he doesn't know how this operator
works -- he has problems because he didn't think through all the
implications of what he's doing.

Richard Bos

unread,
Nov 22, 2002, 4:38:14 AM11/22/02
to
lrasz...@loyola.edu (L. Ross Raszewski) wrote:

> (I am a
> programmer. With the possible exception of INTERCAL, there is
> progrably *no programming language* whose syntax is so bizarre that I
> couldn't work out the basics of it with a language reference and a
> couple of hours of looking at code.

I want to mention only three letters: A. P. L.

Richard

Sam Dennis

unread,
Nov 22, 2002, 6:27:37 AM11/22/02
to

If you're suggesting that APL is more difficult than INTERCAL, you obviously
haven't ever tried coding anything (at all) in the latter.

--
++acr@,ka"

David A. Cornelson

unread,
Nov 22, 2002, 7:45:00 AM11/22/02
to
"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:9TlD9.19302$We5....@nwrddc04.gnilink.net...

> On 21 Nov 2002 22:39:11 -0800, LizM7 <hsel...@hotmail.com> wrote:
> >
> >So learning how to program involves not only learning how to write the
> >actual code, but also how to design a game properly.
> >
> >
>
> I have been saying this for years. The makers of Adrift, or AGT, or
> any other "You don't need to program to write programs" system labor
> under a delusion which is this:
>

Whoa....this is not _that_ discussion.

This discussion is not how a non-programmer can create an IF game by
themselves. I am in complete agreement that in the context of a singular IF
author, you must both write code and write text. There are no short cuts
when you do it by yourself.

However, this discussion is about how a writer could communicate most
elements of an IF game to others that would allow implementation of the game
to be carried out given that the writer knows little or nothing about
programming concepts. Someone along the line _will_ require programming
knowledge and I'm suggesting a high level of programming knowledge. But the
game itself is written by a writer.

Jarb


David A. Cornelson

unread,
Nov 22, 2002, 7:55:53 AM11/22/02
to
"LizM7" <hsel...@hotmail.com> wrote in message
news:d89b4999.0211...@posting.google.com...

> "David A. Cornelson" <da...@plover.net> wrote:
> > What I think is expected of the writer is possibly this:
> >
>
> The problem with this format, I think, is that it *doesn't*
> effectively convey a storyline - simply because when I think of an IF
> story, I think of it in terms of sequencial order - goal A (involving
<snip methods of game design>

Well. I think this is part of my discovery process as I collaborate on a
game. The previously posted example was only to clarify what would _not_ go
into a collaboration transcript.

>
> (Besides, who wants to streamline IF programming? Commercial IF has
> been dead for a decade plus - people do it for fun these days, so
> there's really no need for an assembly line.)
>

I don't want to start a war here, but I believe one of the ways IF can grow
and mature is if we develop _different_ ways of doing it. I think ego plays
a large part in writing IF. Most of us would like to write a game, offer it
to the community, and garner all the just rewards of doing so. This is
natural and a good thing.

But it also limits our production capabilities. If we were to set aside our
ego's and collaborate more often and allow people to take on roles in a team
(author, designer, architect, coder, tester), we would develop more games
and games with a much higher quality. There are those that patently believe
this to be a falsehood, but I don't believe there's any rational basis for
their arguments. Infocom had several instances of non-programmer/writers
develop and design games that were implemented by others within the company.
Some of these games (Hitchhikers) were very well done. Anyway, this
discussion isn't so much about that, but simply how to collaborate
successfully in designing and implementing an IF game.

This could potentially lead to flying sheep. "Think of the commercial
possibilities."

Jarb


Richard Bos

unread,
Nov 22, 2002, 7:43:56 AM11/22/02
to
Sam Dennis <s...@malfunction.screaming.net> wrote:

> Richard Bos wrote:
> > lrasz...@loyola.edu (L. Ross Raszewski) wrote:
> >> (I am a
> >> programmer. With the possible exception of INTERCAL, there is
> >> progrably *no programming language* whose syntax is so bizarre that I
> >> couldn't work out the basics of it with a language reference and a
> >> couple of hours of looking at code.
> >
> > I want to mention only three letters: A. P. L.
>
> If you're suggesting that APL is more difficult than INTERCAL,

More difficult? No, perhaps not. But I wouldn't wager being able to
write anything in it after only a few hours of perusal.

Richard

David Thornley

unread,
Nov 22, 2002, 9:37:13 AM11/22/02
to
In article <6ZKcnYqe8ab...@speakeasy.net>,

David A. Cornelson <da...@plover.net> wrote:
>"LizM7" <hsel...@hotmail.com> wrote in message
>news:d89b4999.0211...@posting.google.com...
>>
>> The problem with this format, I think, is that it *doesn't*
>> effectively convey a storyline - simply because when I think of an IF
>> story, I think of it in terms of sequencial order - goal A (involving
><snip methods of game design>
>
>Well. I think this is part of my discovery process as I collaborate on a
>game. The previously posted example was only to clarify what would _not_ go
>into a collaboration transcript.
>
Yup. I think Liz has an excellent suggestion about setting up goals
and subgoals. To formalize this a bit, possibly a goal "tree" (actually
a DAG - directed acyclic graph - to be more formal) would be a very
good thing to include. It probably should also include notes on
"false" or misleading goals. These could include red herrings as
well as goals that look reasonable at one point but turn out to
be misleading (maybe the apparent bad guy is actually a good guy,
and you need to help rather than stop him).

>> (Besides, who wants to streamline IF programming? Commercial IF has
>> been dead for a decade plus - people do it for fun these days, so
>> there's really no need for an assembly line.)
>
>I don't want to start a war here, but I believe one of the ways IF can grow
>and mature is if we develop _different_ ways of doing it. I think ego plays
>a large part in writing IF. Most of us would like to write a game, offer it
>to the community, and garner all the just rewards of doing so. This is
>natural and a good thing.
>

Right. The problem here is that writing IF requires several different
abilities, and not all of us have all those abilities. Collaboration
allows lousy writers and lousy programmers to get together and write
good IF, and this is good.

>But it also limits our production capabilities. If we were to set aside our
>ego's and collaborate more often and allow people to take on roles in a team
>(author, designer, architect, coder, tester), we would develop more games
>and games with a much higher quality.

I believe there would be more games, but not of a much higher quality.
There are certain benefits in keeping all of the creative work inside
one skull, and provided the user of said skull has all the necessary
abilities this can work very well. It may well increase the average
quality of IF, since most of the bad stuff seems to come from people
who lack one of the abilities.

>Some of these games (Hitchhikers) were very well done. Anyway, this
>discussion isn't so much about that, but simply how to collaborate
>successfully in designing and implementing an IF game.
>

Since people do collaborate, and there are good reasons for
collaboration, I think having some guidelines around (like "This
is what people have tried, this is what people have thought of")
could be useful.

>This could potentially lead to flying sheep. "Think of the commercial
>possibilities."
>

I had a friend trampled by sheep once....

David Thornley

unread,
Nov 22, 2002, 9:43:42 AM11/22/02
to
In article <9TlD9.19302$We5....@nwrddc04.gnilink.net>,

L. Ross Raszewski <lrasz...@loyola.edu> wrote:

>the end of a statement that makes programming hard. (I am a
>programmer. With the possible exception of INTERCAL, there is
>progrably *no programming language* whose syntax is so bizarre that I
>couldn't work out the basics of it with a language reference and a
>couple of hours of looking at code. All the hard things to learn I
>learned back in CS201 learning C)
>

http://www.mines.edu/students/b/bolmstea/randlang/
(although there seems to be a bit of link rot)

There are worse languages to program in than INTERCAL, although
I haven't run into another with such funny documentation. IIRC,
one of them has only been successfully programmed with genetic
algorithms.

Shadow Wolf

unread,
Nov 22, 2002, 1:09:46 PM11/22/02
to
thor...@visi.com (David Thornley) wrote in
news:3dde429e$0$22223$a186...@newsreader.visi.com:

> In article <9TlD9.19302$We5....@nwrddc04.gnilink.net>,
> L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>
>>the end of a statement that makes programming hard. (I am a
>>programmer. With the possible exception of INTERCAL, there is
>>progrably *no programming language* whose syntax is so bizarre that I
>>couldn't work out the basics of it with a language reference and a
>>couple of hours of looking at code. All the hard things to learn I
>>learned back in CS201 learning C)
>>
> http://www.mines.edu/students/b/bolmstea/randlang/
> (although there seems to be a bit of link rot)
>
> There are worse languages to program in than INTERCAL, although
> I haven't run into another with such funny documentation. IIRC,
> one of them has only been successfully programmed with genetic
> algorithms.

That would be Malbolge, which is an _encrypted_ language on a trinary
machine.

How Hello World was made:
http://www.acooke.org/andrew/writing/malbolge.html


--
Shadow Wolf
shado...@softhome.net
Stories at http://www.asstr.org/~Shadow_Wolf

Sam Dennis

unread,
Nov 22, 2002, 2:03:29 PM11/22/02
to

Why not? The only obstacle I can see is that you need to learn a few more
symbols than you do for most languages.

--
++acr@,ka"

John Colagioia

unread,
Nov 23, 2002, 10:01:02 AM11/23/02
to
Quintin Stone wrote:
> On 15 Nov 2002, David Thornley wrote:
>>In the computing literature, this is usually looked at from the
>>programmer's perspective, and is called things like requirements
>>analysis. (Of course, my idea of an ideal Requirements Analyst is
>>illegal:
>>RA: Now, what happens if the person *isn't* in the database?
>>User: I don't know, that shouldn't happen.
>><RA takes another turn on the wheel>
>>User: AAARGHH!
>>RA: So what *if* the user isn't in the database?
>>)
> I find your ideas on requirements analysis intriguing and would like to
> subscribe to your newsletter.

Hell, another couple of months at my current job, and I might be
willing to shell out my own money to have you come in!

[Rant avoided for sake of decorum]

John Colagioia

unread,
Nov 23, 2002, 10:10:12 AM11/23/02
to
L. Ross Raszewski wrote:
[..."Non-programmer programming environments...]

> They believe that the hard part of programming is learning syntax and
> usage. They think that it's things like having to put a semicolon at
> the end of a statement that makes programming hard.

See also COBOL, Visual Basic (older versions, at least; Microsoft
finally realized *that* wasn't working), and a few other "real world"
systems that I'm surely forgetting.

> (I am a
> programmer. With the possible exception of INTERCAL, there is
> progrably *no programming language* whose syntax is so bizarre that I
> couldn't work out the basics of it with a language reference and a
> couple of hours of looking at code. All the hard things to learn I
> learned back in CS201 learning C)

I'd go so far to say that it's not even INTERCAL's syntax, but rather
the oddball mock-arithmetic. Loops are easily done with a NEXT/
FORGET, and conditionals are done with two NEXTs and a FORGET with a
runtime parameter (popping zero or one items off the control stack),
and you're pretty close to programming FORTRAN or some other mundane
language.

The problem is calculating that condition, of course...

> It's not. The hardest thing about programming is learning how to
> *think like a programmer*.

I've also learned, in teaching an adult education class on computer
usage, that it helps mightily to "think like a programmer" when
*using* most common software, as well.

But that's another rant for another forum.

> The reason programming languages seem hard
> isn't because they have things like '->' in them -- it's because they
> require you to be *explicit* and actually *say what you mean*. The
> novice doesn't have trouble because he doesn't know how this operator
> works -- he has problems because he didn't think through all the
> implications of what he's doing.

That's most of it, but there's also some more to it. A nonprogrammer
needs to understand that, for example, computer variables are not
algebraic variables. They need to understand that control flow is
(mostly) purely sequential.

The observant will note that this is what it also takes to learn to
use an ADRIFT or a COBOL, too.

Now, I have ideas on the actual topic, of how to communicate
programming issues without knowing these things, but I'll put them in
a more productive spot in the thread.

John Colagioia

unread,
Nov 23, 2002, 10:20:40 AM11/23/02
to
Richard Bos wrote:
> Sam Dennis <s...@malfunction.screaming.net> wrote:
>>Richard Bos wrote:
[...]

>>>I want to mention only three letters: A. P. L.
>>If you're suggesting that APL is more difficult than INTERCAL,
> More difficult? No, perhaps not. But I wouldn't wager being able to
> write anything in it after only a few hours of perusal.

Actually, APL is fairly easy after the initial learning curve. You
have funny symbols (for which friendlier implementations will have
ASCII counterparts supplied), which are each both unary and binary
operations, and arithmetic is no-precedence, right-associative.

Oh, and GOTOs have a runtime target, which is how you build your
loops and conditionals.

Otherwise, it's pretty mainstream programming, assuming you have an
operation reference list.

abollen

unread,
Nov 23, 2002, 10:59:50 AM11/23/02
to

"John Colagioia" <JCola...@csi.com> wrote in message
news:3DDF9CC8...@csi.com...
>
> Actually, APL is fairly easy after the initial learning curve. [sniperoo]

Otherwise, it's pretty > mainstream programming, assuming you have an
> operation reference list.


Well, I think APL works pretty well as a counterexample to this part of the
original post:

> The reason programming languages seem hard
> isn't because they have things like '->' in them -- it's because they
> require you to be *explicit* and actually *say what you mean*. The
> novice doesn't have trouble because he doesn't know how this operator
> works -- he has problems because he didn't think through all the
> implications of what he's doing.

APL control structures & program flow are easy, but the operators sure as
hell aren't, not for a novice unused to thinking in terms of matrix &
vector algebra. Plus most real APL programs are just about totally
unreadable for anybody, novice or wizard, just because they're mainly
operator applications all curried together, which is hard to understand for
anybody, no matter how well you know the individual operations & how good
you are at "thinking through all the implications".

John Colagioia

unread,
Nov 23, 2002, 11:15:55 AM11/23/02
to
David A. Cornelson wrote:
[...]

> What I think is expected of the writer is possibly this:
>
> ACT I - The Place Where You Do The Thing
> Scene 1 - The Place

If I may, I think you're on the right track, but perhaps with the
wrong focus. Actually, no. I have the wrong focus by thinking about
your notation too literally.

My issue was that Scene 1 takes place in "The Place." I'm thinking
of this as an explicit, physical location (as it would probably be in
a play), which is unlikely in IF. More likely, "The Place" would be
wherever the PC is at the time, and may follow the PC in many cases.

Beyond that, what I think might be usable would be something like:

1. Background information: This section would be a lot like an old
Infocom manual; "You are Fred, owner of Xyzzy Pronunciation Guides,
Inc. In this game, you will be searching for the Staff of Irony.
Blah, blah, blah." In other words, it should be a description of the
world and the intended tone of the work. An "old hand" might also
want to describe physical details, like the contents of the status
bar, and so on, here.

2. Prologue: This might be a standard sample transcript of the
opening few moves that the player would need to type to get the
action rolling. It should probably also describe how "open" the
game is to the starting player.

3. Scenes: A set of titled scenes, not unlike what you've written,
though it probably needs more additions:

3.a) Preconditions: You'd want to rename this so it's not so scary,
but what can we assume of a PC who is entering this scene? What
tasks have definitely been completed? What is she carrying? What
objects are definitely not in-play? A classically-trained writer may
also want to talk about rising actions and the like, here, too.

3.b) Sample Transcript: As usual, what the player is likely to need
to type, along with the bits that have to happen in a particular
order to work right. Alternatively, as someone else mentioned, this
may be more of a prose description of the major puzzle in the
section, with the goal described along with the obstacles in the
order in which the player is likely to encounter them.

3.c) Special Features: Here, you'd include things like an
explanation of the scene's tone, perhaps, or game-like issues, like
which room(s) this scene uses, what NPCs are in the room(s), timed
messages, recurring changes to descriptions, random responses, and so
on. This could probably be added to the sample transcript by a
clever-enough writer, but that'd require evil-looking syntax, which
is probably a bad thing.

3.d) Outbound Paths: Not unlike a CYOA book, presumably more than
one action will exit the scene, and different actions will move the
player to different scenes. This could be described fairly obviously
in the "if the player walks out the red door holding the blue prism,
that'll dump him into the 'Meeting with the Underground' scene."
This is likely to form the bulk of the game, and is more or less a
directed graph (hopefully acyclic, but maybe not, depending on the
game). For the nonprogrammers, "it's a flow chart."

4. Endgame(s): This may just be more scenes, or it may be sort of a
mirror image of the prologue. Basically, it describes the last moves
of the game, what needs to happen, and the resulting post-game text,
complete with "what it means," so that the tone is correct.

5. The Map: If it hasn't already been supplied by the Prologue, a
sketch of the general lay of the land is, of course, a pretty good
idea.

I *think* this minimizes the programming knowledge. It's mostly in a
form that any writer will certainly recognize and understand. The
writer only needs to know the "entry requirements" for a scene, and
how they can be arranged to form a plot. There aren't any variables.
There also aren't any "special operations" or syntax issues. And,
one can fairly easily write a GUI to maintain the scenes, keep them
separate, spellcheck them, and generate nifty things like a visual
chart of the plot paths. Or, it could be done with paper and pen
without losing anything critical.

Note that this also has the added benefit that testers can start work
immediately, too, by making sure that there aren't any nonsensical
paths through the game, and also making sure that the (physical or
plot) map isn't too dense or sparse in any given place.

Of course, that's all my very uninformed opinion, but it looks like
it could work as a firm starting point, at least.

[...]

John W. Kennedy

unread,
Nov 23, 2002, 2:11:20 PM11/23/02
to
John Colagioia wrote:
> Actually, APL is fairly easy after the initial learning curve. You
> have funny symbols (for which friendlier implementations will have
> ASCII counterparts supplied), which are each both unary and binary
> operations, and arithmetic is no-precedence, right-associative.
>
> Oh, and GOTOs have a runtime target, which is how you build your
> loops and conditionals.

And, of course, it's regarded as good form to use heavy functional
decomposition, to minimize the unfortunate effect of the GOTO's.

--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
-- G. K. Chesterton, "The Man Who Was Thursday"

Dennis G. Jerz www.uwec.edu/jerzdg

unread,
Nov 23, 2002, 9:20:09 PM11/23/02
to
It seems to me more useful for a non-programmer to write a full
transcript of an ideal game session, for a coder to code that up
quickly (whether automated or not -- and most likely not).

But what I'd really like to see is some utility to take a transcript
of a beta-testser attempt to work through the game and somehow match
that transcript up against the nonwith the transcript supplied by the
non-programmer. The non-programmer could then add whatever responses
would replace the default actions, or add some notation like "That's a
reasonable guess -- add this to the solutions for this puzzle" or
supply other new material.

Perhaps the programmer could work on turning the non-programmer's
prose into something that is machine-readable.

Dennis G. Jerz www.uwec.edu/jerzdg

unread,
Nov 23, 2002, 9:23:07 PM11/23/02
to
Paul O'Brian <obr...@ucsu.colorado.edu> wrote in message news:<Pine.GSO.4.40.021118...@ucsu.colorado.edu>...
> On Sun, 17 Nov 2002, Cedric Knight wrote:
>
> > There's a continuing thread here called 'What do you do for a living?'
> > which IIRC turned up plenty of programmers, but no authors. Am I
> > mistaken perhaps in seeing a difference in quality in IF produced by
> > published writers (Adam Cadre, now perhaps Yoon Ha Lee, who else?).
>
> Jim Aikin (sf novels). Neil DeMause (journalism). Brent VanFossen (nature
> writing). Graham Nelson (poetry). Gerry Kevin Wilson (RPG materials,
> though I don't know whether that'd fall into your definition of
> "published writer"). I think Michael Gentry (Anchorhead) has had a story
> or two published. I'd imagine that the academics among us such as Nick
> Montfort and Dennis Jerz aren't strangers to publication, though I
> haven't checked their c.v.'s to confirm this.
>
> Also, back in the day, Robert Pinsky (Mindwheel), who would later become
> poet laureate of the U.S., and Thomas M. Disch (Amnesia). Michael
> Berlyn had some novels published, IIRC. And I think maybe Stu Galley, too,
> though my memory's fuzzier on that one. And of course, Douglas Adams.
>
> That's all I can come up with for the moment.

Dennis

Dennis G. Jerz www.uwec.edu/jerzdg

unread,
Nov 23, 2002, 9:25:09 PM11/23/02
to
Sorry... I think I pushed the wrong button while posting from Google.

> I'd imagine that the academics among us such as Nick
> Montfort and Dennis Jerz aren't strangers to publication, though I
> haven't checked their c.v.'s to confirm this.

Nick and I both have academic books coming out... his is on IF, mine
is on American drama. And of course lots of IF folks are contributing
to the IF Theory book.


>
> Also, back in the day, Robert Pinsky (Mindwheel), who would later become
> poet laureate of the U.S., and Thomas M. Disch (Amnesia). Michael
> Berlyn had some novels published, IIRC. And I think maybe Stu Galley, too,
> though my memory's fuzzier on that one. And of course, Douglas Adams.
>
> That's all I can come up with for the moment.

Michael Crichton: http://www.the-underdogs.org/game.php?name=Amazon

-- Dennis

Stas Starkov

unread,
Nov 25, 2002, 3:18:57 PM11/25/02
to
"John Colagioia" <JCola...@csi.com> wrote in
news:3DDF9A54...@csi.com:

> L. Ross Raszewski wrote:
>> The hardest thing about programming is learning how to *think like a
>> programmer*.
>
> I've also learned, in teaching an adult education class on computer
> usage, that it helps mightily to "think like a programmer" when
> *using* most common software, as well.
>
> But that's another rant for another forum.
>
>> The reason programming languages seem hard isn't because they have
>> things like '->' in them -- it's because they require you to be
>> *explicit* and actually *say what you mean*. The novice doesn't have
>> trouble because he doesn't know how this operator works -- he has
>> problems because he didn't think through all the implications of what
>> he's doing.
>
> That's most of it, but there's also some more to it. A nonprogrammer
> needs to understand that, for example, computer variables are not
> algebraic variables. They need to understand that control flow is
> (mostly) purely sequential.

(Back to the topic.)

But is it generally impossible for non-programmer to _describe_ what
he/she wants to see in his/her IF game. I honestly don't think so -- it
seems to me that David Cornelson have suggested a really worth _system
of thoughts_.

--
Stas Starkov (stas_ at mail.rb.ru)

Stas Starkov

unread,
Nov 25, 2002, 3:18:43 PM11/25/02
to
"John Colagioia" <JCola...@csi.com> wrote in
news:3DDFA9BB...@csi.com:

> Beyond that, what I think might be usable would be something like:

[a lot of very interesting stuff snipped]

> I *think* this minimizes the programming knowledge. It's mostly in a
> form that any writer will certainly recognize and understand. The
> writer only needs to know the "entry requirements" for a scene, and
> how they can be arranged to form a plot. There aren't any variables.
> There also aren't any "special operations" or syntax issues.

I _really_ think that your considerations may be very helpful. Thank
you. And, I think, the process you described could be very effective for
a _sole_ author -- if he/she will follow it right from the start.

After reading your article (!) I desired to write a new game keeping
your suggestions in mind. (But with God's help I could resist. :-) )

> Note that this also has the added benefit that testers can start work
> immediately, too, by making sure that there aren't any nonsensical
> paths through the game, and also making sure that the (physical or
> plot) map isn't too dense or sparse in any given place.

Hmmm... Indeed. I never thought that betatesting may be started _before_
a game was finished (or even before it was started). Kudos to you.