|By Paul Shoemaker for the TRS-80 Colour Computer|
Adjustments to Stats and Spell Handling
Although nobility might not be the adventurer's sole motivation. The dungeon is riddled with "chests" that contain gold as well as weapons and armour (of various pluses). I have modified the original game to put some especially richly supplied areas of dungeon levels 2, 3 and 4 behind a locked door. I cannot help but feel that Shoemaker originally intended this feature to be included. There are isolated areas on each of these levels that are especially packed with treasure but with only one passage leading into them. The original game instructions mention a non-existent ability to use the "K" key to kick doors, but in the game as I found it none of the doors actually prevent movement. Also, there is a second level "knock" spell included on the list of spells, but it did not actually do anything except print the message "this cannot be used at this time." I think this is an equivalent of a "work in progress" sign. Shoemaker must have ran out of steam in his gargantuan programming project.
New Graphic Routines
And gargantuan it certainly was. The original consisted of a collection of half a dozen disk based programs that run each other in sequence. Part of the reason for chaining these programs together is, I think, a result of a certain limit of the TRS-80 Colour Computer that the MC-10 doesn't have. For the Coco to get lowrese graphic characters on the screen you have to either print them using the CHR$ or STRING$ commands, or poke their ASCII values directly into screen memory locations. In either case, this requires large amounts of numeric data, not to mention the commands to get each value to the screen. In the MC-10 you have the ability to input graphic characters directly into strings just like any other character. Imagine having to use "PRINTCHRS$(74);CHRS$(73);CHR$(77)" every time you simply wanted to print "JIM" on the screen and you get the picture of how unwieldy using lowres graphics on the Coco can be. I was able to use MC-10's easier use of lowres to allow me to combine all of the programs into only 2: "INN" for generating and managing characters and CAVES to allow the exploration of the 4 dungeon levels. In addition I was able to use the nifty CLOAD*ArrayVar command of the MC-10 to store all the data for each of the levels, and also the data of the characters (with the Level One map data). This way you only have to load one file after loading and running the CAVES and not a separate file for the character data.
Doors and Keys Added
I have modified the level data now to also include info on one locked door for each of the three lowest levels. These doors prevent direct access to the most treasure rich areas. Now you will have to rise to the skill level 2 to achieve the Knock spell, which I also have added, which gives you a chance (based on your intelligence) to open locked doors. Or you must search enough chests on a level until you find a key to the "main treasure area" for that level. I have also modified the routine for assigning the number of spells to adjust depending on your intelligence. This is normal procedure in D&D type games and is the reason high intelligence is a prerequisite for being a magic user. In the original version of CAVES intelligence didn't seem to determine anything. Now a high intelligence increases the speed at which you gain new spells and your ability to use at least one of those spells (Knock). I also found that Wisdom didn't seem to play a role. I was little concerned that the number of random encounters per level seemed low (long gaps were possible) so I also increased the chance of the number encounters based inversely on your Wisdom level. My reckoning is that if you lack wisdom you will tend to blunder more noisily around dungeons and therefore attract more monsters. It's not a major adjustment, but I felt it was important to try to give all the traits some role rather than simply being there for show.
The game had to be simplified. Certain features had to be removed to help it to fit into the 20K of the MC-10 with expansion pack. The instruction screen (with its redundant mention of "K" for kicking doors) had to go, as did the ability to back up a space. I also removed the subroutine to adjust the time delay for the display of messages and the formal quit routine. When the game ends, you must type RUN to get things going again. Here are the remaining key commands for the MC-10 version:
W = Move forward (to go backward you have to first turn around using A or S)
A = Turn Left
S or D = Turn Right
M = See a map for the level (your position is indicated in blue)
Space = Toggle between Stats and Inventory screens
The screen drawing routine had to be condensed to a single routine using an array to change the look direction and results. In the original there were simply 4 completely different routines, even though they did essentially the same thing. I just needed to set up an array with different offsets to search the right X/Y values based on the direction you are facing to boil it down to one routine. I was also able to replace multiple IF commands with a more direct ON/GOTO commands to branch in multiple ways based on a single variable.
Shoemaker had a nice explosion graphic for spells which involved saving the data for an area on the screen, printing the explosion and then putting back the original graphics from "behind" it. It was a bit slow and used an unwieldy number of variables. I was able to simplify it greatly so that it only used the "scratch" variables I had designated for basic tasks in the program. I also added it to the routine when a chest occasionally explodes when you open it.
Reusing variables is a good technique to save memory. I had to use it quite a lot because as it turned out there is only around 400-500 bytes of space free after CAVE initially runs and assigns its primary variables. I've tested it pretty extensively but you just never know if there are conditions and areas of the program that will call for new variable assignments that can push the program into an Out of Memory (OM) error. I spent a lot of time streamlining the program to remove unnecessary variables, commands, spaces between commands and line numbers. Cramming as many commands per line separated by colons can save a lot of memory. Liner numbers take more memory than a colon.
Because of this streamlining and because the graphics can be printed directly, the program runs much more quickly than the original. The slightly higher Basic execution speed of the MC-10 also helps a bit. Now when a monster appears it snaps onto the screen, instead of being painstakingly drawn line-by-line. I adjusted the way monsters are selected to appear for each level. The original simply selected from the lower half of the 16 monster types for levels 1 and 2 and then added the possibility of also encountering the upper half for levels 3 and 4. It loaded the graphics for the monsters from a disk file, but I was able to translate them into characters and put them into DATA statements.
The original code also went through a convoluted process of reassigning numbers for each monster before selection based on level, so I think there must have been a lot of adjustment and experimentation by Shoemaker before he settled on their strengths and which would appear on lower and higher levels. I was able to eliminate all this swapping of values. Then I simply ordered the data for the monsters in terms of their stats (dexterity, damage, armour, treasure). Now the monsters are selected in groups of 4. At level one you can encounter monsters 1-4, level two--monsters 1-8, level three--monsters 1-12 and level four--monsters 1-16. Actually, I have made it so "the guide" guy (who is very weak and obviously just meant as a humourous annoyance) can very occasionally appear on any level.
This now means you can only encounter the 3 most powerful "boss" monsters if you are on level 4. I think by the main title screen and the stats that the super boss is meant to be the Dragon. There is no win routine as such, but I think one can claim that if they have risen to a high enough skill level to defeat the Dragon, they have effectively beaten the game!
I noticed that there were graphics for two additional monsters on the disk file, one particularly nice one for a Giant Mantis, which were listed as numbers 17 and 18. But by the Basic program code I could discern no possible way that these graphics could ever be selected. Since I was pressed for space, I left them out, but I wonder if there is some special routine, perhaps somehow buried in the machine code, or the logic of the Basic code that has somehow escaped me, that can trigger these graphics. Maybe they were for different versions of more advanced levels or for future versions of the program. Or perhaps, again, Shoemaker simply ran out of steam in his development of the program. The mantis (which was really nicely drawn) reminded me of the boss you find in the Temple of Apshai classic RPG, which is another program I ported and blogged about for RetroChallenge back in 2014.
Dungeon Screen drawing.
The original also used special machine language USR routines to draw all of the 3-D dungeon screens. Obviously Shoemaker had to use machine language to avoid the slow crawl of re-drawing each move using CHR$ and STRING$ commands. It also would have allowed him to save memory. Once again, I was able to accomplish these goals in ordinary Basic because the MC-10 allows direct input of graphic characters. I used my own drawing program (SKETCH) to redraw all the elements. I just issued the USR commands after breaking out of the original Coco program (running on VCC) to display each element: USR(1)-USR(18). I then redrew it on the VMC-10 using a special version of Sketch and printed each to strings. With these in hand I could just use ordinary PRINT@ to get them where they needed to go on the screen. I replaced the "elevator" routines with simple stairs-up and stairs-down graphics. Originally I thought this would help me save memory, but I'm not sure it actually does. It makes the dungeon a little more like a real dungeon, but it loses a little of the whimsy of Shoemaker's original. However, over the course of the porting project I grew to like the images I had made, so I kept them in.
I hope the changes I've made have helped improve this amazing program by Showemaker. I hope that he wouldn't be offended by my changes and the use I have made of his work. I tried to look him up on the Net, but was unable to find anyone who was obviously the same person who created this classic RPG for the Coco (and now for MC-10). If anyone can put me in touch with him, I would really appreciate them letting me know, so I can contact him and thank him for his wonderful contribution to the Coco and retro-computing community.
And thanks to the Highretrogamelord for making me aware of the original: