"Treasure House" AKA "Chateau of Gold" by C.J. Davison (1982)

I've been working on a port of a game called "Chateau of Gold" for the Dragon 32 computer by GEM Software to the TRS-80 MC-10 using Micro Color BASIC. The remarks at the top of the GEM code suggest that it was authored by a P. Allen:

10 REM***********************
20 REM**                   **
30 REM** CHATEAU           **
40 REM** WRITTEN BY P.ALLEN**
50 REM***********************

However, it turns out the original program was by C.J. Davison and was published as a type-in BASIC program in Your Computer Magazine January 1982 for the MZ-80 Computer. I learned this from a Chronologically Gaming video and from L. Curtis Boyle talking about that video on the Coco Nation livecast show:

I had to fix a few bugs in Allen's code having to do with RND function differences between Dragon and MZ-80 BASIC. I think my version should play a more faithful rendition and error free version of Davison's original game.

The problem with RND function conversion by Allen was that the Coco allows RND calls with a whole number like RND(10) or RND(100) to get ranges of 1-10 and 1-100, whereas most Microsft BASICs use the convention INT(1+10*RND(1)) or INT(1+100*RND(1)) to get ranges like this. The MZ-80 is a little different again, as it seems to use random numbers (or maybe this is just a quirk of Davison) in the place of the RND(1) or RND(0) to seed the RND function used in most MS BASICs. But these whole numbers do not produce whole number ranges as with Micro Color BASIC. So in the following random coordinate picker routine for putting objects into the 6X6 floor plan of each floor (Z), the refs to RND(7) and RND(5) simply seed the RND function:

1200 A=INT(1+6*RND(7))

1210 B=INT(1+6*RND(7))
1220 C=INT(1+3*RND(5))
1230 IF M(A,B,C)<5 OR M(A,B,C)>8 THEN 1200

For the Dragon, getting a random number from 1-6 can instead be accomplished with a simpler RND(6) call, and Allen correctly converted most of the RND calls to this method.  But in the case of the objects placement routine above, his eye seems to have been distracted by the "seed" number, so that he actually designated a range value of (7) instead of (6) for the 6X6 room populating function. This is Allen's modified Dragon code:

330 FORC=0TO3:FORA=1TO6:FORB=1TO6

340 IFM(B,A,C)<>0THEN360
350 M(B,A,C)=5+RND(7)
360 NEXTB,A,C
370 FORD=1TO2
380 A=RND(7)
390 B=RND(7)
400 C=RND(3)
410 IFM(A,B,C)<5ORM(A,B,C)>8THEN380

This use of 7 means that some items could be placed into the wall zone to the left and bottom of the 6X6 room grid. The wall zones (0 or 7) of the matrix were supposed to remain as zeros. Those zeros prevent the player from moving outside of the bounds of the 6X6 inner dimensions of the M(7,7,3) array, which stores what's in each room. So very occasionally I could move into the 7th space and then if I tried to move beyond the 7th space the program would try to check the un-dimensioned 8th space and a "Bad Subscript" BS error would be triggered.  Allen might never have done this because he had a better sense of the map, and paid attention to staying in the bounds of the walls while navigating the house. In my testing, I just kept moving in random directions to see how the program worked.

So, I checked all of the RNDs in the program. I think I might have found some other anomalies with the map creation logic (with some of the IFs for example), but I can't recall all the details now (too much late night coding). I think I recall a problem with how stairwells, desks, clues, entrances to the basement and the places to store your clues were distributed, leading them not to appear, or not to appear frequently enough. But I think my alterations, including how randomization was being handled, has got everything working like Davison originally intended.

