![]Eamon Adventurer's Guild Online](../images/EAGonline2-inverse.gif){kind=small}
|
|
|
One important aspect of good dungeon design is sometimes overlooked by the author. This is the job of making the player's task of mapping the dungeon interesting and straightforward, rather than an irritating chore. The ease or difficulty of mapping will affect the player's enjoyment, and the rating that the dungeon receives will gain or suffer as a result.
I am not suggesting that the author shouldn't put mazes or confusing passages in the dungeon; that is an important part of adventuring. What I am talking about is the room description that gives lots of detail and color, but doesn't give the room's correct name nor list the available exits.
Let me give you a fictional example of just what I am talking about. Imagine that the player has just entered a room in a dungeon, and gets the following description:
YOU HAVE JUST ENTERED A LARGE, CATHEDRAL-LIKE ROOM. THE CEILING VAULTS HIGH OVERHEAD. A COUCH IS SET AT ONE END ON A HIGH DAIS, ALONGSIDE AN ALTAR-LIKE CABINET
OK, so the player draws this room on their map, and labels it 'Cathedral Room'. But then, when they reenter the room later on, they find the room's name is VIP HALL or QUEEN'S CHAMBER or something similar that has nothing whatever to do with the room's description! And then they have to make a mess of their map, scratching out, or erasing, or just trying to remember which room is which.
There is a second problem with the above description: it doesn't give a clue what the exits from the room are. This is a valid design stratagem when the author is forcing a minor puzzle on the player, or is hiding something off in a corner of the room, and wants the player to have to search for it. But if it is a simple room, with ordinary doorways, then it is good form to list them somehow. In adventures that have a quest with a time limit imposed on the player, this kind of missing information can become quite irritating.
To correct the above problems, the room description can be rewritten to something like the following:
YOU HAVE JUST ENTERED THE QUEEN'S CHAMBER. A LARGE CATHEDRAL-LIKE ROOM, THE CEILING VAULTS HIGH OVERHEAD. A COUCH IS SET AT ONE END ON A HIGH DAIS, ALONGSIDE AN ALTAR-LIKE CABINET. THERE ARE DOORS NORTH AND WEST.
But this rewritten description has problems of its own. There is an absolute limit of approximately 6 lines for a given description. The above 'corrected' description uses up 50-odd characters in making the necessary additions to ease mapping chores. As Eamon authors know, 6 lines is often not nearly enough to squeeze in all of a room description.
One solution is to put this information somewhere besides the room description. The Eamon version 6.2 MAIN PGM addresses this by adding some programming that prints the normal exits just before the 'YOUR COMMAND?' prompt. The 6.2 code for this is as follows:
205 C = 0: PRINT "EXITS ARE ";: FOR X = 1 TO ND: IF RD%(X) > 0 AND RD%(X) < = NR THEN PRINT C $(X);", ";:C = 1 207 NEXT : IF NOT C THEN PRINT "NON-EXISTENT ";
Now, our example description will look like this:
YOU HAVE JUST ENTERED A LARGE, CATHEDRAL-LIKE ROOM. THE CEILING VAULTS HIGH OVERHEAD. A COUCH IS SET AT ONE END ON A HIGH DAIS, ALONGSIDE AN ALTAR-LIKE CABINET.
EXITS ARE NORTH, WEST
Another solution is to put the second half of room descriptions in the Effects, and them print both the Room Description and the corresponding Effect, thus getting 12 lines of text instead of the normal 6. A good example of this method can be found in #145 'Buccaneer!'. In this adventure, Pat Hurst has put the first 6 lines of each room description in the room location in the EAMON.DESC file, and also put 6 MORE lines in an Effect of the SAME number. The applicable code from his program is as follows:
130 VZ = ( INT (V%(RO) / 2) = (V% (RO) /2)): IF NOT VZ THEN PRINT DK$;"READ EAMON.ROOM NAMES, R;"RO: INPUT A$: PRINT DK$: PRINT "YOU ARE ": PRINT " ";A$: PRINT 140 IF VZ THEN PRINT DK$;"READ EAMON.DESC,R";RO: INPUT A$: PRINT DK$: PRINT A$: PRINT :V%(RO) = V%(RO) + 1:EF = RO: GOSUB 60
60 PRINT DK$;"READ EAMON.DESC,R" ;EF + 200: INPUT A$: PRINT D K$: PRINT A$: PRINT 63 RETURN
Examining the above, code, you can see that line 140 prints the room description, then calls the small subroutine at 60 to print the corresponding effect. This is a very simple, elegant solution to the problem of printing long descriptions.
Yet another way to free up the entire 6 lines for describing the room is to print the Room Name every turn, even when the Room Description is to be printed. This can be done by deleting the code in line 130 that tests for the description flag, as follows:
130 PRINT DK$;"READ EAMON.ROOM NA MES,R";RO: INPUT A$: PRINT D K$: PRINT "YOU ARE ";A$ 140 IF INT (V%(RO) / 2) = (V%(RO) / 2) THEN PRINT DK$;"READ EAMON.DESC,R"RO: INPUT A$: PRINT DK$: PRINT A$: PRINT: V%(RO) = V%(RO) + 1
This code would give us the following example:
YOU ARE IN THE QUEEN'S CHAMBER
YOU HAVE JUST ENTERED A LARGE, CATHEDRAL-LIKE ROOM. THE CEILING VAULTS HIGH OVERHEAD. A COUCH IS SET AT ONE END ON A HIGH DAIS, ALONGSIDE AN ALTAR-LIKE CABINET.
From here, it is a simple matter to tack the visible room exits onto the end of the room name, so that it reads like this:
YOU ARE IN THE QUEEN'S CHAMBER (N/W)
or:
YOU ARE IN THE QUEEN'S CHAMBER (NW)
I personally favor the last example, in which the room name is always printed on every turn, and the visible exits are printed without slashes on the end. This has the added bonus of allowing the author to hint that there is something special about the room by not printing the exits. Thus the alert player will think to look for hidden exits or unmarked corners.
But all of the above methods are good ones. The important thing is to take some of the drudgery out of dungeon exploration. Then the player has more fun, and your adventure gets better ratings!
*** VARIABLES
Real ARRAY variables use 5 bytes each, while Integer ARRAY variables use only 2. Thus DIM AD%(100,9) consumes 2000 bytes of memory, but DIM AD(100,9) uses 5000 bytes! Always use Integer for large arrays.
Real SIMPLE variables use LESS memory than Integer SIMPLE variables, and execute faster, too. ALWAYS use Real Simple variables.
Applesoft only 'sees' the first two characters of a variable name. It can't tell a difference between DIE and DIS, which can cause you some real trouble. Short names also save memory. Use short variable names.
*** LOOPS
Consider the following routine:
7420 FOR A = 1 TO NA: IF AD%(A,4) < > ROOM OR AD%(A,2) < 2 OR AD%(A,2) > 3
THEN 7440
7430 PRINT MN$(OF);" PICKS UP";AN$(A):(other statements):RETURN
7440 NEXT:RETURN
This routine has 3 serious problems: 1)Applesoft finds GOTO lines by going to the beginning of the program and checking EVERY line number until it finds it. You have all seen times when a monster broke its weapon during a fight, there were no weapons lying about the room, and things slowed down a LOT each time that monster's turn to fight came up. The above code is responsible. 2)Line 7420 does 3 comparisons for EACH artifact tested, even if the artifact isn't in the room. 3)Line 7430 does a RETURN, leaving an OPEN LOOP. This leaves all of the loop's 'housekeeping' on the program stack, which is only 256 bytes long. If we use up the stack, eventually it 'overflows', and the program crashes with an OUT OF MEMORY error. Note that the program is not really out of memory. This is the cause of Eamon's OUT OF MEMORY problem.
Now look at this routine:
7420 FOR A = 1 TO NA: IF AD%(A,4) < > RO THEN NEXT: RETURN
7425 IF AD%(A,2) < 2 OR AD%(A,2) > 3 THEN NEXT: RETURN
7430 PRINT MN$(OF);" PICKS UP";AN$(A):(other statements):A = 999
7440 NEXT: RETURN
1)Line 7420 avoids doing the time-consuming GOTOs by doing its own NEXT. If it has examined all of the artifacts, the NEXT 'falls through', and the RETURN is executed. This is a huge timesaver. 2)Line 7420 only checks to see if the artifact is in the room. This way we avoid doing unnecessary comparisons. 3)Line 7430 sets 'A' to a number that is greater than NA. Thus when line 7440 is executed, the NEXT statement 'closes the loop', clearing the program stack.
The above listing was to illustrate some points. Here is the optimum listing:
7420 FOR A = 1 TO NA: IF AD%(A,4) = RO THEN IF AD%(A,2) = 2 OR AD%(A,2) = 3
THEN PRINT MN$(OF)" PICKS UP"AN$(A):(other statements):A = 999
7430 NEXT: RETURN
*** MINIMIZING COMPARISONS
Examine the following example: 510 IF RO = 17 AND MD%(5,5) = RO AND PW < 5 AND RND(1) < .5 THEN GOSUB 30000
In this line, all 4 comparisons are ALWAYS done, even if you are not in room 17. Now look at this: 510 IF RO = 17 THEN IF MD%(5,5) = RO AND PW < 5 AND RND(1) < .5 THEN GOSUB 30000
See how this code reduces the comparisons to just one.
510 IF RO = 17 THEN IF MD%(5,5) = RO AND PW < 5 AND RND(1) < .5 THEN GOSUB 30000
See how this line reduces the comparisons to just one. *** EXITING SUBROUTINES
NEVER use GOTO to exit from a subroutine! This is a VERY fast road to a stack overflow OUT OF MEMORY crash. Always use RETURN or POP:GOTO to exit from subroutines, so that the stack is cleared.
This tutorial is necessarily brief do to space limitations. If you have further questions, drop me a line.
Every time a string is modified or read into memory from disk, it is allocated to fresh memory space. Eventually all of the memory space is used up, and Applesoft executes what is called a forced FRE(0) garbage collection. When this happens, everything grinds to a halt until all the old, discarded strings have been identified and flushed from memory. This can take more than a minute on a large Eamon, and looks for all the world like a hung computer. Very large and complicated MAIN PGMs can lead to low levels of free memory for string storage that can result in excessive FRE(0) garbage collections, causing annoying delays in play.
There are several things that you can do to free up more memory (examples are for version 7.0):
1) USE VERSION 7.0: It uses a special string routine that drastically reduces the garbage accumulation, allowing uninterrupted program operation with about 1/8 the free memory required by version 6.2. The routine resides at lines 45-50.
2) DELETE UNUSED COMMANDS: A command can be completely deleted from the pgm. For example, if you have no drinkable artifacts, you don't need the DRINK command. To delete DRINK: change the number in line 31910 from '32' to '31'; delete 'DRINK,' from line 31920; delete '22000,' from line 290, and delete lines 22000-22190. Or you can:
3) 'DUMMY' UNUSED COMMANDS: A lot of code can be deleted by converting a command to a dummy that doesn't do anything. For example, to 'dummy' DRINK, delete lines 22020-22190, and change line 22010 to:
22010 GOSUB 4900: GOTO 94
4) MAKE A COMMAND ARTIFACT-SPECIFIC: For example, if you only have a single drinkable artifact in your adventure (eg: artifact #47), and it doesn't do anything to the player's health (eg: a river), you can delete lines 22020-22190 and replace them with:
22020 IF A < > 47 THEN 94 22030 PRINT "OKAY.": GOTO 98
Feel free to contact us for more information.
The Parameter option was introduced with the version 6 DDD. The programming for this option was left unchanged when the DDD was upgraded to version 7, so the following article applies to both versions.
The purpose of the Parameters option is to allow the author to add to and change the way the data is stored. This feature allows the author to 1) generate additional artifact types with unique data fields; 2) modify existing data fields; 3) change the default values of the data fields.
First, a few definitions:
ARTIFACT TYPE: type of artifact, such as WEAPON or READABLE. FIELD: one of the 8 pieces of data for an artifact. For example, Artifact Field #1 is VALUE. DEFAULT: the value that a Field will have unless it is changed by the author. FORMAT: the Field labels for a given Type.
Standard Artifact Data: 1: Value 2: Type 3: Weight 4: Room
Format #1 (Weapons) Format #6 (Door/Gate) 5: Weapon Type 5: Room Beyond 6: Odds 6: Key # 7: Dice 7: Strength 8: Sides 8: Hidden?
There are 9 such standard formats. For a complete list, see the DDD manual.
There are 3 rules which MUST be followed, or Terrible Things May Happen: Rule #1: Before entering any data, make all parameter changes. Rule #2: Always save the parameters if changes were made. Rule #3: Whenever resuming data entry or editing, be sure to load the parameters file first.
*** HOW TO ADD A NEW ARTIFACT TYPE
The best way to describe this is to step through an example. Let's add an artifact type for ridable things, such as cars, horses, airplanes, etc. The fields of this new format will be: Field 5: TYPE (0=car, 1=horse, 2=boat, 3=plane) default: 0 Field 6: SPEED (in MPH) default: 45 Field 7: # SEATED default: 4 Field 8: ARMOR default: 10
The steps are as follows:
RUN DUNGEON EDIT 7.0 Select: 6 SPECIAL FUNCTIONS Select: 8 CHANGE DATA ASSIGNMENTS Select: 6 ADD A FORMAT Enter the Fields and defaults described above Note that this is Format 10 that you are entering Select: 5 ARTIFACT TYPES Select: 12 NEW TYPE Enter the new type: RIDABLE Select: 6 SPECIAL FUNCTIONS Select: 8 CHANGE DATA ASSIGNEMENTS Select: 3 CHANGE FORMAT POINTER Enter '12' to select the RIDABLE Type Enter '10' to set the pointer to Format 10 Select: 7 RETURN TO MAIN MENU Select: 6 SPECIAL FUNCTIONS Select: 9 LOAD/SAVE CUSTOMIZED PARAMETERS Select: 2 SAVE PARAMETERS Enter a name for the Parameters file. It is recommended that you use PARAMETERS
That's it. What could be easier?
The next time that you start up DUNGEON EDIT 7.0 to continue your data entry, perform these steps:
Select: 6 SPECIAL FUNCTIONS Select: 9 LOAD/SAVE CUSTOMIZED PARAMETERS Select: 1 LOAD PARAMETERS Enter the name of the parameters file. If you can't remember it, type '?' to get a catalog.
TWO WARNINGS: 1) Every time that you add a new format, it will say that it is to be Format 10, even when it is not. You must keep track of how many formats you have so that you will know its real number. (Yes, this is a bug.)
2) When you reload the parameters file, the new Format Pointers are NOT set up correctly. In the above example, after reloading PARAMETERS, the Format Pointer for Artifact Type 12 will be 0, which points to the GOLD format. You must enter 6 (Special Functions), then 3 (Change Format Pointer), then change the pointer for Type 12 EVERY TIME that you run DUNGEON EDIT 7.0.
*** ADDING EXTRA DATA FIELDS
This option exists for both Artifacts and Monsters.
The Artifact option doesn't work right. DON'T USE IT.
The Monster option works OK, but you will be adding fields that are not supported by the MAIN PGM. Since you will have to make many changes to the MAIN PGM anyway, it is recommended that you add extra Artifact and Monster fields directly to the MAIN PGM, using DATA statements and the Applesoft READ command. It will probably be easier to do and remember, and won't make your data files non-standard.
*** SOME OTHER DATA ASSIGNMENT OPTIONS
1. MONSTER DATA: allows you to change the Monster Field labels.
2. ARTIFACT DATA: allows you to change the labels for Fields 1 - 4.
4. CHANGE A FORMAT: allows you to change the Format's labels and defaults for Fields 5 - 8.
*** SOME OTHER SPECIAL FUNCTIONS
7. CHANGE DEFAULTS: 1. ROOMS: aren't saved in the parameters file 2. MONSTERS: works OK 3. ARTIFACTS: changes Fields 5 - 8 only
*** SOME COMMENTS AND SUGGESTIONS
As you can see, changing the formats can be pretty complicated, and you must still keep track of a lot of things that are not stored in the parameters file. If your new artifact type will only have 2 or 3 artifacts, it may prove to be easier to do simple artifact number checking instead of messing about with adding new formats. For example, let's say that your RIDABLE artifacts are artifact numbers 12, 13, and 27. If you add a new format, every time your MAIN PGM wants to test if an artifact is ridable, you would use this test: 'IF A%(A,2) = 12 THEN...'. It would be much simpler to NOT generate a Ridable artifact type, but just make these artifacts Type 1, and use this test: 'IF A = 12 OR A = 13 OR A = 27 THEN...'. However, if you plan to have a lot of Ridable artifacts, then it might be better to go ahead and generate a special Type and Format for it.
The DUNGEON LIST programs do NOT support parameters.
Another option is to use an existing format in a new way. For example, a couple of Eamons are set in modern times and have a special 'Machine-gun' artifact type. It would have been better if the author had used artifact Type 3 (Magic Weapons) for machine-guns instead. Or you could make all treasures Type 1, and use Type 0 for a Special Artifact Type.
Finally, since you have to keep track of it all anyway, it is easiest of all to just use the USER Fields for your special stuff. For example, if you want to add a Food Artifact, you could use Drinkable Artifacts for both food and drink. Then use the USER 8 Field to distinguish between them, setting it to 0 for drink and to 1 for food, then testing A%(A,8) in the MAIN PGM.
One very important thing that you should also do, no matter which method you use, is to add some 'Author's Notes' to the intro program or as a stand-alone program, to explain what special Fields and Types you have used and how you have used any USER Fields.
------------------------------------------------------
As most of you know, John Nelson is up to his ears in IBM-Eamon these days. He is busily adding more features to the Eamon system. He is using QuickBasic, which is compiled, and is not planning to supply the source code with the basic Eamon Designer Disk. Therefore, since the average IBM-Eamon author won't be able to make changes in the basic IBM-Eamon system, John is adding a number of additional features and options which will seldom ever be used, but will be there for the author if he needs them.
John has added several new Artifact categories. We have no plans to implement any of these in Apple-Eamon at this time, but in the interests of standardization, we are describing them here. If you use these categories, it will make the job of porting your Eamon over to the IBM easier, since John's IBM-Eamon system will already recognize them. The categories are:
11: WEARABLE Especially armor. The version 7 Apple-Eamon supports this category to a limited extent; see the manual for details.
12: FOOD This category is easily implemented on the Apple as a subset of the already existing Category 6, Drinkable Artifacts. It is especially easy to do on version 7 by using the USER 8 field to distinguish between food and drink.
13: DRINK John has broken Drinkable Artifacts into two separate categories, reserving Category 6 for healing potions and poisons, and this category for all other drinkables. Note that Apple-Eamon does not make this distinction.
14: DISGUISED MONSTER A familiar example of this category is the good ol' Mimic of the Beginner's Cave. This kind of artifact will have a common name, like 'Treasure Chest'. But when it is acted upon, an Effect is printed that describes the transformation, the artifact disappears, and is replaced by the monster itself. This category has two important fields: 5. Effect number for transformation description 6. Number of Monster that appears
15: TRAP This is somewhat similar to the Disguised Monster described above. It appears to be an ordinary artifact until the player tries to do something with it. Then there is a random chance that the trap will be sprung. The fields for this are: 5. Percent chance that the trap will go off 6. Number of Effect describing the springing of the trap 7. number of dice for damage calculation 8. number of sides on dice.
How many times have you been blind-sided by a no-warning death trap while playing Eamon? How much did you enjoy having to start over again? Eamon authors seem to undergo some kind of strange compulsion to include in their own Eamons the very traps that they hate in others' Eamons. There are three reasons why Eamon authors install death traps:
1) They are practical jokers and think it's funny. RESPONSE: It's NOT funny to have to start over for no good reason and many people will quit if they have to start over too often.
2) They are giving proper responses to stupid player moves. RESPONSE: No one will intentionally kill himself off-if he made a stupid move then the warning clues were very poorly written by the author.
3) They consider it to be an essential part of the plot. RESPONSE: There are alternative methods that can be used that will fit the plot equally well.
ALTERNATIVES TO DEATH
Whenever I complain to an author about a given death trap, a response that I often get is that 'if it were real life, the player WOULD get killed there. I've got to be realistic.' Well, if it were real life, then the player would be really dead, and would never, ever again get to play the adventure. To continue this 'realism', the Eamon disk should erase itself when the player is killed. To carry this 'real life' thing to its ultimate absurdity, the player will have to quit Eamon altogether! The real issue here isn't realism, but sloppy adventure writing.
What this means is that an Eamon that is well-written for realism will be very survivable. Note that I said 'survivable', NOT 'easy'! A rule which all Eamon authors should closely follow is that it should be possible to escape, overcome, or endure anything that the player encounters in the dungeon. If a trap is unavoidable then it should be survivable at least 98% of the time. 'Pass/no pass' puzzles or riddles should send the player away to search for clues, not kill him or force him to battle supernatural opponents.
There are a number of ways that damage can be inflicted on the player when special effects are printed. Any trap will play well if minor to medium damage is inflicted. You can either inflict a standard amount of damage or can make it random. The methods are:
1) I recommend that you use a small set amount. The following will add 3 hit points to the player and then will jump to the melee routine to give a health status report:
DF = 0:D2 = 3: GOSUB 7636
2) A random hit from 0 to 4 can be given with this code:
DF = 0:D2 = INT(RND(1) * 5)): GOSUB 7636
3) If you want to make it truly dangerous with a chance of death, this code will randomly set the amount of damage to something between 0 and the character's total hardiness (M%(0,1)):
DF = 0:D2 = INT(RND(1) * (M%(0,1) + 1)): GOSUB 7636
4) A final alternative is to NEARLY kill the player by giving him hits that NEARLY wipe him out. This code will leave the player one hit point away from death:
DF = 0:D2 = M%(0,1) - M%(0,13) - 1: GOSUB 7636
THE DEATH TRAP
See if you recognize the following scenario: you are walking down a plain hall when you come to an unusual door. You open the door-no result. You pass thru the door, and are told that you walked into an atomic incinerator and have died! This is an example of the worst brand of 'Gotcha' death traps-no warning, no wind-up, and suddenly the game is over. There are four fair ways to have handled this same trap:
1) When the player attempts to open the door, open it, then print an effect that is similar to this: AS THE DOOR SWINGS WIDE, YOU ARE STRUCK BY A BLAST OF WHITE HEAT EMANATING FROM A ROARING INFERNO WITHIN. YOU HAVE FOUND AN ATOMIC INCINERATOR. Then if the player proceeds into the room, kill him.
2) When the player attempts to open the door, DON'T open it, but print an effect that is similar to this: AS THE DOOR SWINGS WIDE, YOU ARE STRUCK BY A BLAST OF WHITE HEAT EMANATING FROM WITHIN! YOU ARE STANDING BEFORE AN ATOMIC DISINTEGRATION CHAMBER! QUICKLY, YOU SLAM THE DOOR SHUT AGAIN!
3) Open the door but print nothing. When the player attempts to enter the room, do NOT actually move him into the room, but instead print an effect similar to this: AS YOU ENTER THE ROOM YOU ARE SEARED BY A BLAST OF HEAT! YOU REALIZE THAT YOU HAVE ENTERED AN ATOMIC INCINERATOR! QUICKLY YOU BACK OUT OF THE ROOM AND FLEE TO THE SAFETY OF THE HALLWAY!
4) Combine option (1) and (3). First give the warning from option (1), then if the player enters the room print the effect from option (3) to show him that he did something stupid. This option or option 2 is recommended; special effects are fun, and the player is not annoyed by needless restarts. It would also be appropriate to inflict some damage as outlined above.
DANGEROUS TRAVEL DIRECTIONS
Many Eamons are set in mountainous country, and it is not uncommon to have cliffs which will kill the player if he foolishly walks off of the edge. Typically, the room description will say something like THERE IS A CLIFF TO THE WEST. Note that it doesn't say how far away the cliff is, or even if it is the top or bottom of the cliff! Subsequently the player decides to go WEST to see if there is anything near the edge, or tries DOWN to see if the cliff can be climbed. Often the results are: YOU HAVE FALLEN OFF THE CLIFF! YOU HAVE DIED!
Now, think about this. In real life, no one is going to mindlessly walk off the edge of a cliff but will stop at its edge, and no one will attempt to climb down a sheer, unclimbable cliff face, either. The author forgets that a real adventurer would KNOW where the cliff edge was and if it was unclimbable. If the player blunders off the edge, then the failure was in the author's descriptions, NOT in the player's decision.
There are 3 valid solutions to this:
1) Simply make the room connection 0, thus using the standard message 'YOU CAN'T GO THAT WAY'. Not very imaginative, but it gets the job done. Remember, if it were real life, the player would KNOW he couldn't go that way because he would be able to see the cliff edge.
2) Make the room connection some random high value negative number, like (-900). Program some code in the 3070-3300 region in this fashion:
3070 IF R2 = - 900 THEN GOSUB 56: PRINT "THE CLIFF EDGE BLOCKS YOUR WAY.": GOTO 300
Notes: 'GOSUB 56' spaces one line and updates the line counter by 2 lines to allow for the text 'GOTO 300' exits the Move routine
3) Use a program line similar to option (2) that prints a special effect that is similar to this: YOU STEP TO THE EDGE OF THE CLIFF. EXAMINING IT, YOU SEE THAT IT IS TOO STEEP AND CRUMBLY TO BE SAFELY CLIMBED. SEEING NOTHING ELSE, YOU STEP BACK TO SAFETY. If the effect number was 15, for example, the programming would look like this:
3070 IF R2 = - 900 THEN GOSUB 51: R = 415: GOSUB 45: GOTO 300
Notes: 'GOSUB 51' spaces one line and increments the line counter by 1 Effects are in the 401-600 range, so effect #15 is record 415 'GOSUB 45' calls the description print routine
Don't make insulting comments like 'THERE'S A CLIFF THERE, STUPID!' If the player tried it, then the descriptions inadequately described the danger and the failure was the author's, not the player's.
An alternative to death by falling off a cliff is death by drowning. Remember the 'real life' rule when doing water hazards. The best way to handle water is with the standard 'YOU CAN'T GO THAT WAY' response, although the alternate 'YOU CAN'T SWIM!' is perfectly acceptable.
POISONS
I dunno about you, but I NEVER drink or eat anything unless I have first saved the game. In fact, I never eat or drink at all if I can avoid it; the occurrence of 'Gotcha' fatal poisons is all too common. There are two fair ways to handle poisons:
1) Give it non-fatal consequences as outlined above.
2) Give it a readable label. This is more difficult to accomplish because it requires that the poison be two different types of artifact at once (readable and drinkable). But is the best way, because it gives the alert player a chance to avoid being blind-sided. To accomplish this: (a) The bottle's description must mention that there is writing on it. It would be best to avoid mentioning a label, because the player is liable to try to READ LABEL instead of READ BOTTLE. (b) make it a drinkable artifact (type 6) but add a line to the READ routine to recognize this one artifact (for example let's make it artifact # 5 and make the writing effect # 2):
23015 IF A = 5 THEN R = 402: GOSUB 45: GOTO 300
ACTS OF GOD
This category includes random events that were added to spice up the adventure. You are all familiar with the old pre-version 7.0 POWER command's 'the ceiling falls on you' death trap. Other examples that come to mind are snipers in modern settings and falling rocks in caves and mountains. This kind of random thing is great for adding realism and excitement, but is patently unfair if it kills the player off. Any of the above examples would play well using one of the 'damage' options. Imagine this special effect: A RUMBLE COMES FROM ABOVE. SUDDENLY A HUGE BOULDER CRASHES ON THE PATH BESIDE YOU AND BOUNCES ON DOWN THE MOUNTAINSIDE! YOU ARE PELTED WITH LESSER ROCKS; ONE THE SIZE OF TWO FISTS JUST MISSES YOUR HEAD! Exciting, huh? And even though you as the author know that the player won't be killed by any such special effects, HE doesn't know it!
FAIR DEATH TRAPS
Is it possible to have a death trap that is fair? The answer is yes; there are two ways to do so:
1) Automatic Resurrection: it's acceptable to kill off the player if a means of resurrecting him can be worked into the plot. One such means can be found in #114 'Thror's Ring'; the player's companions will pull him back from foolish moves or resurrect him with a spell.
2) Progressive Deadliness: death traps are acceptable if some means is provided for the player to learn how to recognize them. One way is to have a series of similar traps that increase in deadliness but offer similar clues as to their whereabouts. An alternate method of doing this is to describe the trap's characteristics in the introduction or by some other means so that the player will know what to watch for.
The bottom line on the subject of death traps is playability. It is NOT fun to have to start over and replay old, stale ground, especially if the player had no control over his demise. And the more fun that people have with your adventure, the higher they will rate it. And the higher the rating, the more people will obtain and play your hard work.
Being somewhat new to the use of Effects in an Eamon game, I have sat down and written out a mini-manual for beginning Eamon designers. The use of Effects is not explained in great detail in the designer manual, and I sorely needed to understand them. After a letter of help from Tom Zuchowski, and the study of the Eamon games 'Eamon v7.0 Demo Adventure' and 'Assault on Dolni Keep', I understand them a bit better now. I wrote down the uses as I came across them, and a wide variety of uses did I find.
Effects can be used for several things. They can print on the screen the message on a note found in a bottle. They can print something when a sword is picked up. They can be used to 'scare' the player. Etc...
Below follow just a few examples of the uses of Effects. Different people use Effects for different uses. Don't let this be a guideline of how to use them, but rather use it to give you ideas of what to do with them.
For those who don't know (i.e. beginners), Effects are stored in EAMON.DESC, record numbers 401 through 600.
Basically, to print out an Effect, one would have a line like this in the MAIN PGM:
R = 401: GOSUB 45
Where R is the record number of the Effect to be printed. In this example, we are printing Effect #1. Since Effects are stored at 401-600, we must add 400 to the Effect number to get the record number. GOSUB 45 calls the subroutine that reads in and prints EAMON.DESC records.
But the question here is, where would one have an Effect in the program? One such place would be in lines 3070-3390 (MOVE). An example of a use in this area would be like this:
3070 IF R2 = - 300 THEN R = 425: GOSUB 45: GOTO 100
R2 is the room to be moved to. When the player tries to move to a room connection with a negative number, he is not actually moved. This allows extra programming to be added for special stuff. In this example, we are using a room connection of (- 300) to trigger the printing of Effect #25, or record #425. Such an Effect might be something like: THE CAR RACES PAST YOU, ALMOST HITTING YOU. THE DRIVER LEANS OUT THE WINDOW AND SHOUTS SOMETHING ABOUT BEACHES. Another example is: WALKING INTO THE CRUSHER, YOU BARELY JUMP OUT BEFORE IT FLATTENS EVERYTHING INSIDE OF IT!
Another interesting use of Effects would be this: you are climbing a mountain. Every now and then, this happens: SUDDENLY, A LARGE BOULDER COMES CRASHING DOWN, NOT 5 FEET FROM WHERE YOU STOOD A MOMENT AGO! This could be generated this way:
510 IF RO < 24 OR RO > 36 THEN 100
520 IF RND(1) > .7 THEN R = 401: GOSUB 45
RO is the current room number. In this example, the mountains are rooms 24 through 36, and the Effect is #1. 100 is the beginning line number of the YOU SEE code that prints what you see in the room.
Line 520 sets up a random number, which will be greater than 0 but less than 1. In this example, if it is .7 or less, the effect will not be printed. What this does is to set the odds to be 70% that it will not happen and 30% that it will. You can set this number to anything between .01 and .99.
Putting this code in the 500-900 programming area will cause it to print out after any monster attacks take place and before the 'YOU SEE' printout. Another good place to put it is in the 201-209 area, where it will print just before the YOUR COMMAND? prompt. If there isn't enough room in the 201-209 area, you can GOSUB to some free line numbers somewhere else.
Another Effect could be added to our 'mountain effects' like this. Imagine that we have 6 effects that are Effects #1-6:
530 R = INT(RND(1) * 6) + 1: IF R < 6 THEN R = R + 400: GOSUB 45
In this way it produces a random effect. Effect #1 might be the 'huge boulder' line printed previously. Effect #2 might be: YOUR HAND SLIPS! YOU BEGIN TO FALL, BUT CATCH YOURSELF AT THE LAST MOMENT! Effect #3 might be: TINY ROCKS BEGIN TO PELT YOU FROM ABOVE. IT APPEARS THAT SOMEONE OR SOMETHING IS THROWING THEM DOWN ON YOU.
Another kind of Effect would involve picking up a weapon or artifact:
4145 IF A = 8 THEN IF NOT QQ THEN R = 405: GOSUB 45: QQ = 1
4235 IF A = 8 THEN IF NOT QQ THEN R = 405: GOSUB 45: QQ = 1
In this example, the Effect is #5 and it is printed when Artifact #8 is picked up, but only if QQ = 0. If QQ = 1, then the artifact has been picked up before and the Effect is not printed. You could use another variable name besides QQ that is not already being used. Line 4145 covers a regular GET command, and Line 4235 covers the command GET ALL. If you have a LOT of something like this to handle, you could do it like this:
31440 DIM QQ%(NA)
4145 IF A = 8 THEN IF NOT QQ%(8) THEN R = 405: GOSUB 45: QQ%(8) = 1
4235 IF A = 8 THEN IF NOT QQ%(8) THEN R = 405: GOSUV 45: QQ%(8) = 1
This code does the same as above, but instead of a single variable QQ, you use an array QQ%() that has a location for every artifact. This makes keeping track of them easier for you while programming the adventure. You can use any array name, as long as it is not already being used. Consult the Designer's Manual to see which array names are already in use.
Here's another example, using the array technique:
4146 IF A = 9 THEN IF NOT QQ%(9) THEN R = 478: GOSUB 45: DF = 0: D2 = 3:
GOSUB 7636: QQ%(9) = 1
4236 IF A = 9 THEN IF NOT QQ%(9) THEN R = 478: GOSUB 45: DF = 0: D2 = 3: GOSUB
7636: QQ%(9) = 1
In this example, when artifact #9 is picked up for the first time, then Effect #78 is printed, then the player takes 3 points of damage.
For use of Effects when reading a note or label, etc., refer to lines 23000-23210 in the MAIN PGM. The use of Effects here is already added to the MAIN PGM. You use DUNGEON EDIT 7.0 to make the note a 'Readable' artifact type, and put the number of the Effect in the field that is titled '1ST EFFECT'. If it is a long message, you can use sequential effect numbers and then put the total number of Effects to be printed in the '# OF EFFECTS' field. If there is just one effect to be printed, '# OF EFFECTS' must be 1.
I am now through describing some basic uses of Effects. Any further ideas should be used by you. If you have any interesting uses for them, please drop me a line with your idea. I'd love to hear some others. Thanks to Tom Zuchowski for writing to me explaining how to use Effects. Robert Parker, 4025 Sunset Pl., South Bend, IN 46619.
New Eamon authors have been almost eternally plagued by problems: "How do I add a new command?" "How can I make the POWER spell do what I want?" "How do I..." and the list goes on.
In the recently rediscovered 'Eamonomicon', the answers to these and many more questions were found. If you're new to Eamon designing, read on...
IMPORTANT POINTS
First, it must be said that it is VERY important to obtain a printout of the MAIN PGM. Without this, it is difficult to decipher the inner workings of each routine. Use the full 80 columns of your printer or even a compressed 132-column mode if you have it, both to save paper and to minimize the paper shuffling while jumping back and forth from routine to routine. Don't fool yourself into the false economy of saving paper; the ease of working on paper, being able to spread it out before you and make notes on the printout will more than make up for 2 cents worth of paper and ribbon.
Commit the following variables to memory:
RO room player is in M%(x,5) room monster is in A%(x,4) room artifact is in T(1) true if hostile monster is in room M%(0,13) player's wounds (damage or 'hit' points) M%(0,2) player's agility
HOW TO ADD A COMMAND
To add a command to the MAIN PGM, change these lines:
LINE 31910: the number stored in this data statement is the total number of commands. Add 1 to this number for each additional command
LINE 31930: put new commands in a list on this line in the same format as line 31920. All commands must be single words with no spaces in the middle; use a hyphen to join two words together if it is a two-word command.
LINE 290: add the line numbers where the start of each new command is located. These must be in the same sequential order as the commands at 31920-31930
Add special programming for each new command at the new line numbers specified in line 290
The best thing to do is to look and see how any normal command is handled by the lines listed above. Here are a few tips:
End each routine with a GOTO 98. This will print a blank line, update the line counter, and proceed to the code that checks to see if there is a fight in progress. Except in special cases, this should always be the exit point.
If the command requires an object, always GOSUB 4900 to check to see if an object was included in the command. If no object was specified, this routine will ask for one before returning.
Use the search routines. GOSUB 4700 for monsters and GOSUB 480x for artifacts. If either of these routines return with the variable F = 0, then instead of exiting to 98, exit to the appropriate error message at lines 91-96. Note that the routine at 4800 has different entry points for different circumstances; once again it is best to examine the code in the MAIN PGM to see how it is done. For example, if the artifact you are looking for must be carried by the player for the command to work, see lines 5010-5030 of the DROP command for the proper coding. If the artifact must be in the room, see lines 4010-4020 of the GET command. If the artifact can be carried by the player or be in the room, see lines 6010-6020 of the EXAMINE command. For artifacts that must be worn, see 27010 of the REMOVE command.
If the command only works with one particular artifact, DO NOT do a string compare with the artifact's name; instead use this line: IF A < > (# of artifact) THEN 94 If the search routine at 4800 finds a match, it returns with the variable A set to the number of the artifact that it found a match to. By checking the artifact number instead of the string, you are letting the search routine worry about abbreviations so you don't have to, and you also get a very consistent response to different abbreviations.
HOW TO USE THE POWER SPELL
The POWER spell effects are in lines 13015-13080, though 13080 may be easily renumbered to anything as high as 13990 for more code space.
For random effects, such as a chance that a cow may fly past, check to see if the random number RL (generated in line 13010) is smaller than the chance (from 1-100) of it happening. If it involves an artifact or a monster entering the room, set the artifact/monster's location to that room. If it's a monster, be sure to then GOSUB 3600 to check its friendliness.
Be sure to put the checks of RL in sequential order. The smallest chances must be checked first, with greater chances following in order of probability. In the following example, the dragon is monster #1 and the box is artifact #1:
13015 IF RL < 35 AND M%(1,5) < > RO THEN PRINT: PRINT " A DRAGON
MATERIALIZES!": M%(1,5) = RO: GOSUB 3600: GOTO 98
13020 IF RL < 60 AND A%(1,4) = 0 THEN PRINT: PRINT " A BOX APPEARS!": A%(1,4) =
RO: GOTO 98
Also, you can have room-specific effects. These are placed before the random ones and check the room number before being executed. In this example, room 13 has a brick wall, artifact #4, that hides a treasure, artifact #5:
13012 IF RO = 13 AND A%(4,4) = RO THEN PRINT: PRINT "THE WALL EXPLODES! SOMETHING WAS BEHIND IT!": A%(5,4) = RO: GOTO 98
HOW TO USE THE 'USE' COMMAND
The USE command is exceptionally easy to use, as all you have to do is check for the artifact you wish to use and then furnish the effects. In the following example, the artifact must be in the player's inventory to be used:
28020 GOSUB 4900: GOSUB 4801: IF NOT F THEN 91
If it can also be in the room, change the above code to read like this:
28020 GOSUB 4900: GOSUB 4804: IF NOT F THEN 94
Here are some examples of code for the USE command (artifact #5 = drugs; #6 = computer; #7 = concrete; #8 = broken wall in room 27; #9 = new wall):
28030 IF A = 5 THEN PRINT: PRINT "WHAT ARE YOU, A FOOL?": GOTO 98
28040 IF A = 6 THEN PRINT: PRINT "THE BLASTED THING EMITS A CURL OF SMOKE, THEN
EXPLODES!": A%(6,4) = 0: GOTO 98
28050 IF A = 7 THEN IF RO = 27 THEN PRINT: PRINT "YOU'VE FIXED THE WALL!":
A%(7,4) =0: A%(8,4) = 0: A%(9,4) = RO: GOTO 98
You may also have the USE command refer to other commands, if the artifact type is right. This is useful for weapons and healing potions. You must check the artifact type, A%(A,2), to see if its the right type. In this example, the command USE (weapon) will jump to the READY command (artifact type 2 = weapon):
28060 IF A%(A,2) = 2 then 17000
Happy Adventurer slaying!
It is not clearly described anywhere in the manual how to properly design for and use the 40/80 column option of version 7.0. This article will attempt to demonstrate just how this is done.
THE INTRODUCTION PROGRAM: when the intro asks whether 40 or 80 columns is to be used, it POKEs either a 40 or an 80 into an unused memory location, so that this information can easily be passed to the MAIN PGM.
THE MAIN PGM: the MAIN PGM PEEKs this number from memory and sets the variable CP to this value. CP is used by the line-counting routine to decide if a description will take (for example) 6 40-column lines or 3 80-column lines.
That’s it! With the addition of code to turn off 80-columns at the end of the adventure, that is the entire programming for the 40/80 column option.
But it's not quite that simple from the author's point of view! Each and every room, artifact, and monster description and all the effects must be carefully designed to look good in BOTH 40-column and 80-column modes. This isn't difficult to do, but can be tedious, depending on just how good you want your descriptions to look.
DEFINITIONS: the following explanation refers to 'odd-numbered' lines and 'even-numbered' lines. Refer- ring to Figure 1a, the 'odd-numbered' lines begin with THIS, HIGHLIGHTS, and BREEZE, and the 'even-numbered' lines begin with POLISHED, LAMP, and ABOVE.
The standard method of writing 40-column Eamon descriptions is to pad the end of each 40-col. line with spaces so that the text will have good line breaks and be left justified. Figure 1a gives an example of this. However, when this same description is displayed in 80-col. mode, a huge gap appears in the center of the text, as shown in Figure 1b. This looks awful and is very distracting, resulting in less player satisfaction and lower ratings for your adventure.
The answer is to spread the extra spaces out along the entire line so that there is never more than a single space at the end of the line. Figures 2a and 2b give an example of this technique. Here are some guide- lines that will help you design good-looking text:
1) The extra spaces are less noticeable following punctuation and next to large words. First put spaces after punctuation before sticking them elsewhere. You can get away with 3 spaces after a comma or a period and still look good.
2) The ODD-NUMBERED lines must never have more than one space at the end of the line. These lines will be the left half of each 80-col. line.
3) If an ODD-NUMBERED line works out to exactly 40 characters so that there is no room for a space at the end, then the following EVEN-NUMBERED line must BEGIN with a space. When these two lines are combined for 80-col., there must be a space between them or else the two words in the center will be run together.
4) The FIRST line can have paragraph-like indentation at the beginning, as has been done in Figures 2a & 2b. If this indentation runs more than 3 spaces then possibly some of the spaces should be spread through the rest of the line.
5) You can treat the EVEN-NUMBERED lines as if they were 40-column only. These lines make up the right half of each 80-col. line and extra spaces at the end don't matter. However, you may want to spread some of the extra spaces into the text to keep it from looking 'heavy' on the right side of the 80-col. line if there is a lot of padding in the left half of the line. Try to balance the line so that the odd-numbered half and even-numbered half are equally dense looking.
6) Try not to put many spaces near short words. The text can get real sparse looking which is unattractive.
OK, now we have filled the huge gap presented in Figure 1b, but Figure 2b still presents a 'gap-tooth' look because all of the spaces are in a straight row, giving a 'two-column' look that is not esthetic to look at. And when several descriptions are run together, as in a large special effect or the appearance of several new monsters, the two-column look becomes quite pronounced and is distracting to read.
The way to fix it is by designing the text so that at least one but no more than two of these middle-of-the line spaces come at the beginning of an even-numbered line instead of at the end of an odd-numbered line. Figures 3a & 3b demonstrate this technique. Yes, the left margin is ragged using this method, but it's not that noticeable and is a lot less noticeable than a line of spaces down the center of your 80-column screen.
That's all there is to it. It takes a little practice and you may have to re-edit a few times before you get it looking good. A paperback Thesaurus is absolutely essential for finding alternative words when you just CAN'T get that darn description to fit the lines right. Also, a Thesaurus is very valuable in helping you avoid overusing a given word when describing (for example) several successive rooms that are very similar.
80-COLUMNS ON THE APPLE II AND II+: The Apple II+ uses a variety of aftermarket 80-column boards, since Apple did not offer an 80-column option for this machine. The Videx board was by far the most successful, and most all other II+ 80-column boards conform to the Videx 'standard'. For the most part it will work fine when you use VTAB, HTAB, POKE 1403, and PEEK 37. However, it does not properly support the HOME command. For HOME to work on a Videx board, it must be followed by a CHR$(12), the Form-Feed character. The technique that I recommend is to set the variable FF$ = CHR$(12); and when clearing the screen use the double command HOME:PRINT FF$ (This will be invisible on a //e or in 40-col. mode). Try to avoid fancy CALLs that clear to end-of-line or do other things, because they won't affect the Videx screen at all. If you need to do such a thing it can be done by printing a line of spaces.
INVERSE and FLASH also do nothing on a Videx.
80-COLUMN INPUT ON THE II AND II+: Since the II has no shift key, the 80-column board must be able to keep track of the case being used and convert the II's upper-case input into lower-case when required. This is done by sending keyboard input to the 80-column board before it goes to the Apple so that the character can be converted if need be. Also, the Videx uses CTRL-A for shift-key and caps-lock and must be able to intercept this keystroke. All this means is that you MUST use GET and INPUT and can't PEEK the keyboard data directly.
Eamon authors and adventurers all have one thing in common: If you want to play, you must play under the old DOS 3.3 operating system. While there is really nothing wrong with this, what if you would rather play under the ProDOS operating system? You are kinda out of luck, aintcha? Not so, Oh tall one! It is unbelievably simple to convert a DOS 3.3 version of a given scenario to ProDOS - even a niffling such as yourself can do it with ease!
But first, why should you convert? To be truthful, there is no adventure oriented reason. A given scenario in ProDOS will appear identical to one under DOS 3.3. But how many adventurers habitually live in the DOS 3.3 world? The advent (No pun intended) (yeah, right) of the Apple IIGS and various program selectors for the rest of the Apple II series, means adventuring in any Eamon world requires that you re-boot the entire system. That's defeating the whole purpose behind the program selectors. However, if you have a ProDOS version of an Eamon adventure, you can simply select the Master Program from within your program selector and be off!
For instance, I play on an Apple IIGS. If I want to play one of the old DOS 3.3 versions, I have to essentially shut the whole thing down, and re-boot on the EAMON MASTER DISK. But, since I have a ProDOS version of the Master, all I need to do is point my mouse at it and "click". Zip, I'm in the Main Hall. From there, it's essentially the same as in the DOS 3.3 versions. Unfortunately, even though I have a ProDOS Master disk, I still need to convert my old DOS 3.3 scenarios if I want to adventure in them. There are other disadvantages to DOS 3.3, not the least of which is it's speed. ProDOS disk access is usually about eight times faster than DOS 3.3.
A thought for future authors, under ProDOS, you could make use of the CHAIN command, which carries variables with it. In other words, under DOS 3.3 you have to write all your variables to a file, RUN the other program, then READ the variables again. Under ProDOS, all you need to do is CHAIN to the next program. The variables will carry over unchanged. ProDOS also offers SAVE and RESTORE commands, which allow you to STORE all your variables in one file, then RESTORE them to a different program - even if your computer has been shut off. (The chain program does this too, but the file created is temporary, internal to the computer, and wiped out when the power goes away. You'll never see it.)
That's neat, but how can I convert the games I already have? Converting Eamon adventures is very easy. In fact, there are fewer than 30 program lines that HAVE to be changed or added. All you need other than a willingness to type a little - is some way to copy files from your DOS 3.3 disk to a ProDOS disk (I use Copy II+). A program such as Beagle Brothers PROGRAM.WRITER can be handy for this project too, but is hardly necessary.
You start out by formatting a blank floppy for use under ProDOS. I recommend it follow this disk naming convention: EAMON.P.XXX, where XXX is the adventure number. Copy II+ or your System Utilities disk can do this for you. Next, use your copy files utility to copy ALL the files on the DOS 3.3 disk to the ProDOS disk. Once that is done, put your DOS 3.3 disk away, you're done with it.
Now, set your PREFIX to your ProDOS Eamon disk, and do a CATalog. You should note that most of the file names have been changed, and in some cases, truncated. This is because ProDOS won't allow filenames longer than 15 characters, and won't allow spaces in the filename. Even most punctuation is replaced with periods. This is nothing to worry about, since it's what the conversion is really all about. In fact, the hard part is done.
In point of fact, that is the whole reason behind the rest of this column. Under DOS 3.3, Eamon filenames are full of spaces and special characters but since ProDOS won't allow spaces or special characters in a filename, AND limits that filename to 15 characters, several EAMON program lines need to be changed to make the programs run properly. Don't worry, there are surprisingly few, and the conversion is very simple.
The next step is the re-naming of several of the programs, mostly just to make the filenames easier to read. One will Usually be: EAMON.ADVENTURE. This file started life as EAMON ADVENTURE # XXX. I recommend you rename it EAMON.XXX (again, XXX is the adventure number). Another file that usually requires renaming is the description file - For instance: THE MINES OF MORIA will be: THE.MINES.OF.MO. after the file copy process. Needless to say, while that can be understood, it's a bit clumsy. I suggest something like: MINES.OF.MORIA. It's still the same file, but it's a little easier to understand the filename. Of course, there ARE those description files whose names are just too long to make understandable under ProDOS, but, since it's just a name, we must do the best we can and live with it.
Now you need to create a short program. In fact, one line is all you really need:
100 PRINT CHR$(4)"RUN (description file)"
For Mines of Moria, the program would be:
100 PRINT CHR$(4)"RUN MINES.OF.MORIA"
Save this program under the name LEADIN. This is a MUST, since both known ProDOS EAMON MASTER disks look for this file. You can add your own embellishments to this program to make things flow more smoothly. For instance, the LEADIN programs I write check for a SAVED game and make provisions to resume it, so they look like this:
100 ONERR GOTO 300
200 PRINT CHR$(4)"VERIFY GAME.VAR":PRINT CHR$(4)"RUN MAIN.PGM,@29000"
300 POKE 216,0:PRINT CHR$(4)"RUN (intro pgm)
Line 200 checks for the file "GAME.VAR" and if it finds it, runs MAIN.PGM, starting at line 29000 - which is where I generally put the RESUME game routine. If "GAME.VAR" is not found, the description file is run, which in turn passes you to MAIN.PGM - but at the beginning, since you are starting a new adventure.
Now, LOAD the MAIN.PGM and LIST line 130. This line varies greatly from one scenario to the next, but they are all similar. Re-type this line exactly, character for character, except where you see PRINT DK$"READ EAMON.ROOM NAMES,R". At this point, type PRINT DK$"READ EAMON.ROOM.NAME,R". Not much difference is there? But it's enough.
One thing to note: when you list line 130, if you don't see anything resembling EAMON.ROOM NAMES anywhere, take a look at the few lines nearest it in the program. If you still can't find a reference to EAMON.ROOM NAMES, note where any nearby GOSUBs go, and take a look at THOSE line numbers. There have been a few occasions where this part of the line has been stashed as far away as line 37000.
LIST line 1040. Do the same thing, using the filename FRESH.MEAT instead of FRESH MEAT.
LIST line 1060. Notice any similarities to line 130? Right, it looks at EAMON.ROOM NAMES too. Re-type this and change EAMON.ROOM NAMES to EAMON.ROOM.NAME .
LIST line 1050. Does it end with "PRINT DK$"DELETE FRESH.MEAT"? If not, add line 1055:
1055 PRINT DK$"DELETE FRESH.MEAT" At this point it would be a good idea to SAVE your changes. Nothing is quite so frustrating as spending even as little as 5 minutes on something, only to have it blown away by a random loss of power, or the calculating destructiveness of your local housecat.
This much is fine, and will allow us to play the game, with a little extra typing to get things started, but we still need to address what happens when we successfully complete the quest. So:
First, check to make sure the lines between 2500 and 2900 don't do anything but provide an exit back to the Main Hall. (They shouldn't it's usually all that's ever there). Now delete them and type in the following listing:
2500 REM >>> RETURN TO MAIN HALL <<<
2510 ONERR GOTO 2530
2520 PRINT DK$"OPEN EAMON.PREFIX":PRINT DK$"READ EAMON.PREFIX":INPUT PR$:PRINT
DK$"CLOSE": GOTO 2570
2530 POKE 216,0:REM >> ERROR TRAP <<
2540 PRINT DK$"CLOSE":PRINT DK$"PREFIX": INPUT CX$
2550 PRINT:PRINT:PRINT CX$:PRINT "IS THE CURRENT PREFIX":PRINT"INSERT YOUR
MASTER DISK AND ENTER ITS PREFIX"
2560 INPUT"";PX$
2570 PRINT DK$"PREFIX"PX$
2580 PRINT DK$"VERIFY MAIN.HALL":POKE 216,0:IF DIE THEN PRINT DK$"OPEN
THE.ADVENTURER": PRINT DK$"CLOSE":PRINT DK$"DELETE THE.ADVENTURER":GOTO 2630
2590 IF REC=-1 THEN 2630
2600 PRINT DK$"OPEN CHARACTERS,L150":PRINT DK$"WRITE CHARACTERS,R"REC:PRINT
MN$(0): PRINT MD%(0,1):PRINT MD%(0,2):PRINT CH: FOR A=1 TO4:PRINT SA%(A):NEXT A
2610 FOR A=1 TO 5:PRINT WA%(A):NEXT:PRINT AE:PRINT SEX$:PRINT GOLD:PRINT
BANK:PRINT AC:FOR A=1 TO 4:PRINT WN$(A):PRINT WT%(A): PRINTWO%(A):PRINT
WD%(A):PRINT WS%(A): NEXT
2620 PRINT DK$"CLOSE":PRINT DK$"OPEN THE.ADVE NTURER":PRINT DK$"WRITE
THE.ADVENTURER": PRINTMN$(0):PRINT REC:PRINT DK$"CLOSE"
2630 REM >>> RETURN TO MAIN HALL <<<<
2640 PRINT DK$"RUN MAIN.HALL
Save the program again.
Take a look at the SAVE/RESTART routines - usually kept at line 18000 and 29000 respectively. Make sure they don't make use of the old filenames. If they do, they need to be changed. Use lines 130, 1040, and 1060 as examples if you need to. ( A better set of ProDOS SAVE/RESTORE game routines should be the subject of a future Dungeon Designs column. )
What about the other programs?
Now, take a look at the remaining BASIC programs on the disk. If you are not sure which they are, simply CATalog the disk and check it out. Every BASIC program will have "BAS" immediately to the right of the filename.
LOAD each remaining BASIC program in turn, and look through it for lines where it makes reference to one of the other files on the disk. In most cases it will be something like this:
20 D$=CHR$(4):PRINT D$"OPEN FRESH MEAT":PRINT D$"READ FRESH MEAT":INPUT NAME$:INPUT REC: PRINTD$"CLOSE"
or:
500 PRINT:PRINT"GOOD LUCK, "NAME$".":PRINT D$"RUN MAIN PGM"
I can't tell you which specific line numbers to change in these cases, since there are nearly as many different line numbers as there are scenarios.
What lies behind all these changes? By now you will have noticed that all this typing (well, most of it) has to do only with those lines that OPEN or otherwise make use of the files on the disk. With this knowledge, you should be able to go through the rest of MAIN.PGM and the other BASIC files and make sure that the filenames - as they appear in the program - agree with what shows up when you CATalog the disk.
That, believe it or not, is all there is to converting the scenarios to ProDOS. It looks more difficult than it really is. In fact, if you intend to convert more than one or two, it might behoove you to use a text editor to pre-type the necessary lines as an EXEC text file, since the applicable lines rarely change. You can even have the Exec file load in your programs for you, and save the program when the changes have been made. Once all the changes have been made to all the programs, you're set! Launch your ProDOS MASTER disk, and go slay a few orcs!
Lurch has done a large number of conversions using the method that he outlined in the preceding article. While it should be mentioned that there are no significant differences between my conversion method and Lurch's, his method and mine differ in some minor respects, that I will list here:
1) I don't check for a saved game in the LEADIN pgm, but do this check at Line 20 of the MAIN.PGM, as it is done in the Dos 3.3 version. In my opinion Lurch is 'showing off' ProDOS features with this step <grin>. Also, I name the saved VAR file SAVED.GAME instead of GAME.VAR.
2) I do not add line 1055 to delete the FRESH.MEAT file if it is missing. In fact, I REM out line 1055 whenever I find it! I don't see any good reason for deleting this file, as it makes it impossible to start a game over again without returning to the Master to resurrect your character and then launching the adventure all over again, a totally unnecessary procedure.
3) I rename the intro pgm in the format EAMON.nnn.INTRO. Note that we are using a 3-digit convention here, with leading zeroes in 1 and 2 digit Eamon numbers (eg: EAMON.008.INTRO).
4) I delete the pgm EAMON ADVENTURE #nnn altogether. It serves as the HELLO pgm in Dos 3.3 but serves no purpose in ProDOS.
5) I add a short pgm with the name REV.DDMMMYY (where DD=date; MMM=month; YY=year). This pgm has 2 lines:
10 HOME: VTAB5: PRINT"EAMON ADVENTURE #nnn": PRINT: PRINT "(name of adventure)": PRINT: PRINT "BY (name of author)" 20 VTAB15: LAST UPDATE: MM/DD/YY
6) Lurch & I disagree on the subject of error trapping when returning to the Master disk. Lurch believes in handling the errors that don't require too much code, whereas I believe that if you aren't going to trap them all then it is better to let all the errors crash uniformly. My 'return' code is:
2500 PRINT DK$"OPEN EAMON.PREFIX": PRINT DK$ "READ EAMON.PREFIX": INPUT PX$:
PRINT DK$ "CLOSE"
2510 HOME: VTAB 5: PRINT "(INSERT EAMON MAS TER DISKETTE, THEN": PRINT " HIT THE
'C' KEY) ";: POKE -16368,0
2515 GET A$: IF ASC(A$) = 3 THEN PRINT: END: REM CTRL-C 2517 IF A$ < > "C" THEN
2515
2520 PRINT A$
2525 ONERR GOTO 2510
2530 PRINT DK$"PREFIX "PX$
2540 POKE 216,0: IF DI THEN PRINT DK$;"DELETE THE.ADVENTURER": GOTO 2900
2550 PRINT DK$"OPEN CHARACTERS,L150": PRINT DK$"WRITE CHARACTERS,R";REC: PRINT
MN$(0): PRINT MD%(0,1): PRINT MD%(0,2): PRINT CH: FOR A = 1 TO 4: PRINT SA%(A):
NEXT
2560 FOR A = 1 TO 5: PRINT WA%(A): NEXT: PRINT AE: PRINT SEX$: PRINT GOLD: PRINT
BANK: PRINT AC: FOR A = 1 TO 4: PRINT WN$(A): PRINT WT%(A): PRINT WO%(A): PRINT
WD%(A): PRINT WS%(A): NEXT
2570 PRINT DK$"OPEN THE.ADVENTURER": PRINT DK$"WRITE THE.ADVENTURER": PRINT
MN$(0): PRINT REC: PRINT DK$"CLOSE"
2900 PRINT DK$"RUN MAIN.HALL"
7) I am taking the INIT lines at 1001-1038 out of the MAIN.PGM and putting them in a small program named MAKE.FAST.START. This pgm loads EAMON.ARTIFACTS and EAMON.MONSTERS, and STOREs then in a VAR file named FAST.START. I put a line in the MAIN.PGM at 1010 to RESTORE FAST.START, resulting in a lot faster startup. I also write a companion pgm to MAKE.FAST.START named MAKE.ARTS.MONS that will generate EAMON.ARTIFACTS and EAMON.MONSTERS from the FAST.START file for editing. This allows you to delete EAMON.ARTIFACTS and EAMON.MONSTERS to save disk space.
8) Both Lurch & I are using STORE and RESTORE to save and resume games. It is very compact and fast. Here is my code:
18000 REM SAVE GAME
18010 PRINT: PRINT "DO YOU WANT TO SAVE THIS GAME? ":INPUT "(Y/N) :";A$: A$ =
LEFT$(A$,1)
18020 IF A$ < > "Y" AND A$ < > "N" THEN 18010
18030 IF A$ = "N" THEN 100
18040 PRINT DK$"CLOSE": PRINT DK$"FRE"
18050 PRINT DK$"STORE SAVED.GAME"
18080 PRINT: PRINT "THE GAME IS NOW SAVED. RUN THE PROGRAM NAMED 'MAIN.PGM' TO
RESTART THE GAME."
18090 END
29000 REM RESTORE
29005 POKE 216,0
29010 PRINT: PRINT "DO YOU WANT TO RESUME THE SAVED GAME?": INPUT " Y OR N:";A$:
A$ = LEFT$(A$,1)
29020 IF A$ < > "Y" AND A$ < > "N" THEN 29010
29030 IF A$ = "N" THEN PRINT DK$"DELETE SAVED. GAME": RUN
29040 PRINT DK$"RESTORE SAVED.GAME"
29060 PRINT DK$"OPEN EAMON.DESC,L256": PRINT DK$"OPEN EAMON.ROOMS,L64": PRINT
DK$"OPEN EAMON.ROOM.NAME,L64"
19070 GOTO 100
It should go without saying that you really need a good program editor to do these conversions. Lurch recommends Program Writer. I have been using a ProDOS version of GPLE and have found that GPLE won't do global searches in line numbers over 9999 on my enhanced //e, so Program Writer is probably the way to go.
Hark! Ready to write an adventure? You're a Basic whiz, know every trick in the book and crush bugs for lunch. You write it and send it to the EAG and LO! Your mighty game gets a 3? What's wrong with those morons? After all, you used flawless algorithms.
Well, let's take a look at your game...."REVENGE OF GWAR". The evil warrior demigod Gwar has taken over a cavern south of town, threatening all life for miles around. You go in, beat up all the cronies, and slay Gwar. What more could you ask for?
A lot. Where's the story here? Who or what is Gwar? Why is he so bad? What's the revenge angle? Where is this town? Why can't they handle Gwar by themselves? This information, known as background, is important to give the adventure some depth and detail. It is also good for helping out with items and events that come along later in the game. For example, if we know that Gwar eats Spam, the adventurer would find lots of Spam cans. Good hints can be placed in the intro, such as recounting a tale of how Gwar once attacked but fled when a turnip cart came near him.
Now we have a background? Is the story ready to go yet? Not unless the bulk of the adventure is interesting and builds up to the finale. What happens in between the intro and the confrontation with Gwar? The player wanders through the caverns looking for Gwar and fighting monsters.
BORING! This is the easiest formula for failure. There are so many random fight-fests out there that they all just get dull. First, if you refuse to have any sort of building plot, at least spice it up. Puzzles and humor work wonders for otherwise sorry adventures. Preferably, build up the plot. In the case of our search for Gwar, what happens in the caves as we search for him?
The key to writing a plot up is, "Would this make for an interesting read if it were a book rather than an adventure?" I was told this by a certain author who knows who he is, and it's helped me five-fold when it comes to writing adventure plots.
This is when you have to get creative; now you need a plot. For space limitations, I'll keep it simple. Remember to keep the background in mind. Nothing annoys like meeting a monster in an impossible and unexplained place.
In our search for Gwar, the character might have to: 1) find the caverns 2) get in 3) get through an orc lair 4) find in the orc treasure how to reach Gwar 5) reach Gwar 6) defeat him.
Each of these steps would have its own substeps. For instance:
3) Get though orc lair a. fight sentries b. open locked door c. find turnip in kitchen (which slays Gwar) d. find Orc King's escort too big to fight e. find secret door to King's room f. slay Orc King; orcs flee
Each of these steps would have their own special programming and such, but obviously the variables and such aren't independent of other steps. You have to make allowances for what can go wrong, or prevent wrong things from happening. Not to mention covering the possibility that the player may try to go about solving a problem a different way than you intended. Putting the plot to play is a long process that includes special programming and text that can only be arrived at through experience gained from trial and error.
Now that you've got that out of the way, what happens once the player beats Gwar? Few things can be as anti-climactic as a dead body and then walking out a side exit, with no more than "You ride off into the sunset" for reward.
Gwar is a mean dude, and he's not of this Earth. Have him go out with a bang. Bodies dissolving in smoke (appropriate only for unnatural beings), disappearing corpses, last words, and gory details always spice up the death scene of an arch-nemesis.
Now that the town is rescued from Gwar, the character is a hero, and heroes do more than ride off into sunsets. A good thing to have is a wrap-up at the end of the adventure consisting of a few effects. These are used to explain the hero's welcome (bumbling moron's welcome?), the town's reaction and reward to the valiant warrior, and anything else that needs to be said. This is one feature that I feel is sorely lacking in most Eamons lately.
The game is complete now. Or is it? What about the text? After all, it's how the player relates to the game. Good grammar can wait. Are the descriptions good? Compare:
YOU SEE GWAR. HE GROWLS AT YOU.
and:
SITTING ON A THRONE IS A GREAT, TOWERING SHAPE WITH RED SHAGGY FUR, SHARP GREEN FANGS AND BEADY EYES. HE SNEERS AND SAYS, 'I AM GWAR! PUNY MORTAL, PREPARE TO BE LUNCH!"
More interesting, isn't it? Do that for everything: monsters, rooms artifacts, and especially effects.
Here comes the equivalent of bug removal for the plot, that is, checking for holes. Pretend you're playing the game, and for some reason can't take a thing for granted. Ask questions about why everything is. Are these things fairly explained or fairly obvious? If not, then you should place something in the game to explain it. For example, if you have 80 jillion orcs in your game, you should have a logical reason. (Author's note: I remember while working on "Ragnarok Revisited" Tom sent me back about a page and a half of questions involving holes in the plot. Working the answers into the game sent the rating up about 3 points.)
Now you game is ready to be mapped, entered, programmed, debugged, and finally released. It's the shortest step, but the most important.
To learn much more about the importance of a good plot, play all the high-rated adventures (8's and up). This is something better learned by example than theory. Take notes. What do you like and what do you dislike about every adventure you play?
"But I don't have any ideas!" you may whine. "I can't think of anything interesting!" Here's a few off the top of my head. If properly used, things like these can really spice up an adventure: unusual magic; an interactive device (like a computer or radio); mysterious things; companions and monsters that "do• things; mysteries about monsters and companions; unusual portals; humor; weapons of uncommon destruction; buying and selling of artifacts; riddles. If you can't come up with much, at least have stuff to read, examine, open, unlock, and find.
While working on one of his adventures, Rob had terrible problems with database corruption in the EAMON.ROOMS file. The problem was traced to the fact that it was to be a 10-direction adventure instead of the normal 6 directions.
Version 7.0 allows for an average of 4 digits for each of the 6 directions from a given room plus the lighting status, for a total of 32 bytes (including CR's after each value). Rob's adventure used lots of special room connections and was averaging very close to 4 digits for ten directions, for a total of about 50 bytes. This meant that the room data was overrunning the disk record space that was allotted for it.
Version 7.0 can accommodate different record lengths, depending on the author-specified length for the room name. It defaults to a room name length of 38 bytes, but a wide latitude of name lengths can be specified when the adventure is initialized, or later with the RESIZE FILES utility.
The allotted record space for room data cannot be so easily modified, but room data shares the same record with the room name. Thus it is quite easy to make more space for extra room data by specifying a longer room name than you really intend to use.
For a 10-direction adventure, you should specify a room name length that is at least 20 characters longer than you really intend to use. For example, if you plan to use the default 38-character name length, you should specify a name length of at least 58. Then you must remember not to let your room name run past the first line even though the editor shows that you have another half-line available.
Yes, this is a kluge fix, but it is very easy to implement. If you don't want to do something mickeymouse like this, you have two other options for 10-direction adventures:
1) Limit your room data to an average of 2 digits per room connection. As long as you don't exceed 20 digits (plus an additional 10 bytes for CR's), the data will fit very well within the standard record space.
2) Rework the DUNGEON INIT, EDIT, & LIST programs to accommodate the extra space. This isn't very difficult to do but then you must somehow make sure that no one ever runs a normal DDD on the adventure.
Rob opted for a modification of option #1. He reworked his room connections to use fewer bytes. But he also deleted the UP and DOWN directions from the database, which gave him an average of 2.75 bytes per direction to play with.
-----------------
So how does one make a 10-direction adventure? The mods to the MAIN PGM are actually quite simple:
1) Add 4 to the number in the DATA statement at line 31910.
2) Add NE,NW,SE,NW to the command list at line 31920, between DOWN and GET.
3) At Line 290, immediately after the GOTO, add the number 3000 four more times, so that the line has 3000 a total of ten times, consecutively.
Next, you must modify the EAMON.NAME file by running this small pgm: 10 D$ = CHR$(4) 20 PRINT D$"OPEN EAMON.NAME" 30 PRINT D$"READ EAMON.NAME" 40 INPUT AN$: INPUT ND$: INPUT DV$ 50 PRINT D$"WRITE EAMON.NAME" 60 PRINT AN$: PRINT "10": PRINT DV$ 70 PRINT D$"CLOSE"
That's all there is to it!
CORRECTION:
The DEC'90 article on how to make a 10-direction had a bug in the small program that modifies EAMON.NAME. Here is the correct program:
10 D$ = CHR$(4)
20 PRINT D$"OPEN EAMON.NAME"
30 PRINT D$"READ EAMON.NAME"
40 INPUT AN$: INPUT ND$: INPUT DV$
50 PRINT D$"CLOSE"
60 PRINT D$"OPEN EAMON.NAME"
70 PRINT D$"WRITE EAMON.NAME"
80 PRINT AN$: PRINT "10": PRINT DV$
90 PRINT D$"CLOSE"
There are only two basic types of information in the room data: exits and light. Light has two values: (1) if the room is naturally lit, and (0) if the room is dark.
A normal Eamon adventure has 6 directions of travel: North, South, East, West, Up, and Down. When editing room data, you must supply an exit number for each of these directions: A (0) means that there is no exit in that direction. A (-99) signifies an exit to the Main Hall. Custom programming can be accomplished by using negative numbers; however, you must supply the programming for such special connections.
The last means of exiting a room is through a Door artifact. The exit number in the room data should equal the artifact number of the door plus 500. For example, if the door's artifact number is 21, then the exit number is 521. This tells the programming to consult Artifact #21 for more information about the exit.
And what about the door itself? First, you must decide if it is a normal door or if it is a secret door. If normal, you simply use the Room number for the door's location and answer "0" to the HIDDEN question. If it is a secret door, add 200 to the room's number for the location, and answer "1" to the HIDDEN question. But if it is hidden, then you must remember to mention it somehow in the room description, so the player will have a name to EXAMINE to make it appear in the room.
Be careful with the KEY question in the door menu. It presently defaults to 99, which means that you will need artifact #99 to use as a key to open it. If you have fewer than 99 artifacts, the program will crash. The KEY number should be set to the artifact number of the key that opens the door. If the door is unlocked, set KEY to zero.
Be sure to set the door's weight to 999. The MAIN PGM recognizes 999 as an impossible weight and responds "DON'T BE ABSURD" if the player tries to GET the door. If you don't do this, some bozo with a super-character will pick up the door and carry it off, which does not open the passageway but does ruin the adventure.
Set the door's strength to whatever you want it to be. This number is reduced by the damage hits inflicted when the player ATTACKs the door; when it reaches zero, the door shatters. If it is a flimsy door, set this number to something small, like 10. If it is armored, set the number very high, like 999.
Let's do an example of a door. Let's say that the door is artifact #5 and is a secret north exit from Room 3. The room beyond the door is Room 7. The door armored and locked, and its key is artifact #6, and is found in Room #2. This example underlines all typed input:
ROOM-2 ART.-4 EFF.-0 MONS.-0
YOUR CHOICES ARE-- 1. ADD NEW ROOM, ARTIFACT, EFFECT, OR MONSTER 2. (etc.)
ENTER KEY OF YOUR CHOICE (1-7) 1
DO YOU WANT TO ADD A ROOM, ARTIFACT, EFFECT, OR MONSTER (HIT KEY, RAEM) R
ENTER ROOM NAME: END OF A N/S TUNNEL
ROOM DESCRIPTION: YOU HAVE REACHED THE END OF THE TUNNEL. IT IS BLOCKED BY A LARGE FLAT PANEL.
FOR EACH DIRECTION ENTER THE ROOM # THAT THIS ROOM CONNECTS TO: MOVE N ...505 (door - artifact #5) MOVE S ...(etc.)
ROOM-3 ART.-4 EFF.-0 MONS.-0
YOUR CHOICES ARE-- 1. ADD NEW ROOM, ARTIFACT, EFFECT, OR MONSTER 2. (etc.)
ENTER KEY OF YOUR CHOICE (1-7) 1
DO YOU WANT TO ADD A ROOM, ARTIFACT, EFFECT, OR MONSTER (HIT KEY, RAEM) A
ENTER ARTIFACT NAME: PANEL
ARTIFACT DESCRIPTION: YOU DISCOVER THAT THE PANEL IS REALLY A STEEL DOOR!
TYPE : 8 (door/gate) VALUE : 50 (doesn't matter) WEIGHT : 999 (immovable object) ROOM : 203 (hidden in Room #3) ROOM BEYOND : 7 (connects to Room #7) KEY# : 6 (Artifact #6) STRENGTH : 999 (can't be broken down) HIDDEN? : 1 (secret door; 0 if not hidden)
ROOM-3 ART.-5 EFF.-0 MONS.-0
YOUR CHOICES ARE-- 1. ADD NEW ROOM, ARTIFACT, EFFECT, OR MONSTER 2. (etc.)
ENTER KEY OF YOUR CHOICE (1-7) 1
DO YOU WANT TO ADD A ROOM, ARTIFACT, EFFECT, OR MONSTER (HIT KEY, RAEM) A
ENTER ARTIFACT NAME: STEEL KEY
ARTIFACT DESCRIPTION: YOU HAVE FOUND A SMALL STEEL KEY.
TYPE : 9 (key) VALUE : 1 (not worth much) WEIGHT : 1 (doesn't weigh much) ROOM : 2 (found in Room #2) USER #5 : (doesn't matter) USER #6 : (doesn't matter) USER #7 : (doesn't matter) USER #8 : (doesn't matter)
That's how it's done. Be sure to print out the manual. It has all this information and more in it, and you will find it a valuable reference.
The above example is not a complete printout of everything that you will see on the screen. There are quite a few on-screen menus during data input that list the allowable inputs, so that you don't have to memorize such things as the artifact type of a door. In fact, the menus almost cover such information better than the manual does.
The USER prompts seen with some types of artifact data input, such as the key above, are not used by the standard MAIN PGM programming. They are made available for the purpose of adding extra data for special programming. If you have not added any such extra programming, simply enter zero at each prompt (or hit Escape to retain the default value shown on the screen) and ignore them.
A container is any kind of artifact that can hold other artifacts inside of itself. Most containers are simple boxes or chests, but this artifact class also includes things like desks, lockets, sacks, and so on. In fact, anything can be used as a container if the story requires that it be able to contain or conceal other artifacts.
Containers may be closed or open, locked or unlocked. Their initial state is up to you. Once a container is unlocked or opened, it may not be closed again or relocked using the standard MAIN PGM programming. However, if the player puts an artifact into an open container, the container will "behave" as if it is closed, holding and concealing the artifact until the player again opens it.
Like doors, container key numbers default to artifact #99. You must change this number to the artifact number of the actual key or to zero. If you leave it as 99, then the player must have artifact #99 in his possession to open the container. If the adventure doesn't have 99 artifacts, the MAIN PGM crashes when the player tries to open the container.
Also like doors, containers have a Strength parameter that is in effect the container's "hardiness". If the player has no key, he can attack a locked container and wear down its strength until it reaches zero, at which time the container shatters and can be opened. Try to select a container description that fits the strength number that you choose. If the container is a lightly built wooden box then the strength should be around 10. If it is a massive iron-bound strongbox then the strength can be in the hundreds. Make some effort to have the container's description match its strength.
Let's do an example of a container. Let's say that the container is a small, stoutly built, locked wooden box that contains an emerald. The box is artifact #1, the key artifact #2, and the emerald artifact #3. The box will be found in room 1 and the key in room 7. This example underlines all typed input:
ROOM-0 ART.-0 EFF.-0 MONS.-0
YOUR CHOICES ARE-- 1. ADD NEW ROOM, ARTIFACT, EFFECT, OR MONSTER 2. (etc.)
ENTER KEY OF YOUR CHOICE (1-7) 1
DO YOU WANT TO ADD A ROOM, ARTIFACT, EFFECT, OR MONSTER (HIT KEY, RAEM) A
ENTER ARTIFACT NAME: BOX
ARTIFACT DESCRIPTION: YOU SEE A SMALL WOODEN BOX. IT IS ORNATELY FINISHED IN DARK VARNISHES WITH SILVER INLAYS. YOU CAN SEE FROM ITS CONSTRUCTION THAT IT IS STOUTLY BUILT. THERE IS A SMALL KEYHOLE ON ONE SIDE.
VALUE : 5 (not worth much) TYPE : 4 (container) WEIGHT : 5 (not too heavy) ROOM : 1 (found in Room #1) KEY# : 2 (Artifact #2) STRENGTH: 50 (moderately strong) OPEN? : 0 (Open = 1; Closed = 0) USER #8 : 0 (doesn't matter)
ROOM-0 ART.-1 EFF.-0 MONS.-0
YOUR CHOICES ARE-- 1. ADD NEW ROOM, ARTIFACT, EFFECT, OR MONSTER 2. (etc.)
ENTER KEY OF YOUR CHOICE (1-7) 1
DO YOU WANT TO ADD A ROOM, ARTIFACT, EFFECT, OR MONSTER (HIT KEY, RAEM) A
ENTER ARTIFACT NAME: STEEL KEY
ARTIFACT DESCRIPTION: YOU HAVE FOUND A SMALL STEEL KEY.
VALUE : 1 (not worth much) TYPE : 9 (key) WEIGHT : 1 (doesn't weigh much) ROOM : 7 (found in Room #7) USER #5 : (doesn't matter) USER #6 : (doesn't matter) USER #7 : (doesn't matter) USER #8 : (doesn't matter)
ROOM-0 ART.-2 EFF.-0 MONS.-0
YOUR CHOICES ARE-- 1. ADD NEW ROOM, ARTIFACT, EFFECT, OR MONSTER 2. (etc.) ENTER KEY OF YOUR CHOICE (1-7) 1
DO YOU WANT TO ADD A ROOM, ARTIFACT, EFFECT, OR MONSTER (HIT KEY, RAEM) A
ENTER ARTIFACT NAME: LARGE EMERALD
ARTIFACT DESCRIPTION: YOU SEE A MARVELOUS LARGE EMERALD! IT HAS AN EXQUISITE COLOR AND WONDERFUL CLARITY. IT HAS BEEN CUT INTO AN OVALSHAPE WITH LARGE FACETS.
VALUE : 500 (valuable) TYPE : 1 (treasure) WEIGHT : 1 (doesn't weigh much) ROOM : 501 (inside Artifact #1) USER #5 : 0 (doesn't matter) USER #6 : 0 (doesn't matter) USER #7 : 0 (doesn't matter) USER #8 : 0 (doesn't matter)
That's how it's done. Be sure to print out the manual. It has all this information and more in it, and you will find it a valuable reference.
The above example is not a complete printout of everything that you will see on the screen. There are quite a few on-screen menus during data input that list the allowable inputs, so that you don't have to memorize such things as the artifact type of a key. In fact, the menus almost cover such information better than the manual does.
The USER prompts seen with some types of artifact data input, such as the key above, are not used by the standard MAIN PGM programming. They are made available for the purpose of adding extra data for special programming. If you have not added any such extra programming, simply enter zero at each prompt (or hit Escape to retain the default value shown on the screen) and ignore them.
Jun'91: Back to the Basics: Containers How to program and use; step-by-step examples
Mar'91: Back to the Basics: Rooms and Doors How to program and use; step-by-step examples
Dec'90: Using 10 Directions in Version 7.0 How to modify the MAIN PGM Pitfalls to watch for
Sep'90: Eamon Style and Technique: the Storyteller’s Craft Pointers on how to plot and write an Eamon adventure
Jun'90: Converting Eamon Adventures to ProDOS A step-by-step discussion of the procedure
Mar'90: Designing Descriptions for the 40/80 option How to write descriptions that look good in both 40 and 80-column formats.
Dec'89: Basic Eamon Routines Tips on modifying commands and on using the POWER and USE commands
Sep'89: Using Effect for Eamon Games with 7.0 How to make and use your own special effects
Jun'89: Traps and Obstructions Guidelines for proper design in order to ensure maximum player enjoyment
Mar'89: The Parameters Option Using this option to make special artifact types
Dec'88: Increasing free memory for large adventures Tips on how to make the MAIN PGM smaller
Sep'88: Programming efficiently for space and speed Tricks that make an Applesoft program run faster
Jun'88: Room Descriptions How to properly describe room exits to make the player's mapping effort more enjoyable
Oct'87: Handling monster groups Special routines for handling the friendliness of 'tribes' of monsters (from "Buccaneer!")
Jan'87: Initializing an adventure diskette A tutorial on how to generate a new adventure diskette
Jun'86: A description of the changes that were made going from version 6.0 to 6.2.
Oct'85: Putting Fun Stuff in Eamons 1) Using gates 2) Number conventions for extended 6.0 usage (also example code for DIG & WEAR commands) 3) Save Game feature 4) Some undocumented features (group monsters, poisons, truces)
Aug'85: Adding commands to the MAIN PGM Discusses an example EAT command
May'85: Things We'd Like to See in Eamon Pets, exhaustion, broken armor, SAY command much good discussion on pets
Mar'85: Guidelines for writing adventures Some good suggestions and guidelines, and a discussion of several inherent limitations of the Eamon MAIN PGM
Jan'85: dead bodies and magic A great discussion of magical effects
Oct'84: Doors, gates, and keys Locked doors for version 5.0, which didn't have key artifacts
Aug'84: Local Magic A few ideas for special stuff
May'84: A brief discussion of some Eamon stuff Eamon Master Diskette Basic monster and Artifact fields
Mar'84: Initializing a new adventure diskette
A "monster" in Eamon is defined as any animate denizen of the dungeon. This includes friends, foes, bystanders, people, wild animals, pets, and all other categories of creatures. The monster routines support weapon-carrying monsters, natural weapons such as claws and teeth, and unarmed monsters who can't fight until they are able to find a weapon.
Monsters can be individuals or groups. A group can be a pack of wolves, an orc patrol, a horde of locusts, or whatever. Groups are important; they permit the author to include many more monsters without filling up the database (which quickly uses up memory and disk space and makes the game run slower). Groups can also make the game play better, as it makes the list of monsters in the room much shorter. If you've ever played an Eamon in which there were 12 or 15 monsters in the room, then you know what I am talking about!
In version 7.0, a monster's fighting ability is determined by his Agility (AG) and his armor. The higher the Agility, the better he can fight. The weight of his armor lowers his fighting ability, but it also protects him. Lastly, his Hardiness (HD) defines how many hits he can take before he dies. Be careful not to select numbers that are too high. If the monsters are too strong then the player will keep getting killed out and will give up in disgust before he gets the chance to see all of your adventure. Here's a rule of thumb that isn't too far off: for the most difficult fights, a character with a fairly strong HEAL spell, chain mail and shield, and a 2D6 weapon should get killed no more than 50 percent of the time. Of course, this balance will be affected by whatever companions you have given the player by the time the confrontation takes place.
One item that seems to confuse many new authors is how to define the room location of an artifact that is a monster's weapon. The artifact's "room number" should be the negative of the monster's number, minus 1. For example, a weapon being carried by monster #5 should have a room number of (- 5 - 1) or -6. Also, a monster can carry any artifact, not just weapons, and you can start him out with as many as you please.
Let's do a few examples. First, lets do a generic sword, artifact #8, that our monster will carry. Next, let's do a simple orc, and let's make him monster #4. (NOTE: the following is not a complete printout of everything that you will see on the screen. There are quite a few on-screen menus during data input so that you don't have to memorize such things as the weapon type of a sword.)
ROOM-0 ART.-7 EFF.-0 MONS.-3
YOUR CHOICES ARE-- 1. ADD NEW ROOM,ARTIFACT,EFFECT, OR MONSTER 2. (etc.)
ENTER KEY FOR YOUR CHOICE (1-7) 1
DO YOU WANT TO ADD A ROOM, ARTIFACT, EFFECT, OR MONSTER (HIT KEY, RAEM) A
ENTER ARTIFACT NAME: SWORD
ARTIFACT DESCRIPTION: YOU SEE A PLAIN IRON SWORD.
VALUE : 10 (not worth a lot)
TYPE : 2 (weapon)
WEIGHT : 5 (not too heavy)
ROOM : -5 (carried by monster #4)
ODDS : 10 (ordinary weapon)
W.TYPE : 5 (sword)
DICE : 1 (not a real good sword)
SIDES : 4 (not a real good sword)
ROOM-0 ART.-8 EFF.-0 MONS.-3
YOUR CHOICES ARE-- 1. ADD NEW ROOM,ARTIFACT,EFFECT, OR MONSTER 2. (etc.)
ENTER KEY FOR YOUR CHOICE (1-7) 1
DO YOU WANT TO ADD A ROOM, ARTIFACT, EFFECT, OR MONSTER (HIT KEY, RAEM) M ENTER NAME: SMALL ORC
ENTER DESC-- YOU HAVE SURPRISED A SMALL ORC! EVEN THOUGH HE'S SMALL, HE'S MAD AS HECK AND HE IS READY TO TAKE YOUR HEAD OFF.
ENTER HD: 8 (he's pretty scrawny)
ENTER AG: 16 (he's pretty quick, though)
ENTER # MEMBERS: 1 (he's not a group monster)
ENTER COUR: 175 (he's fairly determined to kill you. A courage value of less
than 100 makes him more likely to run away, and a value of more than 100 makes
him more likely to chase you if you FLEE.)
ENTER ROOM: 14 (you'll find him in room 14)
ENTER WEIGHT: 80 (he's a little guy)
ENTER ARMOR: 1 (light armor)
ENTER WEAPON #: 8 (do NOT use neg. number here)
ENTER DICE: 1 (doesn't matter-he doesn't use natural weapons, so his dice and
sides will be determined by the weapon he is carrying)
ENTER SIDES: "4• (doesn't matter)
ENTER FRIEND: "1• (an enemy)
OK, now let's do a group monster, a pack of rats. Remember that the data for group monsters is always that of just a single member of the group:
ROOM-0 ART.-8 EFF.-0 MONS.-4
YOUR CHOICES ARE-- 1. ADD NEW ROOM,ARTIFACT,EFFECT, OR MONSTER 2. (etc.)
ENTER KEY FOR YOUR CHOICE (1-7) 1
DO YOU WANT TO ADD A ROOM, ARTIFACT, EFFECT, OR MONSTER (HIT KEY, RAEM) M
ENTER NAME: RAT (always use singular name)
ENTER DESC-- THE ROOM IS CRAWLING WITH RATS!
ENTER HD: 1 (easy to kill with one blow)
ENTER AG: 20 (fast and hard to hit)
ENTER # MEMBERS: 18 (18 rats in the pack)
ENTER COUR: 30 (a bunch of little cowards)
ENTER ROOM: 22 (you'll find them in room 22)
ENTER WEIGHT: 1 (real small)
ENTER ARMOR: 0 (none)
ENTER WEAPON #: 0 (natural weapons--teeth)
ENTER DICE: 1 (these values are used here)
ENTER SIDES: 2 (a single rat bite isn't that dangerous)
ENTER FRIEND: 1 (another enemy)
That pretty much covers basic data entry. If you keep your weapons straight and pick the right numbers for good balance in the fighting, you've got it nailed down. Be sure to print out the manual! You will find it a valuable reference when plotting and populating your dungeon.
Think long and hard before using dead bodies in your adventure. It is not an error that the 7.0 DDD comes with dead bodies disabled with a REM! Only very rarely do dead bodies do anything but take up tons of valuable memory and disk space and slow down the program execution. Dead bodies complicate late data additions while fine-tuning your adventure. And they are very difficult to do that read well with group monsters. Really, the only time that bodies are worth implementing is if you want to use their descriptions to print death scenes when monsters die. But if all you have to say is YOU SEE A DEAD MONSTER, then your adventure will be much better without them.
One feature of modern Eamon adventures is the ability to "embed" artifacts in room descriptions. Such embedded artifacts do not appear in the room until the player examines them, at which time they are converted from "embedded" to "normal".
The biggest drawback of embedded artifacts is that the artifact's name must correspond almost exactly with the name used in the room description. This is often difficult to accomplish in a way that reads well. For example, if there is a secret hidden trapdoor in the floor, the room description can hardly say so! This difficulty could be gotten around in older Eamon versions by making the trapdoor a "hidden" artifact that would appear in the room when the player did a LOOK command, but version 7.0 does not support "hidden" artifacts.
The solution for this problem in version 7.0 was the implementation of the SYNONYMS routine at line 4600. This routine has been designed specifically to identify embedded artifacts that may have names that are drastically different from the one in the room description.
Let's look at an example of a synonym and how it is handled by the routine. We'll use that hidden trapdoor that I mentioned before, and let's say that it is Artifact #17 and is located in Room #21, and its name is SECRET TRAPDOOR.
First, the room description:
THIS ROOM IS LONG AND NARROW, WITH A HIGH CEILING. THE WALLS ARE LINED WITH MOUNTED ANIMAL HEADS. THERE IS AN ORNATE RUG CENTERED ON THE FLOOR. THERE IS A BUMP IN THE RUG NEAR ONE CORNER.
Now, let's generate the lines for the Synonym Checker:
4610 SL = LEN (S$)
4620 IF RO = 21 THEN SY$ = "RUG": SY = 17: GOSUB 4680
4630 IF RO = 21 THEN SY$ = "BUMP": SY = 17: GOSUB 4680
4675 RETURN
4680 IF LEFT$ (SY$,SL) = S$ OR RIGHT$ (SY$,SL) = S$ THEN S$ = A$(SY): POP
4690 RETURN
Variables:
S$ is the "object" that the player is examining SL is the length of the object name that the player typed RO is the Room that the player is in SY$ is a synonym for the object SY is the artifact number tied to the synonym
My example sets up two possible synonyms for the secret trapdoor: RUG and BUMP. Let's examine the routine on a line-by-line basis:
4610 finds the length of the object name the player typed in.
4620 checks to see if the player is in room 21. If he is, it passes the synonym
name RUG and the artifact number of the secret door (which is artifact #17) to
the compare subroutine at 4680.
4630 is the same as line 4620 but for the synonym BUMP.
4675 exits the synonym routine if no synonym match was found.
4680 compares the synonym SY$ to the object S$. If a match is found, it changes
the object name to the name of the synonym and POPs the subroutine stack to
avoid returning to the synonym checker.
4690 exits the compare subroutine. If no match was found, it RETURNs to the
synonym checker in case there are multiple synonyms in the room. If a match was
found, it RETURNs to the routine that called the synonym checker.
In my example, there are two possible synonyms in the room, RUG and BUMP. The command EXAMINE RUG would execute these lines: 4610, 4620, 4680, 4690. The command EXAMINE BUMP would execute these lines: 4610, 4620, 4680, 4690, 4630, 4680, 4690. As you can see, the number of lines executed goes up rapidly with each synonym that is added. This is why the room number RO is checked in 4620 and 4630; if the player is not in room 17 then the lines executed for either command would be: 4610, 4620, 4630, 4675. This avoids wasting time checking for synonyms that aren't even in the room.
Even though my example uses just two synonyms, you can add as many as you want. There is room for 69 synonyms without renumbering the routine, and as many as 94 if you renumber.
The synonym checker is a great tool and I strongly recommend that you take advantage of it.
A Temporary variable and counter
A$ String read in from EAMON.DESC Full command typed by player Name of Art.
being PUT or GIVEn
A$(*) Artifact names
A%(x,y) Artifact data; 'x' is Art. number; (see below for values of 'y')
A2 Temporary variable and counter
AC Armor Class of armor brought by player from Main Hall
AE Armor Expertise; affects combat odds
AR Artifact number of ARmor being worn
B FAST.START parm byte; used to compute if FAST.START file is valid.
B$ Name of Monster being GIVEn to Name of Monster being REQUESTed from Name of
Artifact being PUT
B% Ampersand Integer array search variable used to pass the last location to be
searched to the ampersand routine Temporary variable.
BA Money in BAnk
BV$(*) Attack Verbs used during melees
C Command array number of current command
C% Ampersand search routine Counter
C$(*) Command verb array
CC Line counter for printing valid commands
CH Player's CHarisma
CP Number of Columns of display (40 or 80)
CZ$ Command given in last round of play
D Temporary variable Direction being moved (123456 = NSEWUD) Number of dice for
combat resolution
D$ CHR$(4) for DOS
D% Value to be searched for by Ampersand Integer array search routine
D2 Damage points taken by Defender in combat
D3 Counter variable
DF Monster number of DeFender in combat
DI "DIe" flag-set to 1 if player is killed
EA Armor Expertise weighting factor
ED$ String: "EAMON.DESC"
EM "EMbedded" location--see below
ER$ String: "EAMON.ROOMS"
F "Found" flag--see below F(*) Total hits taken in combat:
F(1) = enemies in room F(3) = player and friends in room
F1 Low byte of top of free memory before string is read in from EAMON.DESC
F2 High byte of top of free memory before string is read in from EAMON.DESC
FF$ Form Feed character CHR$(12) required by Videx 80-column cards
FR Temporary variable used to compute FRiendliness of newly met monsters
G Monster number of Guard of bound monster
GO Player's GOld
HA "HAve" (being carried) location--see below
HI "HIt" flag-set to 1 if defender has been hit in combat
HM "HIMEM" variable; used to compute if FAST.START file is valid K Temporary
variable used when attacking artifacts and freeing bound monsters
L Line counter for screen pause
LA Length of records in EAMON.ARTIFACTS
LK Temporary flag variable-set to 1 if INVENTORY finds artifacts being carried
or if OPEN finds artifacts in a container
LL Number of lines in string read in from EAMON.DESC
LM Length of records in EAMON.MONSTERS
LR Length of records in EAMON.ROOMS
LS Artifact number of artifact being carried that is current Light Source
LT LiT Room flag-set to 1 if room is lit M Temporary counter variable
M$ Monster name being searched by array search routine at 4700
M$(*) Monster names
M%(x,y) Monster data; 'x' is monster number; (Monster '0' is the player)
M%(x,0) 'Seen' flag
M%(x,1) Hardiness
M%(x,2) Agility
M%(x,3) # of members in group
M%(x,4) Courage
M%(x,5) Room number
M%(x,6) Weight (not currently used)
M%(x,7) Armor thickness
M%(x,8) Weapon number
M%(x,9) Number of dice (natural weapon)
M%(x,10) No. of dice sides (natural weapons)
M%(x,11) Friendliness
M%(x,12) Original size of group
M%(x,13) Damage or hits taken
M2 Temporary variable and counter
MC Counter for group Monsters during combat
MR% Number of monsters that flee from combat
NA Number of Artifacts (including those brought by player from the Main Hall)
NC Number of valid Commands
ND Number of valid Directions
NE Number of Effects
NL Flag set to 1 if room is Naturally Lit
NM Number of Monsters
NR Number of Rooms
NX Number of eXits from room NZ Number of artifacts in database (not including
those brought by player)
OF Monster number of attacker in combat
Q Temporary variable used in GIVE, PUT Q$ Temporary input string used in GIVE,
PUT
R Record number to be read in from EAMON.DESC Temporary random number
R2 Number of room being moved to
R3 Number of room last moved from
RB$(*) Verb that describes non-hit attack result RD%(*) Array containing exits
from room
RE REcord number of player character in CHARACTERS file on Main Hall disk.
RL Temporary random number; temporary variable
RN$ Room Name of present room
RO ROom number of present room S Number of dice Sides used to compute damage in
combat Array location of Spell data for spell being cast
S$ Subject (object) of command
S2%(*) Current level of Spell abilities
SA%(*) Absolute level of Spell abilities
SE$ SEx of player character
SH Artifact number of SHield being worn SL Temporary variable used for
S$ String Length during array searches.
SM$(*) SMILE response verbs
SP SPEED spell counter until expiration
SU Flag set to 1 if spellcast was SUccessful
SX Temporary variable used when ATTACKing artifacts
SY Artifact number of SYnonym
SY$ Name of SYnonym
T(*) Total hardiness of combat groups:
T(1) = enemies T(3) = friends
TA Flag set to 1 to tell ATTACK code that it is handling a BLAST spellcast
TP Total value of loot sold at end of game
UP Flag to increase weapon ability
V$ Command Verb
V%(*) 'Seen' flag for rooms
W Weapon number of player Counter at end of game for player's Weapons
W2 Complexity of readied Weapon Counter used at initialization to search for
duplicate artifact names Number of Weapons carried by player at end of game
W5 Input variable for Weapon number that player is selling at end of game.
WA%(*) Player Weapon type Abilities
WD%(*,*) Weapon Data for weapons taken back to the Main Hall
WH "WHere" location--see below WM Computed odds of achieving a hit during combat
WP$(*) Names of all Weapons being carried by layer at end of game
WP%(*) Artifact number of all Weapons being carried by Player at end of game
WT Combined WeighT of all artifacts being carried by player
X Temporary variable and counter
Z Number of artifact that is being PUT
'Seen' flags These variables tell the YOU SEE routine whether it should print the long description of the room, artifact, or monster. If the 'Seen' flag is zero, the description is printed.
Search Routine Variables The variables EM, HA and WH are used by the various command routines to pass location search parameters to the artifact array search routine at 4800 and the monster array search routine at 4700. The default values for these are:
EM <EMbedded> Room number + 200 HA <HAve it> - 1 (carried by player) WH <WHere> Room number
For example, the EXAMINE command would use these defaults, in order to look for artifacts in the room, both seen and unseen, and carried by the player. But the DROP command will set all three of these to (-1) so that only artifacts being carried by the player will be found by the search routine. The GET routine sets HA = WH so that the player can't GET something that he is already carrying.
When the search routines at 4700 or 4800 have completed their search, they set the variable F = 1 if an artifact or monster is matched to the object specified by the player's command, but set F = 0 if no match was found;
Artifact Arrays The first five array locations of all artifacts are identical: A%(x,0) 'Seen' flag A%(x,1) Value A%(x,2) Type A%(x,3) Weight A%(x,4) Location
There are ten different formats for the next four array locations, depending on what the artifact type is:
Type 0 (Gold), 1 (Treasure): A%(x,5) Not used A%(x,6) Not used A%(x,7) Not
used A%(x,8) Not used
Type 2 (Weapon), 3 (Magic Weapon) A%(x,5) Weapon type A%(x,6) Complexity A%(x,7)
Number of dice A%(x,8) Number of dice sides
Type 4 (Container) A%(x,5) Artifact number of key A%(x,6) Strength A%(x,7) Set
to 1 if open A%(x,8) Not used
Type 5 (Lightable) A%(x,5) Counter until extinguished A%(x,6) Not used A%(x,7)
Not used A%(x,8) Not used
Type 6 (Drinkable) A%(x,5) Healing amount A%(x,6) Number of uses A%(x,7) Set to
1 if open A%(x,8) Not used
Type 7 (Readable) A%(x,5) Record number of 1st Effect A%(x,6) Number of Effects
to print A%(x,7) Set to 1 if open A%(x,8) Not used
Type 8 (Door/Gate) A%(x,5) Number of room beyond A%(x,6) Artifact number of key
A%(x,7) Strength A%(x,8) Set to 1 if hidden
Type 9 (Key) A%(x,5) Not used A%(x,6) Not used A%(x,7) Not used A%(x,8) Not used
Type 10 (Bound Monster) A%(x,5) Monster number when freed A%(x,6) Artifact
number of key A%(x,7) Monster number of Guard A%(x,8) Not used
Type 11 (Wearable) A%(x,5) Armor class (not implemented) A%(x,6) Type (not
implemented) A%(x,7) Not used A%(x,8) Not used
That pretty much covers all of the variables. See the DDD manual for more information.
ProDOS NOTE: Most of the DOS 3.3 MAIN PGM Init code at 31000 and 33000 is broken out into a separate program named MAKE.FAST.START. The MAIN.PGM uses the FAST.START VAR file generated by this program to save memory and for much faster startups. Once you have entered your data, run MAKE.FAST.START before testing the adventure.
Also note that ProDOS adventures as distributed by the EAG do not usually contain the data files EAMON.ARTIFACTS nor EAMON.MONSTERS. This data is contained in the FAST.START file. If you want to edit or list the adventure data, first run the program MAKE.ARTS.MONS to generate the two missing data files. If you make a change to the artifact or monster data, be sure to rerun MAKE.FAST.START when done to update the FAST.START file.
I get a fair number of calls and letters from people who are having problems with an Eamon. Often, the fix is something very simple that anyone can do, if they know what to look for.
Problem: The adventure is doing something that doesn't make sense, or is
crashing.
Fix: Check the revision date in the adventure's catalog. Compare the date on
your disk with the revision date listed in this newsletter (a DOS 3.3 list was
in the last issue, and a ProDOS list is in this issue). If the date does not
agree, check the EAG back issues from around the time of the revision date and
look for a bug fix that has the same problem you are seeing.
If you don't see anything that will help, proceed with the various procedures outlined in the rest of this article.
Problem: WRITE PROTECTED error
Files are written to on both the Master and the adventure disks. You must not
cover the write enable notch with a write-protect tab.
If the adventure is written to the back side of a disk, it may be that the write
protect notch was improperly punched.
Fix: If the write-protect notch is covered, remove the Write-protect tape from
the edge of the disk. If the adventure is on the back side of a disk, repunch
the notch or else copy the adventure to the front side of another disk.
Problem: DISK FULL error This error usually occurs when trying to SAVE a DOS
3.3 version of the game. Many of the better Eamon adventures do not have DOS 3.3
on the disk, because they require every possible bit of disk space. You will get
this error on these big Eamons if you make a copy of the disk by using the DOS
INIT command and copy the adventure over to the new disk file-by-file. INIT
automatically installs a copy of DOS 3.3 on the disk.
Fix: Make Eamon adventure copies with Copy II+, using the "disk" option, or else
use COPYA from the DOS 3.3 Master.
NOTE: If you get a DISK FULL error while saving a game, immediately delete the files GAME.STR, GAME.SVAR, & GAME.PTRS (DOS 3.3) or SAVED.GAME (ProDOS). There is a danger that the disk catalog will be corrupted if you don't do so.
Problem: I/O ERROR This error can not be caused by a bug in the adventure. Your disk is bad.
Problem: PROGRAM TOO LARGE This error can not be caused by a bug in the adventure. It can only occur if the adventure's MAIN PGM has become corrupted. Note that your disk might be good, but was copied from a bad disk that contained the original error.
You might also get this error in very large Eamons if you have any extra stuff resident in memory such as Program Writer.
Problem:
SYNTAX ERROR IN XXXX
NEXT WITHOUT FOR ERROR IN XXXX
RETURN WITHOUT GOSUB ERROR IN XXXX
ILLEGAL QUANTITY ERROR IN XXXX
UNDEF'D STATEMENT ERROR IN XXXX
BAD SUBSCRIPT ERROR IN XXXX
DIVISION BY ZERO ERROR IN XXXX
TYPE MISMATCH ERROR IN XXXX
These are genuine program bugs. Please follow these steps immediately after the crash, before typing anything else and before contacting the EAG with a bug report:
1) Write down the line number (XXXX)
2) Type LIST XXXX (XXXX = the line number)
3) The offending program line will be printed to the screen. It will contain a
number of variable names, such as RO, M, AD%(A,4), etc.
4) Type PRINT statements for each of the variables in the bad line. PRINT RO
PRINT M PRINT AD%(A,4) (Note that this includes the variable A which must also
be printed) PRINT A (etc.)
5) Each time you type in a PRINT statement, the value of that program variable
will be printed to the screen. Write down all this info. It is virtually
impossible to fix obscure bugs without full knowledge of what the bad program
line was doing.
6) It will be very helpful if you write down a detailed description of where you
were in the dungeon and what you were doing at the time the error occurred.
Please include the revision date of the disk and where you got it. It is
possible that your supplier's disk became bad somehow and must be replaced; I
will send them a replacement if I make this determination.
Problem: When trying to "go on an adventure", the Main Hall program goes
crazy, printing out all kinds of stuff without waiting for you to type anything.
Fix: The FRESH MEAT file on the adventure disk is locked. Unlock the file with
the command
(DOS 3.3): UNLOCK FRESH M