DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: R T

⟦15ec985d2⟧ TextFile

    Length: 4307 (0x10d3)
    Types: TextFile
    Names: »README«

Derivation

└─⟦b20c6495f⟧ Bits:30007238 EUUGD18: Wien-båndet, efterår 1987
    └─⟦this⟧ »EUUGD18/General/World/README« 

TextFile

This is the portable "C" version of my text adventure game "WORLD".
It is a large game in the flavor of Adventure or Zork, and about as large.
It is, however, a "sci-fi" type game somewhat like the commercial
Infocom games "Planetfall" or "Starcross", but much larger.

The code is written to be quite portable. However, it does make a few
assumptions. These are:
1.     Seven bit ASCII
2.     short int is at least 16 bits
3.     It MAY assume 2's complement arithmetic; I'm not sure.
4.     the read and write IO routines have to work for a second
       argument which is a pointer to short

If your computer doesn't conform to those requirements, the program
"vtxtcn" and the routine "speak" in "helper.c" will most definately
need to be rewritten. There may be other problems as well, particularly
if your machine sets the high bit of a char.

The program has been tested and compiles and runs properly on the following
systems:

1)  VAX/VMS Digital CC compiler. No particular tricks are needed.
2)  IBM PC-AT Xenix 1.00. It seems to be necessary to use the large
    memory model, although I'm not sure why since it runs on the
    same machine under DOS in the small model.
3)  IBM PC under Microsoft C version 4.00. It works in the default
    small memory model if you compile with the -Os switch. Note
    that on this setup you MUST link the main program World with
    binmode.obj, provided by Microsoft, for it to work right.
    Vtxtcn and vcnvrt must NOT be linked with binmode.obj.
    This compiler generates a few harmless warning messages.
    You may need to use EXEMOD to increase the stack size.
4)  VAX/4.3bsd Unix. No particular tricks needed.

    Instructions for generating world:

Once you have unpacked all the files, compile (and link if necessary)
the preprocessor "vtxtcn.c". Then execute it. It will create a few
.inc files and the run-time text base file "q1text.dat".

Then compile, (link) and execute "vcnvrt.c". It will generate more
.inc files.

These .inc files generate the actual game data which is compiled
into the final game program "world".

The main program, which contains seven files world.c, demons.c, helper.c,
motion.c, parser.c, verbs1.c and verbs2.c is then compiled and,
if necessary on your machine, linked. See above for possible special
switches or link files for your machine. Special handling probably
is not necessary for un-segmented Unix machines. Edit the file helper.c
to change the pathname for the data file (q1text.dat), if desired.

The output of the above compilation process is the game program
which should be named "world". It and "q1text.dat" are all that is
necessary to run the game. The game generates save-position files called
"world.sav".

A note on the file q1text.dat: this file is written as an array of
shorts, rather than chars. It is so arranged, however, that if it is 
in fact considered as bytes, there are absolutely linefeeds or
carriagereturns sent to it. Thus on a record oriented machine like the
VAX/VMS, it is a single record. On the IBM-PC/DOS, no conversion from
lf to lf/cr or vice versa is ever required. Save files, on the other
hand, may accidentally contain any control characters, so on a system
like DOS in which the normal text mode does conversions of lf to lf/cr
pairs you must use the special binary mode. None of these considerations 
should apply to Unix. 


Bugs: There are no known bugs. However, some are certain to show up if
it is compiled on different machines, or if players exercise parts
of the code I haven't frequently played with. Please send them to me.

There are Fortran versions of this game for the VAX, PDP-11, IBM-PC, and
Apple Macintosh which implement a niftier user interface than this version.
They will appear eventually (but not in source code) on various bulletin
boards. The Mac version features the full Mac interface.

No claim is made to the effect that this program is an example of "good"
programming practice, whatever that may be. In particular, anyone
who can untangle the spaghetti in scan() will be awarded 8 assorted kazoos
and 4 Bronx cheers.

Please don't cheat by reading the text file!
Cheating by reading the code is only slightly more cowardly!

Doug Mcdonald
Department of Chemistry
University of Illinois
Urbana Ill. 61801


address: mcdonald@uiucuxe