producing adventures
KingNezII
I'm new to the interactive fiction scene. For class I created a small game
engine with an accompanying file format, and have been looking around at
the community to see what other people have done. I'm astounded there is a
virtual machine for text adventure games, and have wondered at the current
procedures for creating interactive fiction. It seems that short of being
a programmer, you can't create a word of adventure fun, unless you int a
bunch of objects.. ok, well, I think the barrier for authoring is still
too high. Are there tools out there that can help non-programmers create
adventures, and what about the file format? Seems like it's a tightly
organized binary file, are there other formats available for that?
Curiously,
Zenko
David Whyld
If you don't know how to program (join the club!), you could always
check out http://www.adrift.org.uk
dgen...@hotmail.com
game engine, as you claim?
Dave
Kevin Forchione
news:pan.2005.09.14....@hotmail.com...
> Hi Everyone,
>
> I'm new to the interactive fiction scene. For class I created a small game
> engine with an accompanying file format, and have been looking around at
> the community to see what other people have done. I'm astounded there is a
> virtual machine for text adventure games, and have wondered at the current
> procedures for creating interactive fiction. It seems that short of being
> a programmer, you can't create a word of adventure fun, unless you int a
> bunch of objects.. ok, well, I think the barrier for authoring is still
> too high.
Oh? Why do you think that? Seems like a lot of games have been written.
>Are there tools out there that can help non-programmers create
> adventures,
There are some tools such as Adrift that are suitable for non-programmers.
You'll want to check out the archives.
--Kevin
Andrew Plotkin
>
> Are there tools out there that can help non-programmers create
> adventures
I know Inform, which is probably one of the ones you don't mean. So I
will let other people answer this part of the question.
> and what about the file format? Seems like it's a tightly
> organized binary file, are there other formats available for that?
There are several formats. Nearly every IF development system (whether
intended for programmers or not) has invented a new one. This has
generally been a mistake, I think, since the advantages of a
"non-programming system" are independent of the final file format. If
you're designing a new system, you really have a wide choice of
formats. Or you could generate source code for an existing IF system.
dgen...@hotmail.com wrote:
> If you don't know how to program, how the hell did you create an
> entire game engine, as you claim?
He didn't say he didn't know how to program; he asked about options
*for* non-programmers.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
David Fisher
>
> I'm new to the interactive fiction scene. For class I created a small game
> engine with an accompanying file format, and have been looking around
> at the community to see what other people have done. I'm astounded
> there is a virtual machine for text adventure games, and have wondered
> at the current procedures for creating interactive fiction.
The main languages used are Inform, TADS 2, TADS 3 (still in Beta) and Hugo
... Adrift is also popular, but it is not free like Inform / TADS / Hugo
are.
Have a look at
http://www.ifwiki.org/index.php/Past_raif_topics%3A_Development%3A_part_1
for more information - the table of contents:
1. Intro to IF creation
2. Authoring systems in general
3. Inform, TADS & Hugo authoring systems
4. Learning Inform / TADS
5. Other authoring systems
6. Writing IF in a general programming language
7. Creating an IF language
8. Potential for IF language for non programmers
9. World definition formats / using XML for IF
> It seems that short of being a programmer, you can't create a word
> of adventure fun, unless you int a bunch of objects..
("int a bunch of objects" ??)
> Are there tools out there that can help non-programmers create
> adventures
Well, the main idea of the above IF authoring systems is to allow anyone to
create IF ... and to have a common format for game files so they can be
played on as many platforms as possible. Some people have pointed out that
some kind of "programming" is inevitable, though ... see section 8 in the
HTML page above.
> and what about the file format? Seems like it's a tightly
> organized binary file, are there other formats available for that?
There is a standard binary format for each system (Inform, TADS, Hugo, etc),
but the source code is text (of course) ... generally IF authors don't need
to know much about the details, though - unless they are creating special
tools, etc.
Hope you had fun writing your own game engine ! I'd be interested to here
what it could do. What kinds of things did you learn / discover along the
way ? (I guess parsing sentences was the trickiest part ...?)
David Fisher
~~ http://www.ifwiki.org/index.php/Past_raif_topics ~~
KingNezII
> Here, KingNezII <dah_c...@hotmail.com> wrote:
>>
>> Are there tools out there that can help non-programmers create
>> adventures
>
> I know Inform, which is probably one of the ones you don't mean. So I
> will let other people answer this part of the question.
>
>> and what about the file format? Seems like it's a tightly
>> organized binary file, are there other formats available for that?
>
> There are several formats. Nearly every IF development system (whether
> intended for programmers or not) has invented a new one. This has
> generally been a mistake, I think, since the advantages of a
> "non-programming system" are independent of the final file format. If
> you're designing a new system, you really have a wide choice of
> formats. Or you could generate source code for an existing IF system.
>
> dgen...@hotmail.com wrote:
>> If you don't know how to program, how the hell did you create an
>> entire game engine, as you claim?
>
> He didn't say he didn't know how to program; he asked about options
> *for* non-programmers.
>
Right, someone pointed me to adrift and that was basically what I wanted
to do. I'm trying to figure out how to contribute to IF without
reinventing the wheel. I know PASCAL/C/C++/Java (the game engine was
written in Java and the file format is XML based).
Here's a sample:
<?xml version='1.0' encoding='utf-8'?>
<GAME name="CTRL" author="Zenko B. Klapko Jr." version="1/0">
<OPENINGTEXT>Operative Training</OPENINGTEXT>
<WINCONDITION requirementid="1">
<WINTEXT>You have completed Operative Training. Congratulations. Please wait for your next assignment.
</WINTEXT>
</WINCONDITION>
<INITIALPLAYERSTATE RoomID="0">
<STARTINGINV>
<ITEMID>4</ITEMID>
</STARTINGINV>
<STARTINGACCOMPLISHMENTS>
<ACCOMPLISHMENT />
</STARTINGACCOMPLISHMENTS>
</INITIALPLAYERSTATE>
<GLOBALREQUIREMENTLIST>
<REQUIREMENT id = "1" promptable="true">
<LISTHEADER>You need:</LISTHEADER>
<COMPLETIONTEXT>All items and accomplishments have been met.</COMPLETIONTEXT>
<ITEMID>1</ITEMID>
<ROOMID>1</ROOMID>
<ACCOMPLISHMENT>Picked up the gun.</ACCOMPLISHMENT>
</REQUIREMENT>
</GLOBALREQUIREMENTLIST>
<GLOBALITEMLIST>
<ITEM id="1" name="gun">
<DESCRIPTION>9 millimeter hand gun</DESCRIPTION>
<ACTIONLIST>
<ACTION name="pickup" initiator="true" target="false" requirementid="">
<DESCRIPTION>Picking up the gun</DESCRIPTION>
<ACCOMPLISHMENT>Picked up the gun.</ACCOMPLISHMENT>
<ADDPLAYERINV itemid="1"/>
<REMROOMINV itemid="1" roomid="0" />
</ACTION>
</ACTIONLIST>
</ITEM>
<ITEM id="2" name="Door">
<DESCRIPTION>A heavy metal door with a small bullet-proof window</DESCRIPTION>
<ACTIONLIST>
<ACTION name="open" initiator="true" target="false" requirementid="">
<DESCRIPTION>The door swings open easily despite its weight.</DESCRIPTION>
<MOVEPLAYER roomid="1"/>
</ACTION>
</ACTIONLIST>
</ITEM>
<ITEM id="3" name="Door">
<DESCRIPTION>A heavy metal door with a small bullet-proof window</DESCRIPTION>
<ACTIONLIST>
<ACTION name="open" initiator="true" target="false" requirementid="">
<DESCRIPTION>The door swings open easily despite its weight.</DESCRIPTION>
<MOVEPLAYER roomid="0"/>
</ACTION>
</ACTIONLIST>
</ITEM>
<ITEM id="4" name="bowl">
<DESCRIPTION>A copper bowl</DESCRIPTION>
<ACTIONLIST>
<ACTION name="drop" initiator="true" target="false" requirementid="">
<DESCRIPTION>The ball hits the ground with a loud clang.</DESCRIPTION>
<REMPLAYERINV itemid="4" />
<ADDROOMINV itemid="4" roomid="0" />
</ACTION>
</ACTIONLIST>
</ITEM>
</GLOBALITEMLIST>
<GLOBALROOMLIST>
<ROOM id="0" name="Starting Room" actionListDisplayable="true">
<DESCRIPTION>You're in an empty room</DESCRIPTION>
<INVENTORY>
<ITEMID>1</ITEMID>
</INVENTORY>
<EXITLIST>
<ITEMID>2</ITEMID>
</EXITLIST>
</ROOM>
<ROOM id="1" name="Finishing Room" actionListDisplayable="true">
<DESCRIPTION>You're in an adjoining room</DESCRIPTION>
<INVENTORY>
<!-- <ITEMID /> -->
</INVENTORY>
<EXITLIST>
<ITEMID>3</ITEMID>
</EXITLIST>
</ROOM>
</GLOBALROOMLIST>
</GAME>
Somewhat crude, but all the basics are there.
KingNezII
> ("int a bunch of objects" ??)
I was trying to do some word play with the C data types but it started to
fall apart, int is short for intialization.
-Zenko
Jake Wildstrom
>It seems that short of being
>a programmer, you can't create a word of adventure fun, unless you int a
>bunch of objects.. ok, well, I think the barrier for authoring is still
>too high. Are there tools out there that can help non-programmers create
>adventures, and what about the file format?
Short answer: yes. Long answer: no.
To elaborate, there are tools designed for non-programmers, but
writing adventures requires programming, pretty much no matter what,
and in the end, even the best game-design tools will not prevent you
from having to do the heavy lifting yourself.
Programming is not a matter of memorizing the vocabulary of braces and
flow-control statements and whatnot: while an individual language may
have its own vocabulary, most of what makes "programming" as a skill
is design: making systems to respond to input. That's basically what
makes a good work of IF too:knowing what people will want to do and
the current game state (i.e. input), it's supposed to determine
responses. Sure, it's possible to build a work entirely from pre-fab
elements, but it'll look like it, and it's not going to help you build
up the skills necessary for original work.
So, by and large, I don't think it's helpful in the long run to seek a
'beginner-friendly' system.
Anyways, the contrast between various systems has been done before,
and better than I can do it, so check out
http://www.plover.net/~textfire/raiffaq/online/tier1.htm for a
somewhat outdated but detailed list of popular authorship systems.
--
D. Jacob (Jake) Wildstrom, Math monkey and freelance thinker
"A mathematician is a device for turning coffee into theorems."
-Alfred Renyi
The opinions expressed herein are not necessarily endorsed by the
University of California or math department thereof.
Kevin Forchione
Object-oriented modeling does seem advantageous to interactive fiction
programming, though of course you can do the trick with many other
structures.
--Kevin
David Whyld
>
> The main languages used are Inform, TADS 2, TADS 3 (still in Beta) and Hugo
> ... Adrift is also popular, but it is not free like Inform / TADS / Hugo
> are.
>
The older version of Adrift - 3.9 - is still free. And the non-free
version - 4 - only costs $18.00. Hardly a fortune.
Default User
Do do anything beyond canned fill-in-the-blank stuff, you will need to
implement custom algorithms working on provided data. That is the very
definition of programming.
What sort of tools would you envision for non-programmers to use? What
would these tools do and how would they work?
Brian
Kevin Forchione
news:3otqlsF...@individual.net...
I suspect that what is envisioned by a lot of java-programming students / IF
newbies is something along the lines of the graphical IDEs they got to play
around with in their classes. There are also shooter game development
systems that provide front-ends that amount to drop boxes and drag and drop
manipulation of game objects. Probably something like that *could* be done,
but in most cases the levels of customization to both objects and libraries
would mean that newbies would quickly get bored with the bells and whistles,
and limitations, of the gui, and find that they have to get their hands
dirty with programming anyway...
--Kevin
Default User
> "Default User" <defaul...@yahoo.com> wrote in message
> news:3otqlsF...@individual.net...
> > Do do anything beyond canned fill-in-the-blank stuff, you will need
> > to implement custom algorithms working on provided data. That is
> > the very definition of programming.
> >
> > What sort of tools would you envision for non-programmers to use?
> > What would these tools do and how would they work?
>
> I suspect that what is envisioned by a lot of java-programming
> students / IF newbies is something along the lines of the graphical
> IDEs they got to play around with in their classes. There are also
> shooter game development systems that provide front-ends that amount
> to drop boxes and drag and drop manipulation of game objects.
> Probably something like that could be done, but in most cases the
> levels of customization to both objects and libraries would mean that
> newbies would quickly get bored with the bells and whistles, and
> limitations, of the gui, and find that they have to get their hands
> dirty with programming anyway...
It's just hard for me to envision much of an IF game that didn't have a
lot of custom programming. You could populate a world with basic rooms,
with objects that you pick up or not, and NPCs you could carry on
rudimentary conversations with, that sort of thing. Those don't seem to
me to be very interesting games.
Brian
Kevin Forchione
Me, either. So the tools that would be most useful would be those that
facilitate programming: a good editor, debugger, and perhaps windiff for
comparing scripts.
--Kevin
KingNezII
> "Default User" <defaul...@yahoo.com> wrote in message
> news:3ou20aF...@individual.net...
>> Kevin Forchione wrote:
>>
>>> "Default User" <defaul...@yahoo.com> wrote in message
>>> news:3otqlsF...@individual.net...
>>
>> It's just hard for me to envision much of an IF game that didn't have a
>> lot of custom programming. You could populate a world with basic rooms,
>> with objects that you pick up or not, and NPCs you could carry on
>> rudimentary conversations with, that sort of thing. Those don't seem to
>> me to be very interesting games.
>
> Me, either. So the tools that would be most useful would be those that
> facilitate programming: a good editor, debugger, and perhaps windiff for
> comparing scripts.
>
Custom programming in the confines of the TADS programming language, or in
the sense that one has to hack around with the virtual machine to get it
to work?
> --Kevin
KingNezII
> "Default User" <defaul...@yahoo.com> wrote in message
> news:3ou20aF...@individual.net...
>> Kevin Forchione wrote:
>>
>>> "Default User" <defaul...@yahoo.com> wrote in message
>>> news:3otqlsF...@individual.net...
>>
>> It's just hard for me to envision much of an IF game that didn't have a
>> lot of custom programming. You could populate a world with basic rooms,
>> with objects that you pick up or not, and NPCs you could carry on
>> rudimentary conversations with, that sort of thing. Those don't seem to
>> me to be very interesting games.
>
> Me, either. So the tools that would be most useful would be those that
> facilitate programming: a good editor, debugger, and perhaps windiff for
> comparing scripts.
>
I'm sure that a bunch of examples spring to mine, could you name a few
that I could play?
Zenko
> --Kevin
Kevin Forchione
Custom programming in the confines of any of the programming languages.
Hacking the virtual machine (or game file) is something only players might
do, once the game was actually created.
I suspect that my statement was confusing because there was no mention of a
compiler/interpreter. The whole point of program development is not to hack
the object module, the compiler, or the translator (or their functional
equivalents), but to work within the confines of the language to produce the
results that the language is especially designed for.
--Kevin
Kevin Forchione
Muffy St. Bernard
> It's just hard for me to envision much of an IF game that didn't have a
> lot of custom programming. You could populate a world with basic rooms,
> with objects that you pick up or not, and NPCs you could carry on
> rudimentary conversations with, that sort of thing. Those don't seem to
> me to be very interesting games.
Most of the 8-bit IF authoring systems were exactly that sort of thing. I
used to write games using "AdventureWriter," which was exactly what you've
described, but without even the rudimentary conversations with NPCs. It did
have a really, really basic scripting language on the sideline that
consisted of choosing a bunch of predefined conditions, followed by
predefined actions. The parser accepted two word commands only (though you
could define additional verbs and nouns). It was really neat given the year
and the system limitations.
I'm not saying those authoring systems lead to a boom in homebrew games, of
course. And they're certainly not anything like what's available today (or
even AGT). But they sure were cool at the time.
Muffy
www.dangermuff.com
Default User
> "Default User" <defaul...@yahoo.com> wrote in message
> news:3ou20aF...@individual.net...
>
> > It's just hard for me to envision much of an IF game that didn't
> > have a lot of custom programming. You could populate a world with
> > basic rooms, with objects that you pick up or not, and NPCs you
> > could carry on rudimentary conversations with, that sort of thing.
> > Those don't seem to me to be very interesting games.
>
> Most of the 8-bit IF authoring systems were exactly that sort of
> thing. I used to write games using "AdventureWriter," which was
> exactly what you've described, but without even the rudimentary
> conversations with NPCs. It did have a really, really basic
> scripting language on the sideline that consisted of choosing a bunch
> of predefined conditions, followed by predefined actions. The parser
> accepted two word commands only (though you could define additional
> verbs and nouns). It was really neat given the year and the system
> limitations.
After thinking about it some, there could be objects that have
predefined actions, keys come to mind. All you would need to do is
specify which lockable object (another canned specialized type) is
associated with the key. Similarly tools could have a basic "use"
function that could be associated with some objects out of an object
library.
Brian
Kevin Forchione
That is indeed already the case ... as with libraries such as Alan, Hugo,
Inform, TADS, or PAWS. The idea of a "use" command (similar to the "use"
function common in graphical games) has been bandied about, but apart from a
conceptual framework for debugging, hasn't been implemented (though it could
easily be done). Some libraries implement such automatic associates: e.g. in
TADS, <<DIG>> would attempt to select the appropriate implement to dig with,
and then select the appropriate object to dig in.
--Kevin
David Fisher
news:1126796487.8...@g49g2000cwa.googlegroups.com...
I wasn't aware of that - thanks for the info,
David Fisher
Kevin Forchione
> Hi Everyone,
>
> I'm new to the interactive fiction scene. For class I created a small game
> engine with an accompanying file format, and have been looking around at
> the community to see what other people have done. I'm astounded there is a
> virtual machine for text adventure games, and have wondered at the current
> procedures for creating interactive fiction. It seems that short of being
> a programmer, you can't create a word of adventure fun, unless you int a
> bunch of objects.. ok, well, I think the barrier for authoring is still
> too high.
Sounds to me like you ought to give the Alan language a look over. Very
interesting conceptually and you might find it feels like less of a barrier
for new and non-programming authors.
--Kevin
Aidy
> It's just hard for me to envision much of an IF game that didn't have a
> lot of custom programming. You could populate a world with basic rooms,
> with objects that you pick up or not, and NPCs you could carry on
> rudimentary conversations with, that sort of thing. Those don't seem to
> me to be very interesting games.
Could you give me some examples (real world or off the top of your head) of
puzzles/things that need custom programming to achieve?
Adam Thornton
Aidy <Ai...@777.com.no.spam> wrote:
>Could you give me some examples (real world or off the top of your head) of
>puzzles/things that need custom programming to achieve?
Ropes, liquids, timed (either turn-based or real-time) puzzles (in
general, things-that-need-daemons). Screen layout tricks.
Doorways/exits with nonstandard behaviors (e.g. the door to the Reactor
Room isn't openable until the earthquake shorts out the controls).
Adam
Aidy
doesn't include liquids or ropes although the game engine half supports
joiners at the minute (assuming you mean "tie rope to object", "climb rope"
etc). But it has non-standard doors, standard heaviour on objects (the
black potion), and non-standard behaviour on objects (the non-black potions
which can't be dropped). A door that is locked and won't open but can be
opened by another event. Also it has a timer attached to the reactor. The
timer can fire every x turns, or every x turns after the player has done y
moves.
The game engine also does the physics for you as seen in the third script.
Not a single line of code was needed for this game.
----- SCRIPT 1 ------
Script mode is on. Scripting to testgame0.txt
> l
Main room
This is a room to demo some game features.
You can see: a reactor door, a small box
Obvious exits: East
> x door
This is a sturdy reactor door.
It is locked.
> open door
The door is locked.
> e
There is no way this sturdy reactor door is going to open.
> x box
This is a small box that probably contains some really cool stuff.
It is closed.
> open box
You open the small box.
> x box
This is a small box that probably contains some really cool stuff.
It is open.
It contains: a red potion, a green potion, a blue potion, a black potion
> get red potion
[from Small box]
Ok.
> x potion
Could you be more specific? You can see a red potion, a green potion, a
blue
potion, a black potion.
> x red potion
The label on this potion says it is a lightning potion.
> drop red potion
I don't fancy being struck by lightning.
> drink red potion
Are you crazy?
> x box
This is a small box that probably contains some really cool stuff.
It is open.
It contains: a green potion, a blue potion, a black potion
> get black potion
[from Small box]
Ok.
> x black potion
The label on this potion says it is harmless.
> drop black potion
Ok.
> l
Main room
This is a room to demo some game features.
You can see: a reactor door, a small box, a black potion
Obvious exits: East
> get black potion
Ok.
> drink black potion
You guzzle it down.
> i
You are carrying:
a red potion
an empty black potion
> drink black potion
It's empty.
> get green potion
[from Small box]
Ok.
> x green potion
The label on this potion says it is an earthquake potion.
> drop green potion
You drop the potion and it smashes on the ground causing an earth quake that
somehow shorts out the controls to the reactor.
> x door
This is a sturdy reactor door.
It is open.
> e
Reactor
This is a reactor.
Obvious exits: West
> z
Time passes.
> z
Time passes.
A janitor pops his head around the door and says, "You know if you wait long
enough you might win."
> z
Time passes.
> z
Time passes.
w00t! You've beaten the game!
------ SCRIPT 2 ------
Script mode is on. Scripting to testgame1.txt
> l
Main room
This is a room to demo some game features.
You can see: a reactor door, a small box
Obvious exits: East
> examine the small box
This is a small box that probably contains some really cool stuff.
It is closed.
> open the box then look in it
[open the box]
You open the small box.
[look in it]
It contains: a red potion, a green potion, a blue potion, a black potion
> get all from box except the red potion and the blue potion
[Green potion]
Ok.
[Black potion]
Ok.
> examine the green potion
The label on this potion says it is an earthquake potion.
> x reactor door
This is a sturdy reactor door.
It is locked.
> drop the earthquake potion
You drop the potion and it smashes on the ground causing an earth quake that
somehow shorts out the controls to the reactor.
> x door
This is a sturdy reactor door.
It is open.
> enter the reactor
Reactor
This is a reactor.
Obvious exits: West
> wait
Time passes.
> wait
Time passes.
A janitor pops his head around the door and says, "You know if you wait long
enough you might win."
> z
Time passes.
> z
Time passes.
w00t! You've beaten the game!
---- SCRIPT 3 ----
Script mode is on. Scripting to testgame3.txt
> l
Main room
This is a room to demo some game features.
You can see: a small box, a brick
Obvious exits: East
> i
You are carrying:
Nothing
> get brick
Ok.
> get box
It would be too awkward to carry a small box as well.
> drop brick
Ok.
> x box
This is a small box that probably contains some really cool stuff.
It is open.
It contains: a red potion
> get potion
[from Small box]
Ok.
> get brick
It would be too awkward to carry a brick as well.
> i
You are carrying:
a red potion
> get box
It would be too awkward to carry a small box as well.
> put potion in box
Ok.
> get brick
Ok.
> put brick in box
Ok.
> get box
Ok.
> e
Reactor
This is a reactor.
Obvious exits: West
> drop box
Ok.
> l in it
It contains: a red potion, a brick
> get brick
[from Small box]
Ok.
> drop brick
Ok.
> get potion then drop it
[from Small box]
Ok.
[drop it]
Ok.
> l
Reactor
This is a reactor.
You can see: a small box, a brick, a red potion
Obvious exits: West
> get bxo
That isn't here
> get box
Ok.
> w
Main room
Obvious exits: East
> drop all
[Small box]
Ok.
> i
You are carrying:
Nothing
> l
Main room
This is a room to demo some game features.
You can see: a small box
Obvious exits: East
> e
Reactor
You can see: a brick, a red potion
Obvious exits: West
"Adam Thornton" <ad...@fsf.net> wrote in message
news:dh1at9$ass$1...@localhost.localdomain...
Aidy
bulk. All objects can contain a certain bulk and a certain weight.
Something can be too bulky to fit a container or for you to hold, or it
could be too heavy or both. Obviously this allows you to put the heavy book
in the drawer but not the 3 meter stick :)
"Aidy" <Ai...@777.com.no.spam> wrote in message
news:dh1fue$off$1...@news8.svr.pol.co.uk...
Andrew Plotkin
> Ok this took about 30 mins to do. Two scripts for the same "game". It
> doesn't include liquids or ropes although the game engine half supports
> joiners at the minute (assuming you mean "tie rope to object", "climb rope"
> etc). But it has non-standard doors, standard heaviour on objects (the
> black potion), and non-standard behaviour on objects (the non-black potions
> which can't be dropped). A door that is locked and won't open but can be
> opened by another event. Also it has a timer attached to the reactor. The
> timer can fire every x turns, or every x turns after the player has done y
> moves.
>
> The game engine also does the physics for you as seen in the third script.
>
> Not a single line of code was needed for this game.
Please don't post long transcripts to this newsgroup. Put them up on a
web page.
Have you done the Cloak of Darkness exercise? This is a simple text
adventure scenario which has been implemented in nearly every IF
development system. If you implement this, you'll have an idea how
your system compares to all the other ones -- at least for simple
puzzles. :)
<http://www.firthworks.com/roger/cloak/>
The usual *complex* test is to implement Colossal Cave. That's a lot
more work, though.
Greg Boettcher
> Sounds like you could use a perusal of the DM4.
> http://www.inform-fiction.org/manual/html/
Don't forget the Inform Beginner's Guide, which is often even more
useful to newbies.
http://www.inform-fiction.org/manual/about_ibg.html
Greg
Adam Thornton
Aidy <Ai...@777.com.no.spam> wrote:
>Didn't make it very obvious but the game's physics rules handle weight and
>bulk.
I didn't make it clear enough by what I meant about ropes and liquids:
Ropes can have their ends in two different rooms, and can be tied to
other objects, and exert forces on those objects when pulled on.
Liquids should present miscibility.
Adam
Dan Shiovitz
Aidy <Ai...@777.com.no.spam> wrote:
>Ok this took about 30 mins to do. Two scripts for the same "game". It
>doesn't include liquids or ropes although the game engine half supports
>joiners at the minute (assuming you mean "tie rope to object", "climb rope"
>etc). But it has non-standard doors, standard heaviour on objects (the
>black potion), and non-standard behaviour on objects (the non-black potions
>which can't be dropped). A door that is locked and won't open but can be
>opened by another event. Also it has a timer attached to the reactor. The
>timer can fire every x turns, or every x turns after the player has done y
>moves.
>
>The game engine also does the physics for you as seen in the third script.
>
>Not a single line of code was needed for this game.
Hmm. I think either you're missing the bigger picture here, or else
this is just a disagreement over what "code" means. Like, to use the
potion example, when someone tries to drop a non-black potion it
refuses and prints a message. Say I'm a programmer using this system
(ie, not someone who has access to modify the engine/interpreter code,
just whatever standard customization is available) and I want to do
something very close to this but not quite the same. A couple examples:
- Refuse and print a particular message when someone attempts to
read the non-black potions
- Print a special message but allow the drop anyway when someone
tries to drop the non-black potions
- Print a message, unlock a door, and move the actor to another room
when someone tries to drop the non-black potions
If I (as the programmer without the ability to modify the general game
system engine) can do all these things, then I would say that I am
coding, however it's presented (drag and drop, selecting things from a
menu, filling in forms). If I can't do this, then I would say the game
system isn't powerful enough for most people's needs. Note that this
isn't about whether or not it supports a particular feature -- I think
Adam is confusing the issue here by pointing out difficult to
implement things. Of course you can modify the game engine to support
anything anyone asks for. The question is, once the game engine is out
there and people are trying to use it, and they say "hey, I want to do
this thing that the system author didn't anticipate", how much of the
time can they do it and how much of the time are they just out of
luck?
Existing top-tier systems (Inform, TADS, Hugo, Alan, even ADRIFT) let
you do things the author didn't anticipate for a very large class of
problems. Certainly not all -- if you want to do things with graphics
or sound you are out of luck in a vast majority of the problem space
(which is not to say there is no graphics or sound support whatsoever --
check out Arrival or Future Boy or the like), and in some cases the
available solution is hacky (ADRIFT, in particular, requires people to
fall back to the catchall handlers much more often than is optimal,
and consequently the games tend to feel like they all have their own
handcrafted interface). At the opposite end of the spectrum would be
my own Snap! (http://www.drizzle.com/~dans/if/snap/) which supports
some reasonably complicated object behavior, but gives relatively
little power to the programmer to do things that the system author
didn't plan for.
Does that clarify the discussion at all? (I apologize if I'm missing
something about your system -- I don't see any posts about it other
than on this thread, so I can't look up its capabilities in more
detail for myself).
--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW
Kevin Forchione
That, of course, depends on the development system you are using. Any system
will have a certain problem domain that it can handle without customization
(that's usually called "the library"). No library can anticipate all
possible problems.
For example, TADS 2 does not provide for nested closable rooms such as
telephone booths, but the system can be customized to accommodate these
kinds of object behaviors. TADS 2 does not provide for time-oriented game
play (such as that of Infocom's Sherlock), but the system can accommodate a
wide variety of customization that would implement these features.
A development system that does attempt to be the Uber development system
will inevitably encounter 2 problems (we will dispense with the issues of
memory consumption and processing time): the first being that the plethora
of features will begin to overwhelm the ordinary author with unwanted
choices; the second being that as specializations begin to become entrenched
in the system and build on one another, the ability to add features that
radically depart from the standard become more difficult. A well-designed
system can attempt to anticipate this, but the difficulty lies in a certain
dynamic that seems to exist in successful game design.
That dynamic is the interplay between "the ordinary" and "non-ordinary" in
the course of the game. While the vast majority of the game environment may
be, and must be, ordinary (i.e. the behaviors of objects are familiar to the
player) in order to form a backdrop against which tension can be built, it
is the "non-ordinary" (i.e. objects that behave or are used in unexpected
ways) that comprise the memorable elements of the game.
What happens with the "physics" model approach to game engine development
(i.e. a game development system that relies on assimilating larger and
larger problem domains, rather than allowing for customization) is that
features of the system become standard fare and result in a whole spate of
games with those particular features (such as players who must eat and
sleep, for example) and authors begin to tire of these - because even the
most complex model then becomes a matter of combinatorial variation. Being
artists they will want to push the envelop, they will want to contravene the
form.
Obviously, on a system by system basis, the question of what puzzles/things
require custom coding is unfortunately a fruitless one. Any one system may
fully accommodate a problem domain, while a perusal of its implementation
will reveal areas where it is lacking, and hence a set of problems could be
devised (imaginal or real-world) that would lie outside the domain. For
instance, has any system yet assimilated the periodic table of elements? It
could be done... and yet!
But the issue of customization is a slippery one. To make my point clearer,
let's assume that the entire development system is written in an
object-oriented language, and consists of a set of objects or classes of
objects. Given that, what is commonly being argued against here is
customization of object behavior, while customization of object state has
been given the nod. So I pick a class (if the system is object-oriented) and
immediately begin modifying the state of the object (assigning it a name,
description, size, weight, and any other number of properties). I've
customized the library! Yet it is only when I begin to modify object
behavior (again if the system is object-oriented) that we begin to speak of
the evils of "hacking" the library, and it is this kind of modification that
is being discussed as "customization". Now, an author may have various
feelings about this kind of modification, and usually does - modification of
Chair behavior is usually viewed as more forgivable than modification of
Parser behavior, though strictly speaking an object is an object, and
behavior is behavior.
The implication is: Modify the states, but don't directly modify the
behaviors. If you want behavior change then do it through state change. That
would seem to necessitate the development of new classes / objects to
accommodate new behaviors, and the question then boils down to, who
implements these new objects: the game author or the library author? Does a
library author really want to police the system that much? Or run into the
inevitable game author's lament that the library doesn't support feature-x?
--Kevin
dgen...@hotmail.com
Kevin Forchione wrote:
> "Aidy" <Ai...@777.com.no.spam> wrote in message
> news:dh1a4t$k46$1...@news8.svr.pol.co.uk...
> >
> > of
> > puzzles/things that need custom programming to achieve?
>
> That, of course, depends on the development system you are using. Any system
> will have a certain problem domain that it can handle without customization
> (that's usually called "the library"). No library can anticipate all
> possible problems.
>
Kevin makes a number of excellent points about libraries and
development systems. I just wanted to add one additional thought, that
if a library is large enough to handle a huge range of authoring needs
without requiring custom programming, then there is a much higher
learning curve for the author to master all the possible uses of that
library. And once the author has learned the default properties of the
various types of chairs and potions and animals and doors available, at
that point they have leaned to use an authoring system which is as
complex as (no, more complex than) any of the currently popular systems
which still require some low level programming.
It is also important to define "programming". If a particular novelist
is not comfortable writing 'switch' and 'if-then' statements in their
game, is that same author going to be any more comfortable without
them, but now having to choose between a time_triggered_doorobj or an
event_triggered_doorobj, lised together in an elaborate maze of nested
pull-down windows?
Dave
Aidy
> Hmm. I think either you're missing the bigger picture here, or else
> this is just a disagreement over what "code" means.
When I said "code" I mean in the way that the likes of Inform etc work. Ie
you have to describe how the world works via the provided scripting
language. The game engine itself is largely "dumb" and the game creator
provides the steps to follow when certain actions are done.
The alternative to that, as I see it, is something more like ADRIFT (I
think, I don't know a lot about ADRIFT) when you simply "configure" the game
and the game engine then makes it all "work".
> Does that clarify the discussion at all?
I do agree that scripting systems like Inform will always be the most
flexible as you are not relying that the person who wrote the game engine
has anticipated your needs in advance. However there is certainly a market
for something in the middle, as the OP suggested. What probably puts many
people off trying their own game is the fact that they need to learn a
certain system's coding language, but the more "point and click" systems are
not flexible or powerful enough for what they need.
Aidy
> (i.e. a game development system that relies on assimilating larger and
> larger problem domains, rather than allowing for customization) is that
> features of the system become standard fare and result in a whole spate of
> games with those particular features (such as players who must eat and
> sleep, for example) and authors begin to tire of these - because even the
> most complex model then becomes a matter of combinatorial variation. Being
> artists they will want to push the envelop, they will want to contravene
the
> form.
I have to say I disagree to some extent. If you give the game engine the
responsibility for handling the real-world physics then you are giving the
game author a realistic game space without him having to code for it. And
as for many games then adopting those features, as long as the feature is a
positive one I can't see the issue.
Let's say a room has no natural light source yet the PC is carrying a light
source, the room should luminate. If the light is placed in an open drawer
the room should still be illuminated. If the drawer is closed the room
should go dark. By giving authors things like this out of the box you are
providing them with a good world simulator in which their PC lives. Why
constantly re-invent the wheel? If an object is flexible enough to be tied
to something, and longer than the room's length why should you have to write
code to allow the PC to take the end of the rope to another room and tie it
to something there?
One thing I *will* say is a downside to these things is that it is good to
give a nod to a player when they've done something that will advance the
game rather than they've done something just cos it is possible. If I was
playing a game that let me tie a rope to something I'd be bashing my brain
wondering how it is going to help me win. So it is vital that all
real-world behaviour is modyfiable. Just cos you *can* do something doesn't
neccessarily mean you should provide the player with the option to do it.
James Mitchelhill
<snip>
> I have to say I disagree to some extent. If you give the game engine the
> responsibility for handling the real-world physics then you are giving the
> game author a realistic game space without him having to code for it. And
> as for many games then adopting those features, as long as the feature is
> a positive one I can't see the issue.
The trouble is that this concentrates on the game, not the story. It's
easy to make realistic physics models - although it's much harder to come
up with sensible ways to describe it to the player and even more difficult
to come up with intuitive ways for the player to describe what they want
to do.
A physical simulation is not intrinsically interesting. In many cases a
full implementation will work against the author. A story hinges upon the
possibilities the author envisages. When the player can succeed with
something the author never thought of, it destroys any effect of pacing
the author may have intended. It also makes getting into unwinnable
situations a lot easier: If the player smashes the glass and uses a shard
to cut the rope that lowers the bucket, they may suddenly find that they
have nothing to put the water in.
I can see cases where physical simulation does make sense, but I don't
think that it's a good idea to incorporate it generally.
> Let's say a room has no natural light source yet the PC is carrying a
> light source, the room should luminate. If the light is placed in an open
> drawer the room should still be illuminated. If the drawer is closed the
> room should go dark. By giving authors things like this out of the box
> you are providing them with a good world simulator in which their PC
> lives. Why constantly re-invent the wheel? If an object is flexible
> enough to be tied to something, and longer than the room's length why
> should you have to write code to allow the PC to take the end of the rope
> to another room and tie it to something there?
It's not the ability of the player to do these things that counts, but the
interesting effects that this can have. The author will always need to
code this himself (because that's what interesting means in this context).
--
James Mitchelhill
ja...@disorderfeed.net
http://disorderfeed.net
Aidy
> easy to make realistic physics models - although it's much harder to come
> up with sensible ways to describe it to the player and even more difficult
> to come up with intuitive ways for the player to describe what they want
> to do.
Sure the game world doesn't make the game, no-one is suggesting it does.
But surely it is best to have a game world that understands all game
mechanics and can therefore say in which context the action is allowed,
rather than have a game engine that just frustratingly reiterates "you can't
do that"?
For example let's say the game engine understands what a kick is. This
allows you to kick anything, but as the game understands kicking you can
specify when "You shouldn't really kick that." or "You kick the object and
it triggers some action".
> If the player smashes the glass and uses a shard
> to cut the rope that lowers the bucket, they may suddenly find that they
> have nothing to put the water in.
That's what I'm getting at. By understanding the world you can apply rules
to all actions. If you don't want the player to cut the rope then you
configure that in.
James Mitchelhill
>> The trouble is that this concentrates on the game, not the story. It's
>> easy to make realistic physics models - although it's much harder to
>> come up with sensible ways to describe it to the player and even more
>> difficult to come up with intuitive ways for the player to describe what
>> they want to do.
>
> Sure the game world doesn't make the game, no-one is suggesting it does.
> But surely it is best to have a game world that understands all game
> mechanics and can therefore say in which context the action is allowed,
> rather than have a game engine that just frustratingly reiterates "you
> can't do that"?
I agree, but I don't think more advanced physics models necessarily help
that problem. As I see it, game and story are often at odds with each
other and the author's task is to combine the two so that the conflict
occurs in interesting ways. Introducing realistic physics, massively
increases the authorial burden. It's difficult enough for an author to
effectively anticipate the majority of player actions, even when the
author knows exactly what objects are available for use with every
command. If the behaviour of the game emerges from underlying game
physics, the author will have to anticipate interactions they never
intended.
A stock response is a stock response, whether it's "You tie the rope to
the tree" or "You can't do that." I'd argue that it's easier for an author
to make things interesting if they have to actively consider what actions
are effective.
Most responses in a typical work of IF are failure responses. There's a
limited number of actions that advance the story, but a huge number
of responses that don't. Even if it does nothing within the game, "Bark
rasps against hemp as you tie the rope around the tree, tiny flakes of
leafmold falling to the forest floor," is a lot more interesting than
simply being told you can do it.
Victor Gijsbers
> If an object is flexible enough to be tied
> to something, and longer than the room's length why should you have to write
> code to allow the PC to take the end of the rope to another room and tie it
> to something there?
The problem with this approach is that the author has to specifiy for
each object:
1. Whether it can be tied to something
2. Whether something can be tied to it
3. If it can be tied to something: how long it is
And for each room:
1. The size of the room
2. The distance to all other rooms accesible from it.
A complicated physics model will mean that the author MUST specifiy lots
and lots of information he would not normally bother with. An intricate
physics model will automatically mean an unwieldy language.
Greetings,
Victor
Aidy
> each object:
>
> 1. Whether it can be tied to something
> 2. Whether something can be tied to it
> 3. If it can be tied to something: how long it is
I don't see how that is a problem. Objects normally need a few
characteristics anyway, so what difference is a few more?
> 1. The size of the room
> 2. The distance to all other rooms accesible from it.
>
> A complicated physics model will mean that the author MUST specifiy lots
> and lots of information he would not normally bother with. An intricate
> physics model will automatically mean an unwieldy language.
Not really, again it comes down to configuration. If you don't care about
tying things to other things then you can just configure the game system
such that these things are not possible. Or if certain options are not
provided then they default to their "not possible" configuration.
Aidy
> increases the authorial burden.
Only if badly implemented. If there is a default "you can't do that"
mechanic in place unless you explicitly say such an action is possible, then
you still get a fail response but one that is relevant to the action you
attempted.
Victor Gijsbers
> I don't see how that is a problem. Objects normally need a few
> characteristics anyway, so what difference is a few more?
A few more makes little difference, although anything unnecessary can be
a nuisance. However, _every_ aspect of our physics that you wish to
incorporate adds a few things more. I, for one, do not relish the
thought of specifying for each item what its colume is, whether it can
be attracted by magnetism, whether it can conduct electricity, whether
things can be tied to it, and so on.
> Not really, again it comes down to configuration. If you don't care about
> tying things to other things then you can just configure the game system
> such that these things are not possible. Or if certain options are not
> provided then they default to their "not possible" configuration.
Instead of configuring the game system in order to take out everything
that it not relevant, it might be more convenient to load add-on modules
for things that _are_ relevant. This is just how Inform works.
Defaulting responses to the "not possible" configuration is not a very
good idea. "You cannot tie things around the tree." "The paper does not
burn." "The copper coin does no conduct electricity" - nah, better to
have no meaningful response than a false response.
In Inform, you must not forget to define 'container' or 'supporter' for
everything that is a container or a supporter. Forgetting this leads to
stupid answers in your game. If you have many attributes like this,
mistakes will be almost inevitable.
Greetings,
Victor
Aidy
> that it not relevant, it might be more convenient to load add-on modules
> for things that _are_ relevant. This is just how Inform works.
If something is missing then you make it the most prohibitive by default.
That way you don't have to do anything unless you want it to happen.
For example in my system all people have an "AcceptAnything" attribute which
is false by default. If you simply create a person that person won't accept
anything you give them and that is no code needed. If you supply the tag
and set it to True then they will accept what you give them. More commonly,
you set up the objects that the person *will* accept. So a person by
default will accept nothing, a person with a "WillAccept" tag will accept
what you define them to be interested in. You don't need to configure reams
of items
James Mitchelhill
At this point I'm somewhat baffled by what you're actually suggesting.
Especially since you said earlier:
> But surely it is best to have a game world that understands all game
> mechanics and can therefore say in which context the action is allowed,
> rather than have a game engine that just frustratingly reiterates "you
> can't do that"?
Also, most modern systems don't actually include a literal "you can't do
that" message. They tend to go with some variation on "I don't know
what you mean by VERB" or "VERBing the object doesn't seem to have any
effect" or "I don't know how to VERB the object."
Take touch, for example. Touching an object generally doesn't have any
untoward effects; there is no reason why the PC should be unable to do
this in most cases. So a failure message isn't a sensible solution. But
neither is it interesting to have a default "It feels like any other foo".
In fact, that message will discourage players from ever using touch as a
verb.
If an author implements "touch" it is desirable to have sensible
descriptions for every object. This is what I mean by massively increasing
authorial burden. And the situation worsens with every verb the physics
model requires. Functionality is a fine thing, but without it being
interesting in some way, it's pointless.
I'm assuming that you're suggesting something that goes beyond the
facilities provided by current systems. If not then my response probably
doesn't make much sense.
Adam Thornton
James Mitchelhill <ja...@disorderfeed.net> wrote:
>On Sun, 25 Sep 2005 21:43:03 +0100, Aidy wrote:
>> Sure the game world doesn't make the game, no-one is suggesting it does.
>> But surely it is best to have a game world that understands all game
>> mechanics and can therefore say in which context the action is allowed,
>> rather than have a game engine that just frustratingly reiterates "you
>> can't do that"?
>I agree, but I don't think more advanced physics models necessarily help
>that problem. As I see it, game and story are often at odds with each
>other and the author's task is to combine the two so that the conflict
>occurs in interesting ways.
And here's precisely where I disagree with Chris Crawford, and, largely,
with Aidy:
Simulationism is not interesting. At least not in IF.
It makes a great deal of sense in a CRPG; I'd say that Nethack is as
close of the pinnacle of an interesting purely-simulationist game as
there is. Crawford, of course, tries to extend the simulation to the
emotional state of actors and their concomitant action, which works,
kind of, if you're doing Greek Tragedy, but doesn't for much else.
Simulation is very much at odds with a plot-driven adventure, and
non-plot-driven-adventures are, I find, usually pretty boring.
Adam
Nikos Chantziaras
> Let's say a room has no natural light source yet the PC is carrying a light
> source, the room should luminate. If the light is placed in an open drawer
> the room should still be illuminated. If the drawer is closed the room
> should go dark. By giving authors things like this out of the box you are
> providing them with a good world simulator in which their PC lives.
Instead of worrying about puzzles based on real-world mechanics, I'm
more interested in parser-technology. Custom verbs, disambiguation,
indistinguishable objects, etc.
I think a system where everything in the game world can be set-up using
a GUI is indeed possible, even though (IMO) it will be much harder to
operate than a programming language[1]. But customizing the parser only
through a GUI? I have to see this.
[1] Why harder? Well, one example that comes to mind are non-static
descriptions. With a programming language, it's trivial to achieve
something like:
"Gandalf is wearing a <<gandalf.color>> robe. "
This trivial example might be hard to implement though a GUI, unless you
provide at least some basic scripting functionality.
Another example: suppose we have a button that changes color on each
turn (or in realtime). The door opens only when the button is pushed
while it's green. With custom programming, it's trivial:
if (button.color == green)
// Open the door
else
// Tell the player nothing happened
I could come up with hundreds of such examples, but I think you get the
idea. I'm not saying that a GUI wouldn't allow for such functionality,
mind you. It just seems harder to achieve it. With programming, I just
write down what I want. With a GUI, I would have to search for it
through large lists, pop-up menus and dialogs.
Mike Roberts
> James Mitchelhill <ja...@disorderfeed.net> wrote:
>>I agree, but I don't think more advanced physics models necessarily
>>help that problem. As I see it, game and story are often at odds with
>>each other and the author's task is to combine the two so that the
>>conflict occurs in interesting ways.
>
> And here's precisely where I disagree with Chris Crawford, and,
> largely, with Aidy:
>
> Simulationism is not interesting. At least not in IF.
>
I tend to agree, with the caveat that this is only true in a limited domain.
I'd claim that if you make a graph plotting goodness vs simulation
completeness, you get a curve that starts (with zero simulation, as in
CYOA-type games) at some middling goodness, rises briefly (you get more
goodness for better simulation), locally peaks somewhere not too far beyond
late-Infocom-level simulationism, then starts descending, and keeps
descending for a long, long ways. When you finally get out to the level of
simulation you get with a human GM, you get a sudden spike to high goodness.
Let me explain. The instinct that Aidy is following is that when players
try something that's reasonable, they want a reasonable response. They
don't want to be told "I don't know that verb" and they don't want "You
can't do that (just because I say so)." Aidy's instinct, I think, is that
adding more simulation will yield fewer of these, which is true as far as it
goes. The naive misconception is that this is always a net win. In the
experience of lots of people who've been at this a while (as seen in this
thread), there's a point of diminishing returns. The cost of added
simulation is that it creates more opportunities for bizarre, bug-like
responses that reveal the limits of the simulation - "Okay, the rope is now
tied to the quantity of water," or "It feels like an ordinary buzzing sound
to me." I think it's arguable that the existing systems have more or less
gravitated around a natural point of diminishing returns.
Now, if you can have simulation at the level of a human GM, everything is
suddenly good again. The system will do what the author wants, which is to
deny actions that aren't consistent with the story - but the system will do
it in a way that's acceptable to the player, which is to understand the
player's intentions properly and provide a good reason why the action is
denied (or, alternatively, why it's allowed but innocuous) - a reason that's
consistent with the player's common sense, with the setting, with the
characters and with the story. In principle, this is what everyone involved
in IF would ideally like; the problem is that it's not possible in practice
with foreseeable technology. It's a matter of controversy whether there's
another plateau of goodness beyond the current state of the art; there's
been a lot of speculation that there is, but no demonstrations.
--Mike
mjr underscore at hotmail dot com
James Mitchelhill
<snip>
> Now, if you can have simulation at the level of a human GM, everything is
> suddenly good again. The system will do what the author wants, which is
> to deny actions that aren't consistent with the story - but the system
> will do it in a way that's acceptable to the player, which is to
> understand the player's intentions properly and provide a good reason why
> the action is denied (or, alternatively, why it's allowed but innocuous) -
> a reason that's consistent with the player's common sense, with the
> setting, with the characters and with the story. In principle, this is
> what everyone involved in IF would ideally like; the problem is that it's
> not possible in practice with foreseeable technology. It's a matter of
> controversy whether there's another plateau of goodness beyond the current
> state of the art; there's been a lot of speculation that there is, but no
> demonstrations.
I'd agree with this, and I'm going to speculate some more (without
actually demonstrating anything, of course).
Increasing levels of simulation lead to decreases in abstraction. The
containment system common to most IF is a fairly abstract representation
of placement. The game doesn't care (or even provide for) where the
character is within a room, or (generally) which pocket the character is
carrying all his treasures in. Containment made abstract is much easier to
generate descriptions for than less abstract versions. The code can still
get quite complicated when there's nested containment, but it's easy to
generate.
The less abstract a simulation gets, the more difficult it is to generate
a description of the world. It's not impossible, but the amount of work it
takes soon becomes almost prohibitively big.
Example: The last (unfinished) game I worked on had snow. I got to the
point where I decided that as I'd described footsteps somewhere, I should
at least implement a basic simulation of tracks in the snow. As it was
snowing, these could disappear over time. Additionally, because they were
tracks they had to lead from one direction to another. And, there could be
multiple tracks in any one area.
The simulation quickly got out of hand. Actually coding the "physics"
behind it was simple enough, but generating the description of the tracks
in any area was a nightmare. And this was a case with a fairly limited
number of well-defined states. The majority of the code (which ended up
around 1000 lines for what amounted to a throw-away idea) was taken up
with generating a simple paragraph that read as if it had been written by
a human.
So, the problem with deep simulation is communicating less abstract
information to the player. The additional complexity does lead to the
possibility of bugs, but (especially with reasonably contained systems
that don't interact with much else) this is not an insurmountable problem.
The problem of authorial burden in supplying information about objects
could be relieved with a large enough database of standard objects
(where, for most objects, the author only has to define the differences
between their object and a 'standard' one). What is deeply problematic,
is the effort involved in generating human-like text.
I think this is the real obstacle to exploration of deep simulation.
There may be a solution to it, but I have no idea how that solution would
look and it's probably a long, long way off.
ems...@mindspring.com
Adam Thornton wrote:
> Simulationism is not interesting. At least not in IF.
> Crawford, of course, tries to extend the simulation to the
> emotional state of actors and their concomitant action, which works,
> kind of, if you're doing Greek Tragedy, but doesn't for much else.
Adam, you're singing my anti-song.
Here's my take. Simulationism is not in itself interesting in IF. It
becomes useful if and only if it provides the player with means of
expressing his intentions and interacting with the puzzles/story: so
that a simulation of NPC reactions, and a story that moves forward when
someone gets mad, might be reasonably effective. So can a puzzle where
the solution is to get rid of an item, and the player has an assortment
of physical means at his disposal.
This I think is the real problem with James Mitchelhill's snow -- were
the directions of the tracks in any way important to the way the player
was going to interact with the game? Did they tell him anything he
needed to know, or change anything important? Probably not; so it would
work just as well to say "Someone has left footprints in the snow," and
leave it at that.
Besides, complex simulation of systems that do not allow the player to
do anything interesting in the story/puzzles can be a distraction,
because he may spend the whole time (as noted upthread) tying ropes
into fifteen kinds of noose when he is supposed to be chatting up the
bartender, instead. (Yes, I know some people would enjoy tying up the
bartender, but let's not go there.)
Therefore, it's probably not useful to provide a complex base physics
library. The game model really does need to be tailored to each work.
Which is pretty much what you were arguing for yourself, I admit, but I
didn't like the way the argument was going en route.
I'm not going to start in on the nature of characters in tragedy.
James Mitchelhill
<snip>
> This I think is the real problem with James Mitchelhill's snow -- were the
> directions of the tracks in any way important to the way the player was
> going to interact with the game? Did they tell him anything he needed to
> know, or change anything important? Probably not; so it would work just as
> well to say "Someone has left footprints in the snow," and leave it at
> that.
Well, there was eventually going to be a point to it, although I did
overimplement. The game was set in a zoo and the animals were going to be
let out at some point. At certain points the PC would not want to meet
certain other characters and the tracks would have provided a nice way to
avoid that.
Since my last couple of games I've turned into a terrible completist. I
was going for deep implementation of everything in that game, trying to
implement an interesting response for every possible interaction. I still
think this is the way to go (for me at least), but it takes time. Then
again, I'm leaning towards games where exploration of the environment is a
major component. This may be one of the reasons I haven't released
anything for years. (That and the fact I actually enjoy programming
hideous complexity, so I tend to get distracted.)
> Besides, complex simulation of systems that do not allow the player to do
> anything interesting in the story/puzzles can be a distraction, because he
> may spend the whole time (as noted upthread) tying ropes into fifteen
> kinds of noose when he is supposed to be chatting up the bartender,
> instead. (Yes, I know some people would enjoy tying up the bartender, but
> let's not go there.)
Why ever not? There's always the possibility of Kallisti II: The Sequel
Nobody Wanted.
Ah. I seem to have answered my own question.
Aidy
> a GUI is indeed possible, even though (IMO) it will be much harder to
> operate than a programming language[1]. But customizing the parser only
> through a GUI? I have to see this.
What do you mean by customising the parser?
> [1] Why harder? Well, one example that comes to mind are non-static
> descriptions. With a programming language, it's trivial to achieve
> something like:
>
> "Gandalf is wearing a <<gandalf.color>> robe. "
>
> This trivial example might be hard to implement though a GUI, unless you
> provide at least some basic scripting functionality.
Defining the game via a GUI isn't the only way of doing things if you don't
supply a scripting language. My system is set-up via XML files. Sure you
could strap a GUI in front to make the more trivial object creations easier.
> Another example: suppose we have a button that changes color on each
> turn (or in realtime). The door opens only when the button is pushed
> while it's green. With custom programming, it's trivial:
>
> if (button.color == green)
> // Open the door
> else
> // Tell the player nothing happened
>
> I could come up with hundreds of such examples, but I think you get the
> idea. I'm not saying that a GUI wouldn't allow for such functionality,
> mind you. It just seems harder to achieve it. With programming, I just
> write down what I want. With a GUI, I would have to search for it
> through large lists, pop-up menus and dialogs.
Such a puzzle is also rather trivial with my system. I agree that
programming will always be better as you write what you want possible. I'm
just saying that it is surely possible to create a powerful enough IF system
that someone who doesn't want to learn a language can use to create decent
games.
Adam Thornton
James Mitchelhill <ja...@disorderfeed.net> wrote:
>Example: The last (unfinished) game I worked on had snow. I got to the
>point where I decided that as I'd described footsteps somewhere, I should
>at least implement a basic simulation of tracks in the snow. As it was
>snowing, these could disappear over time. Additionally, because they were
>tracks they had to lead from one direction to another. And, there could be
>multiple tracks in any one area.
Anyone remember something like this in one particular Graham Cluely
adventure? I think it was Quest for the Golden Wombat. In any event,
it had a maze which was mappable by determining how many times you'd
been somewhere, as visible by your tracks in the mud, which eventually
just got chewed into a big mess and was no longer useful except to say
"you've been here more than 5 (or some other smallish integer) times."
That was tons of no fun to play.
Adam
Richard Bos
> Let's say a room has no natural light source yet the PC is carrying a light
> source, the room should luminate. If the light is placed in an open drawer
> the room should still be illuminated. If the drawer is closed the room
> should go dark.
Guess what: Inform provides all this, in the standard library. You can
even make the drawer transparent and it still works correctly.
No, Inform doesn't come with a (nearly) full model of the physical
world, as you propose. Why not? Because experience has shown that only a
few aspects of physics (such as light; containment; and weight) both
make for playable puzzles, and are simple to generalise. It's no good
having a general model for some part of the real world if every program
using the system will either turn that model off, or have to rewrite 80%
of it anyway to suit that particular game. Much better to provide only
the generalisable 20% in the first place.
Richard
Richard Bos
> > The problem with this approach is that the author has to specifiy for
> > each object:
> >
> > 1. Whether it can be tied to something
> > 2. Whether something can be tied to it
> > 3. If it can be tied to something: how long it is
>
> I don't see how that is a problem. Objects normally need a few
> characteristics anyway, so what difference is a few more?
A few? Whether it can be tied to every single tieable object (a key
cannot be tied to a hawser, but can be tied to a string; a ship vice
versa). That in itself is hardly going to be simple. Then, if you want
to be complete, you'll want colour; reflectiveness, transparency and
translucency; whether it is gaseous, liquid or solid, and discrete or
fungible if solid; its density, and that numerically (does it float in
water? In olive oil? In air?); its precise physical dimensions (so you
can immerse a brick in two liters of water in a sink, but not in ten
liters of water spilled on the floor - and also so that you can drag a
chain behind you, and control where the ball on the other end is);
whether it's smooth, hairy, rough, sticky, you name it.
> > 1. The size of the room
> > 2. The distance to all other rooms accesible from it.
> >
> > A complicated physics model will mean that the author MUST specifiy lots
> > and lots of information he would not normally bother with. An intricate
> > physics model will automatically mean an unwieldy language.
>
> Not really, again it comes down to configuration.
Yes, but there's the rub. If it does, then the system itself must be set
up so that all these properties _can_ be configured. The systems author
must have thought of everything. With a truly programmable system, the
_game_ author can add properties he only thought of just now, and give
them precisely the behaviour he wants.
The advantage of a programming system over a configuration system is
not, as such, that you can inherently do more with it; it is that, if
the system itself does not allow you to do what you want, you can expand
it to do so.
Richard
Aidy
> cannot be tied to a hawser, but can be tied to a string; a ship vice
> versa).
Like most people you are tied up in the world of scripted IF and can't see
outside the box. In a realistic world you don't have to specify that every
object can tie itself to every object. The fact that an object is flexible
and that another object can have things tied to it is enough....you need do
no more and the game knows that the cord can be tied to the hook but not the
book.
> Then, if you want to be complete, you'll want colour; reflectiveness,
> transparency and
> translucency; whether it is gaseous, liquid or solid, and discrete or
> fungible if solid; its density, and that numerically (does it float in
> water? In olive oil? In air?); its precise physical dimensions (so you
> can immerse a brick in two liters of water in a sink, but not in ten
> liters of water spilled on the floor - and also so that you can drag a
> chain behind you, and control where the ball on the other end is);
> whether it's smooth, hairy, rough, sticky, you name it.
Yes, it would be great to have those things if a puzzle needs them. If it
doesn't you can leave them out and the world acts as normal.
> Yes, but there's the rub. If it does, then the system itself must be set
> up so that all these properties _can_ be configured. The systems author
> must have thought of everything. With a truly programmable system, the
> _game_ author can add properties he only thought of just now, and give
> them precisely the behaviour he wants.
The reality of that is that the programmed version constantly tells you "I
can't do that", whereas the configured system knows what you're trying to do
and intelligently caters for it.
> The advantage of a programming system over a configuration system is
> not, as such, that you can inherently do more with it; it is that, if
> the system itself does not allow you to do what you want, you can expand
> it to do so.
True, as I've said before.
Mike Roberts
>Richard Bos <r...@hoekstra-uitgeverij.nl> wrote:
>> (a key cannot be tied to a hawser, but can be tied to a
>> string; a ship vice versa).
>
> Like most people you are tied up in the world of scripted
> IF and can't see outside the box.
A bit of friendly advice - when you choose that kind of wording, you're
likely to make people think you're a troll. I almost did until I realized
telepathically that you were just doing some good-natured ribbing. At the
least, you're inviting equally condescending responses ("like most people
who've never actually built IF before, you have no idea what you're talking
about" - just a hypothetical example). I'm sure you'd much rather discuss
the merits of your ideas than get into that whole you're-a-troll/am-not
unpleasantness.
> In a realistic world you don't have to specify that every
> object can tie itself to every object. The fact that an object
> is flexible and that another object can have things tied to it is
> enough....you need do no more and the game knows that the
> cord can be tied to the hook but not the book.
I think you must have skipped over reading Richard's point - Richard was
pointing out a flaw in your model, and your answer merely reiterated the
model. Richard's point was that 'flexible' and 'tieable' attributes are not
adequate because they allow for nonsensical results that reveal the lack of
detail in the simulation model. The key will have to be declared tieable
because a piece of string can be tied to it; the hawser will have to be
declared flexible because it's basically a gigantic rope, and because it can
be tied to the battleship elsewhere in the game. But TIE HAWSER TO KEY is
nonsensical - for proper results, it has to respond "The hawser is too large
to fit through the hole in the key," but there's no provision for this in
your proposed attributes. Likewise, a player who successfully restrains the
battleship with a piece of dental floss will get a good laugh and then send
in a bug report.
To solve this problem in a simulationist fashion, you'd (minimally) have to
parameterize the type of tying that a tieable can engage in: is it bar-like
(how thick, then?) or eyelet-like (how big, then?) or hook-like (how large,
what radius of curvature?); and you'd have to parameterize the nature of the
flexibility: what's the minimum radius of curvature of flexing, how thick is
the object being flexed, how strong is it?
Or, you can take a non-simulationist approach and list the objects that can
be tied to the key, and those that can be tied to the ship. But that's not
an option in your realistic world, as you said.
And another thing: why *can't* the cord be tied to the book? In the real
world, if I have a long enough string, I most certainly *can* tie it to a
book: I do this by making a pair of loops around the outside of the book, at
90-degree angles to one another, as though I were tying a ribbon around a
gift box. Surely any sufficiently realistic simulation should handle this.
To parameterize this I really think you'll have to drop the whole idea of
tieability as a declared attribute, and replace it with a formula (built
into the system, of course, since there's no scripting) based on attributes
like the size, geometry, strength, and friction of the tieable object, and
by considering the different possible geometries that the string can assume,
based on the detailed flexibility parameters you had to add above. If you
find that the combination of the string and the other object can assume a
stable gift-box-ribbon configuration, then wrapping-type tying should be
allowed.
One more small detail: for sufficient realism, I should be also be able to
take my knitting needle object (which is declared as long and skinny and
pointy and with metallic strength about 5.7) and use it to make a hole in
the cover of the book (declared as cardboard, which only has strength 1.3),
which I can then use as an eyelet to tie the slippery cord to the book, even
though the slippery cord has friction too low to make a stable
gift-box-ribbon knot.
Somebody better stop me before I go on all night. Do you really, honestly,
still see no value in programmability?
Nikos Chantziaras
>> But customizing the parser only through a GUI? I have to see this.
>
> What do you mean by customising the parser?
New verbs. Imagine CALL. It could be used like this in the game:
>call for help
>call the police
>call george
>call 911
Seems difficult without custom programming. You cannot utilize the
system's "real world simulator" for CALL.
Or perhaps a simpler example, like TAKE: TAKE KEY vs. TAKE A SEAT.
>> "Gandalf is wearing a <<gandalf.color>> robe. "
>>
>> This trivial example might be hard to implement though a GUI, unless you
>> provide at least some basic scripting functionality.
>
> Defining the game via a GUI isn't the only way of doing things if you don't
> supply a scripting language. My system is set-up via XML files. Sure you
> could strap a GUI in front to make the more trivial object creations easier.
I had the impression your system involved IF-design using a GUI-only
interface.
Never mind. With XML-style "IF descriptional databases" (I just made
this term up), it could become even worse than with a GUI.
>> Another example: suppose we have a button that changes color on each
>> turn (or in realtime). The door opens only when the button is pushed
>> while it's green. With custom programming, it's trivial:
>>
>> if (button.color == green)
>> // Open the door
>> else
>> // Tell the player nothing happened
>
> Such a puzzle is also rather trivial with my system. I agree that
> programming will always be better as you write what you want possible. I'm
> just saying that it is surely possible to create a powerful enough IF system
> that someone who doesn't want to learn a language can use to create decent
> games.
Without seeing the system at work, we can only speculate about it. Who
knows; it might turn out to be actually working.
In any event, the common belief is that you cannot write programs
without using a programming language, and text adventures *are* programs.
Kevin Forchione
"Mike Roberts" <mj...@hotmail.com> wrote in message
news:LA2_e.7040$6e1....@newssvr14.news.prodigy.com...
> Somebody better stop me before I go on all night. Do you really,
> honestly, still see no value in programmability?
An excellent demonstration of the point of the practical limitations of
simulation, and one which brings us back to the earlier aspect of the
thread, that of the desirability of customizable and flexible development
systems.
--Kevin
Mark J. Tilford
Golden Wombat of Destiny, by Huw Collingborne?
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
Adam Thornton
Probably. Not sure why I thought it was a Cluley game.
Adam
James Mitchelhill
<snip>
...
> One more small detail: for sufficient realism, I should be also be able to
> take my knitting needle object (which is declared as long and skinny and
> pointy and with metallic strength about 5.7) and use it to make a hole in
> the cover of the book (declared as cardboard, which only has strength
> 1.3), which I can then use as an eyelet to tie the slippery cord to the
> book, even though the slippery cord has friction too low to make a stable
> gift-box-ribbon knot.
**********
Secret Plans For TADS 4 Revealed!
=================================
In a shock announcement today, Mike Roberts let slip top secret details
for the next generation of TADS, codenamed Poolhorn.
As TADS 3 has neared completion, speculation has grown about where the
popular IF design system can go next. Rumours have surged through the IF
community that the use of HTML for layout will be abandoned in favour of a
mixture of XML and troff. These new revelations only confirm the
suspicions of the community's more paranoid members.
An industry insider overheard Roberts speaking to an unknown associate
before making the posting. "Everything is a number," Roberts was heard to
say. "Text is dead. Number is king. All values must be declared in hex."
Our reporter caught a glimpse of a notebook the designer carried.
Unfortunately he was unable to gain access as his hands had only a
friction value of 0x3A, while the glossy cover of the notebook had a
slipperiness factor of 0x42. The edge of a loose leaf of notepaper was,
however hanging out at an angle of 0x2D degrees. Our reporter was able to
slip it from the notebook, but did not notice that the page had
the "sharp" attribute set and sustained a paper cut of severity 0xF. He
was, alas, unable to decipher any of the detailed notes, before passing
out through loss of blood caused by a bug in the library.
**********
(with deep apologies to Mike Roberts)
Ben Heaton
> > Instead of configuring the game system in order to take out everything
> > that it not relevant, it might be more convenient to load add-on modules
> > for things that _are_ relevant. This is just how Inform works.
>
> If something is missing then you make it the most prohibitive by default.
> That way you don't have to do anything unless you want it to happen.
The most prohibitive response for a command is something along the lines
of Inform's "That's not a verb I recognize." Anything else makes
assumptions that may not be valid.
Well, OK, Inform does make the assumption that the word it didn't
understand was a verb, but that's a different sort of matter.
>noun
That's not a verb I recognize.
-Ben Heaton
--
No sale, honcho!
Aidy
honestly,
> still see no value in programmability?
Given that I have already aswered to the contary at least twice already I'll
refrain from doing so again :)
I am merely pointing out that depending on the design you can still provide
non-programmers with a relatively powerful and flexible way of creating IF.
Jess Knoch
> My system is set-up via XML files.
> Such a puzzle is also rather trivial with my system. [...]
> I'm just saying that it is surely possible to create a
> powerful enough IF system that someone who doesn't want to learn a
> language can use to create decent games.
What does XML stand for again?
--
Jess K., who is trying really hard to make sense of Aidy, but failing.
Aidy
*sigh*
"Jess Knoch" <jessic...@mindspring.com> wrote in message
news:3ptcbsF...@individual.net...
Jess Knoch
> I meant programming language as well you know.
>
> *sigh*
Honestly, I didn't know. I *still* don't know what you're getting at. All I
see is contradictions in what you're saying. I'll go back to letting
everyone else argue with you instead.
--
Jess K., who doesn't like top-posting.
James Mitchelhill
> Aidy wrote:
>> My system is set-up via XML files.
> [snip]
>> Such a puzzle is also rather trivial with my system. [...] I'm just
>> saying that it is surely possible to create a powerful enough IF system
>> that someone who doesn't want to learn a language can use to create
>> decent games.
>
> What does XML stand for again?
eXtensible Markup Language
It's a mark-up language with the same ancestry as HTML, but where HTML
marks-up hyptertext, XML can be used to mark-up anything (because it's
extensible).
HTML is itself moving towards an XML format, which is known as XHTML.
See: <http://www.w3.org/XML/>
And also: <http://en.wikipedia.org/wiki/XML>
(Aidy's response to you downthread seems to have resulted from him
assuming you were pointing out that XML is itself a language which would
need to be learnt in his system.)
Jess Knoch
Thank you!
Rikard Peterson
"Ben Heaton" wrote in
news:Pine.GSO.4.58.05...@mail1.ats.rochester.edu:
> Well, OK, Inform does make the assumption that the word it didn't
> understand was a verb, but that's a different sort of matter.
>
>>noun
> That's not a verb I recognize.
"Noun" is not a verb I recognize, either. ;)
Kevin Forchione
news:dh8nt3$p3i$1...@news7.svr.pol.co.uk...
<snip>
> I'm
> just saying that it is surely possible to create a powerful enough IF
> system
> that someone who doesn't want to learn a language can use to create decent
> games.
Certainly. I suspect that this bunch here could turn out some decent games
using the system you've developed. Where can we find it?
--Kevin
Aidy
> using the system you've developed. Where can we find it?
It's just on my hard drive at the minute :) I still have a few things to
implement and polish off so it isn't finished.
ems...@mindspring.com
James Mitchelhill wrote:
> On Sun, 25 Sep 2005 23:20:40 -0700, emshort wrote:
>
> <snip>
> > This I think is the real problem with James Mitchelhill's snow -- were the
> > directions of the tracks in any way important to the way the player was
> > going to interact with the game? Did they tell him anything he needed to
> > know, or change anything important? Probably not; so it would work just as
> > well to say "Someone has left footprints in the snow," and leave it at
> > that.
>
> Well, there was eventually going to be a point to it, although I did
> overimplement. The game was set in a zoo and the animals were going to be
> let out at some point.
Aha. Well, that sounds potentially cool -- I was perhaps misled by your
phrasing of "throw-away feature" (or something like that) in the
original post.
> Since my last couple of games I've turned into a terrible completist. I
> was going for deep implementation of everything in that game, trying to
> implement an interesting response for every possible interaction. I still
> think this is the way to go (for me at least), but it takes time.
I guess I'd say: deeply implement the stuff that matters to the
interaction. But of course it's possible to define "stuff that matters"
very broadly.
Kevin Forchione
news:1127961701.4...@g44g2000cwa.googlegroups.com...
> I guess I'd say: deeply implement the stuff that matters to the
> interaction. But of course it's possible to define "stuff that matters"
> very broadly.
There are certainly interesting levels of abstraction that can be done. For
instance, in one of my wips I've got an actor who "hears" the knocking of a
door and can react to it. What this means is that when the player types:
<<knock on door>> a "sound event" is created that is associated with the
door. Actors that are able to listen to sound events can then perceive the
knocking and respond to it in various ways. An actor might even instruct
another actor to answer the door, or may choose to answer it or ignore it.
Traditionally, the usual way to implement this kind of behavior was to
capture the action in either the actor and have it react, or more crudely,
in the door, in which case the actor's responses were simply displayed text
that was actually part of the door code. But the sense events (implemented
in TADS 3) provide a level of abstraction. The door receives the
knock_action and produces a sound_event. The sound event is associated with
the door and persists for a single turn. If an actor capable of detecting
the sound_event does detect it, then that actor may respond to the
sound_event.
In this respect simulationism doesn't facilitate the story, per se (although
one might argue that having classes of actors who can respond to
sense_events could add atmosphere). But it does provide an extra level of
complexity to the way the program is coded so that an actor is not actually
responding to an action directly, but to an event caused by that action and
whose detection is governed by the scope/sense model of the library. Would a
player appreciate this added level of abstraction? Probably not because the
effects could be duplicated, albeit tediously, by other means. The benefit,
then is to the author, who can now concentrate on the reactive responses of
actors to various stimuli, rather than to the coding of the mechanics
involved in extracting this information from lower-level object
interactions. It might even be possible to generalize these responses into
classes so that a kind of default plug-in response repertoire for sensing
actors with specialized responses for "interesting" events based on the
character of the actor or the requirements of the narrative.
But would the player appreciate these sophistications of simulation? And
would they really add anything to the player's experience of the game?
Maybe. Would this level of sophistication be of assistance to the
development of games by novice writers? You're talking about an author who
would have to become familiar with the "biology" of the abstraction, which
is several levels beyond simply "If I knock on the door, then display ....".
It's still a lot of fun to play with, though!
--Kevin