diff --git a/prod/resources/text-files/medium.txt b/prod/resources/text-files/medium.txt index d60fd39..4a711c2 100644 --- a/prod/resources/text-files/medium.txt +++ b/prod/resources/text-files/medium.txt @@ -1,4 +1,4 @@ -:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.: +:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:. -----=====Earth's Dreamlands=====----- (313)558-5024 {14.4} (313)558-5517 A BBS for text file junkies @@ -805,467 +805,467 @@ in the safe, Watson," said he, "and get out the papers of the Conk-Singleton forgery case. Good-bye, Lestrade. If any little problem comes your way, I shall be happy, if I can, to give you a hint or two as to its solution." -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. - - --> 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. - -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. - +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. + + --> 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. + +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. + Aesop's Fables Translated by George Fyler Townsend