The other major problem that I do recall clearly was with how Allen had implemented the final "mastermind-like" guessing game for opening the treasure chest that you find if you gather all the clues and make it to a place to store the clues. You  have to guess a four digit code (1-9) that has no digits repeating (I added a mention of this to the instructions). Instead of preserving the screen readout of the score of your prior guesses, as I think occurred in the MZ-80 version, Allen cleared the screen (he had implemented a fancy red semi-graphic border drawing system) and requested the input of a new code for each guess. This made it very difficult to work out the code by using your prior guesses, unless you were recording the scores on paper. Also, Davison's original version included a system call, probably to a beep routine, for indicating right numbers in a wrong position (1 point each), to help differentiate those from right numbers in a right position (3 points).  Since you are simply given an aggregated total for each guess, it is helpful to hear a number of "beeps" for how many of those are 1 point guesses. So I added in a SOUND command to do this (hoping my guess is right about the function call).

And Davison's original version compounds the difficulty by only allowing a random number of guesses between 1 and 10. But finding the code in anything less than 10 guesses is probably impossible, logically speaking, leaving game completion entirely up to chance. This seemed unfair. So I changed the system to a fixed 10 tries. In the magazine article Davison mentions only winning once in a month of tries. This indicated to me that there were problems in game balance. One area that also might have contributed to this was the random number used to determine any magical items you sometimes find when you uncover a cash of gold. You are given a 1 in 9 chance of also getting one such item. I changed this to a 1 in 4 chance, but I reduced the gold amount possible from 900 to 700 to compensate. Still, since treasure is fairly rare, finding special items is still fairly rare.

I also fixed how movement into a stairwell from a closed door is handled, and the ability to forego choosing to move up or down them after using the (E)xplore command. I also added back in (from Davison's original version) a message indicating that you are passing through a door. This seemed to have been removed by Allen. When you are on a door space, you are not shown that a hallway is next to it (doors close automatically?). I think it is a good reminder to the player that doors block indication of  the direction of nearby hallways. The message about a door being open reminds the player of this. It took me a while to figure out the ways doors work, and it required going back and carefully reading the original article.

I've also added 2 more color alternatives to the red borders that Allen had added and worked hard to improve and standardize the layout of messages. I had to remove REM statements and combine lots of single command lines to get the program shrunk to fit a 20K MC-10. Allen had added a nice mapping or (P)lan function to show the layout of the house and where you had travelled already. I added to that by using reversed characters in a way that indicates which rooms you have searched and found nothing. I also fixed some quirks with how the (E)xplore function reports messages. Sometimes Allen had it explicitly report that that nothing could be found, but other times it would just return to the main menu without a message. I changed it so that it always tells you explicitly when nothing was found. And I fixed a message that could appear after you open an object and find the entrance to the basement.  Sometimes, if you selected "yes" to exploring the basement, a message about "not being able to open an X" would be displayed.

The following video contains a demonstration of my new final puzzle routine, and fancy colors:

Chateau is a game with unique random map layout generation and interesting "hot key" text adventure command entry. There are a bunch of challenges and puzzles to overcome to solve the game, so I can understand why it would have taken Davison so long to accomplish a victory.  Back in the day, this would have been considered evidence of lots of "repeat play value." Today, I suspect this would just be considered frustrating. But in a time when software was expensive and relatively scarce, we were keen to find any computer gaming opportunities, especially if they were "free" just for the price of a little typing. This game shines in comparison to many contemporary type-in CRPG/text adventures BASIC games.

CHATEAU can be found in my Github repository here:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Text%20Adventures/Chateau

It can be played from my GameJolt page.  Select the big green PLAY button.  Then choose the "8-bit BASIC Text Adventures" collection. Choose "CHATEAU" from the Cassette menu and then type RUN and hit Enter in the main emulator screen.

https://gamejolt.com/games/jgmc-10games/339292

It can also be played on the Internet Archive:

https://archive.org/details/chateau_202501

"Schatzoeken" or "Treasure Caves" by Unknown Author (198?)

Original Map Playthrough

I ran across a simple little BASIC Action game/CRPG on Jason Dyer's Renga in Blue blog. It was called "Schatzoeken" and was written in Dutch. Jason mentioned it because he was discussing a text adventure by the same name, which he needed to disambiguate as he did his research. His brief mention peaked my interest. The game was for the Sinclair ZX-81 and from the image of the simple semi-graphic "dungeon" screen, it looked like it should be able to be translated to TRS-80 MC-10 fairly easily. I've never had much problems with Sinclair BASIC, which is a good BASIC with some unique features that are fairly easy to work around. Translating to Dutch was made easy by Google translate. It rendered the title from the titlepage/instruction screen as "Treasure Caves".  However, Renga had mentioned that "Schatzoeken" is used in Dutch as something like "Treasure Hunt" and is even used more generically for things like "geocaching" in modern Dutch.

So the move from Sinclair to Microsoft BASIC and from English to Dutch was not too difficult.  However, once I had the game running I noticed that the movement between rooms seemed very odd.  It was extremely difficult to map, and there were all kinds of geographical incongruities. The first oddity was that it didn't matter which of the two differently numbered exits that you took from a room, you always ended up in the same room. But since the exits were numbered, it seemed like you should be able to get to different rooms depending on the numbered exit you selected.  A quick look at the code revealed an obvious cause of this behaviour:

800 REM ROOM CHANGEOVER 

805 CLS

810 LR=PR:IF PR<>21 THEN 815

813 PR=R3:REM INT(RND(0)*19+1)

814 GOTO 825

815 IF N=0 THEN PR=R1

820 IF N=15 THEN PR=R1

The N variable in the above is the Y coordinate of your player location.  0 is the top of the screen where one exit is, and 15 is at the bottom where the other exit is.  Clearly the assignment of PR (present room) needed to be set to different variables depending on which location you exited from.  It seemed obvious that R1 should be for the top and R2 should be for the bottom exit, so I changed those lines to the following:

815 IF N=0 THEN PR=R1

820 IF N=15 THEN PR=R2

This at least made it possible to go to different rooms, but there was still weirdness (see the video at the top of this post). The following spreadsheet shows how the map looked once I could travel in multiple directions and explore a little easier. I also added some test code to turn off the monsters, so I could explore in peace. Doing that made it fairly obvious that the map wasn't a random dungeon, but instead more like a cross, with the "Entrance hall" (Room 0) at the centre. This made sense of the start screen, which prompted you to choose a starting direction/room (1-4). The weird thing was that you could choose start room, 4 for example, but once you did the "exits" for that room would not allow you to go back to room 0 and on to another beyond (down the line), but instead to go sideways to room 3 or on to room 8. This "offset" return direction was echoed for all rooms.

There was also a kind of "tear" in this offset pattern at room 14/15 on the room 3 line, which clearly took you to room 14 that was also a part of the room 4 line. The whole thing was just very confusing.  The physical layout of the rooms with two entrances seemed to indicate that the original programmer wanted to have a cross-shaped dungeon.  Another thing that indicated this was that the game expects you to regularly return to Room 0 to cache your treasure. You can't carry more than 50 points worth at any time, but if you cache it in room 0 you can go back to get more to add to your score. The original map, also seemed to be missing room 15 and 18. If you could get to room 21 you could find a large hoard of treasure, although the treasure carrying limit still applied.  You would then have to navigate back from whichever random room you were sent to after exiting that room (see line 813 above).

Repeated rooms in red

So I examined the string containing the data for the map, which consisted of 3 characters per room.  Two of those characters obviously were meant to symbolize the two rooms that the exits would take you to. There was a special condition where the third character would be substituted for those two exit room numbers:

960 IF R1=LR THEN R1=R3

965 IF R2=LR THEN R2=R3

It seemed obvious that LR meant something like "last room" or "room just left."  But from the data it seemed clear that the numbers being assigned to the 3 characters were out of sink in terms of the pattern being broken at around 14 and 15 in the original map above, and also there was some confusion between the 2nd and 3rd character (R2 and R3).  The IF statements above seemed to be some kind of kluge to fix that confusion. Once I had fixed the break in the data pattern at 14/15, the cross-structure came into better focus. Now you could travel back and fourth on each of the 4 lines of the dungeon.  But there was sill a problem at the end of each line.

It seemed that the bounty of the special treasure of room 21 was meant to lure the adventurer down each line. As you travel down a line, if you fail to get the single treasure in each room it disappears not to be seen when you return back along the line. This was a normal function of the existing movement routine. It seemed to be an incentive for making periodic returns to the Room 0 to cache treasure, and then make new forays to reach the (randomly) large treasure at then end. In the existing rooms routine, you would then be sent to a random location after leaving the treasure chamber via its single exit at top of the screen. Once again this seemed geographically confusing. It seemed to me that the R3 value might have been added to each room so that for the last 4 rooms before the treasure room an extra coordinate could be stored to allow the player to return to a specific line after leaving its treasure room. So I changed the data to allow the program to do that instead.

Now, you can play for a max score by carefully exploring each line. This would involve getting all the single treasure from each of the total of 20 normal rooms (5 per line) and whatever treasure you can get returning to the treasure rooms as many times as possible, while making return journeys back through the cleared lines.  To maintain a random element to game movement I have added randomly appearing "magical white portals", which if you hit them, will transport you to a random room in the dungeon complex. You can simply avoid these if you wish, or duck into them if you find yourself trapped by the monsters.

New Map Playthrough

Because the MC-10 is so much faster than the ZX-81 I also had to change another feature. In the original, the monsters tracked slowly that the programmer made the walls kill you instantly if you carelessly stumbled into them. But this game dynamic was impossible to deal with on the speedier MC-10 version. So I changed the walls to be solid barriers. Also, the monsters normally would just transit right through interior walls. But since they move so much faster now, I made it that they couldn't move though the solid block characters of those walls. However, they can still transit through the partial block characters of the "craggy" bits of the interior walls. This means you must navigate in ways that take into account the possibilities of monsters being blocked, while trying to recognize and account for those parts of walls that will not block them. But even with these changes, I found the monsters were too quick, so I added a level system at the beginning of the game that decreases their speed for the lower levels.

I'm not sure if I have destroyed some unique vision of the original programmer in terms of the "map" and game play, or whether I have fixed an annoying coding knot in the mapping routine that they simply couldn't fix. They might have got the game to the point where it provided enough of a navigable "maze" for adventuring to occur, and then simply called it a day. Back in the day, especially on a dangerously unreliable machine like the ZX-81 (long cassette loading, ram pack wobble) and its horrible keyboard and awkward editing features, I can imagine the programmer might have felt more bug chasing simply wasn't worth the trouble or risk.

But it is a neat little CRPG, which I hope my tweaks have helped nudge more towards an original vision. There were a couple of Youtube walkthrough videos that showed that others had also been intrigued by its unique dungeon aesthetic. However, neither of those playthoughs went very far. For example, neither player seemed to have discovered that there was an ability to fire arrows to kill monsters and neither stuck with the game long enough to make it to a treasure room and its perilous "trap."

Playthrough of original

Another playthrough

My final edits involved adding to the instruction screen to give a description of the keys used for movement and firing. I also changed the movement keys to the more familiar (to modern game players) WASD pattern and added some sounds, "blood spatter" and a high score readout. I hope these changes will encourage people to try out this unique type-in game. I'd also like to say "classic game," but there is no date mentioned on archive sites, so it might not be from the early 1980s. However, from the limited bug chasing that seems to have been done on the source code that I found, I suspect that it is. If anyone knows anything about its programmer or timing, please let me know.

New Instructions

Here is the source code for the original game:

Here is a link to my updated source code: https://github.com/jggames/trs80mc10/tree/master/quicktype/Dungeon/Schatzoeken

"SCHATZOE" can be played on GameJolt. Hit the green Play button and then choice "More 8-Bit BASIC Game Ports."  https://gamejolt.com/games/jgmc-10games/339292

It can also be played on the Internet Archive:

https://archive.org/details/SCHATZOE