Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Development system requirements

16 views
Skip to first unread message

Andrew Plotkin

unread,
Aug 6, 2003, 1:15:33 PM8/6/03
to
Since the dev-system thread has mostly degenerated to arguing about
ADRIFT, and therefore I'm skipping most of it, I'll start a new thread.

Question I ask myself: what features do successful IF development
systems have? I don't want to argue "programming" versus
"non-programming", or "good for beginners" versus "good for experts".
(These are false dichotomies in any case.) I want to think about
high-level features which are not very obvious, but which are
necessary for a usable and scalable development tool.

(I am *not* looking for a spate of posts about how system X fulfils my
requirements, or has something "just as good", or doesn't really need
them. Nor am I going to get into the portability, proprietary/open, or
shareware/freeware arguments. You've already heard those.)

Four features occur to me immediately.

* World-state management

Some consistent way of handling the data that describes the game
state. You need this to make save, restore, and undo work.

It's a truism in software development that if you want to implement
undo -- for any program -- you have to design it in from the start.
Retrofitting undo is a nightmare. True of IF also.

* Backwards compatibility

You are going to improve your development system over time. But games
tend to "freeze"; most authors release a handful of updates and then
mothball the source code. A couple of years later, the source code --
even the author -- may be unfindable. You need to take care that those
old games remain playable forever.

Backwards compatibility always breaks *somewhere*, of course. Players
probably won't fuss if they have to keep two interpreters around,
SystemX-1 and SystemX-2, for playing older and newer games. (And your
alpha and beta versions will undoubtedly vanish into the mists.)

But if players need to keep a dozen interpreters between 1.0.0 and
1.3.7, and need to pick the right one to match to any given game, they
will come for you with the pitchforks.

* A layer of abstraction between player input and game actions

What do I mean by this? Well, consider the idea of a game object. The
object is described by a list of words. The parser matches player
input against the words, picks the ojbect, and then applies the
action. This is good because the author can associate actions with the
object, not with the individual words.

(For example, a RUG object is described by the words "rug" and
"carpet". The player might type "look under rug" or "look under
carpet". As an author, you want to write *one* "look under" action for
RUG. You *don't* want to have to duplicate this action for "rug",
"carpet", and every other synonym your beta-testers think up. When you
add another synonym, you should only have to add it in a single
place.)

This layer of abstraction for objects is pretty obvious. Just about
every IF system every proposed has it. What's less obvious is that the
*same* sort of abstraction is necessary for *actions*.

In other words, you should be able to add "look beneath ___" as a
synonym for "look under ___". Both of these describe the action
LOOKUNDER. So the author writes an action for <LOOKUNDER RUG>; then
adding more synonyms for LOOKUNDER is *just as easy* as adding
synonyms for RUG. Again, it just has to be done in one place -- even
if RUG has several synonyms, or if there's a BED with its own list of
synonyms.

* Polymorphism for game messages

Any IF game has a million places where it prints a message. Almost
every IF system uses the model of objects with properties. (Typically,
every object has a description property, which is the message printed
out when the player types "examine object".)

It really has to be possible for the author to use a routine -- some
complex dynamic thing -- *wherever* a simple text message is expected.

Moreover, this has to be *easy*. If I decide, halfway through creating
my game, that the hat looks different when it's out in the rain, then
I should be able to go back and change the hat's description to a
dynamic message that depends on the weather.

Dynamic messages must be able to have side effects, also. (If I want
the hat to print a longer message the first time I look at it, this
should be straightforward. If I want it to *also* print a *different*
longer message the first time I look at it *in the rain*, that
shouldn't be much harder.)

Text adventure design involves a lot of twiddling of these little
messages. There's no safe upper bound to how complex this twiddling
can get. (A hardwired feature to print a different message the first
time is great... but sooner or later I'm going to want to print a
different message the first *two* times. In the rain. There'd better
be a way to specify this.)

--Z

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

Rexx Magnus

unread,
Aug 6, 2003, 1:45:24 PM8/6/03
to
On Wed, 06 Aug 2003 17:15:33 GMT, Andrew Plotkin scrawled:

> Question I ask myself: what features do successful IF development
> systems have? I don't want to argue "programming" versus
> "non-programming", or "good for beginners" versus "good for experts".
> (These are false dichotomies in any case.) I want to think about
> high-level features which are not very obvious, but which are
> necessary for a usable and scalable development tool.

Something that you might have overlooked - readability. Just being able
to pick up any old section of code/schematic/whatever the system produces,
and read it - and be able to know what it does - is always a good thing.


--
UO & AC Herbal - http://www.rexx.co.uk/herbal

To email me, visit the site.

Seebs

unread,
Aug 6, 2003, 2:31:51 PM8/6/03
to
In article <Xns93CFBECD2C6...@130.133.1.4>,

Rexx Magnus <tras...@uk2.net> wrote:
>Something that you might have overlooked - readability. Just being able
>to pick up any old section of code/schematic/whatever the system produces,
>and read it - and be able to know what it does - is always a good thing.

It's also only marginally possible. There is no language in which you
cannot write bad code.

-s
--
Copyright 2003, all wrongs reversed. Peter Seebach / se...@plethora.net
http://www.seebs.net/log/ - YA blog. http://www.seebs.net/ - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/

Andrew Plotkin

unread,
Aug 6, 2003, 3:02:46 PM8/6/03
to
Here, Rexx Magnus <tras...@uk2.net> wrote:
> On Wed, 06 Aug 2003 17:15:33 GMT, Andrew Plotkin scrawled:
>
> > Question I ask myself: what features do successful IF development
> > systems have? I don't want to argue "programming" versus
> > "non-programming", or "good for beginners" versus "good for experts".
> > (These are false dichotomies in any case.) I want to think about
> > high-level features which are not very obvious, but which are
> > necessary for a usable and scalable development tool.
>
> Something that you might have overlooked - readability. Just being able
> to pick up any old section of code/schematic/whatever the system produces,
> and read it - and be able to know what it does - is always a good thing.

Valuable, but hard to judge. "A sufficiently bad programmer can write
FORTRAN in any language." :)

Kevin Forchione

unread,
Aug 7, 2003, 2:34:37 AM8/7/03
to
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:bgrd3l$its$1...@reader1.panix.com...

> Since the dev-system thread has mostly degenerated to arguing about
> ADRIFT, and therefore I'm skipping most of it, I'll start a new thread.
>
> * A layer of abstraction between player input and game actions
>
> What do I mean by this? Well, consider the idea of a game object. The
> object is described by a list of words. The parser matches player
> input against the words, picks the ojbect, and then applies the
> action. This is good because the author can associate actions with the
> object, not with the individual words.
>
> (For example, a RUG object is described by the words "rug" and
> "carpet". The player might type "look under rug" or "look under
> carpet". As an author, you want to write *one* "look under" action for
> RUG. You *don't* want to have to duplicate this action for "rug",
> "carpet", and every other synonym your beta-testers think up. When you
> add another synonym, you should only have to add it in a single
> place.)
>
> This layer of abstraction for objects is pretty obvious. Just about
> every IF system every proposed has it. What's less obvious is that the
> *same* sort of abstraction is necessary for *actions*.
>
> In other words, you should be able to add "look beneath ___" as a
> synonym for "look under ___". Both of these describe the action
> LOOKUNDER. So the author writes an action for <LOOKUNDER RUG>; then
> adding more synonyms for LOOKUNDER is *just as easy* as adding
> synonyms for RUG. Again, it just has to be done in one place -- even
> if RUG has several synonyms, or if there's a BED with its own list of
> synonyms.

Another interesting layer of abstraction is that representing the World
Model, and can be illustrated by the following example.

Suppose the PC knocks at a door. One level of abstraction simply captures
the knock action within a game object (say Door), which sends a message to
another game object (say Mrs. Hubbard), resulting in Mrs. Hubbard opening
the door.

Another level of abstraction models the sensory event of sound, so that Mrs.
Hubbard then reacts, not to the message produced from the capture of the
knock action, but from the sound event produced from the knock at the door.
These kinds of abstractions haven't been deeply explored due to resource
limitations, certainly this involves more sophisticated "physics" modelling,
but are becoming increasingly possible.

It then becomes a matter, of coding the exception not in the capture of the
knock action, but in the kinds of behaviors that the class of door might
exhibit, and the kind of person Mrs. Hubbard is, and whether or not the
event produces the desired stimulus-response.

--Kevin


Richard Bos

unread,
Aug 7, 2003, 8:11:59 AM8/7/03
to
Andrew Plotkin <erky...@eblong.com> wrote:

> Question I ask myself: what features do successful IF development
> systems have?

> Four features occur to me immediately.
>
> * World-state management

> * Backwards compatibility

> * A layer of abstraction between player input and game actions

> * Polymorphism for game messages

* Generality

The implementor must not be limited by what the creator of the system
thought would be necessary; the system needs to supply a means to extend
the standard library beyond the call of duty.
This doesn't mean that it must be possible to implement a real-time
Tetris clone in the system, though that _was_ a nice trick. It does
mean, though, that if it's not possible to realistically implement, say,
a turn-based board game, with the game playing reasonably strongly
against the player, sooner or later you're going to run into a puzzle
you want to write, but cannot.

Richard

Roger Carbol

unread,
Aug 7, 2003, 11:29:54 AM8/7/03
to
Andrew Plotkin wrote:

> What features do successful IF development systems have?


> * World-state management

I'm not entirely convinced this is required on the level of the
development system. Surely the interpreter can manage the state
of the game it's interpreting.


> * Backwards compatibility

As above -- this would seem to be an interpreter issue more than
a development system issue. On the other side of the coin, however,
I will agree that backwards compatibility is nice in that it allows
programmers familiar with the old system to more readily adopt the
new system. But I don't think that's quite what you were getting at.


> * A layer of abstraction between player input and game actions

Yes. Even parsing itself is in this layer.


> * Polymorphism for game messages

Agreed. It also makes things like localization possible.


The above two points seem to be referring to the same underlying
concept. Something related to "String literals are bad" or some
such, I would offer.


.. Roger Carbol ..

Andrew Plotkin

unread,
Aug 7, 2003, 12:12:39 PM8/7/03
to
Here, Roger Carbol <rca...@home.com> wrote:
> Andrew Plotkin wrote:
>
> > What features do successful IF development systems have?
>
>
> > * World-state management
> > * Backwards compatibility

>
> I'm not entirely convinced this is required on the level of the
> development system.

By "development system" I include the game-file format, the language
(or whatever) specification for source, the compiler tools, the
library (or whatever), the interpreter. The whole thing.

(If you try to invent a system which lacks one of these -- say,
something that generates C or an executable binary -- you still have
to deal with the same issues.)

> > * A layer of abstraction between player input and game actions

> > * Polymorphism for game messages
>

> The above two points seem to be referring to the same underlying
> concept. Something related to "String literals are bad" or some
> such, I would offer.

That does cover them, but I wanted to delve more deeply.

Mark S

unread,
Aug 7, 2003, 1:02:55 PM8/7/03
to
Andrew Plotkin <erky...@eblong.com> wrote in message news:<bgrd3l$its$1...@reader1.panix.com>...
> Since the dev-system thread has mostly degenerated to arguing about
> ADRIFT, and therefore I'm skipping most of it, I'll start a new thread.
>
> Question I ask myself: what features do successful IF development
> systems have? I don't want to argue "programming" versus
> "non-programming", or "good for beginners" versus "good for experts".
> (These are false dichotomies in any case.) I want to think about
> high-level features which are not very obvious, but which are
> necessary for a usable and scalable development tool.

<snipped>


As a lurker here, you can take my thoughts with a grain of salt, but
these things have always been something I've been concerned with in my
coding:


** A logical order of sequence in which actions are performed on each
turn. Knowing that when a player tries to exit a door (which will open
automatically for him) the following events happen:

1. See if door is opened
2. Open door automatically (if not already open)
3. Move player to new room
4. Perform any daemons not related to NPC
5. Determine state of room and any objects within room.
6. Perform any post state operations.
7. Print out room description to player.


Obviously there are many other actions which could occur, and the
before and after actions could apply to any object, room, npc, daemon,
etc. along the way. However, a well defined sequence of which actions
get performed in which order is a must for developers trying to make
sure things perform in the right order.


** I have always secretly craved a tool for developing which allows a
programmer to type a phrase into the parser, which would allow for him
to then take the parsed word and associate it to an object. For
instance:
I could type "take spade".
The tool replies "There is no spade available.
These objects are in scope:
1. Hammer
2. Rake
3. Shovel
4. Lawnmower"
To which I could choose 3.Shovel, which would update the object tree
to associate the parsed word to the object I select.

I guess the functionality that I am stating here is a fully
bidirectional association between parsed input and the object model
which allows for the developer to associate a parsed term with an
object. Being able to easily manipulate the association between parsed
text and objects allows for easier disambiguation of things like
">take brick. >Do you mean brick or brick wall?"

This isn't as well thought out as I intend it to be, but hopefully you
understand the intent here.


There are others, but I can't think of them right now.

-Mark

Jim Aikin

unread,
Aug 7, 2003, 2:22:02 PM8/7/03
to
Don't know if anyone else has mentioned this, but I like having a
well-defined class/inheritance mechanism.

I've found it very useful (in TADS 2) to be able to define, for instance, 16
buttons on a control panel using a PanelButton class. The class contains all
of the functionality -- whether a button is depressed, what it sends a
message to when pressed, etc. Each button object can be defined very simply,
like this:

button1: PanelButton
num = 1
adjective = 'red'
;

Et cetera.

--JA


Joe Mason

unread,
Aug 7, 2003, 3:16:49 PM8/7/03
to
In article <dNwYa.147$eD3.10...@newssvr14.news.prodigy.com>, Jim Aikin wrote:
> Don't know if anyone else has mentioned this, but I like having a
> well-defined class/inheritance mechanism.
>
> I've found it very useful (in TADS 2) to be able to define, for instance, 16
> buttons on a control panel using a PanelButton class. The class contains all
> of the functionality -- whether a button is depressed, what it sends a
> message to when pressed, etc. Each button object can be defined very simply,
> like this:

Hmm, I think you've hit on another principal for the list: there should
be a way to automate the creation of similar, er, "stuff" - objects,
sections of code, etc. Class/inheritance is a specific technique for
achieving this.

Joe

Andrew Plotkin

unread,
Aug 7, 2003, 3:57:10 PM8/7/03
to

I like that way of putting it. "Automate" may not be the best word
(since we're not talking about run-time object creation), but sharing
behavior between similar objects is definitely on the list.

Rexx Magnus

unread,
Aug 8, 2003, 6:43:12 AM8/8/03
to
On Thu, 07 Aug 2003 17:02:55 GMT, Mark S scrawled:

> ** I have always secretly craved a tool for developing which allows a
> programmer to type a phrase into the parser, which would allow for him
> to then take the parsed word and associate it to an object. For
> instance:
> I could type "take spade".
> The tool replies "There is no spade available.
> These objects are in scope:
> 1. Hammer
> 2. Rake
> 3. Shovel
> 4. Lawnmower"
> To which I could choose 3.Shovel, which would update the object tree
> to associate the parsed word to the object I select.
>
> I guess the functionality that I am stating here is a fully
> bidirectional association between parsed input and the object model
> which allows for the developer to associate a parsed term with an
> object. Being able to easily manipulate the association between parsed
> text and objects allows for easier disambiguation of things like
> ">take brick. >Do you mean brick or brick wall?"
>

*snip*

Sounds similar to the way in which one develops a MUD - from within the
world, so to speak. It would be nice to have a system by which one can do
that for IF - if one doesn't already exist.

David Thornley

unread,
Aug 10, 2003, 11:28:21 PM8/10/03
to
In article <3f314997$0$1094$3c09...@news.plethora.net>,

Seebs <se...@plethora.net> wrote:
>In article <Xns93CFBECD2C6...@130.133.1.4>,
>Rexx Magnus <tras...@uk2.net> wrote:
>>Something that you might have overlooked - readability. Just being able
>>to pick up any old section of code/schematic/whatever the system produces,
>>and read it - and be able to know what it does - is always a good thing.
>
>It's also only marginally possible. There is no language in which you
>cannot write bad code.
>
Consider readability given normal code writing.

Since I really don't want to start an IF language war on this thread,
I'm going to use non-IF languages as examples.

APL had a reputation as a read-only language, although I never used it.

Forth could be written readably, but very often wasn't. The normal
state seemed to be less readable than the normal state of C, for example.

In Lisp, it used to be fairly popular to represent structures as lists,
and nested structures as nested lists. It then became rather common
for people to refer to them using the c[a|d]+r notation, which meant
that what "caddar" would mean would depend on exactly what sort of
structure, and there was no typing.

Once "defstruct" was popular, Lisp code involving structures became
a heck of a lot more readable.

The least readable languages would tend to be the ones not intended
for programming. For example, early versions of Excel could be
programmed in, and sometimes were. The results sometimes made
Intercal look intuitive.

I would think that a legible language would be one easily representable
in human-readable text, with features to help locality, such as
modularity, local variables, and relatively long variable and routine
names.

It is entirely possible that there are better ways to lay out complicated
programming specifications, but decades of trying to figure out something
else really hasn't come up with anything.

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

Jeffrey Zahn

unread,
Aug 11, 2003, 1:41:30 AM8/11/03
to
In article news:3f370d55$0$169$a186...@newsreader.visi.com,
thor...@visi.com (David Thornley) wrote:

> I would think that a legible language would be one easily
> representable in human-readable text, with features to help
> locality, such as modularity, local variables, and
> relatively long variable and routine names.

Umm, I think you just sortakinda described COBOL[1].

It still runs on many, ahem, "legacy" systems and perhaps
processes your bank statements. It's the most human[2]-readable
"programming" language out there, and even though it's a
Languasaur. But it wasn't designed for programmers ease-of-use.

[1] For you young Whippersnappers, with yer OOP and such,
"COmmon Business Oriented Language".

[2] Pointy-haired non-programming management review committee
member.

--
Jeff "Working on my 2004 Comp Entry" Zahn

Andy Leighton

unread,
Aug 11, 2003, 6:42:10 AM8/11/03
to
On 11 Aug 2003 05:41:30 GMT, Jeffrey Zahn <jz...@NOSPAM.pipeline.com> wrote:
> In article news:3f370d55$0$169$a186...@newsreader.visi.com,
> thor...@visi.com (David Thornley) wrote:
>
>> I would think that a legible language would be one easily
>> representable in human-readable text, with features to help
>> locality, such as modularity, local variables, and
>> relatively long variable and routine names.
>
> Umm, I think you just sortakinda described COBOL[1].

[snip]

> [1] For you young Whippersnappers, with yer OOP and such,
> "COmmon Business Oriented Language".

Although to be fair one company has been advertising object oriented
cobol for years, and stressed its suitability for writing windows
GUIs as well. Now they are on a web services kick with integration
with Java and .NET.

Personally as a programmer I cannot think of anything worse (well mainstream
stuff anyway - I am sure there are a hundred and one toy/joke languages that
are worse).

--
Andy Leighton => an...@azaal.plus.com
"The Lord is my shepherd, but we still lost the sheep dog trials"
- Robert Rankin, _They Came And Ate Us_

Kevin Forchione

unread,
Aug 11, 2003, 10:33:47 AM8/11/03
to
"Jeffrey Zahn" <jz...@NOSPAM.pipeline.com> wrote in message
news:Xns93D410C10A4...@198.99.146.11...

> In article news:3f370d55$0$169$a186...@newsreader.visi.com,
> thor...@visi.com (David Thornley) wrote:
>
> > I would think that a legible language would be one easily
> > representable in human-readable text, with features to help
> > locality, such as modularity, local variables, and
> > relatively long variable and routine names.
>
> Umm, I think you just sortakinda described COBOL[1].
>
> It still runs on many, ahem, "legacy" systems and perhaps
> processes your bank statements.

No perhaps about it... Banking and Insurance industries couldn't function
without it.

--Kevin


David Thornley

unread,
Aug 11, 2003, 11:10:55 AM8/11/03
to
In article <Xns93D410C10A4...@198.99.146.11>,

Jeffrey Zahn <jz...@NOSPAM.pipeline.com> wrote:
>In article news:3f370d55$0$169$a186...@newsreader.visi.com,
>thor...@visi.com (David Thornley) wrote:
>
>> I would think that a legible language would be one easily
>> representable in human-readable text, with features to help
>> locality, such as modularity, local variables, and
>> relatively long variable and routine names.
>
>Umm, I think you just sortakinda described COBOL[1].
>
No, I didn't. Not the version I used to use, anyway. It is conceivable
that later versions of the language had actual virtues.

The variable names were long, but the pitiful attempt at subroutines
was difficult to use, and it was completely impossible to use user-
defined functions properly.

I don't know how often I missed the ability to use them. In any
reasonable computer language, say you want to have a different way
of accessing certain data. You can go through, remove the variable
names, and substitute functions. Elementary, provided the language
supports it.

Moreover, with the incredibly clunky subroutine interface, the
programs tended to be all PERFORM-based* with nothing but global
variables.

To put it another way, the locality on most of the programs I worked
on sucked. The variable definition was far away in the DATA DIVISION,
and it could be mucked with anywhere in the PROCEDURE DIVISION.

I was thinking of languages like C when I wrote that (yes, I know of
the thing about variables with external linkage in C90, but all
implementations I ever used ignored it, and I did too). In C, it
is easy to write functions, and it has a clumsy but doable way of
encapsulation in modules (make each module precisely one file, and
use "static" wherever you can).

*PERFORM is something like the BASIC GOSUB, except that it lends itself
to more abuses.

>It still runs on many, ahem, "legacy" systems and perhaps
>processes your bank statements. It's the most human[2]-readable
>"programming" language out there, and even though it's a
>Languasaur. But it wasn't designed for programmers ease-of-use.
>

I think it was designed for programmers' ease of use, back around
1960 or so. That was at the dawn of higher-level languages, back
when nobody really knew anything about good computer language design.

>[1] For you young Whippersnappers, with yer OOP and such,
>"COmmon Business Oriented Language".
>
>[2] Pointy-haired non-programming management review committee
>member.
>

For some time, COBOL was touted as a way to replace programmers
because anybody could read or write it. I think we all know
how that worked out.

David Thornley

unread,
Aug 11, 2003, 9:23:47 PM8/11/03
to
In article <bgrd3l$its$1...@reader1.panix.com>,

Andrew Plotkin <erky...@eblong.com> wrote:
>
>* Backwards compatibility
>
>You are going to improve your development system over time. But games
>tend to "freeze"; most authors release a handful of updates and then
>mothball the source code. A couple of years later, the source code --
>even the author -- may be unfindable. You need to take care that those
>old games remain playable forever.
>
>Backwards compatibility always breaks *somewhere*, of course. Players
>probably won't fuss if they have to keep two interpreters around,
>SystemX-1 and SystemX-2, for playing older and newer games. (And your
>alpha and beta versions will undoubtedly vanish into the mists.)
>
That depends on the players. Quite a few Macintosh and Windows
users are used to double-clicking on a game icon to bring up the
appropriate interpreter. If this doesn't work, I would think
these users would find that annoying.

In other words, it would be well to supply different Macintosh
file types and Windows extensions for incompatible versions.

>But if players need to keep a dozen interpreters between 1.0.0 and
>1.3.7, and need to pick the right one to match to any given game, they
>will come for you with the pitchforks.
>

In some environments, it's bad if the player has to pick out the
right interpreter in any case.

0 new messages