"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 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 the how randomization was being handled, has got everything working more like Davison originally intended.

The other major problem that I do recall clearly was with how Allen had implemented the final guessing mini game for the big 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 from 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 full 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 such an 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 especially 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 EXPLORE 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 present next to it (doors close automatically?). I think it is a good reminder to the player that doors block indication of the location 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 color to the 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 (Plan) function to show the layout of the house and where you had travelled to already.  I added to that by using reversed characters in a way that indicates which rooms you have searched already. I also fixed some quirks with how the EXPLORE 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 can be found.  And I fixed a message that could after you open an object and find the entrance to the basement.  Sometimes, after saying 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:

It's a game with unique random map layout generation and interesting "hot key" text adventure command entry. There's a bunch of challenges and puzzles to overcome to "solve the game," so I can understand why it would 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, folks were keen to find any computer gaming opportunities.  This game shines in comparison to many contemporary hybrid CRPG text adventures BASIC games.

The game 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