Pages

Thursday, 30 March 2017

Caves of the Unwashed Heathen

By Paul Shoemaker for the TRS-80 Colour Computer
First--a disclaimer. The title of the game is not mine. I wish no offence to any neo-pagans or others out there who might be concerned about the old pejorative term "heathen" used by some Christians against religious competitors. The title of the game, I am quite sure, is meant by its author Paul Shoemaker, as tongue-in-cheek. The game is a straightforward dungeon crawler in the D&D Tolkien tradition, but there is also a certain irreverent cheekiness directed towards the genre. Besides the title, this irreverence takes the form of a number of funny minor elements included in the game. For instance, in the original you descend into the caves by way of an elevator. Also, one of the enemies you occasionally encounter is a smiling little round green fellow called "the guide guy," who is clearly a rendition of the round character from the Sci Fi novels (and the box art for the text adventure game version) of The Hitchhikers Guide to the Galaxy. There is a message below him that reads "Don't Panic!" However, the game is also filled with the standard dwarfs and magic users, as well as a host of vile monsters from the depths, who conceivably represent the "unwashed heathen" opponents of our "noble" paladin.


Adjustments to Stats and Spell Handling

But 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.



Simplifications

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.


Explosion

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.


Variable Use

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.


Monsters

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.


Wrap Up

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:


4 comments:

  1. Hi Jim, I really like what you've done to improve the game, make the code more elegant and address some of the unfinished aspects. You're right, I did run out of steam after a while. :-)

    I honestly don't recall why monsters 17 and 18 don't appear. Probably an oversight, but it may be that I intended to add them into the lower levels when I completed them.

    Most of the monster graphics are modeled after illustrations in the Basic D&D manual.

    I'm delighted to see that you and perhaps a handful of others have played the game and hopefully gotten some enjoyment out of it. I certainly enjoyed writing it.

    ReplyDelete
  2. Mr. Shoemaker,

    Thank you for getting in touch. It is so nice to have some of the mysteries of your code uncovered at last. I was really baffled by the fact that monsters 17 and 18 didn't seem to be able to be selected. These days I code using a text file in Windows, which gives a much more panoramic view of the program code than working on a real machine using the EDIT and LIST commands (and break key). I recall how easy it was under such conditions to lose track of features that one was trying to implement. And the diagrams did remind me of the original D&D manuals. They're amazing semi-graphic works art!

    I certainly have got a great deal of enjoyment from your game, although I must admit that I haven't made it all the way to defeating the dragon without cheating (all in the name of game testing of course).

    There is another fellow on the net, Jerry Young, who I know has also played the game quite extensively. Here's a link to his video:
    https://youtu.be/gOJvo3R_DLI

    I also recently made a mapmaker for the MC-10 version. It does not use hires graphics like yours, but it gets the job done: https://youtu.be/2LLIkGuP2IA

    Thanks for your comments and for a great game.

    ReplyDelete