Parser Techniques

[Paul Allen Panks]

If you use BASIC to program your text adventure, and you are having
problems with writing an effective (yet simple) word parser, check out the
lines below for some help:

5 DIM aa AS STRING
10 DIM words$(50)
15 INPUT ">", aa
20 post = 1: number = 0
25 dat$ = aa: FOR a = 1 TO LEN(dat$)
30 IF MID$(dat$, a, 1) = " " THEN
35 aa = MID$(dat$, post, a - post): post = a + 1: number = number + 1:
words$(number) = LCASE$(aa)
45 END IF
50 NEXT: number = number + 1: aa = MID$(dat$, post, a - post):
words$(number) = LCASE$(aa)
55 FOR x = 1 TO number: PRINT words$(x), x: NEXT

The above example was written in QBASIC, but can easily be adapted to
other variants of BASIC and even C or Java.

Lines 5-10 and 55 are not really necessary, although creating "error
traps" to check to see if a line entered is too long *before* Line 20
would be practical and useful.

What this parser does is break each word in string "aa" into individual
words for use later by the filtering routine and verb-jump routine. What
are those, you ask? Well, a filtering routine may be the following:

60 if aa="" then PRINT"I didn't understand that. Try again please.":GOTO
15

65 if len(aa)>40 then PRINT"Your command is too complex. Please reprase
it.":GOTO 15

This weeds out user input that doesn't satisfy what the program is looking
for.

Another useful function is the "Word Lookup Routine". This routine, listed
below as an example, compares words entered previously to the "vocabulary
list" used by the game (i.e. nouns, verbs, pronouns, etc):

70 for x=1 to number: REM number equals the number of words found in "aa"
75 for y=1 to MAX_NOUNS: REM set MAX_NOUNS to all the Nouns in the game
80 if words$(x)=NOUN$(y) then NOUN=y
85 NEXT:if NOUN=0 then ?"There isn't a valid noun in that sentence.":GOTO
15

...

and so on.

This looks up the nouns and, if none found, tells us to try again. If,
however, a noun is found, the program then jumps to the "verb-jump"
routine.

I won't go into detail how the "verb-jump" routine works, but basically
you do the same thing as the "noun lookup" routine for the VERBS and then,
if no verb is found, print out a similar message. If one is found,
however, the program then jump to the appropriate "action verb"
subroutine:

90 ON VERB GOTO 100,200,300,400,500 ... etc

95 Print"What?":GOTO 15
99 REM Verb#1
100 ...
199 REM Verb#2
200 ...

etc.

There are tons of neat and useful things you can add to a text adventure,
including the ability to place objects inside other objects, fight
monsters, and solve quests. My game, "Westfront PC: The Trials of Guilder"
(http://www.geocities.com/dunric/westfront.html), does just that.

Have fun, and keep adventure games alive! :)

Regards,

Paul Panks (a/k/a "Dunric")
dun...@yahoo.com

--
********************************************************************************

Few cats act their age, while most just cough up fur balls.

********************************************************************************

[David A. Cornelson]

"Paul Allen Panks" <pa...@dana.ucc.nau.edu> wrote in message
news:9hao95$il0$1...@usenet.nau.edu...

> If you use BASIC to program your text adventure, and you are having
> problems with writing an effective (yet simple) word parser, check out the
> lines below for some help:
>
> 5 DIM aa AS STRING

<snip lots of old BASIC code>

{shudder}

Jarb

[Paul Allen Panks]

There are, of course, additional techniques useful in a text adventure.
You'll probably want a minimum of 20 verbs, with most text adventure games
supporting nearly two dozen. The best advice is to code your adventure
game by a "Divide and Conquer" philosophy. What is this you ask? No, it's
not the board game RISK (tm of Parker Brothers). It is a coding technique
that takes a modular (piece by piece) approach to game design. Instead of
sitting down in front of a Commodore 64 and coding, say, Doom C-64 all in
one sitting, you are actually taking the chore of piecing together an
adventure game like you would a jigsaw puzzle.

HOW TO GET STARTED
------------------

Programming your own adventure game can be a daunting task, even for an
experienced programmer (I'm middle of the road myself!). The best way to
start is to think up a story in your head and put it to paper. Do this all
before a single line of code is written, otherwise you'll "Pull A Dunric"
and end up with a four or five year debugging nightmare that somehow
evolved a playable game. {g}

The "GO/ENTER" Verb Routine
---------------------------

Let's start by fleshing out a simple GO/ENTER verb routine. Doesn't have
to be anything fancy, long winded or Zorkian(tm). Just a simple,
functional design that allows the user/player the opportunity to move from
one location (room) to another (how to actually turn numbers into workable
"rooms" is really beyond the scope of this article; however, basically you
assign numbers to five or six compass directions and if a room can be
entered from, say, the NORTH, you assign the 1st compass direction of
NORTH for that room with the corresponding [destination] room number).

Listed below is QBASIC/BASIC code for a simple GO/ENTER verb routine
(pardon the Commodore 64-ish line numbering):

REM Go/Move Routine
100 IF N > 6 THEN COLOR 12: PRINT "You can't do that here.": MN = 1: GOTO
parser
105 IF M(RM, N) = 0 THEN COLOR 12: PRINT "You can't go in that
direction!": MN = 1: GOTO parser
110 IF M(RM, N) = -1 THEN COLOR 12: PRINT "Fallen trees obstruct your path
in that direction.": MN = 1: GOTO parser
115 IF M(RM, N) = -2 THEN COLOR 12: PRINT "Your path is blocked by a mean
looking "; RO$(RM): MN = 1: GOTO parser
120 RM = M(RM, N): COLOR 7: IF LO(156) = RM THEN fald = 1: PRINT "Faldor
follows you "; NO$(N); "..."
125 COLOR 11: PRINT "You move "; NO$(N); " into a "; DE$(RM, 1); "..."
130 GOTO RoomDesc

...

Pay no attention to "MN = 1", as that is a flag I usually set in my
adventure games to handle mutiple parsed commands (i.e. "GET SWORD THEN
ENTER CAVE").

"N" is a variable I set in the "Parser" routine that corresponds to the
"NOUN" entered in by the player. If no such noun is entered, it is set to
zero (0) and the game output returns to the "command prompt" (i.e. ">" in
most adventure games; whatever input prompt is displayed to signify to the
user, "I'm waiting for your input.")

"M(RM,N)" needs some explanation. What I do in my games is to set up a
2048 by 6 "Map Array" containing a possibility of 2,048 "rooms"
(locations) with 6 "compass directions" each. These are (in order of use):
NORTH (1) ,SOUTH (2) ,EAST (3),WEST (4) ,UP (5) ,DOWN (6)

So M(1,1), for example, would correspond to:

Map Array(Room#1, NORTH)

To use another example, the following:

M(256, 3)

would translate into:

Map Array(Room#256, EAST)

Make sense? The important thing to note here is that although a "Map
Array" routine is essential to gameplay, you won't be able to do anything
with the numbers you give the computer without a proper "Verb" routine
such as "GO" or "ENTER" to move the player/user from one "room" (location)
to another.

"RO$(RM)" is simple enough (even though the variable name is vague). "RO$"
in my games corresponds to "Room Object", or an object in the room that is
typically immovable, such as a boulder or fence. The "(RM)" suffix points
to the current "room number", or present locations where the player's
character resides. If a "Room Object" exists in the current "Room" (RM),
then it is printed out in LINE# 115. Make sense? :)

"DE$(RM,1)" is a subscripted variable that is commonly used when one or
more "attributes" for a room need to be defined at "program startup"
(better known as "Fire Up the HAL 9000" in DunSpeak(tm)). An "attribute"
can be anything really, up to and including whether or not magic is
present in room or if a wall might collapse after a predetermined set of
turns has been reached by the program (or user). "(RM,1)", in LINE# 120,
points to the "Brief Room Descriptor" routine (BRD Route in DunSpeak),
which might contain useful phrases such as "DARK FOREST", "BURTON MANSION"
or "GREEN VALLEY".

I guess since I actually do have time to go over this more indepth, a
successful "GO" and/or "ENTER" verb routine depends on a series of numbers
stored within the program itself. As stated previously, a "Map Array" is
used (stored in "M(RM,N)" in my example) to correlate user input from a GO
command to rooms within the Gaming World (GW).

Examples commonly used include the following gibberish:

10000 REM N , S, E, W, U, D
10005 DATA 807, 2, 0, 1501, 1503, 0 : REM Room#1 in "Westfront
PC"
10010 DATA 1 , 7, 3, 5, 0, 0 : REM Room#2 " "

...

"0" means "You can't go in that direction!" to the program.
"1" means "Room#1" (don't confuse this with N=1, i.e.,
1=NORTH,2=SOUTH,etc. in the compass discussion earlier in this article;
they are *not* referring to the same thing)

"2" means "Room#2"
"807" means "Room#807"

...

and so on.

I hope this at least helps, but if I've confused you beyond all hope, feel
free to e-mail me at: dun...@yahoo.com

Other verbs
-----------

There are other verbs you will need. A short list of common ones are
listed below:

(NOTE: Some verbs have multiple synonyms, such as "GET" and "TAKE", for
example)

Minimalist Set of Game Commands
-------------------------------

Normal Verbs
------------

V#1
GO
ENTER

V#2
GET
TAKE

V#3
DROP

V#4
WIELD
READY
EQUIP

V#5
UNWIELD
UNREADY
UNEQUIP

V#6
WEAR
PUT ON

V#7
REMOVE
TAKE OFF

V#8
OPEN

V#9
CLOSE

V#10
LOCK

V#11
UNLOCK

V#12
USE

V#13
PUT

V#14
LIGHT

V#15
EXTINGUISH

V#16
EXAMINE
LOOK AT
LOOK

V#17
READ

V#18
PULL
TURN
PUSH
THROW

V#19
EAT
DRINK

V#20
KILL
ATTACK

V#21
CAST

V#22
ASSESS
APPRAISE

V#23
LIST
MENU

V#24
BUY

V#25
SELL

V#26
CLIMB

V#27
PLAY

Miscellaneous
-------------
V#28
PRAY

V#29
SAVE
SAVE GAME

V#30
LOAD
LOAD GAME

V#31
SCORE
?

V#32
I
INVENTORY

V#33
HELP

V#34
QUIT
EXIT
BYE

---------------------------------------------------------------------------

This should be enough information to get you started; however, I recommend
you spend several hours at your local library reading as much as you can
about both the history of text adventures (commonly also called
"interactive fiction") and game design in general.

Reading List
------------

"Golden Flutes and Great Escapes: How to Write your Own Adventure Games"
by Delton T. Horn (ISBN: 0880560894; Dilithium Press; 1984).

"How to Create Adventure Games" by Christopher Lampton (ISBN: 0531101193;
Franklin Watts; 1986)

"Creating Adventure Games on Your Computer" by Tim Hartnell (ISBN:
0345318838; Ballantine Books; 1984)

"Compute!'s Guide to Adventure Games" by Gary McGath (ISBN: 0942386671;
Compute! Publications; 1984)

Have fun! :)

Regards,

Paul Panks (a/k/a "Dunric")
dun...@yahoo.com

http://www.geocities.com/dunric/westfront.html

[Jonathan Rosebaugh]

On 27 Jun 2001 02:11:14 GMT, Paul Allen Panks <pa...@dana.ucc.nau.edu> posted:
>(snip reinventing wheel)

Two points, quickly, since I'm tired:
1) People talk about writing games on raif, not rgif.
2) Most everyone uses an IF-specific language nowadays. Even those who
don't aren't likely to use BASIC. I'm afraid your audience is VERY
limited. You might try putting this information on a web page, and
just posting the url.

--
Skip - http://www.plover.net/~skip/
GPG key 0x41963E43 - See http://www.plover.net/~skip/gpg.html
-------------------------------------------------------------
The greatest disloyalty one can offer to great pioneers is to refuse to
move an inch from where they stood.

[Paul Allen Panks]

A lot of stuff in BASIC can be hardcoded like so:

19999 REM SHOP (LIST)
20000 PRINT ">";
20001 IF lo(37) = 75 THEN PRINT "300: SWORD."
20002 IF lo(26) = 75 THEN PRINT "75: WOLFSBANE."
20003 IF lo(13) = 75 THEN PRINT "100: LANTERN."
20004 IF lo(14) = 75 THEN PRINT "15: MIRROR."
20005 IF lo(15) = 75 THEN PRINT "35: POLE."
20006 IF lo(36) = 75 THEN PRINT "180: BOWIE KNIFE."
20007 IF lo(27) = 75 THEN PRINT "1500: IRON AXE."
20008 IF lo(23) = 75 THEN PRINT "42: TORCH."
20009 IF lo(24) = 75 THEN PRINT "16: CANTEEN."
20010 IF lo(19) = 75 THEN PRINT "24: SACK."
20011 IF lo(7) = 75 THEN PRINT "30: FOOD."
20012 IF lo(9) = 75 THEN PRINT "100: BACKPACK."
20013 IF lo(10) = 75 THEN PRINT "40: OIL."
20014 IF lo(12) = 75 THEN PRINT "20: HOLY WATER."
20015 IF lo(18) = 75 THEN PRINT "84: SMALL SACK."
20016 IF lo(25) = 75 THEN PRINT "1000: WINE."
20017 IF lo(32) = 75 THEN PRINT "70: DAGGER."
20018 IF lo(38) = 75 THEN PRINT "5000: SCIMITAR."
20019 IF lo(39) = 75 THEN PRINT "6000: TWO-HANDED SWORD."
20020 RETURN

Not the best method, but it gets the job done. If you need a FOR-NEXT
LOOP, try:

FOR X=1 TO 500
IF lo(n) = 75 THEN PRINT Price%(N)": "NO$(N)"."
NEXT

Paul

[Paul Allen Panks]

Oops, should be "X", not "N" for the variable in the FOR-NEXT Loop:

: FOR X=1 TO 500
: IF lo(X) = 75 THEN PRINT Price%(X)": "NO$(X)"."
: NEXT

Paul

Paul Allen Panks (pa...@dana.ucc.nau.edu) wrote:
: A lot of stuff in BASIC can be hardcoded like so:

[Goober]

"Paul Allen Panks" <pa...@dana.ucc.nau.edu> wrote in message

news:9hbnlv$l05$1...@usenet.nau.edu...

> Oops, should be "X", not "N" for the variable in the FOR-NEXT Loop:
>

I would recommend a look at C++ if you are interested in writing you own
i.f. engine. The object handling will save you much time and trouble, and
lead to cleaner and simpler code in the long run.

[Alex Warren]

Goober wrote:

> > Oops, should be "X", not "N" for the variable in the FOR-NEXT Loop:
> >
> I would recommend a look at C++ if you are interested in writing you own
> i.f. engine. The object handling will save you much time and trouble, and
> lead to cleaner and simpler code in the long run.

If I was in the position of being just about to start an IF engine (and not in
the position of having been developing one for three years as I am now), I think
it might be interesting to take a look at Perl. I'm very much a Perl novice but
I think an IF engine written in Perl (or perhaps some kind of library which
could be used as an extension) could well be the proverbial dog's gonads.

Then again it could well end up causing the most horrible code in the known
universe.

--
Alex Warren
al...@axeuk.com
Quest - Make adventure games easily - http://www.axeuk.com/quest/

[David Thornley]

In article <blsjjtsjacq4slb8l...@4ax.com>,
Alex Warren <al...@asparagus.co.uk> wrote:
>Goober wrote:

NOTE: This is off-topic for rec.games.int-fiction, so I've set
the followup to rec.arts.int-fiction.

>
>> > Oops, should be "X", not "N" for the variable in the FOR-NEXT Loop:
>> >
>> I would recommend a look at C++ if you are interested in writing you own
>> i.f. engine. The object handling will save you much time and trouble, and
>> lead to cleaner and simpler code in the long run.
>

There are various languages I'd suggest, BASIC not being among them.

C++ is a powerful language, and you can generally find compilers on
most systems. C trades a good deal of power for additional
portability. Java trades a good deal of power (some of which would
be irrelevant to an IF engine) for a sorta portable GUI.

Common Lisp is my kneejerk answer to any hard programming problem,
but distribution is a problem. CLisp runs on Windows and Unix,
but I don't know of any good CL compiler for the Macintosh that
doesn't require a runtime distribution license.

TADS and Inform have the distinct advantage of being widely
cross-platform, with most people in IF already being able to use
these.

Python is a nice clean language, but it's questionable whether
it's enough better than TADS to justify the lesser familiarity
(more IF players have TADS and zcode interpreters installed than
Python, I'd imagine).

BASIC is generally unportable and not very powerful.

Fortran has really lousy string handling.

I'd be really impressed to see a good Intercal IF engine, but I
wouldn't recommend it to the beginner (or anybody else, for that
matter).

As for Perl....

>If I was in the position of being just about to start an IF engine (and not in
>the position of having been developing one for three years as I am now), I think
>it might be interesting to take a look at Perl. I'm very much a Perl novice but
>I think an IF engine written in Perl (or perhaps some kind of library which
>could be used as an extension) could well be the proverbial dog's gonads.
>
>Then again it could well end up causing the most horrible code in the known
>universe.
>

Both possibilities seem plausible.

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

[Paul Allen Panks]

I"ve looked at both languages. Since I understand BASIC better than I Do
C, I stick with that for now. YEs, it's like going back to the AGe of the
Dinosaurs, but if you know the age better than your back hand, it gets the
job done. I wrote "WEstfront PC: THe TRials of Guilder" in PowerBASIC
which, I think, showcases the potential of BASIC to produce
C++/Java-quality work.

I think people quickly forget just how useful BASIC is, and how easy it is
to understand and implement. I don't see why age has to be at issue. Sure,
other programming languages exist, but I'm using what I know here. Sorry
if this sounds like a flame; it's not. I'm merely pointing out that BASIC
isn't the "Programming Anti-Christ" like so many individuals portray it to
be.

Dunric
dun...@Yahoo.com

Goober (g.pr...@NOSPAMntlworld.com) wrote:

: "Paul Allen Panks" <pa...@dana.ucc.nau.edu> wrote in message

--

[Alex Warren]

Paul Allen Panks wrote:

> I"ve looked at both languages. Since I understand BASIC better than I Do
> C, I stick with that for now. YEs, it's like going back to the AGe of the
> Dinosaurs, but if you know the age better than your back hand, it gets the
> job done. I wrote "WEstfront PC: THe TRials of Guilder" in PowerBASIC
> which, I think, showcases the potential of BASIC to produce
> C++/Java-quality work.

You can create both quality programs and complete crap in BASIC, C, Perl or
whatever else takes your fancy.

> I think people quickly forget just how useful BASIC is, and how easy it is
> to understand and implement. I don't see why age has to be at issue. Sure,
> other programming languages exist, but I'm using what I know here. Sorry
> if this sounds like a flame; it's not. I'm merely pointing out that BASIC
> isn't the "Programming Anti-Christ" like so many individuals portray it to
> be.

Partly why BASIC has had a bad name has been because of code similar in style to
the code which you posted, actually:

5 DIM aa AS STRING
10 DIM words$(50)
15 INPUT ">", aa
20 post = 1: number = 0
25 dat$ = aa: FOR a = 1 TO LEN(dat$)
30 IF MID$(dat$, a, 1) = " " THEN
35 aa = MID$(dat$, post, a - post): post = a + 1: number = number + 1:
words$(number) = LCASE$(aa)
45 END IF
50 NEXT: number = number + 1: aa = MID$(dat$, post, a - post):
words$(number) = LCASE$(aa)
55 FOR x = 1 TO number: PRINT words$(x), x: NEXT

Obviously this works for you, and that's absolutely fine, but it is a good
example of why a Computer Science professor on another newsgroup claims that
"BASIC causes brain damage".

From the point of view of somebody who rather likes VB, I think for the purposes
of explaining techniques yours wasn't a particularly brilliant example.
Something more modern-looking but exactly equivalent like my "translation" below
would perhaps have been better.

Dim InputText As String, Post as Integer, Number as Integer
Dim Dat as String, WordList(50) as String, a as Integer

INPUT ">", InputText
Post = 1
Number = 0
Dat = InputText

For a = 1 TO Len(Dat)
If Mid(Dat, a, 1) = " " Then
InputText = Mid(Dat, Post, a - Post)
Post = a + 1
Number = Number + 1
WordList(Number) = LCase(InputText)
End If
Next a

Number = Number + 1
InputText = Mid(Dat, Post, a - Post)
WordList(Number) = LCase(InputText)

FOR x = 1 TO Number
Print WordList(x), x
Next x

At least it doesn't make my eyes go funny, anyway.

[Alex Warren]

Alex Warren wrote:

> For a = 1 TO Len(Dat)
> If Mid(Dat, a, 1) = " " Then
> InputText = Mid(Dat, Post, a - Post)
> Post = a + 1
> Number = Number + 1
> WordList(Number) = LCase(InputText)
> End If
> Next a

Incidentally, one of the reasons I was suggesting Perl is that you can replace
all of the lines above with something like:

@wordlist = split(/ +/, $inputtext)

If $inputtext was "I think Perl is rather nice", you'd get "I", "think",
"Perl", "is", "rather" and "nice" as elements of the wordlist array. Nice.

[Garth Dighton]

thor...@visi.com (David Thornley) wrote in
<A7n_6.4053$B7.6...@ruti.visi.com>:

>
>Python is a nice clean language, but it's questionable whether
>it's enough better than TADS to justify the lesser familiarity
>(more IF players have TADS and zcode interpreters installed than
>Python, I'd imagine).
>

The one nice thing about PAWS is that it uses a truly complete language
(i.e. Python) - so you could do things like create entire maps, etc. on the
fly. One vaporware project I was thinking of was to use PAWS to write a
dungeon-crawl text adventure (and it really would be "text adventure"
rather than "interactive fiction"), where the rooms, monsters, and
treasures would be randomly generated as you explored. While TADS/Inform
have some capability along these lines, I don't think they could handle
this sort of project.

--
Garth Dighton

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

[Beej Jørgensen]

In article <9hcss6$n93$1...@usenet.nau.edu>,

Paul Allen Panks <pa...@dana.ucc.nau.edu> wrote:
>I think people quickly forget just how useful BASIC is, and how easy it is
>to understand and implement.

To be sure. One thing that I consider to be VITAL* for an IF language
(for lack of a better term) is being object-oriented. It's the only
sane way.

And there are OO BASICs out there, totally. But, alas, if you write
your game with it I won't be able to play it; I use a Linux box, and
it's unlikely that I'll have an interpreter. At least if it was written
in C/C++ I could compile it.

If I had to choose another general purpose language for coding IF, it
would be Python. But it's still not as easy as Inform, since IF
languages are tuned to making IF creation easier.

-Beej

* by "vital" I mean that you might was well start OO, or you'll end up
implementing your own OO on top of your procedural languages.

[Poptasticboy UK]

>The one nice thing about PAWS is that it uses a truly complete language
>(i.e. Python) - so you could do things like create entire maps, etc. on the
>fly. One vaporware project I was thinking of was to use PAWS to write a
>dungeon-crawl text adventure (and it really would be "text adventure"
>rather than "interactive fiction"), where the rooms, monsters, and
>treasures would be randomly generated as you explored. While TADS/Inform
>have some capability along these lines, I don't think they could handle
>this sort of project.

Hehe, I'm planning to prove you wrong on this point... but don't hold your
breath, it'll be at least a couple of years before it's ready :)

Actually, my plan is more ambitious than that... an RPG based heavily on the
brilliant Central Casting books [Paul Jaquays]... I have begun work and believe
I can pull it off... time will tell.

Chris Warr

[Poptasticboy UK]

I'm interested in attempting an i.f. game in Prolog at some point, just for the
Prolog experience, but purely for game-creation I will stick to TADS.

Anyone tried this?

Chris Warr.

[Poptasticboy UK]

I very much agree with this. There are some extremely good versions of BASIC
around, many of which I suspect are intuitive, easy to learn and pretty
powerful.

It's just that some of them use the kind of code from the original post which
makes even people with experience in BASIC cringe at least a little.

Still I can't look at something like that without thinking fondly of my Amstrad
CPC. <sigh> :)

Chris Warr.

[Adam Thornton]

In article <3b3a1...@goliath.newsgroups.com>,

Garth Dighton <gdig...@geocities.com> wrote:
>The one nice thing about PAWS is that it uses a truly complete language
>(i.e. Python) - so you could do things like create entire maps, etc. on the
>fly. One vaporware project I was thinking of was to use PAWS to write a
>dungeon-crawl text adventure (and it really would be "text adventure"
>rather than "interactive fiction"), where the rooms, monsters, and
>treasures would be randomly generated as you explored. While TADS/Inform
>have some capability along these lines, I don't think they could handle
>this sort of project.

If you do this, I want the source, so I can turn it into my live D&D
"Stochastic Dungeon Crawl," which I've wanted to do for a while. It
would be a nice break from campaigns with politics and emotions and
stuff.

Adam

[Adam Thornton]

In article <20010627164548...@ng-fk1.aol.com>,
Poptasticboy UK <poptast...@aol.com> wrote:

>I'm interested in attempting an i.f. game in Prolog at some point, just
>for the Prolog experience, but purely for game-creation I will stick to
>TADS. Anyone tried this?

Phil Goetz. I saw him around here not long ago.

Adam

[Garth Dighton]

ad...@fsf.net (Adam Thornton) wrote in <9hdoso$ofp$1...@news.fsf.net>:

