|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: R T
Length: 4307 (0x10d3) Types: TextFile Names: »README«
└─⟦b20c6495f⟧ Bits:30007238 EUUGD18: Wien-båndet, efterår 1987 └─⟦this⟧ »EUUGD18/General/World/README«
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