(This is the "Dungeon Designs" column from the September 1993 issue of the Eamon Adventurer's Guild newsletter. Copyright 1993 Eamon Adventurer's Guild, 7625 Hawkhaven Dr., Clemmons, NC 27012-9408. You may reproduce this freely as long as this credit remains attached to the article.) Designing and Testing your Eamon Adventure by Tom Zuchowski The hardest part about writing your own Eamon adventure is designing it. It's really hard to decide how to organize and enter the data and how best to test and debug the completed piece. Here is a grab-bag of thoughts and techniques that I have used in writing my own Eamons. The Design Long before you begin data entry for your new Eamon adventure, plan out as much of the map as you can. Actually draw a free-hand map on paper. Once the map is drawn, mark it into individual "Eamon rooms". Plot where puzzle clues, puzzle solutions, special effects, plot development, secret doors, etc. will go in this map. Assign as many monsters and artifacts as you can. Make copious notes on how each part of the adventure is to work. Nothing clears your head like writing it down. The more you get straight at this point, the easier your adventure will be to construct. Reason out now how your special events will work. Decide how the event will be triggered. What the player will see. How it will affect everything that may be in the room. Work out as many details as possible, or else you may discover later that your all-important special event is impossible to implement. For example, suppose that you envision a sentry who will sound the alarm if he happens to spot you, destroying the Quest's chances of success. You may decide that the only way the alarm can be safely avoided is for the player to shoot him with an arrow before he enters the room occupied by the sentry. Well, we have a few problems here. The player won't know that the sentry is there until after he enters the sentry's room, when it will be too late. If he is somehow informed that there is a sentry in the next room, he won't be aware that the sentry can be killed from a distance. Informing him that this can be done, and how it can be done, has the potential of making this a very klunky and unsatisfactory special event. I solved this very special event in "Assault on Dolni Keep" by making it a certain companion's decision and job to shoot the sentry without any intervention on the player's part. I executed this with Effects that were triggered by entry into the adjacent room. And when the sentry's room is entered, his arrow-shot body is found on the ground at the player's feet. If I do say so myself, this particular event reads and plays well enough. But if I hadn't planned this in advance, I might have been forced to delete the sentry from the scenario, which would have made it much less believable. Data Entry I find that the adventure is less difficult to build and execute if you separate the map and plot into several sections that can be entered and largely debugged section-by-section. Any problem is easier when it can be broken into smaller pieces which can be solved individually. adventure writing is no exception to this rule. I tend to enter the data for each section, and playtest and debug just that section before entering the next one. Then once the entire adventure has been entered and each section debugged, you can concentrate on debugging any problems that appear when playing the entire adventure at once. Once you have completed data entry, use DUNGEON LIST 7.0 to print out your entire database. Print rooms, monsters, artifacts, and effects. Use these printouts to cross-check for errors. Believe me, you will find many things to fix! Skimping on a bit of printer paper at this point will make it just that much harder to straighten out the inevitable errors. Once you have fixed all of the errors discovered through cross-checking, print it out again! You will find this printout to be an extremely valuable reference while playtesting. Playtesting My method for playtesting an adventure is to play it as far as it will go, taking notes about problems that I see as I progress. Make an effort to try something new every time you go through a room or solve a puzzle. You'll be amazed at the holes in your plan that you overlooked. If you're careful and thorough, you may find that a single playthrough has given you an entire page of problems to correct. Fine. At the end of the playthrough, fix all the problems in the database and in your special programming. Then play it through again. If you make that effort to try different approaches to your puzzles and obstacles, you may continue to find problems for several playthroughs. The more complex your adventure and special programming is, the more problems you will probably have to fix. Timed events (such as the sudden appearance of a certain monster or the printing of a special effect at a particular point in the play) are a bit trickier to get completely debugged. I'm talking about the kind of event that only happens when a predetermined set of other events have occurred. Unless your map is very narrowly and rigidly drawn so that nothing can occur out of sequence, this type of event needs special attention during playtesting. Be sure to try as many ways to get around the special event as you can think of. Every time you play, try to think of some new action to try that will cause the event to not take place as planned. It's quite likely that you will find a good many holes to plug! Needless to say, playing and replaying your adventure over and over again does get real old, real quick. This is where my method of building it in sections helps. Once you have debugged one section, it is very simple to add a temporary line to the MAIN PGM to skip over the part already completed. For example, let's say that you have completed and debugged rooms 1-40, and you wish to skip ahead to room 41 for advanced playtesting. Your scenario says that a successful adventure at this point requires that you be carrying artifact #7 and that you be accompanied by monster #1 and #3. Your special programming requires that variable Z1 and Z5 be set to 1. Adding this line will enable you to "jump ahead" to room 41 for playtesting purposes: 31500 R2 = 41: A%(7,4) = R2: M%(1,5) = R2: M%(3,5) = R2: Z1 = 1: Z5 = 1: GOTO 3500 I typically will make several of these lines for different places in the adventure, and will add them all to the MAIN PGM with REM's so that they are ignored. Then when I need to use one, I merely remove the REM from the front of the line to activate it. Don't forget to delete this line when you are through playtesting! Some suggestions Don't make your character specially super-strong or immortal for the purposes of playtesting. Playing with such "cheater" characters will give you a very warped idea about what it will be like for others to play your adventure. Just when you think that you have got it perfect, play with a "normal" character may reveal that it is impossible to survive! Well, okay, it's all right to use an immortal character during the early phases of testing the individual sections. But if you do this, be sure to play the entire adventure through about six times with a "normal" character to be sure that you have pegged the difficulty right. Some may differ, but I would define a "normal" character in this range: HD, CH, AG = 20; all weapon abilities = 50; armor ability = 20; all spell abilities = 70; gold = 10,000; two swords with 10% complexity and 2D8 damage ability; plate armor and shield. If your adventure requires a stronger character or abilities, it is up to you to make the extra power available in the actual adventure. You can make special potions and weapons available to pump up the character, or you can provide powerful companions to take up any slack. I used the "powerful companions" option in both "Thror's Ring" and "Dolni Keep", and pumped up the character in "Walled City of Darkness". Either method works well. If you pump up the character to really high levels, it's a good idea to shrink him most of the way back down before returning him to the Main Hall. If your adventure has puzzles to be solved for special events, be sure to plan for the super-characters, too. A significant percentage of Eamon players like to use super-strong characters with nuclear-weapon-level weapons to crash through everything in sight. If you have a vault door with a strength of 900, these guys will simply beat it down instead of figuring out how to open it. This kind of thing is fairly easy to defeat with special programming, but you must plan ahead. For an example, in "Walled City", I had a number of supernatural foes who could only be destroyed by a special weapon that the player had to obtain in the adventure; and use of the player's strong magical weapons were rigged to do more harm than good!