Funny, that's exactly the same use I was planning for it :-)

Maybe I'll get to it one of these days, but I really want PAWS to have a
command-type syntax first - "BOB, CAST FIREBALL" - so you can order other
members of your party about. Right now, PAWS won't accept this syntax, as
far as I know.

[Andrew W Frederiksen]

In article <A7n_6.4053$B7.6...@ruti.visi.com>,
David Thornley <thor...@visi.com> wrote:

[Complete contextectomy]

>Fortran has really lousy string handling.

Oddly enough, I'm using Fortran to write my epic sequel, 'The
Eigencave, Part 2 - 3i'. A sample transcript follows.

---------------------------------------------------------

> WEST

You have entered a dark place. It is pitch black. You are
likely to be eaten by round-off error.

> TURN ON LAMP

You are standing in a vast cavern, 3.3765277D02 feet in
diameter. There is a large ill-conditioned matrix here!

> TAKE EIGENVALUES

(from the matrix)

Ha-HA! They're imaginary!

-------------------------------

-- A.

[Greg Ewing]

Poptasticboy UK wrote:
>
> I'm interested in attempting an i.f. game in Prolog at some point, just for the

> Prolog experience, ...
>
> Anyone tried this?

There is a book called "Adventure in Prolog", by someone
I forget the name of for the moment... wait on, let's
see if Google can tell me...

...well, what do you know, the whole book seems to
be on line:

http://www.cs.wisc.edu/~fischer/cs538.s01/prolog/ADVTOC.HTM

The author is Dennis Merritt.

The author uses the construction of a simple text
adventure as a running example while introducing
Prolog.

After reading it a while back, I did some experimenting
with Prolog as an IF language. I concluded that Prolog
has some interesting possibilities in that role, but
very different techniques are required from those
used in Inform, TADS and the like.

One problem I found is that the structure of Prolog
makes it difficult to build extensible libraries of code.
There may be a way, but I didn't find it at the time.
I may have another go one day.

--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg

[wo...@one.net]

Hi Garth,

>Maybe I'll get to it one of these days, but I really want PAWS to have a
>command-type syntax first - "BOB, CAST FIREBALL" - so you can order other
>members of your party about. Right now, PAWS won't accept this syntax, as
>far as I know.

Um, yes it will, actually. In fact in the Thief's Quest sample game
both the druid and dryad are commanded with this syntax.

Respectfully,

Wolf

"The world is my home, it's just that some rooms are draftier than
others". -- Wolf

[wo...@one.net]

Hi David,

