And now for a few words from our sponsor... Elves '87 is a Christmas text adventure written using David Betz's ADVSYS Version 1.2. Many thanks to David for all the work that went into ADVSYS, I think now that ELVES is finished we have some appreciation for the amount of effort required. We lost count at 600 hours+ of programming time that went into ELVES '87, not to mention several trips to the North Pole and to the local malls to check the facts with the old elf himself. Elves '87 is actually the second adventure we've done with ADVSYS. The first, (known as just ELVES) was done with the original version of ADVSYS and the original runtime package which David provided at the time. Well Christmas '86 came and went and most of what we tried to do in ELVES had flopped. It turned out that about all we could get ADVSYS to do was give us room descriptions, allow us to pick up objects and run around the adventure. This was pretty boring and we nearly gave up on ADVSYS. We started looking around for another method of producing text adventures. I even went so far as to consider writing something totally from scratch using Modula-2. The thought of writing my own parser scared the daylights out of me. So Marlene and I kept looking. We played some with EAMON but found it lacked any real substance. We kept thinking of the potential of ADVSYS. Then we came across Version 1.2 (advsys) and I tried again to improve on the original ELVES. I still found the documentation and the runtime package sadly lacking. ELVES remained essentially a cute little 'joke' for our local users group to chuckle over. It wasn't until two things happened that we decided to take another crack at it. First in April I found ADVRUN.ARC on a Citadel BBS in Minnesota. I do a bit of long distance (very long distance from Halifax) modeming and had been watching for signs of ADVSYS life out there. ADVRUN.ARC contained a more advanced runtime package and a very simple sample adventure. In May, David's article appeared in BYTE magazine which helped to lift some of the fog surrounding ADVSYS. We had the tools to rebuild ELVES. We considered ourselves armed and dangerous and decided to re-write the ADVRUN runtime package. The accompanying arc file contains our version of the runtime code along with full sources for ELVES. Files with the .BOA extension (BOA stands for Burnt Out Adventurers) are the more generic runtime files with verb and actions, etc. .ELV files are those specific to ELVES containing object descriptions. In August ELVES '87 was born. We set about in earnest to re-write our original Christmas adventure. All went well until about October. We hit the limit of the ADVSYS compiler. ARGH! Too many actions! OK, no problem we said, we'll just have to re-write it, we've got time... Two weeks later the re-write was done only to hit the compiler limit AGAIN. This time in the DATA department. I was ready to throw in the towel. I sulked for a weekend and then hit upon the idea of recycling objects within the adventure. I created a new concept of FLOORS in the game. Floor 1 would be all the rooms and objects at the North Pole. Floor 2 would be all the South Pole parts. We even recycled Frosty The Snowman into a Penguin. Frosty becomes Percival Penguin depending on where you are in the game. Percival has a completely different personality and keeps track of his inventory separately from Frosty. By recycling objects we were able to greatly reduce the load on the compiler. The FLOORS concept makes liberal use of SETP to modify objects relative to which floor of the adventure you are on. Percival/Frosty is an indepently moving Actor. The only limit to his movement is that he has to stay on one floor. I've numbered FLOORS 1 2 4 8 16 etc, although only 1 and 2 are used in ELVES '87. My only real regret now that ELVES '87 is finished is that I didn't comment the source code. Some of it is pretty obvious but the XLISPish brackets can make for some pretty odd looking code. (If(I(never(see)another)(bracket))again)(It will)(be((too)soon)) As we were writing ELVES it never crossed our minds that someone else might actually be interested in our source code. Also, the addition of the FLOORS concept half way through writing the adventure really messed up that neat and tidy modularity I was trying to maintain in the sources. Bits and pieces of code were moved and shoved all over the place. At three in the morning (which often was the case) if it runs without crashing, who cares if the code is commented. My biggest frustrations with ADVSYS came from three areas. I found the ADVSYS docs to be very sketchy. It's easy once you know how, but in the beginning the docs weren't much use. The BYTE article really helped there. Second frustration was from the inability of the compiler to interpret long complex statements. No error gets generated, it's just that the adventure doesn't work correctly. After hours of examining the code, I finally broke the complex statement into two simpler statements and everything worked 100%. Moral of that story is KISS (Keep It Simple Stupid). Third frustration was just in the overall limits on the compiler. As I said, we hit the limit for ACTIONS and DATA on more than one occasion. In the very end we stripped ELVES '87 down to the point where we couldn't even add one more SYNOMYM. Perhaps my coding is just really sloppy. If anyone can show me a way/s to cut it down some I'd been very happy. If you browse through the source code you'll find a few items which were commented out at the last minute due to space restrictions. At the very last minute as were preparing the finishing touches we accidentally created a minor bug which we didn't take time to fix. There is an error in the calculation of the total weight an actor is carrying. You may find that you have to drop more items than you would think normally necessary in order to pick up large items. This should only be a minor annoyance and will not affect successful completion of the game. Several other minor bugs in the original ARC'd release of ELVES '87 at Christmas time have been corrected in this version of the sources. We haven't looked for the WEIGHT bug. If you find it please let me know and I'll fix it at my end. In the meantime we're putting ELVES behind us and are planning on re-writing the runtime package to make the code tighter and to better facilitate FLOORS and object recycling. We are already doing research for the next BOA! adventure. What I'd like to see in upcoming versions of ADVSYS would be: 1. Higher limits on data and actions for the compiler or alternatively a way to call another adventure file from within the current adventure. I don't think this is as far fetched as it sounds if the second file was written in such a manner as to be compatible with the first. I very well could be totally out to lunch on this last part. I would think it would all depend on exactly how ADVSYS keeps track of everything. You most likely would have to write out the status of Part A to some kind of temporary data file. Probably just easier to expand the compiler limits. 2. An external PEXEC call (on the Atari ST version, don't know what you call it in MSDOS Land) which could be used for possibly a graphics loader or even call another game from within ADVSYS. Picture this... You enter the Arcade room in StarShip Columbus, instead of playing Murray, you grab for your joystick and play a game of Space Invaders. Of course we'll need a pipeline open from the outside routine to pass a parameter back to the ADVSYS calling routine. How about a system variable which we can poll for the result of the outside call? I'd even settle for the ability to run a graphics loader and be able to create text/graphic adventures. (Alas, I am not a C programmer or I'd try to add this myself. I use Modula-2, GFA Basic and Assempro) I'm not asking for a loader of course, as this is very machine/ resolution specific. I'll write the loader, etc, I just need to be able to make an outside call with parameters passed to and from ADVSYS and the routine being called. Possible parameters passed to the outside routine could be the name of a picture file to load, the player's current score, health status, etc. Parameters passed back to ADVSYS could include error messages (File not found, etc), a score from an outside game of blackjack, etc.... 3. In ELVES '87 we had a @#$# of a time creating output which might look like this... _____________________ | | | Text Goes Here | |_____________________| In the end we had to resort to.... ............................................................................ ............................_____________________........................... ...........................|.....................|.......................... ...........................|....Text.Goes.Here...|.......................... ...........................|_____________________|.......................... ............................................................................ and call it a piece of "lined note paper". This was the more generic way of doing it as ADVSYS takes repetitions of white spaces and compresses them into a single space. Since we thought ELVES '87 was to be aimed only at our local ATARI user's group we resorted to VT52 control codes for direct cursor addressing and clearing the screen. VT52 codes were used in the diary, for the "It's too dark to see" routine and the clear screen at the end of the penguin map. While it would have been possible to use control codes, we used the ...... method above for the penguin map as it was too complex and would have required far too much effort to direct cursor address that much information onto the screen.. I'd like to see a way of inputting literal text strings and have them reproduced verbatim including all white space characters. I realize that this negates the ability of ADVSYS to modify it's output for variable screen width but most machines supporting ADVSYS are 80 column anyways. This should only affect online BBS gaming with the 8 bit crowd. Apologies to those of you who are using computers that won't support the VT52 control codes. We have used them several places in ELVES '87. Feel free to modify the sources to give proper display for your terminal type. Features I particularly liked in ADVSYS, but didn't know they were there from the docs include... Passing the screen size (rows and columns) to ADVSYS as parameters when the interpreter loads. This could be particularly useful in a BBS environment where the same game could be provided with both 40 and 80 column screen width. Creation of a game log file. Again passed as a parameter when ADVINT loads. Great for play testing. We could run ELVES '87 with a journal file open and let someone play away to their heart's content without watching over their shoulder. We were able to view the entire game at our leisure after the person had finished playing. The game only slows down slightly from increased disk read/write cycles but on the hard drive this wasn't noticeable. Unfortunately with a Christmas deadline fast approaching us, we did not get to have ELVES '87 play tested to the degree which we would have liked. There were quite a few minor bugs in the release which was posted to Usenet in mid December. Greatly under-utilized features of ADVSYS which I plan to explore further... Probably the most powerful, yet least used are the bitwise operators. I scratched the surface of their potential with the FLOORS idea but suspect we could reduce a lot of code by setting bit flags rather than wasting an entire integer to see whether the player has gone potty or not. Will have to check that one out. Might take more code to do the bit check than if you just used BOOLEAN logic on integer values. An area I'm still foggy in are the OPTIONAL/REQUIRED/FORBIDDEN flags. I had no problem with OPTIONAL, but haven't tried working with REQUIRED or FORBIDDEN yet. Yet another concept I didn't really work with.... SUPER-CLASS. Would like to see some more source code examples of how to use it efficiently. I was just using (class obj). I suspect one of the reasons that our code is more verbose than possibly it could be is that I did not approach CLASS in a more organized fashion. We ended up with a hybrid combination of our own work together with the ADVRUN runtime package. There are a lot of ADVRUN remnants which need to be stripped out or reworked. The key to creating a successful ADVSYS adventure is in the development of an intelligent runtime package. I would be VERY INTERESTED in working together with others on the development of a standardized series of runtime modules. Individual adventure authors could readily add their own runtime enhancements in the form of additional modules but I'd like to see a foundation worked out. Here are some of the concepts which would be common to most adventures and should be developed as part of the Advanced Runtime Package (can we agree to use a .ARP extender on each module filename?). Some work will no doubt be required to sort out Integral Parts, Stationary Things, etc... It's just that there is no sense in each author re-inventing the wheel with every new adventure that's written. Here's that short list of a few concepts I'd like to see incorporated in addition to the obvious ones like movement directions, basic things, etc...: Floors - so we can recycle objects, rooms and actors as required to keep within the limits of the ADVSYS compiler. Actors - independently moving if desired similar to Frosty in ELVES '87 but with more interaction with the player. "Frosty, get the fork." Fuses & Demons - timed events based on the players actions in the adventure. Events - one-time events that only occur at given points in the action. Perhaps the first time a player enters a room or picks up an object. We need something generic here rather than coding each as entirely separate. Similar to the VISITED? flags maybe? In ELVES we worked around this by putting some things in the Long Description of the object or room. This worked fine as long as the player didn't do a LOOK in the room again. Sometimes you get an awkward response back. Try it in the first couple of rooms in the ice floes. I'm sure there's lots more, this is at least a start. ****************************************************************************** Well enough rambling for one text file. Hope the comments and questions above can generate some discussion. Bruce MacKay January 04/87