Infocom commands
Mikael
not satisfied with the existing text adventure creation systems. On the one
hand there is TADS and Alan which are too simplistic, on the other hand
there is Inform which is so complex that it's almost a computer language in
it's own right. Why learn a new language when I'm allready well versed in C?
The other reason is that writing a text adventure in C gives the author
total control over his/hers creation.
The final, and most important, reason is that I enjoy programming in C.
Thanks for the tip on the Inform library.
Regards
Michael Lonc
Joe Mason <jcm...@uwaterloo.ca> skrev i
diskussionsgruppsmeddelandet:DrXo4.29520$45.17...@news2.rdc1.on.home.com..
.
> Mikael <018-4...@telia.com> wrote:
> >I'm writing a text adventure game in C. I've come across a problem with
> >verbs/commands. What verbs/commands should I use? I figured the best
> >solution would be to copy the commands that are used in Infocom games.
> > Does anyone have a list of them?
>
> First, discussion of writing games (rather than playing) goes on
> rec.arts.int-fiction. (Followups set.)
>
> Second, unless you're doing it in C for a reason (like you really, really
want
> to write a parser), you should use one of the existing text adventure
creation
> systems, like Inform, TADS, Hugo, or Alan.
>
> Third, Infocom changed the commands used from game to game. For a good
> "generic" list of commands, see the Inform standard library at
>
> ftp://ftp.gmd.de/if-archive/programming/inform6/library/grammar.h
>
> Joe
Gabe McKean
but the defaults for everything, your options are fairly limited. But TADS
is highly extensible. Once you learn enough, you have almost as much
control over it as you would if you were writing your own parser. I'm sure
the same is true of Inform and Hugo and some other languages, though I
haven't really used them for much. As for why you would want to learn a new
language for writing text games, I would think it would be much easier to
learn a pre-existing high-quality parser language than it would be to write
your own high-quality parser.
Stephen Granade
> The reason I've decided to write a text adventure "from scratch" is that I'm
> not satisfied with the existing text adventure creation systems. On the one
> hand there is TADS and Alan which are too simplistic, on the other hand
> there is Inform which is so complex that it's almost a computer language in
> it's own right. Why learn a new language when I'm allready well versed in C?
> The other reason is that writing a text adventure in C gives the author
> total control over his/hers creation.
The following is more for informational purposes than to try to stop
you from your chosen project. TADS, Inform, Alan, Hugo and the like
are Turing-complete languages, and are truly computer languages in
their own right. The answer to the question "why learn a new language"
is the same as to "why learn C if I know assembler?" Namely: there are
tools which are better suited to certain jobs, as anyone who has tried
to drive a nail with a potato peeler might tell you.
Stephen
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Visit About.com's IF Page
Duke University, Physics Dept | http://interactfiction.about.com
Mike Roberts
> Using task-specific tools can sometimes be counterproductive,
> they prevent a deeper understanding of the subject.
That depends on what subject you want to understand. If you write a game of
any substance, you'll find that none of the major IF systems will keep you
from learning all about the design and implementation of a simulation world
model. The systems will furthermore do nothing at all to reduce your
exercise of the technical skills of developing plot, setting,
characterization, suspense, pacing, revelation, narration, and puzzles.
None of the major systems could be considered a crutch that lets an
unskilled author create a good game.
The things the systems will do automatically for you include serializing and
unserializing game state, formatting text into lines and paragraphs nicely
broken at word boundaries and sized to fit different types of displays,
providing portability to numerous types of computers, managing memory,
interacting with the local operating system's user interface, implementing
high-level datatypes, and decomposing complex declarative structures.
Now, I'd be the last person (or quite nearly, at least) to disparage the
merits of building all of this stuff yourself. I happen to find a lot of
these low-level details rather interesting. But they are by themselves not
particularly related to IF; an understanding of object serialization is not
sufficient for writing good interactive fiction, and it isn't necessary,
either. So don't think you'll understand IF better if you write your own
state-saving code; you'll just understand state saving. Furthermore, these
sorts of things can be pretty time-consuming (they have been for me,
anyway); so if the literary aspects are what interest you, you're going to
learn more using a specialized IF system, because it will give you a lot
more time to spend on developing the deeper understanding that you seek. If
it's data structures and Windows API's that interest you, though, you should
certainly head straight for C++.
--Mike
Stephen Granade
> If I understood you correctly what you're saying is that there is a specific
> tool for solving every problem. If I wan't to drive a nail I should
> preferably use a hammer.
Yes.
> If I wan't to write a text adventure I should use
> an existing text adventure creation system instead of a computer language
> devised for more general purposes.
No.
I trust I have confused people now. :)
It depends on your aim. If your aim is merely to create a text
adventure, and you're not much interested in the details of creating,
say, a parser, then you should use a text adventure language. You seem
to be interested in how text adventures are put together on the most
basic level, though. In that case, then using a text adventure
language is not the best tool.
> It is however my experience that the easiest solutions are not always the
> best ones. It's better to learn arithmatics the "hard way" by understanding
> it's rules and the logic it is founded on than simply save time and effort
> by using a pocket calculator.
Yes. The question becomes, how far back do you stop in recreating
something other people have done already? That is something each
person has to answer. Clearly you have chosen to go back further than
others.
Mikael
tool for solving every problem. If I wan't to drive a nail I should
an existing text adventure creation system instead of a computer language
devised for more general purposes.
best ones. It's better to learn arithmatics the "hard way" by understanding
it's rules and the logic it is founded on than simply save time and effort
by using a pocket calculator.
crude tools not suited for such a complex task as creating Interactive
Fiction. Far from it. They are just as well suited for their task as a
pocket calculator is suited for dividing integers. Using task-specific tools
can sometimes be counterproductive, they prevent a deeper understanding of
the subject.
computer language, I think I can say with confidence that the difference
between assembler and C is of an entirely different magnitude than the
difference between C and Inform. Comparing C with assembler is
underestimating the power and versatility of C.
I just hope my attempt to write a text adventure in C will be more
sucessfull than "driving a nail with a potato peeler".
Regards
Michael Lonc
Stephen Granade <sgra...@login1.phy.duke.edu> skrev i
diskussionsgruppsmeddelandet:jd7lgbe...@login1.phy.duke.edu...
> The following is more for informational purposes than to try to stop
> you from your chosen project. TADS, Inform, Alan, Hugo and the like
> are Turing-complete languages, and are truly computer languages in
> their own right. The answer to the question "why learn a new language"
> is the same as to "why learn C if I know assembler?" Namely: there are
> tools which are better suited to certain jobs, as anyone who has tried
> to drive a nail with a potato peeler might tell you.
>
Evin Robertson
Stephen Granade <sgra...@login1.phy.duke.edu> wrote:
> The following is more for informational purposes than to try to stop
> you from your chosen project. TADS, Inform, Alan, Hugo and the like
> are Turing-complete languages, and are truly computer languages in
> their own right.
Actually, I'm pretty sure that despite its name, Alan isn't Turing
Complete. Without a jump backwards opcode or recursion (or infinitely
large game files), you can't perform loops without knowing in advance
the maximum loop count. This makes many things annoying and some
things impossible.
And if you're doing complicated non-IF-like parsing, TADS probably
isn't your best bet. Yes, the latest version makes this situation
better, but now even though most stuff is possible, a lot of it is a
pain.
If you're dealing with complex data structures or dynamic memory
allocation, Inform is extremely annoying. And it could take a lesson
or two on syntax sanity from C.
But yes, the benefits of portable game files and having a parser and
game model already written usually outweigh the disadvantages of the
existing IF systems in most IF situations.
Sent via Deja.com http://www.deja.com/
Before you buy.
Jake Wildstrom
Mikael <018-4...@telia.com> wrote:
>If I understood you correctly what you're saying is that there is a specific
>tool for solving every problem. If I wan't to drive a nail I should
>preferably use a hammer. If I wan't to write a text adventure I should use
>an existing text adventure creation system instead of a computer language
>devised for more general purposes.
Well, there are degrees of usefulness. We had the same analogy discussioon
with Chris "Erasmatazz" Crawford a while ago, with r*if's readership taking the
completely opposite viewpoint.
Nobody objects to your right to use whatever languae you want. I don't think
any of us have the right to say "you shouldn't use C--use an IF language".
What we're saying is that you're likely to be _happier_ with an IF language.
There are several specific ways in which IF languages are likely to work
better:
* More advanced parser. Writing your own parser is a thankless, tedious job,
and while you could probably write a decent one, the models behind all
Big Four IF languages are quite sopisticated. Writing a parser which
won't lose on "pick up all the apples but the green one and the orange
then go ne" is really tough, and if you want to focus on your actual
game, its unlikely you'll develop such a full-featured parser.
* Portability. C code is portable. Its binaries aren't. 'Nuff said.
* Object-based world-model. IF is made for "objects", since it's full of
items, rooms, etc. all of which it makes sense to model as "objects".
You could do this in C++, and a pretty good facsimile thereof in C, but
why reinvent the wheel.
+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into |
| theorems. -Paul Erdos |
+-------------------------------------------------------------+
| Jake Wildstrom |
+-------------------------------------------------------------+
Andrew Plotkin
> To be perfectly honest with you I'm too lazy to learn a new language. And
> why should I? There is nothing one can do using Inform that one can not do
> using C.
It is easier to learn Inform than to write an equivalently powerful game
engine yourself. That's why.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
mathew
> I'm not trying to imply that all the text adventure creation systems are
> crude tools not suited for such a complex task as creating Interactive
> Fiction. Far from it. They are just as well suited for their task as a
> pocket calculator is suited for dividing integers. Using task-specific tools
> can sometimes be counterproductive, they prevent a deeper understanding of
> the subject.
So if I understand correctly: You're implementing the adventure in C
because you're more interested in learning how to write parsers, text
compression, string handling, list manipulation, memory allocation, disk
swapping, fake object orientation and the like in portable C, than you
are in actually producing an adventure game?
That's fine, but it's good to be clear about that up front before asking
for suggestions.
> Without turning this discussion into a dispute over what is the best
> computer language, I think I can say with confidence that the difference
> between assembler and C is of an entirely different magnitude than the
> difference between C and Inform. Comparing C with assembler is
> underestimating the power and versatility of C.
Power, maybe; versatility, no, because you can do more things in
assembler than you can do in C.
The point is that there are a number of basic features that make it
vastly, hugely easier to write an adventure game: object orientation,
strings and lists as first class data types, built in parsing, automatic
memory management, transparent data compression, object persistence, and
so on. C has none of those features, so you'll have to re-invent all
those wheels before you even get started on the actual game.
Compared to spending a weekend learning a new language, that's not a
sensible use of time if your goal is the game, rather than the knowledge
of how to code stuff in C.
mathew
Thomas Galen Ault
Jake Wildstrom <wil...@mit.edu> wrote:
> * More advanced parser. Writing your own parser is a thankless, tedious job,
> and while you could probably write a decent one, the models behind all
> Big Four IF languages are quite sopisticated. Writing a parser which
> won't lose on "pick up all the apples but the green one and the orange
> then go ne" is really tough, and if you want to focus on your actual
> game, its unlikely you'll develop such a full-featured parser.
Just one nitpick. Writing a parser that correctly parses "pick up all the
apples but the green one and the orange one then go ne" is "really tough"
only for someone who hasn't had any formal training in text parsing
techniques. Although I've only looked at Inform and TADS, from following
the parser discussions here in r.a.i-f, I can say that the parsing systems
in the current generation of adventure authoring tools are pretty trivial
compared to the state-of-the-art parsers in natural-language and speech
understanding systems. This isn't to look down on the parsers in Inform,
TADS or the like, or depreciate the effort put into them by their authors,
but to place them in their proper perspective. A lot of research has
been done on parsing over the years and it might be a good idea to
go down to the local University library and read a book or two on the
subject before starting any parser project.
Tom Ault
SteveG
On Fri, 11 Feb 2000 21:35:45 GMT, "Mikael" <018-4...@telia.com>
wrote:
>The reason I've decided to write a text adventure "from scratch" is that I'm
>not satisfied with the existing text adventure creation systems. On the one
>hand there is TADS and Alan which are too simplistic on the other hand
>there is Inform which is so complex that it's almost a computer language in
>it's own right.
This is the first time I've seen TADS and Alan put in the same
"simplistic" basket. I don't think this is very fair to either system.
I think Alan is simple (but not simplistic--I'd argue instead that it
is tightly focussed on its target 'problem space.') I'd recommend it
to beginning programmers and writers.
TADS, on the other hand, is far from being either simple or
simplistic. In fact, I'd recommend it to someone who wants to write a
good text adventure and who also enjoys programming in C. Its true
that the TADS system has simple features for creating the basics of a
text adventure. However a C programmer who is not afraid to write
their own functions and get into the depths of the TADS system will
find that they have enormous power and flexibility to produce any sort
of text game features that they require. Also TADS is a nice, friendly
introduction to the concepts of object-orientated programming which a
C programmer may enjoy more than first encountering OOP when faced
with an urgent task to be done in C++, (for example.)
>Why learn a new language when I'm allready well versed in C?
I found that knowing a bit of TADS helped when I wanted to write
software in C. I imagine the reverse would also be true. Using TADS
(or the similarly powerful, but differently flavoured, Hugo or Inform)
to write text games is not a waste of one's C programming experience
but rather a sensible way to use that experience and at the same time
to benefit from other programmers' design-thinking and experience in
the text game field and, furthermore, a way to avoid the drudgery of
re-inventing the dull, black and oily bits required in any text game
machine.
>The other reason is that writing a text adventure in C gives the author
>total control over his/hers creation.
>The final, and most important, reason is that I enjoy programming in C.
You'll enjoy programming in an IF language too!
If you remain unconvinced then by all means do it C - that's perfectly
valid way of having fun too!
I think there's some source code for text adventures written in C at
the IF Archive - ftp.gmd.de/if-archive/ - take a look at that code and
perhaps at the C code and language libraries for some of the existing
systems for ideas.
[snip]
--
SteveG
(Please remove erroneous word from address if emailing a reply)
Magnus Olsson
Thomas Galen Ault <tom...@cs.cmu.edu> wrote:
>Just one nitpick. Writing a parser that correctly parses "pick up all the
>apples but the green one and the orange one then go ne" is "really tough"
>only for someone who hasn't had any formal training in text parsing
>techniques. Although I've only looked at Inform and TADS, from following
>the parser discussions here in r.a.i-f, I can say that the parsing systems
>in the current generation of adventure authoring tools are pretty trivial
>compared to the state-of-the-art parsers in natural-language and speech
>understanding systems.
The parsers themselves are quite simple. Inform's parser even cheats :-).
The difficult problem really isn't parsing, but disambiguation and
scoping. IF terminology is a bit sloppy in including these in
"parsing".
>A lot of research has
>been done on parsing over the years and it might be a good idea to
>go down to the local University library and read a book or two on the
>subject before starting any parser project.
Good advice.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Larry Smith
Andrew Plotkin <erky...@eblong.com> wrote in message
news:8846eu$lco$3...@nntp8.atl.mindspring.net...
> Mikael <018-4...@telia.com> wrote:
> > To be perfectly honest with you I'm too lazy to learn a new language.
And
> > why should I? There is nothing one can do using Inform that one can not
do
> > using C.
>
> It is easier to learn Inform than to write an equivalently powerful game
> engine yourself. That's why.
I concur. As has been said, "Just because it's possible to push a pea up a
hill with your nose, doesn't mean that's the best way to get it there!"
Thomas Galen Ault
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>The parsers themselves are quite simple. Inform's parser even cheats :-).
>
>The difficult problem really isn't parsing, but disambiguation and
>scoping. IF terminology is a bit sloppy in including these in
>"parsing".
Even here, I'd hesitate to call the disambiguation and scoping problems
encountered by today's IF systems "difficult." An IF parser has
complete knowledge of the world state, needs to recognize only a limited
vocabulary and (relatively) simple sentence structure, and doesn't
need to make use of common-sense knowledge. Under these conditions,
scoping and disabiguation are relatively simple compared to the
conditions under which a natural language understanding system must
work. Parsing for an IF system, including disambiguation and scoping
issues, just isn't all that difficult *if you know what techiniques that
have already been developed to address these problems*. On the other hand,
it is difficult if you start from scratch, without the benefit of the
work of others, which is why I recommended...
>
>>A lot of research has
>>been done on parsing over the years and it might be a good idea to
>>go down to the local University library and read a book or two on the
>>subject before starting any parser project.
>
>Good advice.
>
For natural-language parsing, I recommend "Natural Language Understanding"
by James Allen (Bejamin/Cummings Publishing Co.).
Magnus Olsson
Kevin Forchione <Lys...@email.msn.com> wrote:
>"Magnus Olsson" <m...@bartlet.df.lth.se> wrote in message
>news:889t0d$ao2$1...@bartlet.df.lth.se...
>> The parsers themselves are quite simple. Inform's parser even cheats :-).
>
>but I haven't studied the parser in enough detail to know how it is
>cheating.
Well, "cheating" may be a bit strong, but Inform's parser doesn't do a
complete parse of the input sentence, and it stops considering grammar
rules once it's found one that matches the input - so if the input is
ambiguous and matches two rules, it only finds the first one. This
can be considered a feature or a bug depending on the circumstances
:-).
Magnus Olsson
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>In article <88ccnf$ahg$1...@cantaloupe.srv.cs.cmu.edu>,
>>encountered by today's IF systems "difficult."
(...)
>OK. I really meant that it was a lot of work to get right, not in
>the sense of "a difficult research problem". An analogy: finding
>the prime factor of a moderately large integer with pen and paper
>isn't a difficult problem in the sense that it requires only that
>you can perfomr division.However, it involves a lot of work.
>
Ouch. That was a *really bad* analogy. The downside of reading news
late at night, I suppose :-). I'll be back on the subject.
Iain Merrick
> If you really want to have the fun of implementing
> IF from scratch, rather than using an existing IF
> system, the language I'd recommend you use is
> Python. It's a very nice dynamically-typed object
> oriented language that ought to be excellent for
> developing an IF code library. Also, it runs on
> all the major current-day platforms, so whatever
> game you come up with will be nearly as portable
> as an Inform/Tads/Alan game.
Yes, Python would be a pretty good choice -- although it might be tricky
to implement UNDO neatly. Any new system worth its salt ought to have
efficient multiple UNDO, I reckon; otherwise you might as well use T3 or
Glulx.
Someone said they were working on a Python IF library a while back. I
forget who it was, sorry. Any news on how that's coming along?
--
Iain Merrick
i...@cs.york.ac.uk
Magnus Olsson
Iain Merrick <i...@cs.york.ac.uk> wrote:
>Someone said they were working on a Python IF library a while back. I
>forget who it was, sorry. Any news on how that's coming along?
Are you referring to PAWS? The author's home page is at
<http://w3.one.net/~wolf/PAWS.htm>.
And then there's the Python Universe Builder at
<http://www.strout.net/python/pub/index.html>, which has been around
for a couple of years.
wo...@one.net
Hi Iain:
>Yes, Python would be a pretty good choice -- although it might be tricky
>to implement UNDO neatly. Any new system worth its salt ought to have
>efficient multiple UNDO, I reckon; otherwise you might as well use T3 or
>Glulx.
>
>Someone said they were working on a Python IF library a while back. I
>forget who it was, sorry. Any news on how that's coming along?
I'm currently working on 0.5 alpha, the version that finally
implements save/restore. I'm currently fighting a bug in the Python
shelve routine but it looks as though the folks at comp.lang.python
may have some answers to that soon.
There is no undo in PAWS, because A) I never thought to put one in,
and B) I find the idea of undo sort of "cheating" (just my opinion.
:))
Other than that (and a couple of small syntax errors) 0.4 alpha is
nearly feature complete, it even includes 2 manuals (Word 2000 format,
I think Word 97 can read them). I can also supply HTML or RTF
documents if anyone's interested.
PAWS comes with a Universe, a library somewhere between adv.t and
Worldclass.t in features. The whole engine/library's about 10k lines
of code, plus an incomplete sample game of about 3k lines.
The whole package is aimed at new game authors who are a bit code-shy,
so it's about 70% comments! :)
If you want to download a copy it's located at:
http://w3.one.net/~wolf/PAWS.htm
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
Magnus Olsson
Iain Merrick <i...@cs.york.ac.uk> wrote:
>Magnus Olsson wrote:
>> Why would it be more difficult to implement undo in Python than in
>> a different language?
(...)
>Well, it is a VM issue. T3 and Glulx both have built-in support for
>UNDO; most other VMs don't, including (I assume) the Python one. Native
>machine code doesn't have UNDO support either, although it might be
>possible with hairy VM tricks on some operating systems. (VM as in
>Virtual Memory that time. Cluttered namespace, sigh.)
>
>If your VM has specific support for object-orientation but not UNDO,
>things could get rather fiddly. You'd have to explicitly copy the entire
>game state every turn, or wrap all your OO calls up in little routines
>which track which objects have changed and so on.
One thing that strikes me is that you're going to have basically the
same problems with save/restore as with undo. So if you've implemented
save/restore, couldn't you just make an auto-save (to a RAM buffer if
you don't want a lot of disk writes) after each move, and let the undo
command just do a restore from that buffer?
But this, of course, raises the question of how to implement
save/restore.
If your run-time (VM or memory management system in a native-code
model) supports dumping the whole game state to disk, then the
problem's basically been solved for you.
But what if you're not that lucky?
In a non-OO system, you can "centralize" the game state into a small
number of data structures. My own game "Dunjin" has, let's see, one
bug "travel table" with the list of exits for each room, one location
table with the location of every object, and one array of flags, one
array of timers, and that's about it - saving and restoring simply
means writing or reading those tables to disk. The disadvantage is
that the code is pretty unreadable; instead of Inform's
if (living_room.n_to == bedroom) {
move apple to bedroom;
give player hungry;
}
you get the Pascal code
if exits[23, 1] = 24 then begin
location[45] := 24;
flags[15] := true;
end;
(well, Dunjin is actually a _little_ more OO in that it's really
"rooms[23].exits[1]" and so on, but there's still an awful lot of
numeric constants).
In an OO program, however, game state is spread out over lots and lots
of objects.
One way of implementing save would be to give each object a save
method, which writes all state information for that object to a file,
register all objects in some central registry, and let the save method
call each object's save method. In a language such as C++, this is a
lot of work, since you'll have to implement the save methods for
each object by hand. (You can do what we have done at work and write
a supporting system that reduces this chore to a few macro definitions
for each class, but it's still a lot of work). It's much simpler in
an OO language with a proper metaclass and type information system.
In C++, you could also rewrite the new and delete operators so that
all your game objects end up in a memory buffer that can be saved
and restored - then you get something similar to the Z-code VM's
way of handling this.
But what I'd like to know is: How have you people out there who
are writing IF in C, C++, Basic, Python, whatever, solved these
problems?
Richard Bos
> if exits[23, 1] = 24 then begin
> location[45] := 24;
> flags[15] := true;
> end;
>
> (well, Dunjin is actually a _little_ more OO in that it's really
> "rooms[23].exits[1]" and so on, but there's still an awful lot of
> numeric constants).
Not that this has anything to do with IF, but doesn't your compiler
allow you to define manifest constants (something like C's
#define troll_room 14)?
Richard
Magnus Olsson
Yes, it did (past tense since were talking about Turbo Pascal 3.0),
and it would have simplified things a lot if I'd thought of it at the
time. However, I would still have had to maintain a huge set of
constant declarations by hand.
wo...@one.net
Hi Magnus,
>One thing that strikes me is that you're going to have basically the
>same problems with save/restore as with undo. So if you've implemented
>save/restore, couldn't you just make an auto-save (to a RAM buffer if
>you don't want a lot of disk writes) after each move, and let the undo
>command just do a restore from that buffer?
Save/Restore is actually a lot different from Undo. In a save/restore
you're saving the entire game state, in effect the values of all
variables. In an undo you're saving the "state delta" of a limited
number of moves. Undo therefore would almost certainly not use the
same techniques as save/restore.
>But this, of course, raises the question of how to implement
>save/restore.
In Python we have a lovely little module called "shelve" that will
automagically save an object's state, and the state of any objects
that relate to the object in some manner. At least that's the theory,
right now the PC version of Python seems to have some bugs in shelve.
:(
Ah, well, the problem's being traced so shelve will soon be debugged.
L. Ross Raszewski
>
>Hi Magnus,
>
>>One thing that strikes me is that you're going to have basically the
>>same problems with save/restore as with undo. So if you've implemented
>>save/restore, couldn't you just make an auto-save (to a RAM buffer if
>>you don't want a lot of disk writes) after each move, and let the undo
>>command just do a restore from that buffer?
>
>Save/Restore is actually a lot different from Undo. In a save/restore
>you're saving the entire game state, in effect the values of all
>variables. In an undo you're saving the "state delta" of a limited
>number of moves. Undo therefore would almost certainly not use the
>same techniques as save/restore.
>
Not necessarily; you _can_ implenet undo as a save.restore (some
systems use thsi methog. Z doesn't specify HOW undo works, so a terp
might do this. Since savign the entire game state tends to be a slow,
memory intensive operation, one doesn't generally like to do this
every turn, so undo is usuall mplemented as above -- though this may
be a more difficult thign to do.
>
>In Python we have a lovely little module called "shelve" that will
>automagically save an object's state, and the state of any objects
>that relate to the object in some manner. At least that's the theory,
>right now the PC version of Python seems to have some bugs in shelve.
>:(
>
>Ah, well, the problem's being traced so shelve will soon be debugged.
>
Yeah; thisis the problem; caching the state of a program in any form
is a tricky thign to do correctly. In a VM, at the very least, the
most braindedad forms of flashing otu the gamestate isn't too hard
(THe vm has a memory region, which you can just copy to somewhere else),
but in a non-vm language, you need to do the (pretty tricky) task of
keeping track of everything that's yours and putting it somewhere.
--
"This above all -- To thine own self be true." -- Shakespeare, Hamlet I.iii
Evin Robertson
wo...@one.net wrote:
> Save/Restore is actually a lot different from Undo. In a save/restore
> you're saving the entire game state, in effect the values of all
> variables. In an undo you're saving the "state delta" of a limited
> number of moves. Undo therefore would almost certainly not use the
> same techniques as save/restore.
In Frotz, 'undo' slots are implemented simply by making a duplicate of
all volatile memory. Not very space efficient, but fast.
Quetzal is a save game format for z-machine games. In old versions of
nitfol (my z-machine interpreter), I was actually using the Quetzal
format for the undo slots, so the process of saving/restoring was
*identical* to the undo operation. Yay code reuse. The quetzal
format can either keep a duplicate of volatile memory or a simple diff
between the current state and the initial game state.
Unfortunately, Quetzal 1.4 requires that the save operation actually
be inside a @save (or @save_undo which is fairly equivalent) opcode,
so I couldn't implement undo for version 3 games (which don't call
@save_undo). So I tossed Quetzal for undo except for the stack format
which was decent enough. Now nitfol does a per-turn-diff of volatile
memory to make each undo slot really small, so it can have virtually
unlimited undo/redo depth.
Magnus Olsson
>
>>One thing that strikes me is that you're going to have basically the
>>same problems with save/restore as with undo. So if you've implemented
>>save/restore, couldn't you just make an auto-save (to a RAM buffer if
>>you don't want a lot of disk writes) after each move, and let the undo
>>command just do a restore from that buffer?
>
>you're saving the entire game state, in effect the values of all
>variables. In an undo you're saving the "state delta" of a limited
>number of moves. Undo therefore would almost certainly not use the
>same techniques as save/restore.
I guess I was in Computer Scientist mode when writing that. From an
abstract point of view, undo is equivalent to save/restore: on one
hand, in order to do a diff between the current and the previous game
state, you have to be able to access it, so you could just as well
save it as it is. On the other hand, doing a save followed by a
restore is obviously one way of implementing undo.
And nothing stops you from having a save function that saves a diff
between the current game state and the initial state.
Mike Arnautov
> Save/Restore is actually a lot different from Undo. In a save/restore
> you're saving the entire game state, in effect the values of all
> variables. In an undo you're saving the "state delta" of a limited
> number of moves. Undo therefore would almost certainly not use the
> same techniques as save/restore.
Um... Possibly. But the other way round, I am less sure. In fact, I've
been thinking of implementing undo in A-code as a very simple
"differential stack", recording game changes between moves. One
advantage would be exactly in implementing save simply as a dump of that
stack. I haven't done me sums, but I *think* it wouldn't make the save
file overall much bigger ('cause a lot of things don't actually change
-- not in the A-code representation, anyway) and it would give you a
built-in log of the game, which would be invaluable in debugging. (I
find that players are very reluctant to mail game logs, even where the
game generates them automatically.)
--
Mike Arnautov
mailto:m...@mipmip.demon.co.uk
http://www.mipmip.demon.co.uk/mipmip.html
Philip Goetz
news:889sfd$mdj$1...@cantaloupe.srv.cs.cmu.edu...
> techniques. Although I've only looked at Inform and TADS, from following
> the parser discussions here in r.a.i-f, I can say that the parsing systems
> in the current generation of adventure authoring tools are pretty trivial
> compared to the state-of-the-art parsers in natural-language and speech
> understanding systems.
>
This is even more true than it was when I made the same statements
back around 1985. And it's still true that, as I found, the parser is
not the limiting factor. The world model is the limiting factor.
It is worse than useless to build a better parser without building
a better world model -- you just make exponentially more work
for the IF writer, who must anticipate how, say, adverbs might
be used, and for the IF player, who must now try "walk quietly
past sleeping troll," "tiptoe past troll", and "walk past troll
while holding breath" as well as "walk past troll" (or just
"north").
Phil Goetz
Philip Goetz
> Even here, I'd hesitate to call the disambiguation and scoping problems
> encountered by today's IF systems "difficult." An IF parser has
> complete knowledge of the world state, needs to recognize only a limited
> vocabulary and (relatively) simple sentence structure, and doesn't
> need to make use of common-sense knowledge. Under these conditions,
> scoping and disabiguation are relatively simple compared to the
> conditions under which a natural language understanding system must
> work. Parsing for an IF system, including disambiguation and scoping
> issues, just isn't all that difficult *if you know what techiniques that
> have already been developed to address these problems*. On the other
hand,
> it is difficult if you start from scratch, without the benefit of the
> work of others, which is why I recommended...
The parser I wrote in 6502 code used world knowledge for disambiguation.
There wasn't a lot of work on this; most of the work I knew then on
disambiguation
tried to use information in the text rather than information in the world to
do
disambiguation. There might have been some such in SHRDLU; I forget.
Simple technique: Use the scope which provides you with an object.
So if I say, "Put the block on the table on the floor", then if there
is a block on the table, the program puts it on the floor; if there is
no block on the table, but there is a table on the floor, then find a
block and put it on that table. I don't think our parsers now do
even this.
> For natural-language parsing, I recommend "Natural Language Understanding"
> by James Allen (Bejamin/Cummings Publishing Co.).
A good introduction, but IIRC it won't talk about disambiguation
using world knowledge. Just syntactic parsing, & a tiny section
on pragmatic parsing. All the techniques presented in that book
are more or less equivalent. No mention of using statistical information.
Phil Goetz