(This is the "Dungeon Designs" column from the March 1994 issue of the Eamon Adventurer's Guild newsletter. Copyright 1994 Eamon Adventurer's Guild, 7625 Hawkhaven Dr., Clemmons, NC 27012-9408. You may reproduce this freely as long as this credit remains attached to the article.) SPECIAL NOTICE I'm facing a problem with this column: I am having a bit of difficulty coming up with stuff to write about that hasn't already been covered in past issues. If there's something that you would like to see discussed or explained, please let me know about it! Miscellaneous Notes and Suggestions Monster Weapons: Few things detract from the feel of combat like silly and inappropriate weapon assignments. Pay attention to the monsters' weapon numbers! If the monster is supposed to be carrying a weapon, be sure to actually assign him a "real" weapon that is included in the artifact database. If the monster is fighting with natural weapons (teeth, karate, whatever) be sure to give him natural weapons by assigning a Weapon Number of zero. Note that you can set up individual monsters as "unarmed" by giving them a negative weapon number. A good example of when this is appropriate would be a freed prisoner who has no weapon but will fight if given one. The Play really gets screwy when a multiple-monster is carrying a real artifact-weapon and drops or breaks it during combat. (I don't mean that the program breaks, just that this event reads very poorly.) Avoid this by not assigning a real weapon to multiple monsters unless there is some overriding reason for such a weapon to exist. When possible, give all multiple-monsters "natural" weapons, even if they should be carrying real ones. Minimize the confusion by making little or no reference to the monsters' weapons. If there are just two or three members of the group, it might be better to make them individual monsters and assign real weapons to them. Artifact USER Fields: The artifact database fields named USER are not used by the MAIN PGM. It doesn't matter what is put in these locations, since this information isn't used for anything. The DUNGEON EDIT program makes them available so that authors can easily use these locations for special programming data of their own. Synonyms: Be sure to use the synonym checking routine for your embedded artifacts. See the June '92 EAG newsletter for a step-by-step tutorial of this powerful feature. Special Checking: When you add special programming that checks for specific artifacts, never make the check by comparing the artifact's name to S$! Always use the variable "A" and compare "A" to the artifact number that you are looking for. What difference does it make? It uses the standard player interface, permitting him to expect certain responses from certain inputs by utilizing the standard checking code. One of the worst mistakes that new Eamon programmers make is to bypass the standard interface routines. Let's do an example. Let's say that something special will happen when the player picks up an artifact named MAGIC WAND. Let's say that this wand is Artifact #12. WRONG WAY: 4060 IF LEFT$ ("MAGIC WAND",LEN(S$)) = S$ THEN (special programming) Problem: This line won't detect right-end abbreviations; the command GET WAND won't see it. WORSE WAY: 4060 IF S$ = "MAGIC WAND" THEN (special programming) Problem: This line won't detect any abbreviations; the command GET WAND won't see it, and neither will GET MAGIC. RIGHT WAY: 4060 IF A = 12 THEN (special programming) Benefits: Improves execution speed by making use of already-executed existing code; utilizes standard interface that detects truncated words. The player expects to be able to use commands as short as G M, and this line will do it. How does the "right way" work? If you look at the GET routine at 4000-4020, you will see that it calls the subroutine at 4800 to see if the artifact named by S$ is available. If the artifact is available, the routine at 4800 sets the variable A to the number of the artifact. So, you see, all of the checking has been done for you already by the time you get to your special programming at line 4060. Closed Artifacts: Containers, readable artifacts, and drinkable artifacts all have the option of being open or closed. Unless there is a strong reason to have it closed, you should be sure to leave readable and drinkable artifacts already open in the database. For example, it's irritating to the player to have to OPEN an ordinary book before reading it, as the READ command implies opening the book as well. Unfortunately, the editor defaults drinkable and readable artifacts to the closed state. Be sure to enter the open state for anything that isn't locked or tied to special effects upon opening. Containers are a special case; it doesn't matter which state they are in, as the OPEN command functions to empty them out onto the ground. However, you will of course want to have locked containers closed!