>Python is a nice clean language, but it's questionable whether
>it's enough better than TADS to justify the lesser familiarity
>(more IF players have TADS and zcode interpreters installed than
>Python, I'd imagine).

Can't resist plugging PAWS after such a perfect opening:

http://w3.one.net/~wolf/PAWS.shtml

For those interested in comparing extant languages, Roger Firth's
Cloak Of Darkness page:

http://homepages.tesco.net/~roger.firth/

offers a look at almost a dozen different ones implementing the same
small game.

[J Holder]

IIRC, there were a bunch of articles in this newsgroup and a web site
by Phil Goetz on Prolog IF programming a few years back - the
discussions are quite interesting. Dave Baggett about the same
time was proposing Scheme as a perfect IF language. Most of
the very little time I spend on IF is more in the LISP / Scheme
area now.

I'm sure Google newsgroup archive will have some of it.

John
--
John Holder (j-ho...@home.com) http://members.home.net/j-holder/
Coffee should be black as hell, strong as death and sweet as love.
-Turkish proverb
"Greg Ewing" <gr...@cosc.canterbury.ac.nz> wrote in message
news:3B3A7561...@cosc.canterbury.ac.nz...

[Goober]

> I think people quickly forget just how useful BASIC is, and how easy it is
> to understand and implement. I don't see why age has to be at issue. Sure,
> other programming languages exist, but I'm using what I know here. Sorry
> if this sounds like a flame; it's not. I'm merely pointing out that BASIC
> isn't the "Programming Anti-Christ" like so many individuals portray it to
> be.

Totally, use what works. The point is, you have actually gone and finished a
project, rather
than most of us who just like to chat about it!

[David Thornley]

In article <3b3a1...@goliath.newsgroups.com>,
Garth Dighton <gdig...@geocities.com> wrote:

>thor...@visi.com (David Thornley) wrote in
><A7n_6.4053$B7.6...@ruti.visi.com>:
>
>>Python is a nice clean language, but it's questionable whether
>>it's enough better than TADS to justify the lesser familiarity
>>(more IF players have TADS and zcode interpreters installed than
>>Python, I'd imagine).
>
>The one nice thing about PAWS is that it uses a truly complete language
>(i.e. Python) - so you could do things like create entire maps, etc. on the
>fly. One vaporware project I was thinking of was to use PAWS to write a
>dungeon-crawl text adventure (and it really would be "text adventure"
>rather than "interactive fiction"), where the rooms, monsters, and
>treasures would be randomly generated as you explored.

Have you looked at roguelike games? Those in general do what
you are talking about, although with a different interface.
I find them an excellent replacement for the sort of D&D I played
in the 1970s.

While TADS/Inform
>have some capability along these lines, I don't think they could handle
>this sort of project.
>

Dunno about that. TADS is a full programming language (and presumably
so is Inform, although I can't speak to that from personal knowledge).
I don't know that you could do this in Python and not TADS.

SPOILER WARNING: Mild spoiler for "Hunter, In Darkness"
F
R
O
B
O
Z
Z
M
A
G
I
C
S
P
O
I
L
E
R
S
P
A
C
E
Have you looked at the game "Hunter, In Darkness"? It's written
in Inform and has a dynamically generated maze. I believe the
author, Zarf, has made source available.

[David Thornley]

Again, this is off-topic for rec.games.int-fiction, and followups
have been set accordingly.

In article <9hcss6$n93$1...@usenet.nau.edu>,

Paul Allen Panks <pa...@dana.ucc.nau.edu> wrote:
>I"ve looked at both languages. Since I understand BASIC better than I Do
>C, I stick with that for now. YEs, it's like going back to the AGe of the
>Dinosaurs, but if you know the age better than your back hand, it gets the
>job done. I wrote "WEstfront PC: THe TRials of Guilder" in PowerBASIC
>which, I think, showcases the potential of BASIC to produce
>C++/Java-quality work.
>

Could be; I can't tell. The reason I can't tell is that it's
available in a form I can't run on either of my home boxes.
This community is seriously cross-platform, and by sticking to
something that runs only on MS Windows you're going to be losing
a fair number of people out of an already small community.

BTW, what is PowerBASIC? Is it at all standard? Did you take
advantage of any particular extensions to the language that are
not common to other Basics? If so, your code is tied to one
language system, which is undesirable (just how undesirable
is up to you). Fifty years from now, if IF in its current form
lasts that long, people will still be able to play Anchorhead
and enjoy it, but they may not be able to play WFPC easily.

This is why I'd like people in IF to avoid proprietary, MS Windows-
only, languages and go for something more or less standard, with
multiple implementations (or at least implementations on multiple
platforms).

>I think people quickly forget just how useful BASIC is, and how easy it is
>to understand and implement. I don't see why age has to be at issue.

Since my favorite, Lisp, is the second-oldest language in current
use (Fortran is older), I'm not criticizing BASIC because of age.
My criticism is that it hasn't aged well in some sort of standard
form. The old Microsoft Basic I worked with in the early 80s
was greatly limited compared to other languages I started to
have available on my machines later in the 80s, and it has
diverged into a host of idiosyncratic implementations that usually
run on only one platform. There are versions of BASIC that
are quite good, but (except, AFAICT, for TrueBASIC, which does
not seem to be all that popular), they're one-offs that you
can't take with you to another platform.

Sure,
>other programming languages exist, but I'm using what I know here. Sorry
>if this sounds like a flame; it's not. I'm merely pointing out that BASIC
>isn't the "Programming Anti-Christ" like so many individuals portray it to
>be.
>

No, but it's not really possible to write portable programs in a good
style. I would not recommend it to anybody who might want to take
something cross-platform or who wanted his or her work to be lasting.

[Garth Dighton]

wo...@one.net wrote in <smvkjtgjorbummupi...@4ax.com>:

Ah, thanks - I didn't see any examples of this in the manual, so I never
really looked at the TQ code.

Maybe one day I'll actually get around to working on this project (along
with my Lua roguelike, my Pernangband variant, my... I've got a lot of
vaporware on my hard disk.)

[Garth Dighton]

thor...@visi.com (David Thornley) wrote in

<_YH_6.4422$B7.7...@ruti.visi.com>:

>In article <3b3a1...@goliath.newsgroups.com>,
>Garth Dighton <gdig...@geocities.com> wrote:
>>thor...@visi.com (David Thornley) wrote in
>><A7n_6.4053$B7.6...@ruti.visi.com>:
>>
>>>Python is a nice clean language, but it's questionable whether
>>>it's enough better than TADS to justify the lesser familiarity
>>>(more IF players have TADS and zcode interpreters installed than
>>>Python, I'd imagine).
>>
>>The one nice thing about PAWS is that it uses a truly complete language
>>(i.e. Python) - so you could do things like create entire maps, etc. on
>>the fly. One vaporware project I was thinking of was to use PAWS to
>>write a dungeon-crawl text adventure (and it really would be "text
>>adventure" rather than "interactive fiction"), where the rooms,
>>monsters, and treasures would be randomly generated as you explored.
>
>Have you looked at roguelike games? Those in general do what
>you are talking about, although with a different interface.
>I find them an excellent replacement for the sort of D&D I played
>in the 1970s.
>

I play Angband (and Pernangband, and Cthangband, etc), so yes - I've also
started writing my own roguelike in Lua. However, I wanted something more
CRPG like, where you could have a party of characters to command - despite
Teamangband, and pets in Adom/Nethack/some 'bands (none of which I can
stand - I always dismiss all pets ASAP), roguelikes are very much a single-
character against the world game. The IF-type parser seemed to me to be the
best way to go for this - The Frenetic Five games, for instance, already
feature a team of protagonists (superhero rather than dungeon-crawling
party perhaps, but the principle is definitely there).

> While TADS/Inform
>>have some capability along these lines, I don't think they could handle
>>this sort of project.
>>
>Dunno about that. TADS is a full programming language (and presumably
>so is Inform, although I can't speak to that from personal knowledge).
>I don't know that you could do this in Python and not TADS.

The big problem I can see is that their mechanisms for generating -new-
objects at runtime are rather ugly and difficult to work with - whereas,
with PAWS, all of your objects are a Python class with a global
instantiation, and it's trivial to instantiate a new instance - you just do
it in a function instead of globally.

SPOILER WARNING - Much heavier spoiler than David's

As I understand it, while the maze is dynamically generated - it's still
Wumpus, which is a fairly limited number of rooms (20, I think).

[Alex Warren]

David Thornley wrote:

> BTW, what is PowerBASIC? Is it at all standard?

PowerBasic is a company that makes compilers. Last time I looked (a few years
ago) they offered a compiler for DOS (presumably what is being used here), plus
Windows console-mode and DLL compilers. Rather quick they are too, apparently -
faster than QuickBASIC and VB.

As for standards, PB differs a bit from QB and VB, but since there's no ANSI
BASIC to my knowledge, any talk of standards in BASIC is rather meaningless.

> Fifty years from now, if IF in its current form
> lasts that long, people will still be able to play Anchorhead
> and enjoy it, but they may not be able to play WFPC easily.

I'm sure there will be a retro MS-DOS/MS-Windows scene in the future just as
there is with BBC Micros etc. today.

[Mike Snyder]

> BASIC is generally unportable and not very powerful.

BASIC might not be portable, but it's perfectly suited for non-portable IF.
Lunatix: The Insanity Circle (12th in IF-COMP '99) was QuickBASIC. I wrote
it in a month. If a person had the inclination to do so, something even
better could be possible.

Mike Snyder
Prowler Productions
http://www.prowler-pro.com/

[Mike Roberts]

Garth Dighton <gdig...@geocities.com> wrote:
> >TADS is a full programming language (and
> >presumably so is Inform, although I can't speak
> >to that from personal knowledge). I don't know
> >that you could do this in Python and not TADS.
>
> The big problem I can see is that their mechanisms for
> generating -new- objects at runtime are rather ugly and
> difficult to work with - whereas, with PAWS, all of your
> objects are a Python class with a global instantiation, and
> it's trivial to instantiate a new instance - you just do it in
> a function instead of globally.

I don't understand what you're getting at, at least with respect to tads.
In tads, you create a new instance at run-time using the 'new' operator,
which operates essentially as you would expect from C++ or Java. You can
use 'new' in a function or method (not "globally," whatever that means), and
it simply yields a reference to the newly-created object, which is an
instance of the class you specify in the 'new' expression. Could you
elaborate on what makes the model ugly or difficult to work with?

--Mike
mjr underscore at hotmail dot com

[Mikael Svane]

I wanted to read some more about parsing, so I tried the link mentioned in
the FAQ http://www.frii.com/~jholder/intfiction/parser.html but it is
broken. Does anyone know where the information has moved to?

Regards,
Mikael

[Richard Bos]

Alex Warren <al...@asparagus.co.uk> wrote:

> As for standards, PB differs a bit from QB and VB, but since there's no ANSI
> BASIC to my knowledge, any talk of standards in BASIC is rather meaningless.

There is, apparently, an ISO Basic Standard. I don't know any details,
though. It appears not to be widely supported.

Richard

[David Thornley]

In article <D%O_6.76201$R7.13...@typhoon.kc.rr.com>,

Mike Snyder <wy...@prowler-pro.com> wrote:
>> BASIC is generally unportable and not very powerful.
>
>BASIC might not be portable, but it's perfectly suited for non-portable IF.

Under most circumstances, non-portability is not considered a virtue.
If you just don't care about portability, using one of the IF languages
(TADS, say) is IMNSHO better suited. You can get a lot of functionality
out of TADS fast. (Presumably this is equally true of Inform and other
languages I'm not as familiar with.)

>Lunatix: The Insanity Circle (12th in IF-COMP '99) was QuickBASIC. I wrote
>it in a month. If a person had the inclination to do so, something even
>better could be possible.
>

No doubt something better would be possible, although I'm not the
person to judge, not having played Lunatix. There is nothing in
the way of conventional IF that cannot be done in BASIC, Inform,
TADS, COBOL, or Intercal, so that's not a meaningful statement.

It may be worthwhile to do a one-off in a language you're
familiar with, but if you're going to make a practice of writing
IF you're almost certainly better off learning Inform or TADS.

As I've said elsewhere, the IF community is not large. Using
MS Windows-only systems cuts you off from a certain part of it.
Using BASIC, as opposed to one of the more specifically IF
languages, means you're working in a very small community, with
many fewer people to answer questions and contribute code.

[David Thornley]

In article <a3qmjtgvdnf4jrqqm...@4ax.com>,

Alex Warren <al...@asparagus.co.uk> wrote:
>David Thornley wrote:
>
>> BTW, what is PowerBASIC? Is it at all standard?
>
>PowerBasic is a company that makes compilers. Last time I looked (a few years
>ago) they offered a compiler for DOS (presumably what is being used here), plus
>Windows console-mode and DLL compilers. Rather quick they are too, apparently -
>faster than QuickBASIC and VB.
>

OK, so it's a one-off commercial product. This is the sort of thing
I usually want to avoid. I am sufficiently vain to think that things
I do should outlast a single product from a single company. Other
people may feel differently.

>As for standards, PB differs a bit from QB and VB, but since there's no ANSI
>BASIC to my knowledge, any talk of standards in BASIC is rather meaningless.
>

There have been three or four standards, the latest being ISO. AFAIK,
TrueBASIC adheres fairly closely to the standard. The fact that you
don't know about the standard suggests that it isn't as influential
as, say, the C standard.

(The standard was published in 1991, which means that it's only
likely to be available in the very expensive dead tree version,
rather than the affordable PDF version the more recent standards
come in. Not that most people want to deal with the language
standard anyway.)

>
>> Fifty years from now, if IF in its current form
>> lasts that long, people will still be able to play Anchorhead
>> and enjoy it, but they may not be able to play WFPC easily.
>
>I'm sure there will be a retro MS-DOS/MS-Windows scene in the future just as
>there is with BBC Micros etc. today.
>

No doubt, but how many people have it installed is another question.
IF junkies are going to have TADS and zcode interpreters as a matter
of course, just like they do now. (On my Mac, I have several
interpreters, including TADS, HTML-TADS, zcode, Hugo, and Alan.
I don't have an emulator for CP/M, Apple II, or any Intel OS
installed.)

[Alex Warren]

David Thornley wrote:

> >I'm sure there will be a retro MS-DOS/MS-Windows scene in the future just as
> >there is with BBC Micros etc. today.
> >
> No doubt, but how many people have it installed is another question.
> IF junkies are going to have TADS and zcode interpreters as a matter
> of course, just like they do now. (On my Mac, I have several
> interpreters, including TADS, HTML-TADS, zcode, Hugo, and Alan.
> I don't have an emulator for CP/M, Apple II, or any Intel OS
> installed.)

I would argue that it's probably just as easy/hard to install an interpreter to
allow whatever is the fashionable adventure game format to run as it is to
install an emulator to allow x86 EXE files or similar to run. In fact I would
say that, in the future, it may even be easier, due to the huge number of
Windows/DOS programs out there today, to find a Pentium emulator in the year
2050 than it will be to find a Z-Code or similar interpreter.

[Adam Biltcliffe]

Some are born Garth Dighton. Some achieve Garth Dighton. But
rec.arts.int-fiction had Garth Dighton thrust upon it:

> SPOILER WARNING - Much heavier spoiler than David's
>

> >F
> >R
> >O
> >B
> >O
> >Z
> >Z
> >M
> >A
> >G
> >I
> >C
> >S
> >P
> >O
> >I
> >L
> >E
> >R
> >S
> >P
> >A
> >C
> >E

[Hunter, In Darkness]

> As I understand it, while the maze is dynamically generated - it's still
> Wumpus, which is a fairly limited number of rooms (20, I think).

I may be mistaken, but I believe you're wrong on both counts. The maze
has 32,768 (or possibly 65,536) rooms, and the connections are
generated by some kind of arcane mathematical formula (and aren't
necessarily two-way) which is the same from game to game. I believe
the maze may appear to be dynamically generated because the player
starts in a random room each time, giving the appearance of a
different maze.

I believe Zarf's intention was to create a maze which appeared
realistic and yet could not be mapped or navigated by brute force.

jw

[Andrew Plotkin]

> [Hunter, In Darkness]

32768. I didn't want to worry about interpreters messing up the modulo
operator on negative numbers.

I did retain the Wumpus convention of having exactly three exits from
each room.

> and the connections are
> generated by some kind of arcane mathematical formula (and aren't
> necessarily two-way) which is the same from game to game. I believe
> the maze may appear to be dynamically generated because the player
> starts in a random room each time, giving the appearance of a
> different maze.

You always start in the same room. There are two formulas for the
exit-path, however, depending on which branch of the plot you're
following. (They exit at two different locations.)

> I believe Zarf's intention was to create a maze which appeared
> realistic and yet could not be mapped or navigated by brute force.

More precisely: a map which *could* be mapped by brute force -- no
random changes of anything; you can find your way back to the same
room twice. In fact, if you use any simple rule for moving, you're
almost certain to wind up back in the starting room, and get stuck in
a loop from there.

You can even drop objects, and find them waiting for you when you
return to that room.

However, mapping the *whole* thing will take an unreasonable *amount*
of brute force, and in any case won't get you out of the maze.

(I hoped this would rapidly become obvious to the player. In fact, it
didn't -- not for all players. Learn from my mistake.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* It's about the vote, stupid!

[Richard Bos]

Alex Warren <al...@asparagus.co.uk> wrote:

> David Thornley wrote:
>
> > >I'm sure there will be a retro MS-DOS/MS-Windows scene in the future just as
> > >there is with BBC Micros etc. today.
> > >
> > No doubt, but how many people have it installed is another question.
> > IF junkies are going to have TADS and zcode interpreters as a matter
> > of course, just like they do now. (On my Mac, I have several
> > interpreters, including TADS, HTML-TADS, zcode, Hugo, and Alan.
> > I don't have an emulator for CP/M, Apple II, or any Intel OS
> > installed.)
>
> I would argue that it's probably just as easy/hard to install an interpreter to
> allow whatever is the fashionable adventure game format to run as it is to
> install an emulator to allow x86 EXE files or similar to run.

On a Mac, yes. On a Psion Series 5, no.

Richard

[SteveG]

I tracked this down for you.

John Holder's homepage is now at
http://members.home.net/j-holder

His parser essay is at
http://members-http-3.rwc1.sfba.home.net/j-holder/intfiction/parser.html

By the way, if anyone finds errors in or has suggestions for the raif
FAQ then please email me about them. I won't always notice comments
about the FAQ posted in raif threads. Thanks.

The most up-to-date version of the raif FAQ can be found at
http://www.textfire.com/raiffaq/

-- SteveG
remove _X_ from my address to send me email

[Todd Nathan]

Thanks so much for the reference. Now, if we could get someone
to do the same in CLOS, that would be COOL!!! ;'P

\t

Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote in message
news:3B3A7561...@cosc.canterbury.ac.nz...

[Jonadab the Unsightly One]

an...@cats.ucsc.edu (Andrew W Frederiksen) wrote:

> Oddly enough, I'm using Fortran to write my epic sequel, 'The
> Eigencave, Part 2 - 3i'. A sample transcript follows.

[...]

> > TAKE EIGENVALUES
> (from the matrix)
>
> Ha-HA! They're imaginary!

ROFL. There are some things Fortran does do well.

- jonadab

[Jonadab the Unsightly One]

Alex Warren <al...@asparagus.co.uk> wrote:

> I would argue that it's probably just as easy/hard to install an
> interpreter to allow whatever is the fashionable adventure game format
> to run as it is to install an emulator to allow x86 EXE files or
> similar to run.

Oh yeah? Try it. Installing frotz is a matter of gunzip and
tar -xvf and play. Installing WINE, and getting it to work, and
getting it to work with any given app, is an exercise in pain
tollerance, even on an Intel box, much less on anything else.

- jonadab

[Anders Hellerup Madsen]

Jonadab the Unsightly One skriver:

Installing WINE - In 10 easy steps

1. Download the WINE source-code
2. Unzip, Untar, Un-wahtever the WINE source-code
3. Type ./configure
4. Type make depend && all
5. Switch to root user (not needed if you are not doing a system wide
install)
6. type make install
7. create a directory called windows or something in your Home
directory. Create a directory called system inside the windows directory
8. edit the wine config file: Erase all drive parts except the one that
points to the Home dir. Change that to c:
9. edit the wine config file: Change the "c:\windows" and
"c:\windows\system" strings to the directories created in step 7.
Remember that ~/ is now c:\
10. Wine is installed and working. Note that you can skip the compiling
part if you prefer to use .rpm or .deb pakages and can find one that
fits your system.

There, done. Now install directX and the htmlTADS reader.

Anders

[Joe Mason]

In article <3B4EC0F8...@hellerup-madsen.dk>,

Anders Hellerup Madsen <and...@hellerup-madsen.dk> wrote:
>Jonadab the Unsightly One skriver:
>>
>> Alex Warren <al...@asparagus.co.uk> wrote:
>>
>> > I would argue that it's probably just as easy/hard to install an
>> > interpreter to allow whatever is the fashionable adventure game format
>> > to run as it is to install an emulator to allow x86 EXE files or
>> > similar to run.
>>
>> Oh yeah? Try it. Installing frotz is a matter of gunzip and
>> tar -xvf and play. Installing WINE, and getting it to work, and
>> getting it to work with any given app, is an exercise in pain
>> tollerance, even on an Intel box, much less on anything else.
>
>Installing WINE - In 10 easy steps

Wow. You have a bizarre idea of 'easy'.

>1. Download the WINE source-code

First off, this isn't as easy as it sounds. It's been my experience that you
need a different version of WINE for different apps. A lot of stuff just won't
work with the older versions, but you can never be sure the latest snapshots
will be stable.

>2. Unzip, Untar, Un-wahtever the WINE source-code
>3. Type ./configure
>4. Type make depend && all
>5. Switch to root user (not needed if you are not doing a system wide
>install)
>6. type make install

Now we get to the not-easy part:

>7. create a directory called windows or something in your Home
>directory. Create a directory called system inside the windows directory
>8. edit the wine config file: Erase all drive parts except the one that
>points to the Home dir. Change that to c:
>9. edit the wine config file: Change the "c:\windows" and
>"c:\windows\system" strings to the directories created in step 7.
>Remember that ~/ is now c:\

Sure, I understand this. I've installed WINE a couple of times. But how is
fiddling with config files *easy*? This is at least three times as much work
as it takes to install Frotz.

>10. Wine is installed and working. Note that you can skip the compiling
>part if you prefer to use .rpm or .deb pakages and can find one that
>fits your system.
>
>There, done. Now install directX and the htmlTADS reader.

How do I install DirectX? Where do I get it from? (I already have it on my
Windows partition, and I always just point WINE to that. But if you're
installing it from scratch on a completely non-Windows machine, I have no idea
what I'd do here.)

Installing Frotz - in 5 easy steps:

1. Download the Frotz source code.

ftp://ftp.gmd.de/if-archive/infocom/interpreters/frotz/frotz-2.41.tar.gz or
.../xfrotz-2.32.1.tar.gz for an X version

2. Unzip, Untar, Un-whatever the Frotz source code.

Un-tar, to be precise. tar zxvf <filename>.tar.gz
If your version of tar doesn't recognize the z switch, gunzip <filename>.tar.gz
and then tar xvf <filename>.tar
Then go into the directory just created (cd <filename>)

3. Type make

4. Switch to root user (not needed if you are not doing a system wide install)

5. Type make install.

Frotz is installed and working. Note that you can skip the compiling part if
you prefer to use .rpm or .deb packages and can find one that fits your system.
(There are RPM's of 2.32 on GMD in the same directory. I should really update
them, I guess. For Debian, 'apt-get install frotz' will get 2.40.)

Notice there are half the steps, and the ones that are missing are the hard
ones.

Joe

[Alex Warren]

As I recall the original post was to do with future-proofing games and whether
it would be easier in the future to run a TADS game or some equivalent DOS or
Windows EXE file.

Given that EXE is a somewhat popular executable format I should think that, in
the future, if x86 vanishes, it will still be possible to run EXE files on the
latest systems via emulation.

I was not talking specifically about current incarnations of things such as WINE
which from what Anders Hellerup Madsen says looks rather hideous, following the
Linux approach to ease of use.

But then I expect setting up an Acorn Electron emulator on a computer in 1982
would have been a bit of a pain. Today systems such as ElectrEm
(http://electrem.emuunlim.com) make running programs for older systems on new
computers rather easy. "And so it shall be with EXE" is my prophecy.

Alex Warren

[Jonadab the Unsightly One]

Alex Warren <al...@asparagus.co.uk> wrote:

> Given that EXE is a somewhat popular executable format I should think that, in
> the future, if x86 vanishes, it will still be possible to run EXE files on the
> latest systems via emulation.

Possible, sure.

> I was not talking specifically about current incarnations of things such as WINE
> which from what Anders Hellerup Madsen says looks rather hideous, following the
> Linux approach to ease of use.

It's the Windows part that makes WINE a pain. Well, and the
fact that it _is_ an emulator, and the target (emulated)
system is not publically specified in detail. (frotz is
arguably an emulator too, but the target system (the
z-machine) has a detailed public specification, and that
changes everything. Even so, many of the emulations are
less than perfect.)

> "And so it shall be with EXE" is my prophecy.

That surely explains why older EXEs made to run on DOS 3
on an 8086 with a CGA monitor are so _easy_ to get to
run on a current PC? (Try it.) Or why Windows 3 apps
run so _well_ in Windows Me? (Try it.)

I think you're being a tad optimistic.

- jonadab

[Alex Warren]

Jonadab the Unsightly One wrote:

> > "And so it shall be with EXE" is my prophecy.
>
> That surely explains why older EXEs made to run on DOS 3
> on an 8086 with a CGA monitor are so _easy_ to get to
> run on a current PC? (Try it.) Or why Windows 3 apps
> run so _well_ in Windows Me? (Try it.)
>
> I think you're being a tad optimistic.

I don't have much in the way of old EXEs to try, but I seem to recall
"Paratrooper" from 1982 works perfectly well under Win98 and I've never had any
trouble with the few Win3.x programs I've tried. If my usual computer wasn't
being repaired I could verify that something like QuickBasic runs perfectly
under Win2k as well.

Still, this misses the point a little - newer versions of operating systems
don't usually have full backward compatibility in mind, whereas with an emulator
"backward compatibility" is the sole point of its existence.

Alex
--
Alex Warren
al...@axeuk.com
Quest - make adventure games easily - http://www.axeuk.com/quest/

[L. Ross Raszewski]

On Sat, 14 Jul 2001 00:35:54 +0100, Alex Warren <al...@asparagus.co.uk> wrote:
>Jonadab the Unsightly One wrote:
>
>> > "And so it shall be with EXE" is my prophecy.
>>
>> That surely explains why older EXEs made to run on DOS 3
>> on an 8086 with a CGA monitor are so _easy_ to get to
>> run on a current PC? (Try it.) Or why Windows 3 apps
>> run so _well_ in Windows Me? (Try it.)
>>
>> I think you're being a tad optimistic.
>
>I don't have much in the way of old EXEs to try, but I seem to recall
>"Paratrooper" from 1982 works perfectly well under Win98 and I've never had any
>trouble with the few Win3.x programs I've tried. If my usual computer wasn't
>being repaired I could verify that something like QuickBasic runs perfectly
>under Win2k as well.

At a guess, I'd say that the problems suggested with old DOS programs
all stem from a single source; it used to be common practice to rely
on the CPU speed to get the timings right in games, rather than the
"proper" way of relyign on the system clock. Games which use no-op
loops to make the timing work run too fast under modern processors.
Of course, it has nothign at all to do with portability or
compatability; it has to do with shoddy coding.

Now, on the windows front, my word processor was written for windows
3.1. It ran perfectly well up until a few months ago, when, for no
clear reason, it started crashing on shutdown. Think it's a dll thing,
but I'll be damned if I can trace it.

[Anders Hellerup Madsen]

Joe Mason skriver:

> Wow. You have a bizarre idea of 'easy'.

No, it seems people have a bizarre idea that editing config files is,
per default, hard. This is somewhat true, but the changes you have to
make to the Wine config files are very small, and the files themselves
are really not that hard to understand.

> >1. Download the WINE source-code
>
> First off, this isn't as easy as it sounds. It's been my experience that you
> need a different version of WINE for different apps. A lot of stuff just won't
> work with the older versions, but you can never be sure the latest snapshots
> will be stable.

It's a long time since you used Wine isn't it. These days the latest
version will most likely do, and it will run nearly anything.

> >2. Unzip, Untar, Un-wahtever the WINE source-code
> >3. Type ./configure
> >4. Type make depend && all
> >5. Switch to root user (not needed if you are not doing a system wide
> >install)
> >6. type make install
>
> Now we get to the not-easy part:
>
> >7. create a directory called windows or something in your Home
> >directory. Create a directory called system inside the windows directory
> >8. edit the wine config file: Erase all drive parts except the one that
> >points to the Home dir. Change that to c:
> >9. edit the wine config file: Change the "c:\windows" and
> >"c:\windows\system" strings to the directories created in step 7.
> >Remember that ~/ is now c:\
>
> Sure, I understand this. I've installed WINE a couple of times. But how is
> fiddling with config files *easy*? This is at least three times as much work
> as it takes to install Frotz.

When fiddling with the config files boiles down to deleting a few
sections, and changing three lines I think most people would find that
it's not that big a deal. But OK, installing frotz is easier. I just
think that the few extra minutes you have to spend on getting Wine to
work doesn't quallify it as being *hard*. Perhaps I could go for,
*relatively easy, but still just a bit harder than installing a program
that requires no configuration at all*

Anders

[Jonadab the Unsightly One]

Alex Warren <al...@asparagus.co.uk> wrote:

> I don't have much in the way of old EXEs to try, but I seem to recall
> "Paratrooper" from 1982 works perfectly well under Win98 and I've
> never had any trouble with the few Win3.x programs I've tried.

Sure, and Solitaire works fine under WINE, but plenty of other
things _don't_.

> Still, this misses the point a little - newer versions of operating
> systems don't usually have full backward compatibility in mind,

One of the major selling points of Windows '95, in theory, was
full backward compatibility. Of course, that's marketroidese,
but if you can't believe MS about what MS had in mind, who can
say _what_ they had in mind (other than $$$)? I don't honestly
believe a better DOS emulator will be produced.

- jonadab

[Jonadab the Unsightly One]

lrasz...@loyola.edu (L. Ross Raszewski) wrote:

> At a guess, I'd say that the problems suggested with old DOS programs
> all stem from a single source; it used to be common practice to rely
> on the CPU speed to get the timings right in games, rather than the
> "proper" way of relyign on the system clock. Games which use no-op
> loops to make the timing work run too fast under modern processors.

Only the oldest things break that way. But _many_ DOS apps
break under Windows. Even things like Lotus 123 don't work
properly. The DOS version of Descent doesn't work right in
Win 95 either; runs fine in DOS 6 on the same PC. I could
list a couple dozen such programs, but the list isn't important.

- jonadab

[John Colagioia]

Jonadab the Unsightly One wrote:

These are--from what I know of the problem--mostly changes to the BIOS and
DOS (software) interrupt system. For those people who don't know the
setup, DOS doesn't really have an API like most systems. Instead, it
usurps the interrupt-handling mechanism to provide services.
Unfortunately, while backward-compatibility has always been a concern for
the "Microsoftians," it's not always feasible when something is in need of
an overhaul.

I've heard that the FreeDOS people, however, have done a pretty darn good
job of reproducing old versions of DOS. There was, if I'm not mistaken, a
project or two to do the same for Windows, but that fell apart when too
many people joined who wanted "better" than Windows, if I remember
correctly...

[John Colagioia]

Jonadab the Unsightly One wrote:

[...]

> One of the major selling points of Windows '95, in theory, was
> full backward compatibility. Of course, that's marketroidese,
> but if you can't believe MS about what MS had in mind, who can
> say _what_ they had in mind (other than $$$)? I don't honestly
> believe a better DOS emulator will be produced.

Definitely take a look at FreeDOS.
http://www.freedos.org/
http://freedos.sourceforge.net/compat.html (known compatibility list)
They're not there, yet, but they're doing a darn good job, from what I can
see...