Languages vs. Design Tools?

[Brad O`Donnell]

There's been a lot of debate lately about whether the
current IF languages out there today are comparable to
professionally-made languages. (That, and there's debate
about whether they should even be compared at all...)

One problem stems from just exactly what we want the
languages to do.

Languages are a good way to tell the computer to do
something, (Well, duh!) but they're miserable means for
designing data sets. Take (for instance, (I'll get to the
IF part soon)) an arcade game, a simple maze-run:

The player moves the smiley from the beginning
of the maze to the end, and wins.

Pretty sucky game, but bear with me :)

In this instance, it's easy to define your maze; you can
do it in all sorts of languages by just setting up an array, with
some kind of common language data definition construct:

def array(4 x4) Maze1 = "1022"
"2029"
"2000"
"2222"

(where 1 is the starting square, 9 is the ending square,
0 is an empty square, and 2 is a wall)

Now, assume that your game works, based on that data set...
...and you want to add new functionality. (Say, invisible walls.)

def array(4 x4) Maze2 = "1022"
"2029"
"2040"
"2222"

(so now 4 is our invisible wall)

Adding new things is easy... until you start to run out of digits.
To demonstrate how messy things get, take the example of adding squares
that teleport you to another space in the maze:

def array(4 x Variable) Maze3 = "100302"
"222200"
"033322"
"222900"

Following the 3's are two numbers, which are the x and y
coordinates of the square that the "3" square sends you to.
Add to this: squares with lava pits, squares which disappear
when you hit a switch, not to mention the switches, and things
become a bloody good mess indeed. Oh, and an extra wrinkle:

Expand the game to 30 x 30 mazes, and
Add an intelligent monster that chases you around the maze :)

"Wait!" you scream, brandishing your tomatoes: "That's not the
way you make a maze game! No one in his right mind would even
try to do a respectable arcade game like that! It would be
torture!"

Well, you're right. Creating an arcade game without (at least)
first making an interactive map-making tool would be just on the
left side of hari-kari. So you go, and you make your map tool,
which presents you with a grid and you move your cursor to edit
the square you want, and you save your maze to a file and then load
it back up again and you're happy, you can make as many mazes as
you want and never have to worry about the internals of data
definition until you want to add new features. You can give the
design tool to your little brother, who never coded a line, and
he makes mazes up the whazoo.

(Hey, look, below! I think there's a point here somewhere!)

So why, oh why, are we *still* using language constructs to
define the data in IF? As far as I can see, there are a number of
reasons:

-IF needs all the language constructs it can get, there's no
denying that. Defining data in a language seems to be a natural
way to provide the constructs we need.

-It's portable. I can't think of very much that is more portable
than a simple ASCII text file. (Except, perhaps a .Z3 file <heh>)

-History. (That's the way it's always been done...)

-There's no money in IF. (Which leads to why we don't spend
great gouts of time <my apologies to everyone who does..erm>
developing the interactive tools we lust for.)

So, improving the tools with which we make IF usually happens in
the following ways:

-By altering the languages to provide better constructs. (i.e;
Inform 6.10, a wonderful IF lang, IMHO)

-The occaisional source-code builder, which focuses on a standard
task and creates the constructs for us. (umm...Infoclues)

[Imitating Bill Clinton] As I see IF rising into the 21st century,
I think that, in the tools of the future, instead of the data being
stuck in an ASCII file, subordinate to the IF language, the language
itself would be embedded within the data definition tools...

So, now, of course, the Big Question is: What kind of tools does
the IF community want? (And you know you want them, don't you?)

--
Brad O'Donnell
"Sure, people are idiots; but
if I'm so damn smart,
what am I doing here?"

[Roger Carbol]

Brad O`Donnell wrote:

<lots of good stuff I mostly agree with>

> So, now, of course, the Big Question is: What kind of tools does
> the IF community want? (And you know you want them, don't you?)

Well, something I've been working on, at a remarkably slack rate, has
been a tool something like this:

(transcript follows)

You are in the Start Room.
>DESCRIBE HERE: You are in a narrow, twisty passage, running north to south.

You are in a narrow, twisty passage, running north to south.
>N
You can't go that way.
>DIG N
Done.
>N

You are in a featureless room.
>S
You are in a narrow, twisty passage, running north to south.
>CREATE LAMP
Done.
>I
You are holding a lamp.
>X LAMP
There is nothing remarkable about the lamp.

>DESCRIBE LAMP: The lamp is brass and tarnished.
Done.
>ADD LAMP LIGHTOBJECT
Done.

>X LAMP
The lamp is brass and tarnished. It is currently switched off.

---

AND, and perhaps this is the big AND, the tool would output a file
containing
the definitions of all of the above in a nice modifiable standard form,
such
as a TADS file. AND the tool would be written in TADS, for example.

Sounds a bit optimistic? Well, yeah, I said progress was slow. But I
still
think it would rock.

Roger Carbol .. r...@col.ca .. define author witty

[Bill Hoggett]

>(transcript follows)

>---

Hmmm, useful idea. IF creation on-the-fly, as it were. A good tool to create
the adventure outline and automatically generate some of that "dull" code
we all hate inputting ourselves. A nice touch would be if the tool was
written in a poratble non-IF language and was capable of generating code
via a language module, so that you could later add modules for Inform,
Hugo etc. code generation. Now *THAT* would be useful!

---

Bill Hoggett (aka BeeJay) <mas.su...@easynet.co.uk>

IF GOD IS LIFE'S SERVICE PROVIDER WHY HAVEN'T I GOT HIS I.P. NUMBER ?

[Brad O`Donnell]

Roger Carbol wrote:

> Well, something I've been working on, at a remarkably slack rate, has
> been a tool something like this:
>

(transcript deleted)

> ---
>
> AND, and perhaps this is the big AND, the tool would output a file
> containing
> the definitions of all of the above in a nice modifiable standard form,
> such
> as a TADS file. AND the tool would be written in TADS, for example.
>
> Sounds a bit optimistic? Well, yeah, I said progress was slow. But I
> still
> think it would rock.
>

Yes, it would rock. It would be good to be able to play a game
while you're making it. Certainly a step in what I think is the
right direction. My personal inclination in tools would somehow
integrate an object editor (meaning "data objects") and routine
editor into an interpreter platform for testing.

Am I going to write it?? Probably not. My idea of what works and
what doesn't probably won't fit with most other people.

--
Brad O'Donnell
"A story is a string of moments, held together by memory."

[Roger Carbol]

Bill Hoggett wrote:

> Hmmm, useful idea. IF creation on-the-fly, as it were. A good tool to create
> the adventure outline and automatically generate some of that "dull" code
> we all hate inputting ourselves. A nice touch would be if the tool was
> written in a poratble non-IF language and was capable of generating code
> via a language module, so that you could later add modules for Inform,
> Hugo etc. code generation. Now *THAT* would be useful!

Well...perhaps. Right now I'm leaning fairly heavily towards writing
it in the same language that it outputs, ie, all TADS.

Why, one might ask? Well...some good reasons, some bad reasons. I'd
rather
only screw around with one language, rather than two. I know TADS is
somewhat
portable, although since I'd probably be wallowing in filesystem
extensions
that might not hold. It kinda strikes me as the proper way to go about
it.

And I'm not at all familiar with Inform or Hugo...but perhaps, after the
fact,
someone might translate it. Which would be fine with me.

Roger Carbol .. r...@col.ca .. exceeding his grasp

[Dirk Coppelmans]

Brad O'Donnell wrote:
> :

> So, now, of course, the Big Question is: What kind of tools does
> the IF community want? (And you know you want them, don't you?)

Brad, my man, this is the question I have been asking myself for some
time now. The world is loaded with all kinds of 'Visual' tools today,
so why don't we have such thing as a Visual IF tool. Visual IF should
provide us with IF game design and play facilities. Game design
should provide:

- Game map
You do need to plan ahead your surroundings: the Game World.
IMHO creating a game while playing it is not such a good approach
(sorry Roger). In the Game Map you can locate the locations of
your game world and you define all possible passages to and from
these locations.

- Locations, Items, Creatures
A way to define all details on locations, their contents and
creatures that you might bump into (NPC's). Let's refer to them
as Game Objects. Since we're talking about objects here, lets
make it entirely object oriented (see below). Visual IF++ must
provide classes, class hierarchies and should enable us to
import/export parts of this hierarchy, so we can simply create
entire worlds around us.
Of course we like cut-copy-paste around with these objects, but that
is detail for now.

- Characteristics
Give all the objects above their characteristics, properties,
whatever you like to call them. The actual action in games is
altering these characteristics.

- Actions
Game Objects must not only be defined as a string ("This is a
match"), but should also be able to respond to actions. The action
"strike match" would change one of its characteristics to 'burning'
and after some time (or after action "blow out match") to 'burned'.
Besides altering characteristics of game objects, actions can
create, destroy, move game objects, display files, text, graphics,
play sounds and movie clips and start deamons (a time deamon
for the burning match, for instance).

- Commands
User commands must be linked to actions, mentioned above.
This is also the place where we can define other elements of the
vocabulairy of the game (like synonyms).

- Autonomous actions
Each characteristic can be linked to actions, that need to be
executed each time it is altered, each turn, each so many minutes,
at random or when the value of the characteristic reaches some
value. It is the basis for autonomous behaviour of the NPC's
(agents).

- Debugger
Since all kind of actions can be linked to all kinds of
characteristics, lotsa stuff happens underneath the surface.
Soon, we'll loose sight on what we created. So we need a debugger.
To trace commands, events and results, define breakpoints (on
events), etc.

In a nutshell, this is it! OK, details must be defined, but you don't
have to write code. Or at least, you'll do not have to write so much
code as today. Define locations, place your player character in one
of them, and off you go! The player, her/his actions and all
autonomous actions determine what happens next.

In fact: you take all the good things of Inform, TADS and the
like and wrap it in a friendly user interface.

So Brad, when do we start? In Java, of course, otherwise we'll have
trouble making it platform independent...

Dirk Coppelmans - di...@iaehv.nl

[Brad O`Donnell]

Dirk Coppelmans wrote:

> Game design
> should provide:
>
> - Game map
> You do need to plan ahead your surroundings: the Game World.
> IMHO creating a game while playing it is not such a good approach
> (sorry Roger). In the Game Map you can locate the locations of
> your game world and you define all possible passages to and from
> these locations.

The map-maker is one of the few things that almost everyone wants.
(Although that supposes you're making a traditional, path-linked
game; for G. Caswell's proposed sector-based layout, a different
type of map (and thence, a different map-maker) would be needed.)

> - Locations, Items, Creatures
> A way to define all details on locations, their contents and
> creatures that you might bump into (NPC's).

That's good and generic, and, once again, fairly game independent.
(Most games are going to want objects.) I envision something where
as much or as little of the object tree is revealed (for the
designer's viewing) as the designer wants. This get's us out of the
"all or nothing" trap of current debugging verbs.

> Let's refer to them
> as Game Objects. Since we're talking about objects here, lets
> make it entirely object oriented (see below).

Now we're starting to get into slightly more debated ground...I
would argue that the orientation of a system is more a language
concern than a design concern, but there's no denying that the
language affects the tools considerably. Also, I agree that Object-
communication of some sort is definitely desirable.

> Visual IF++ must
> provide classes, class hierarchies and should enable us to
> import/export parts of this hierarchy, so we can simply create
> entire worlds around us.

I agree about being able to flush out the parts of a system you
don't want.

> - Characteristics
> Give all the objects above their characteristics, properties,
> whatever you like to call them. The actual action in games is
> altering these characteristics.

Now we're delving into game system design...(I personally like the
ideas you propose...) boy, this has turned into a complex question,
hasn't it?

>
> - Actions
> Game Objects must not only be defined as a string ("This is a
> match"), but should also be able to respond to actions. The action
> "strike match" would change one of its characteristics to 'burning'
> and after some time (or after action "blow out match") to 'burned'.
> Besides altering characteristics of game objects, actions can
> create, destroy, move game objects, display files, text, graphics,
> play sounds and movie clips and start deamons (a time deamon
> for the burning match, for instance).

Now here's a conundrum...The kind of design tools you need, are
highly dependent on what *kind* of game you're making...If you're
making an Infocom-style game, you need tool x, for a Scott Adams-
style game: tool y, for a multi-media blowout sensation: tools a,b,
and d. Is there a good way to make the system such that you can
modify the tools, and create new ones to suit a particular library/
game-style combination?

>
> - Commands
> User commands must be linked to actions, mentioned above.
> This is also the place where we can define other elements of the
> vocabulairy of the game (like synonyms).

This, too, is a pretty standard desire, no matter what kind of
game you're making. (Even a point-and-click game!)

>
> - Autonomous actions
> Each characteristic can be linked to actions, that need to be
> executed each time it is altered, each turn, each so many minutes,
> at random or when the value of the characteristic reaches some
> value. It is the basis for autonomous behaviour of the NPC's
> (agents).

This is more of a library thing, But: How do the tools allow you
to import this library into the (perhaps, initially bare) system?

>
> - Debugger
> Since all kind of actions can be linked to all kinds of
> characteristics, lotsa stuff happens underneath the surface.
> Soon, we'll loose sight on what we created. So we need a debugger.
> To trace commands, events and results, define breakpoints (on
> events), etc.

Agreed. The debugger, is of course, horribly language-dependent.

>
> In a nutshell, this is it! OK, details must be defined, but you don't
> have to write code. Or at least, you'll do not have to write so much
> code as today. Define locations, place your player character in one
> of them, and off you go! The player, her/his actions and all
> autonomous actions determine what happens next.

What I start to see is that there are a lot of things that would
have to be cleared up before this system got off the ground... but,
I see a few components which would be beneficial to almost all games:

-Object Editor:
Perhaps the whole point of the exercise is to make the game
objects easier to define. Some extensions of the object editor
would be:
-Tree Editor:
Allows you to run through the object hiearchy, editing
the objects with tools based on their type, which would
be defined along with the library which implements these
types.
-Map Editor:
All sorts of setups for making maps, also edited with
tools defined along with whatever mapping library (or
extensions to a given library) you're using.

-Interface Editor:
This would allow you to build (or extend) whatever user interface
you're using. This would control syntax and the like. Also, different
tools would be defined along with extensions to the parser, to make
integration as easy as possible. When I think about it, if the syntax
were defined a la Inform/Hugo, this would be another kind of data
editor.

-Code Editor:
Lets you build the code behind the objects.

(Note: It's important that these be defined so that one Editor
could call another..Most importantly, the code editor (which, I
suppose, would just be a text-box type window) should be able to be
called by any other editor)

-Run-Time Debugger:
Hey, we can dream, can't we??

>
> In fact: you take all the good things of Inform, TADS and the
> like and wrap it in a friendly user interface.

Uhh..yah. :)

>
> So Brad, when do we start?
> In Java, of course, otherwise we'll have
> trouble making it platform independent...

Sometime after the beginning of the Third Millenium :)
I'm really just theorising here... but it's fun. I'm probably
not going to make them, or even try. (Well, I might try, but I'm
not going to announce it..ever heard of SuperAGT?..me neither!)

>
> Dirk Coppelmans - di...@iaehv.nl

Thanks for replying, Dirk.

[Bill Lash]

Brad O`Donnell wrote:
>
> Dirk Coppelmans wrote:
>
> > Game design
> > should provide:
> >
> > - Game map
> > You do need to plan ahead your surroundings: the Game World.
> > IMHO creating a game while playing it is not such a good approach
> > (sorry Roger). In the Game Map you can locate the locations of
> > your game world and you define all possible passages to and from
> > these locations.
>
> The map-maker is one of the few things that almost everyone wants.
> (Although that supposes you're making a traditional, path-linked
> game; for G. Caswell's proposed sector-based layout, a different
> type of map (and thence, a different map-maker) would be needed.)
>

Have you guys looked at the program "ifmap"? It was written by Matthew
Crosby, and has a web page at:

http://ugrad-www.cs.colorado.edu/~crosby/ifmap/IFMap.html

It is also available on ftp.gmd.de at:

ftp://ftp.gmd.de/if-archive/programming/editors/ifmap.tar.gz

I use it to map out games that I am playing, but it was really
intended more for writing IF. An excerpt from the web page states:

"Eventually, I want to expand this to create a graphical IF
creation tool. A sort of 'Visual inform and
tads'. As it stands, it is actually pretty far along; it
should be relatively trivial to write a converter
from the save format for this program to any language.
(The format is pretty self explanatory if
anyone wants to go for it)."

I thought about writing a converter to output Hugo source code,
but never got around to it. The format did look fairly straight-
forward.

I am not sure what platform you develop on, so the requirement of
Tcl/Tk might not fit with your plans, but I think Tcl and Tk are
available at least for Mac and Windows as well as Unix/X11.

Bill Lash
wel...@xnet.com

[Andrew Plotkin]

Bill Lash (la...@welash.xnet.com) wrote:
> > The map-maker is one of the few things that almost everyone wants.

And, it sometimes seems, one of the things that almost everyone has
started to write.

Somehow, though, nobody ever finishes them, or uses them to write games
if one is finished.

> Have you guys looked at the program "ifmap"? It was written by Matthew
> Crosby, and has a web page at:

> http://ugrad-www.cs.colorado.edu/~crosby/ifmap/IFMap.html

> It is also available on ftp.gmd.de at:
>
> ftp://ftp.gmd.de/if-archive/programming/editors/ifmap.tar.gz

> I use it to map out games that I am playing, but it was really
> intended more for writing IF. An excerpt from the web page states:

> "Eventually, I want to expand this to create a graphical IF
> creation tool. A sort of 'Visual inform and
> tads'. As it stands, it is actually pretty far along; it
> should be relatively trivial to write a converter
> from the save format for this program to any language.
> (The format is pretty self explanatory if
> anyone wants to go for it)."

I find that creating the rooms and exits and objects -- the things whose
Inform code can be generated automatically -- is just a tiny fraction of
my programming time. That's why I have never wanted one of these tools.
Making 1% of my job easier is simply not worth it, no matter how much
easier that part gets.

--Z

--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

[Brad O`Donnell]

Bill Lash (la...@welash.xnet.com) wrote:

> > > The map-maker is one of the few things that almost everyone wants.

> And, it sometimes seems, one of the things that almost everyone has
> started to write.
>
> Somehow, though, nobody ever finishes them, or uses them to write
> games
> if one is finished.

Excellent point. Let's not throw our hands up in the air and
pretend we never heard of map-makers as we turn back to the old,
reliable, ways, though. Let's do something equally useless, but
several times more interesting: try to figure out why.
(* Comments are without reference to any particular mapper, because
I can't run any of the current ones.)

One of the main problems with map-making utilities is that, although
they're kind of nifty to look at, if all a map-maker does is make a
map and output the skeleton, people will lose interest in it pretty
quickly.

Also, most map-makers are not integrated into whatever
system/language is being used by the author.

What this means is that if you want to add another room to your
map, no matter what language you're using, you need to output a
file full of useless room code (useless because it contains the
skeletons of all the rooms you have modified to make them into
a game) just to get the skeletons to a few new rooms. Even if a
program allows you to output just the skeltons for new rooms,
it would (at least in my view) be a bother just to load the thing
up. I can draw new rooms on a map on paper *way* faster than I can
load, edit, output, open, cut, copy ,close, open, and paste,
especially if, like me, you like to work on one room at a time.

This makes a nice corollary to what I was thinking about halfway
through my reply to Dirk, which is that nothing short of tools that
are integrated with both each other and the language of choice will
come into full, accepted, productive use.
(Perhaps even as part of the language/system; Although that means
that people will be forced to use the tools to get anything done.
hmmm...fascinating)

>
Andrew Plotkin wrote:
>
> I find that creating the rooms and exits and objects --
> the things whose
> Inform code can be generated automatically --
> is just a tiny fraction of
> my programming time. That's why I have never wanted
> one of these tools.
> Making 1% of my job easier is simply not worth it, no matter how much
> easier that part gets.

Well, what part of your job do you want made easier?
It would help discussion along quite a bit if you'd tell what tools
you would like. (I'm pretty much of the school of thought
where "You get out of a game, essentially, what you
program/write/create, and a fool with a tool is just a
well-equipped fool," but I still think that interactive <notice I
didn't say "visual"> tools have some place in the IF author's
desktop, and the ideas about it have dogged me for some 6 years.
It would be nice to spread the bug around a bit, and this seems like
the place to do it.)

[Magnus Olsson]

In article <erkyrathE...@netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>I find that creating the rooms and exits and objects -- the things whose
>Inform code can be generated automatically -- is just a tiny fraction of
>my programming time. That's why I have never wanted one of these tools.
>Making 1% of my job easier is simply not worth it, no matter how much
>easier that part gets.

Indeed.

It would of course be nice to be able to create new rooms while playing,
or to move rooms and exits around - as some MUDs allow you to do.

However, like Andrew, I find that room and object creation is the easy
part. What consumes most of the time is getting all those thingies to
interact in the right way; testing all action routines, and debugging
them. It would be nice to get rid of the edit - compile - restart -
recreate-previous-situation cycle (and the tedious part is *not*
recompiling, that takes ten seconds, but making sure that everything
is in the correct place and state ("Hmmm - had I eaten the biscuit
when I pressed that button last time?").

What I'd really like to see would be an incremental development system,
that allowed me to change a piece of code while running the game,
and without having to change the game state. Such a system is possible,
but it's a few orders of magnitude more difficult than a dynamic room
creator.

(What I mean is something like this:

You are in a boring room.
There is a hungry-looking troll standing here.

> i

You are carrying a rotting dog carcass and a large carrot

> give carrot to troll

The troll doesn't seem interested. "Gimme some food, human!"

[ oops, forgot that though trolls prefer meat, they can eat
vegetables too ]

> $edit troll.ioGiveTo

[ enter some code for eating vegetables here ]

> give carrot to troll
The troll eyes the carrot suspiciously. "Can I eat this strange
orange thing?" He takes a tentative bite from it, then
wolfs it down. "Not bad."

[ No. Too tame. ]

> undo
> $edit troll.ioGiveTo

[ Rewrite code ]

> give carrot to troll
The troll eyes the carrot suspiciously. "Can I eat this strange
orange thing?" He takes a tentative bite from it, then spits
it out. "Blecch! Gimme some real food! That dog sure looks yummy!"

--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)

[Neil K. Guy]

Andrew Plotkin (erky...@netcom.com) wrote:

: I find that creating the rooms and exits and objects -- the things whose
: Inform code can be generated automatically -- is just a tiny fraction of
: my programming time. That's why I have never wanted one of these tools.

I tend to agree. I assembled some semi-graphical HyperCard scripts for
automating some of the process of putting together rooms - they just spit
out TADS files. Parts of these scripts were based on the HyperCard stack
someone put onto ftp.gmd.de a while ago. And, while they saved a few
minutes in terms of generating some more repetitive chunks of code (eg:
some streets in a city) they are utterly useless for the actually
interesting parts of IF - writing plot, coming up with characters,
thinking up dialogue, designing clever puzzles, etc.

- Neil K. Guy

--
the Vancouver CommunityNet * http://www.vcn.bc.ca/
(formerly the Vancouver Regional FreeNet)

[Andrew Plotkin]

Brad O`Donnell (s7...@romulus.sun.csd.unb.ca) wrote:

> Andrew Plotkin wrote:
> >
> > I find that creating the rooms and exits and objects --
> > the things whose
> > Inform code can be generated automatically --
> > is just a tiny fraction of
> > my programming time. That's why I have never wanted
> > one of these tools.

> > Making 1% of my job easier is simply not worth it, no matter how much
> > easier that part gets.

> Well, what part of your job do you want made easier?
> It would help discussion along quite a bit if you'd tell what tools
> you would like.

If there was a tool I wanted, I would have asked for it. :)

The hard part is A: writing prose (which will not be automated in the near
future, I damn well hope) and B: writing code. Writing code is, as far as
I'm concerned, not automatable. The easy parts are already easy (I copy
and paste, or type simple lines of Inform source) and the hard parts are
everything else. The dozens of one-time hacks and ad hoc bits of code
that go into any large game. Which is to say, computer programming. I
know of no better approach to programming than writing source code in a
medium-to-high level language.

> (I'm pretty much of the school of thought
> where "You get out of a game, essentially, what you
> program/write/create, and a fool with a tool is just a
> well-equipped fool," but I still think that interactive <notice I
> didn't say "visual"> tools have some place in the IF author's
> desktop, and the ideas about it have dogged me for some 6 years.
> It would be nice to spread the bug around a bit, and this seems like
> the place to do it.)

Have fun. I don't have any ideas.

I *am* sympathetic to the "digging out a MUD" idea, where you are
issuing both game commands and game-building commands at the same prompt.
I've done that. It's great -- my objection is (as I said) that it only
helps with a small fraction of the job.

Now, an incremental compiler / interpreter combination -- that would be a
tremendous win. You start the game, play a segment, and then edit one
function in the source code and tell the compiler to compile *just that
function*. It does so and changes your game environment on the fly.
The next command you type in the game executes with the new function in
place. If you change an object definition, similarly, the object is
rebuilt in front of you.

This is an extension of the MUD-digging idea (where you can edit text
properties on the fly, and create objects.) However, it avoids the
problem making the program generate or edit source code.

The downside is that you really can't trust the incrementally compiled
code -- I mean, you can trust the *code*, but you can't be sure that your
play-testing-and-editing really verifies that the final product does what
you want. Eventually you have to do a fresh build, turn off wizard-mode,
and play "clean". Nonetheless I bet I'd eliminate 75% of my usual
start-play-quit-edit-compile cycle. You have no idea how often I add a
single line of code, compile and test it, swear and curse, and change an
"if" to an "if not", or a ">" to a ">=".

Implementation: certainly a pain in the butt. To be at all useful, the
system would have to correctly perform "undo" or "restore" across
on-the-fly game changes. The Z-machine certainly won't handle this; I
don't even know if it's possible for many kinds of game changes. (What
does it mean to change the *initial* value of a property which has
changed several times since you started playing? Heh heh.)

Ok, I had an idea. There it is.

[Brad O`Donnell]

Andrew Plotkin wrote:
>
>
> The hard part is A: writing prose (which will not be automated in the
> near future, I damn well hope) and B: writing code. Writing code is,
> as far as
> I'm concerned, not automatable.

Agreed. But I have trouble managing big projects...they make my head
hurt.

I suppose that what bugs me most about current systems is that if you
want to change the way the game acts, you have to go fish every piece
of
code out of the system that the change in behavior effects, and fiddle
around... For instance, I would very much like to have a slightly
different
exit, time, description output, and a few other changes. But when I
look
at the sum total of the changes I would like to make I find it
constitutes
a considerable rewrite of a large percentage of a library I didn't
write in
the first place. I can't see this situation changing in the near
future,
though.

( and messing with the core routines (Parser, et al.) scares the
bejabbers
out of me...)

> Now, an incremental compiler / interpreter combination -- that would be a
> tremendous win. You start the game, play a segment, and then edit one
> function in the source code and tell the compiler to compile *just that
> function*. It does so and changes your game environment on the fly.
> The next command you type in the game executes with the new function in
> place. If you change an object definition, similarly, the object is
> rebuilt in front of you.

Yes! I used the phrase "completely integrated with the
compiler/system"
to describe this...but I guess it didn't convey the meaning very well.
I liken this to the way that you can "break out" of an interpretive
program
to edit the source, and then resume execution with the revised program.

> The downside is that you really can't trust the incrementally compiled
> code -- I mean, you can trust the *code*, but you can't be sure that your
> play-testing-and-editing really verifies that the final product does what
> you want. Eventually you have to do a fresh build, turn off wizard-mode,
> and play "clean". Nonetheless I bet I'd eliminate 75% of my usual
> start-play-quit-edit-compile cycle. You have no idea how often I add a
> single line of code, compile and test it, swear and curse, and change an
> "if" to an "if not", or a ">" to a ">=".

Of course not, but I can tell you how often I compile a whole program
for a single line...For especially small changes, recompile once for
every minute of playing the old version.

>
> Implementation: certainly a pain in the butt. To be at all useful, the
> system would have to correctly perform "undo" or "restore" across
> on-the-fly game changes.

It would? What do you mean?

> The Z-machine certainly won't handle this; I
> don't even know if it's possible for many kinds of game changes. (What
> does it mean to change the *initial* value of a property which has
> changed several times since you started playing? Heh heh.)

Well, if it's been changed several times since the start of the game,
doesn't that mean that the new "initial" property has been changed too?
Of course, keeping track of this would be a wonky proposition... to
be at all manageable it would probably need to be built-in to a
"debugger's
extension" to the Virtual Machine.

>
> Ok, I had an idea. There it is.
>

Every bit helps.

[Andrew Plotkin]

Brad O`Donnell (s7...@romulus.sun.csd.unb.ca) wrote:

> > Now, an incremental compiler / interpreter combination -- that would be a
> > tremendous win. You start the game, play a segment, and then edit one
> > function in the source code and tell the compiler to compile *just that
> > function*. It does so and changes your game environment on the fly.
> > The next command you type in the game executes with the new function in
> > place. If you change an object definition, similarly, the object is
> > rebuilt in front of you.

> Yes! I used the phrase "completely integrated with the
> compiler/system"
> to describe this...but I guess it didn't convey the meaning very well.
> I liken this to the way that you can "break out" of an interpretive
> program
> to edit the source, and then resume execution with the revised program.

> > Implementation: certainly a pain in the butt. To be at all useful, the

> > system would have to correctly perform "undo" or "restore" across
> > on-the-fly game changes.

> It would? What do you mean?

Many game situations are one-time scenes. I play up to the beginning of
the scene; I save; I play the scene. It behaves wrong. I change one
object and recompile it. Now I have to restore in order to play the scene
again. If this is illegal, then I have to quit and restart the game in
order to test my change; that's the *current* situation, the one I'd like
to fix.

If I restore the game *before* I recompile, the problem is only delayed.
I can play through one more time, but I can't restore to play the scene a
third time. This is pretty worthless -- I often go through scenes dozens
of times in a programmnig session.

Undo is needed for the same reason. I often test grammar by trying one
command, undoing, trying another, undo... repeat a dozen times. I'd like
to be able to incrementally compile anywhere within this sequence, as
often as necessary.

> > The Z-machine certainly won't handle this; I
> > don't even know if it's possible for many kinds of game changes. (What
> > does it mean to change the *initial* value of a property which has
> > changed several times since you started playing? Heh heh.)

> Well, if it's been changed several times since the start of the game,
> doesn't that mean that the new "initial" property has been changed too?
> Of course, keeping track of this would be a wonky proposition...

No kidding.

[Paolo Vece]

"Brad O`Donnell" <s7...@romulus.sun.csd.unb.ca> wrote:

> Well, what part of your job do you want made easier?
> It would help discussion along quite a bit if you'd tell what tools

> you would like. (I'm pretty much of the school of thought

> where "You get out of a game, essentially, what you
> program/write/create, and a fool with a tool is just a
> well-equipped fool," but I still think that interactive <notice I
> didn't say "visual"> tools have some place in the IF author's
> desktop, and the ideas about it have dogged me for some 6 years.
> It would be nice to spread the bug around a bit, and this seems like
> the place to do it.)

Speaking for myself (with the experience that I'm having with my first
still ongoing game) the hardest part of the job is the _creative_ one (write
good descriptions in good English and such), and I think that won't ever be
a tool that can automatically write a vivid description of a room.

I'm a programmer and maybe I've got a strange view of the things.

Maybe some of us could start thinking about _cooperations_ between a
writer and a programmer (and, possibly, an english proof-reader).

> --
> Brad O'Donnell
> "A story is a string of moments, held together by memory."

--
Paolo Vece (Roma, Italy) - pv...@mclink.it

[Kevin P. Soucy]

Brad O`Donnell <s7...@romulus.sun.csd.unb.ca> wrote:

> Sometime after the beginning of the Third Millenium :)
> I'm really just theorising here... but it's fun. I'm probably
> not going to make them, or even try. (Well, I might try, but I'm
> not going to announce it..ever heard of SuperAGT?..me neither!)

Well, for your information, SuperAGT is still alive and well. It's
just undergone a name change....Text AGATE (Adventure Game Authoring &
Testing Environemnt) It is going to be written in C, and will be
primarily used for creating games with AGT structures. (IE: ROOMS,
NOUNS, CREATURES, COMMANDS, etc. Most people with AGT experience know
what I'm talking about.) I'm doing this because I find AGT's
structures easier for a beginner to understand than an Object Oriented
approach. I still haven't decided weather or not to allow export of
different IF language source code files....since the stand-alone game
can be compiled from within the environment. Why would you write out
the source code just to compile it under a different compiler? It's
still the same game. Importing from other languages is a different
story, and is something I plan on taking a swing at. Secondly, is
that I WILL be allowing Libraries in order to make the program as
flexable as everyone here seems to want it. These Libraries will
allow an AGATE programmer to write their own META-Command Tolkens in a
C-like language. More on this feature after I have given it some more
thought. I'm currently shooting for an early 1998 release...but don't
hold me to that.

"The AGT/AGATE Guy"

Stee...@Mindspring.Com

[Kevin P. Soucy]

erky...@netcom.com (Andrew Plotkin) wrote:

>Now, an incremental compiler / interpreter combination -- that would be a
>tremendous win. You start the game, play a segment, and then edit one
>function in the source code and tell the compiler to compile *just that
>function*. It does so and changes your game environment on the fly.
>The next command you type in the game executes with the new function in
>place. If you change an object definition, similarly, the object is
>rebuilt in front of you.

This is a feature that AGATE will have. There will be two modes of
design: Write and Play. When you are in Write Mode, all the coustom
commands are non-functional. This is a safety precaution because when
in Write Mode, you are writing and reading directly from the source
code. So, if you were to pick up a noun and move it to another room,
it will be located there in the final version of the game. To test
your coustom commands, you would switch to Play mode, where the
program writes all changes to a work file and reads the source code
after seaching for a change in that work file. When in this mode, you
can reset all the games initial values, and even edit these values in
order to change the conditions for the command you are testing. (IE:
You can chage the number of turns the player has taken already, what
objects the player might be carrying at that moment, or what flags
would be on or off.) These changes will not affect the source code,
allowing you to resume in Write mode where you left off.

"The AGT/AGATE Guy"

Stee...@Mindspring.Com

[Andrew Plotkin]

Kevin P. Soucy (stee...@mindspring.com) wrote:
> Brad O`Donnell <s7...@romulus.sun.csd.unb.ca> wrote:

> Well, for your information, SuperAGT is still alive and well. It's
> just undergone a name change....Text AGATE (Adventure Game Authoring &
> Testing Environemnt) It is going to be written in C, and will be
> primarily used for creating games with AGT structures. (IE: ROOMS,
> NOUNS, CREATURES, COMMANDS, etc. Most people with AGT experience know
> what I'm talking about.) I'm doing this because I find AGT's
> structures easier for a beginner to understand than an Object Oriented
> approach. I still haven't decided weather or not to allow export of
> different IF language source code files....since the stand-alone game
> can be compiled from within the environment. Why would you write out
> the source code just to compile it under a different compiler? It's
> still the same game.

So that people can play that same game under an existing Mac interpreter.
So that *I* don't have to port the Max{TADS/Zip} interface to yet another
damn engine which has exactly the same I/O capabilities.