games/adventure-systems

From gnat@kauri.vuw.ac.nz Tue Sep 6 01:06:59 1994 From: gnat@kauri.vuw.ac.nz (Nathan Torkington) Newsgroups: rec.arts.int-fiction,news.answers,rec.answers Subject: Adventure Authoring Systems FAQ Supersedes: Followup-To: rec.arts.int-fiction Date: 31 Aug 1994 12:00:04 GMT Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand. Distribution: world Reply-To: Nathan.Torkington@vuw.ac.nz NNTP-Posting-Host: kauri.vuw.ac.nz Originator: gnat@kauri.vuw.ac.nz Archive-name: games/adventure-systems Maintained-by: Nathan.Torkington@vuw.ac.nz Last-changed: Thu Jun 30 11:13:13 NZT 1994 ---------------------------------------- Changes: * ftp.gmd section ---------------------------------------- This is a list of systems that can be used to author adventure games. Information about TADS, ADVSYS, ADL, OASYS, INFORM and ALAN can be found here. Where possible, pointers to existing information (such as books, magazine articles, and ftp sites) are included here, rather than rehashing that information again. If you haven't already done so, now is as good a time as any to read the guide to Net etiquette which is posted to news.announce.newusers regularly. You should be familiar with acronyms like FAQ, FTP and IMHO, as well as know about smileys, followups and when to reply by email to postings. For more information on interactive fiction in general, pointers to books and dissertations, and this group's focus, see David Graves' "Frequently Asked Questions (FAQ)" posting, which appears periodically in rec.arts.int-fiction. This FAQ is currently posted to rec.arts.int-fiction and news.answers. All posts to news.answers are archived, and will then possible to retrieve the last posted copy via anonymous FTP from rtfm.mit.edu as /pub/usenet/news.answers/games/adventure-systems Those without FTP access should send e-mail to mail-server@rtfm.mit.edu with "send usenet/news.answers/finding-sources" in the body to find out how to get archived news.answers posts by e-mail. This FAQ was mostly written by Nathan Torkington, with numerous contributions by readers of rec.arts.int-fiction. Credits appear at the end. Comments and indications of doubt are enclosed in []s in the text. Each section begins with forty dashes ("-") on a line of their own, then the section number. This should make searching for a specific section easy. If you suffer loss in any way, shape or form from the use of information in this file, then Nathan Torkington expressly disclaims responsibility for it. It's your own damn fool fault if you go broke, detonate your computer or eat broccoli as a result of anything you read here. As a final note, this FAQ should be regarded as volatile. If this version is more than two months old, you should consider acquiring a new version. See the instructions above for details of how to do this. Contributions, comments and changes should be directed to Nathan.Torkington@vuw.ac.nz ---------------------------------------- List of Answers 1 What to look for in a system 2 Writing your own adventure 3 TADS 4 ALAN 5 ADVSYS 6 ADL 7 OASYS 8 INFORM 9 Interactive-Fiction FTP Site Z Credits ---------------------------------------- 1 What to look for in a system --> Sample adventures, written using the system. This will make learning how to program the system easy. It will also show you the workarounds for any clumsiness in the language. Hookahs --> The ability to handle non-player characters. This means that players should be capable of being addressed, eg "amy, take the cat" should be a valid command to type. Players should be capable of having turns in the background (to allow movement, thieving, etc). --> The ability to handle events that occur independent of players actions (often called fuses and daemons). Fuses are scheduled events, such has having the bomb detonate three turns after the fuse is lit. Daemons are routines that are called once every move. --> Documentation. You need, at least, a reference page. Sample code helps, and a full explanation of the order that routines are called by the game kernel (eg ADL calls the following for each direct object: the actor's action, the verb's preaction, the indirect object's action, the direct object's action, then finally the verb action. If any one of these procedures returns a true value, then that procedure is assumed to have completed the command handling for that direct object, and processing continues for the next direct object. After all the direct objects are handled this way, the room's action is called and the kernel continues). --> Distribution mechanism. Is the game code fully yours to use? Do you have to pay a fee for commercial distribution? For shareware distribution? For free distribution? Are you obligated to offer the source code to the game interpreter as well as your compiled adventure? --> Is it object oriented? If so, you will probably have an easier time of writing your adventure -- text adventure worlds lend themselves to object orientation better than some other forms of simulation. Of course, learning the subtleties of the OO method might be harder than writing your game using a traditional (non-OO) system. --> Is the game language functional or procedural? That is, does the language look like LISP (lots of parentheses) or a kind of cross between BASIC and C (curly braces {} are a dead giveaway for C lookalikes). You might have to learn a whole new programming style if you write your adventure in a language style that you are unfamiliar with. ---------------------------------------- 2 Writing your own adventure Dave Librik posted Dave's Quick Guide To Getting Started with TADS, which was so good that I've generalised it to cover most adventure systems. Above all else, the key to learning how to write adventures is to start writing one. Practice not only makes perfect, but trial-and-error makes passable too. You will need the following: --> a language/kernel reference manual for your adventure system. You might have to register your system to get this. --> printouts of sample adventures. Staple each printout, so the printouts won't get lost or confused. Also print out any standard libraries that the system comes with (eg adv.t in TADS or standard.adl in ADL). Now: --> familiarise yourself with the basics of the language. Subtleties (syntax details, daemons, fuses) should be left for later -- just the basic ideas of objects, inheritance (if your language is OO), printing text. It might help if you already knew a language in the same style (procedural or functional) as the language you will have to program in. --> read the sample adventures. Get a feel for how items and rooms are defined. This step is fairly important -- you will write most of your adventures by strategically stealing the way someone else has written theirs (software professionals call this "code reuse" -- we call it laziness). --> make a copy of one of the simpler sample adventures. Take out all the stuff specific to that adventure (rooms, players, objects, etc) and just leave the verbs, the initialisation code, and the definition of the player's character. Now start writing your own adventure. Start simple -- a couple of rooms and some objects to take. --> add more complicated things. For ideas of things to add, it helps to have played some adventures. Try adding code for doors, containers, other actors, new verbs, fancy verbs that need indirect objects. Use the sample adventures that came with the system as a reference for using things. --> if the sample adventure you modified included standard code for players or startup (std.t in TADS), then include those libraries and customise them to your taste (you should have no trouble reading and understanding the code by now). Add any of your own initialisation code to this. --> when you want to start making significant changes to the behaviour of the adventure, you will have to change any standard libraries that your adventures includes (standard.adl in ADL, adv.t in TADS). Whenever you make a change, comment at the top of the file why you make the change, and exactly what you changed. This is so that when your later adventures need any of the features you have added, it will be easy to add them. It also helps when newer releases of the adventure system arrive -- you can make the changes to the new standard library with minimal hassle. --> now realise that what you have written is a practice game. It probably wasn't well laid out, or well planned, or even consistent. To write your Real Adventure, you will have to go through some serious Design and Implementation. The classic Colossal Cave adventure has been rewritten in TADS by Dave Baggett and is available in source from the IF archive (see Section 9) in the directory if-archive/games/others/ccr.tar.Z The documentation to INFORM (see section 8) contains a wealth of material relevant to designing adventure games under any system. This is highly recommended for those wishing to write their own games. ---------------------------------------- 3 TADS TADS stands for "Text Adventure Development System". It is available for MSDOS, Atari ST, Macintosh, Sun, SGI, Linux, DEC/MIPS, and NeXT computers at the moment. It is available via anonymous FTP as msdos.archive.umich.edu:msdos/games/adventure/tads.zip mac.archive.umich.edu:mac/game/gameutil/tads2.1.cpt.hqx atari.archive.umich.edu:atari/Games/Tads/tads.lzh ftp.gmd.de:if-archive/programming/tads/ but these are not the latest versions (at the time of writing). The latest version, TADS 2.1, features virtual memory, expanded C-like syntax, improved documentation and an improved debugger. TADS is released by High Energy Software, and is shareware. Shareware games can (and have) been written using TADS, and commercial distribution of games written using TADS seems allowable. TADS consists of a compiler (which converts the source code to adventures into TADS game code) and an interpreter (which reads the TADS game code produced by the compiler and lets users play the game). Registered users get a form of the interpreter which can be combined with the game code file to form a single executable for distribution. The interpreter is licensed for shareware use, you don't have to pay a penny if you distribute your games via shareware. If you plan to sell it commercially, contact Mike Roberts for information on getting the rights. The TADS language is declarative and object-oriented. It appears very C-like, and the syntax shouldn't be too difficult to learn by people who know C or Pascal. The language provides a basic syntax, some text manipulation and support for object-oriented programming. The interpreter provides parsing, question-and-response I/O format, and activation of the appropriate methods in objects depending on what the player types. The language has support for actors, fuses and daemons. TADS comes with the source to a trivial adventure, and source to an Infocom quality game ("Ditch-Day Drifter"). On registration of the package, a manual can be obtained. The manual for v1.* is very good (although it doesn't explain well the contents of the standard library file, adv.t). The v2.1 manual is apparently twice the size of v1. The prices for versions < 2.0 are: TADS shareware fee: 25.00 Includes printed TADS Author's Manual, the current TADS software on specified media, plus the source code for "Ditch Day Drifter," a complete sample game. Deep Space Drifter: 10.00 Includes "Deep Space Drifter" on the disk media specified above, plus a complete map of the game and the DSD Hint Book. California residents please add 7% sales tax. The price of v2.1 is US$40 (+ California sales tax for California residents, $3 for shipping and handling within the US and Canada, or $8 for international air mail). If you register "Deep Space Drifter" at the same time, the total is only US$50 (plus sales and shipping). For more information, contact: --> BBS: 415 493 2420 (set modem to 14400-N-8-1) --> CompuServe: 73737,417 --> GEnie: M.ROBERTS10 --> Internet: 73737.417@compuserve.com --> US Mail: High Energy Software, PO Box 50422, Palo Alto, CA 94303. ---------------------------------------- 4 ALAN The Alan System is a special purpose language for creating interactive fiction or text adventures. It consists of a compiler which compiles Alan source to an intermediate form and an interpreter that interprets such an intermediate form. The Alan language was designed to give the maximum functionality from as little code-writing as possible. This means: --> the system provides default behaviour for many things (which the author can override). --> the system directly supports locations, objects, actors and other concepts natural to the domain of interactive fiction. --> the author can extend the allowable input of the player, and connect actions to that input. It is also a safe language in the sense that extensive compile-time checking makes it nearly impossible to produce a game that crashes or behaves inconsistently. The language is declarative and very close to English. It supports fuses and daemons by use of events, and is object-inspired (all declarations are local to entities, but no inheritance). The Alan System is request-ware. The complete system is available without charge through electronic mail. Send a message with a single line: SEND INFO to alan-request@softlab.se for more information. The complete distribution includes the compiler, the documentation, a 100+ page manual in plain text and postscript versions, some examples and the interpreter with debugging support. The interpreter can be redistributed with your games, so this seems to open the way for commercial and shareware release. The manual is available from the IF archive (see Section 9) in the directory if-archive/programming/alan/manual.zip The current version of Alan is 2.4 which runs on Sun/UNIX, Amigas, PCs (MSDOS and OS/2) and VAX/VMS. A major revision of the manual is planned, and a larger game is also being worked on for release. The authors may be contacted at: alan-request@softlab.se pseudo-mail-server for deliveries thoni@softlab.se gorfo@ida.liu.se ---------------------------------------- 5 ADVSYS ADVSYS (ADVenture SYStem) was written by David Betz, and the latest version (1.3) is based on the 1986 release of 1.2 which seems more prolific. This package consists of LaTeX and ASCII documentation, C source code for the compiler and interpreter, and the source code for several sample adventures (as well as a demonstration library). It was written up in Byte magazine [reference here]. The language is LISP-like, and object-oriented. The game has no knowledge of the difference between actors, objects, locations, etc -- all this must be present in the game code. As such, the runtime library is rather more complex than might be desired. Actors, fuses and daemons can all be implemented easily. There is [somewhere] a library of code developed by the (now-defunct) ADVSYS mailing list. This provides rather better code than the library distributed with ADVSYS, and includes containers and limits to containment. The documentation says "Permission is hereby granted for unrestricted non-commercial use". You might have to contact David Betz to ask about commercial and shareware distribution. ADVSYS was posted to comp.sources.games, and appeared in volume 2. It can, therefore, be found on any FTP site that archives it. Two such FTP sites are: ftp.uu.net:/usenet/comp.sources.games/volume2/advsys wuarchive.wustl.edu:/usenet/comp.sources.games/volume02/advsys An ANSI C version is available, on the IF Archive site (see section 9). ---------------------------------------- 6 ADL ADL (Adventure Design Language) was written by Ross Cunniff and Tim Brengle. The package posted to comp.sources.games consists of plain ASCII documentation, C source for a compiler, interpreter and debugger, and several sample adventures (ranging from the complex to the very simple) which illustrate the various features of ADL. ADL is a declarative, semi-object-oriented language. It has the concept of methods (procedures that are attached to objects) but not inheritance. This means that an object-oriented style of programming will be rather inhibited. The language recognises actors, locations and objects as being distinct. Fuses and daemons are supported in the language. A standard library comes with the package, that gives a firm foundation to write games on. The documentation is very close to being excellent, and contains a full language reference. The documentation doesn't appear to contain any guide to distribution of anything but the source code. Therefore it may be legal to distribute the compiled interpreter with your game. For more information, you should contact the authors at: USMAIL: Ross Cunniff 636 La Grande, #7 Sunnyvale, CA 94087 ---------------------------------------- 7 OASYS OASYS stands for Object-Oriented Adventure System. It was distributed in comp.binaries.ibm.pc in 1992, and is available from any FTP site which archives cbipc. It was written by Russell Wallace, who is reachable via e-mail as RWALLACE@vax1.tcd.ie. The package has documentation, two sample adventures, C source for the compiler and interpreter, and MS-DOS binaries for the compiler and interpreter. The source is missing an include file (Russell will provide it on request) and shouldn't be very difficult to port to non MS-DOS systems. Glass Pipes The language is declarative, and (not really) object-oriented. The major limitation of the parser is that it forces the player to type the adjectives along with the noun ("ceramic key" must be typed, even if there are no other keys accessable). This may be fixed later. Actor support is provided, and players can issue commands to other actors. [fuses? daemons?] There don't appear to be any legal restrictions, so you can probably distributed compiled interpreters with your commercial/shareware/free games. ---------------------------------------- 8 INFORM INFORM was written by Graham Nelson at Oxford University, UK. It is a compiler that produces Infocom story files. There are many public-domain interpreters for these files, available from the Interactive Fiction archive site. The compiler is written in ANSI C, and is freely available (but not public domain). It produces version-3 files from a fairly C-like source language, and can produce version-5 files as well (an important innovation since they are twice as large --- Trinity-sized instead of Zork-1-sized). The documentation (in the same package as the source) contains a description of INFORM, as well as a specification of the story file form. It also contains enough articles for a short book on game design, which are not specifically about INFORM. Two example games are included, one medium-sized and one trivial. Both the source files and the story files are included. There are also fully modifiable libraries, which are heavily commented. INFORM is genuinely free, and the rights to a game it produces belong to the author of the game. ---------------------------------------- 9 Interactive-Fiction FTP Site The FTP site ftp.gmd.de:/if-archive contains most, if not all, of the software mentioned here as well as interpreters for Infocom games, source and binaries for many other games and sundry information files too numerous to mention. ftp.gmd.de:/if-archive is mirrored in wuarchive.wustl.edu:/doc/misc/if-archive. The latest FAQ is stored here as if-archive/info/authoring-systems.FAQ and as if-archive/programming/general-discussion/authoring-systems.FAQ ---------------------------------------- Z Credits Nathan Torkington , David Librik , Dave Baggett , Thomas Nilsson , Graham Nelson , Volker Blasius and the documentation for the various systems mentioned here.

Posted in: