Tuesday 20 February 2024

"Haunted House" by Tandy (1979): A Narrative Update

This is a classic text adventure first sold for the TRS-80 Model 1 in 1979 by Tandy. It is a little unclear who the actual author was, but the game was originally a machine language game in two parts, which was able to be played on an original 4K TRS-80. More info on the game can be found on numerous sites, such as the following very helpful homage site:

https://www.figmentfly.com/hauntedhouse/hauntedhouse.html

Now it is available for the TRS-80 MC-10 because Donald Foster ported the game to QB64 BASIC and posted his source online. I just had to add line numbers (instead of subroutine titles). I can't recall now or locate where I first spotted his source, but it was attached to a post in one of the innumerable retrocomputing forums that I visit.  He has my thanks. If I recall correctly, his post asked folks to try out his port and report any bugs. I think I might have overcome some minor ones and some limitations in game logic in a few places, which I can't recall now. But there was one major bug I do recall. The 4th "chief" ghost was supposed to be "immune" to the attacks of the sword, but I think instead there was the same message printed about "killing" the ghost.  But the ghost would still be there regardless of the message. I noticed this because published walkthroughs of the game kept mentioning how the main ghost was "immune" to your attacks.

This got me going on a kick to make some more changes to the game. I added an intro screen in semigraphics-4 mode of a creepy old house. I also made some corrections to the intro text that Foster had added (from the manual I presume). Thanks to some folks who posted some comments on my first video about the game I was able to correct some spelling mistakes and typos. 

I've now made some substantial additions and a few subtle changes to the messages and the outcomes to try to create what I feel is a more coherent narrative for this classic. Even in the original game it was apparent that there were two warring metaphysical factions at work in the house. I have worked to clarify and highlight this tension. Each faction is contending with the other as a result of a terrible wrong that has trapped both in a seemingly interminable struggle. 


-- Can you figure out which is on the side of right?  Can you help right a historic wrong and bring resolution to a lost soul?  It all depends on you!


I have added many messages that hint at this refined narrative to allow the player a richer more standard text adventure experience than the original spare 4K version could provide. For example, Jason Dyer of the Renga in Blue text adventure blog series expressed frustration with the lack of interactivity with the BUCKET object regarding the flames in the first floor master bedroom:

https://bluerenga.blog/2016/09/21/haunted-house-finished/

The bucket it turns out is a complete red herring because the fire is an illusion. But now with my changes you can at least try to use it and get some response instead of the original game's standard "I don't understand."

The player can now "examine" things and get some narrative hints at what might have occurred in the house to create the metaphysical deadlock. As noted above, the original narrative hints at some struggle between spirits-- malevolent versus benign. The knife doesn't want you to read the scroll for example. But the scroll points to a possibility of escape. The fire seems aimed at preventing you from getting to the room with the hole that will take you to the second floor, but if you get there the rope uncoils and allows you to go up. The three upstairs ghosts in the main rooms block your way, but a magic sword is left that allows you to vanquish them. Behind one of those ghosts is another who, if you get to him only lets you pass to the final room if you relinquish the weapon. I added the necessity of also "killing" (i.e. dispatching to hell) all 3 of the obstructing ghosts.

I made this addition because otherwise there appears to be no function for killing the other two ghosts, since they don't obstruct you from getting to the 4th ghost. And I take it as given that these are the three malevolent spirits of the house and that the 4th is benevolent (i.e. fundamentally non-violent) and that there is a issue of justice at stake. The intro mentions "a visitor." My take on the story is that the visitor was an innocent victim of the three sinister and grasping McDaniels who had made vast profits off of illegal hooch manufacture during prohibition. I've added clues that hint at this narrative that you can find by using the added "examine" command. For example, one clue you don't see in my walkthrough video above is that if you EXAMINE COINS you will see they are minted in 1932, which was a year before the end of prohibition. 

I also changed the "suit of armour," which prevents you from getting to the key in the servant quarters, to a "spectral hound". The suit of armour seems out of keeping with the North American setting I am assuming for the house. If one assumes the knife is in the command of the evil McDaniel spirits, then the possession of the crumpled paper talisman with "Plugh" on it, is imbued with the power of the good spirt. Even in the original game you must be carrying that paper to be able to get hold of the floating knife. If you don't have the paper, you can't get the knife.  But if you do get the knife then you can also scare the spectral hound/suit of armour. My take on this is that the knife of the McDaniels was often used to harm their old guard dog. So the control of that knife can actually be used to subvert their manipulation of the spectral dog to protect the servant quarters. If you get past the dog you can now also find bottles hinting at the source of the McDaniel's ill-gotten wealth.

So I am of the mind that somehow in around 1932 a federal agent by the name of Plugh was investigating the "hooch magnet" McDaniels when somehow he ran afoul of the murderous clan. They killed him, but somehow he was able to strike back, either metaphysically after his death, or before his death in some way that brought about their end as well, and perhaps inadvertently the end of their poor maltreated dog too. I'm thinking a gas leak or a series of fomented mishaps. Their house was obviously booby trapped to the hilt to prevent theft of their vast wealth, which can now be seen in the final room. Perhaps even Plugh was tempted by that wealth and the possibility of making off with it, which helped bring about his end. This might explain the somewhat cryptic/ambivalent/poetic clue scratched on the sign in the final room. I have added the treasure at the end to allow for this reimagined scenario. Can you maintain your honour and escape like Plugh perhaps did not?  Can his failure to rise to the challenge of this temptation explain why he was consigned to his spectral existence-- to atone? Can you rise to the challenge?  The introduction hints at what you must do.


Enjoy.

Jim Gerrie, (c) 2024.

HAUNTTRS can be selected at the following link (at least for a short while) from the "Cassette" menu. Then type RUN and hit ENTER in the main emulator screen: http://faculty.cbu.ca/jgerrie/MC10/JG_MC_Text_Adventures.html


ADDENDUM

I've made a few more changes and additions in keeping with my new narrative.  I changed the paper at the beginning to an FBI badge with "Plugh" on the back of it, and hidden it under the front mat. I've also added a reaction of the benign ghost if you drop the badge in front of it.  To allow for this, I've added the ability to "wear badge", which will allow the badge to be carried with you up the rope. I might as well go whole hog on altering the game since there's no point in just recreating the original.  There are many ways for folks to play the pristine original if they really want to. Here's a video with the main changes demonstrated-- and a "speed playthrough" to a win-- SPOILER ALERT!



ADDENDUM TO ADDENDUM

I made some more changes. I added some randomness to the location of the rope. I added much more descriptive content to be EXAMINEd. I added the ability to move objects around and drop them in other places and then pick them up again.  I added another puzzle regarding the badge. Now you must have it for the sword to appear.  There is not much more that can be added.  Sadly I'm getting close to the max 20K now.  So hopefully, this will be my last addendum.  The game should now at least be equivalent in game play to your average 16K 8-bit BASIC text adventure.  Abysmal, but better than a two meagre 4K games.  My task is complete.  I feel I have taken a classic game that was an introduction to many, but sadly somewhat wanting because of the strictures of the classic trinity 8-bit computer it was designed for, and rounded out its very suggestive but minimalist storyline.

Monday 1 January 2024

"Dungeon" by Brian Sawyer (1979)


This is a port of the classic PET "Rogue-like" game (before Rogue) "Dungeon" to the TRS-80 MC-10. I found an unfinished part in it that would have allowed the player to have a double distance "fog of war" view instead of the single space view immediately around the player's position. The "S" key was assigned to the function and it would have cost -2 HP. In fact, I think the -2 part of the function works when you hit S, but the full expanded view routine doesn't seem to have been implemented. See lines 610 and 1310 in the source that I worked from:

600 K=-40:J=3:M=40:R=3:GN=0
610 IFSM=1THENK=-80:J=5:M=80:R=4:SM=0
620 O=L-32767-R
630 IFO+32811>33768THENM=0

This is the beginning of the "fog of war" reveal routine. The SM variable is a switch that if activated in the key input routine causes an alteration of variables to create different offsets for the reveal box around the player. But not all these variables are actually used in the subsequent nested FOR/NEXTs used to display the spaces around the character.  I think Sawyer realized that an odd number would be needed for the routine to actually be centered on the character, which would require a 5 X 5 character space box around the player character instead of an originally planned 4.  Also, this would require some error checking as the routine moved past the edge of the screen in the bottom right and top left.  A vestige of that can be seen in line 630 where a check is made to see whether the offset takes the view outside of screen memory at the bottom right.  

Here is the code that was meant to switch the mode on:

1310 IFL$="S"THENSM=1:HP=HP-2

My guess is that Sawyer realized what a daunting task getting the routine working would be (a bounds check also for the top left, for example) and that the game was playing just fine without it. So he just left it half implemented and carried on. It is not uncommon to find such unfinished bits and pieces in old BASIC games. I think there were other unused variables that I removed from this game and untold others in other games. They are the vestiges of the unwieldy editors that one had to use back in the day.  It was impossible to simply see the code whole and to be able to do quick searches. LISTing and then pausing the display as the lines sped past meant that many false starts would simply be left in place if they didn't impede program execution. Today I like to clean these things up, as they can help smooth out and speed up game play.  I recognize that there is a loss of fidelity with the original, which is why I try to document such modifications. But my love of these programs means I like to see them run as best they can.

To that end I also added a feature to continue with another dungeon if you get all the gold on a screen.  The game as it was would simply end in the same way as when you die. It would reveal the map and prompt for a replay. It didn't display a win message.  However, it seemed simple to preserve the player's basic stats of Hit Points, Experience and Gold Pieces and then generate a new map for the player to continue their quest. This will be extremely difficult as the monsters ramp up according to your own HP modified by their own intrinsic level of ferocity.  In fact, it might be a good strategy to simply bleed off HP down to a level that is easier to manage.

I also added a "bloodstain" which shows where you were killed on the map. It's just a red block, but it helps differentiate an end from death versus completing a level. I also added messages "You have found all the gold" and an alternate prompt "Continue to next level?" if you complete the map. Here's a video of a test of an early version of this feature:


I also added some sounds, such as when you find gold or are killed, since the MC-10 is a slightly more advanced machine than the soundless classic "trinity."  And I added some instructions to the title screen about the keys used in the game.

Hit Points Oddity Fixed?

There's an oddity about one of the keys. There seems to be no limit to the player's ability to press R (the 5 key in the original game) to "rest" and gain Hit Points. The only disincentive seems to be the time taken waiting for the screen update.

1290 IFA=ASC("5")THENHP=HP+1+SQR(EX/HP)

The use of the SQR function and a division of Experience by Hit Points scales the function down (I think) as you increase the number of HP, so the speed of increase will decrease as you add HP.  This means you will have to waste more time pressing the R key.  And you also will simply have to fight tougher monsters as you add HP as HP is one of the factors determining the stats of the monster you face.  So there is some mathematical alchemy of hitting the right spot of building strength in relation to experience that might be useful for game play. I will have to examine the code more closely and discuss this issue with my mathematically adept son next time he comes home. If he has any insights, I'll add them here.

But as I tested the game I realized that using the Rest function in combination with the "walk-through-walls" spell gave a pretty ironclad way to defeat the game. You just have to run away from monsters after you get the report of their HP and then build HP using the Rest function until you are equal or better than them. Then I realized I could even do this from the safety of being inside the walls!  So, as soon as I spotted a monster, I would just fade into the nearest wall and start hitting R. Then I would reemerge and kick the monster's butt. This seemed unfair and kind of dull once I'd figured it out.  So I just modified my version to prevent Resting while inside walls. And as further incentive, if you try to do this, you lose the standard amount of HP used for regular movement. I thought this made sense.  After all, you are casting and maintaining a powerful spell while travelling inside walls.  Now, at least you must use HP to travel and then risk emerging into areas to rest that may be inhabited by other denizens of the dungeon. A little more resource management and path planning skills will be needed.

Finally, I had to take all the fancy string declaration used in the original PET version to clear a space in high memory where the dungeon can be safely POKEd before being revealed to the screen by the Fog of War function.  Robin from 8-bit Show and Tell has a nice video documenting a bug that affects this function between early and later versions of PET BASIC.  This video is what made me aware of this classic game, and his information about the game and links to other sources was very helpful.  But I didn't have to replicate this method.  I could just use the CLEAR command to define the end of memory that BASIC is allowed to use.

CLEAR500,26384

Then I just poked the dungeon into the space above 26384. This second argument of CLEAR is usually for defining an area to POKE any machine language subroutines that your BASIC program might call using the USR or EXEC functions.  But its also handy for simply protecting an area for poking data into.  I guess the PET doesn't have this function or the programmer simply used a different method.  I've certainly used blank strings, usually in the form of array strings, to define areas to POKE info into.  It's a very memory efficient method as long as the strings are not altered so they are switched around in string space.  I usually use the VARPTR function to find the beginning of the various indexed array strings, and then POKE using the address returned.  But I didn't use that method here as the program itself uses a method of a single continuous space in memory like the screen memory somehow defined by the string declaration of the early version of PET BASIC, but not in the second version.  Robin was able to patch this code so it worked on the more common updated version of BASIC.

Since the MC-10 screen is smaller than the PET's I also made the dungeon generating routine use all the space in the box defined by the impermeable outside wall around the dungeon. The rooms therefore can butt right up against the outer walls. I also decreased the max room size from 9 to 7.  Hopefully these changes maximize the space for the dungeon.  My efforts at such re-scaling were helped by the fact that the program uses variables to define the horizontal and vertical screen size of the dungeon/screen area.  It makes me wonder whether the dungeon engine had been designed for some generic BASIC system and then utilized by Sawyer.  Either that or he possibly planned to create versions of the program for other systems.

One final oddity. The following code from the monster movement routine has a number 31 in it:

910 IFA=41THENA=39
920 IFA=-39THENA=-41
930 GOTO960
940 IFA=31THENA=41
950 IFA=-41THENA=-39

When moving up or down in a 40 column screen numbers like 40,-40,39-39, 41 and -41 make sense. They allow movement in the up, down and horizontal directions. But 31 doesn't make sense except for a 32 column screen like the MC-10 has. For that kind of screen you want values like 32,-32,31,-31,33 and -33.  It might just be that someone inadvertently modified the original PET source, but it seems strange. I got my source from PYDungeon on Github, who has made a port of the game to the modern language Python. But it might be another indication that the game was originally designed for a different system from the PET with a different screen resolution. Perhaps the KIM?  Who knows.
 
My source can be found here:


How to play

PETDUNG can be played at my GameJolt site under the "More 8-bit BASIC game ports" menu item.


Just select Play Game, "More 8-bit BASIC game ports", and then select PETDUNG from the Cassette Menu, and type RUN and hit Enter in the Main emulator screen.

Wednesday 27 December 2023

The High Mountains by Paul Braithwaite (1984)

This is a unique multi-player text adventure game loosely based on John Christopher's Tripods trilogy. It allows players to take the roles of the human resistance or the alien masters and their tripods. Originally published as a type-in game for the ZX Spectrum in the British magazine Personal Computer News #79, my version is a port to the TRS-80 MC-10 using Micro Color BASIC from source for the Dick Smith VZ-200.

I remember there being lots of bugs in the code from the VZ. Some of these are outlined by Chickenman in his handy map and walkthrough which can be found on the Solution Archive.  He apparently ported the code from the original Sinclair version, so the bugs might be endemic rather than just in the VZ conversion that I worked from.

I'm posting about this game now despite the fact that I ported it many years ago because I recently revisited the code because Greg Dionne sent me a bunch of printouts from his BASIC compiler and his attempts to compile various of my programs. Most of these reports consisted of missing line numbers for GOTO and GOSUB statements (or THENs). Others regarded variables that are never declared or declared but never used.  Most of these latter problems are not catastrophic. They just represent some wasted memory. But sometimes a mistyped variable can affect the operation of the game. I don't think I have found any of that type yet in any of the games I've looked at but I'm working through the list to see if I can find any.  And I'm also getting ride of redundant variables in games that I know are near the max of memory so I can reduce any possibilities of Out-of-Memory (OM) errors.  

The latter was the case with "The High Mountains." I knew that this was a big program, so when Greg's compiler reported an unused Array, I went to weed it out. When I was looking at the code I realized that there were still many memory saving tricks that I hadn't applied. For example, replacing all ,0, references in DATA statements with ,, references since MS BASIC will just assume a 0 for such instances of double commas. I took the quote marks off all text DATA statement except for sentences with commas in them, since commas are used by DATA commands to separate items. I got rid of any <>0 references in IF statements, since all non-zero variable values are treated as true. I also updated my standard word-wrap routine with a shorter version that I had developed since making my port of MOUNTAIN.  

When I was finished I realized that I had freed up quite a bit of space. In fact I had enough space to add a title screen.  So I tried to recreate the Tripod rampaging image of the original Sinclair version (see the pic at the top of this post). I think it came out pretty well.

Another reason I am writing about this game is that in replaying it I remembered a few more bugs from my conversion process that were not mentioned in Chickenman's walkthrough. The biggest bug involved the command "RIDE" that one could use to travel on various objects in the game. Chickenman mentions fixing the BOAT routine to make it work properly, but he mentions "GET IN" rather than RIDE as the command for using it.  I remembered that I had fixed a number of transport items so their ride function worked. In addition to the BOAT there is a CAR and a HORSE and a TRAIN, all of which you can ride in a particular direction.  You just type RIDE TRAIN SOUTH or RIDE CAR WEST and you will go as far as possible in that direction until you hit a barrier to normal in game movement in that direction. You don't see any of the intervening spaces, so there might be advantages to avoiding use of this feature while exploring. But this feature is great for getting around fast in the game. The Masters and Tripods are not able to use this method, so perhaps in a real game the human characters were intended to use these objects to help them make quick getaways.  The map seems specifically designed to limit the pathways for these items to specific L and U-shaped circuits.

Another missing aspect from Chickman's walkthrough involved the final puzzle.  In my version of the game the player must use the BAG item, which can be found in Wichester village where the character Henry starts.  That item is needed to help with the transfer of the HYDROGEN to the BALLOON in the cave.  In my version there are 3 and 4 word commands for doing this like FILL BALLOON WITH HYDROGEN. I wonder if Chickenman took some of this complexity out, because he mentions a two step process of first issuing the command FILL BALLOON and then responding to a prompt for "WITH WHAT?"  I don't think I added these features and I'm pretty sure the bag is in there from the original.  

He also mentions another fix I that also found, which is that the random movement of NPCs could have them wander right off the map grid.  If you were playing the bad guys you might not actually be able to win because characters you need to kill would disappear forever.  He also mentions not having to engage in any combat. This is definitely a part of my port's operation, but I remember there being some weirdness with this routine as well and possibly I added some fixes to get combat to operate properly.  I can't remember exactly.  Maybe I'll get my son Charlie to exercise some Github skills to help me track back through the changes.

Anyway, I thought I should document some of these aspects of my porting recollections in case anyone is interested. It is a pretty unique game. I can't think of any other multiplayer text adventures from the early 8-bit era that I am aware of.  I'd love to actually see two players try to play this game against each other.  My son Charlie wasn't willing, and I knew the game too well from inside the code for any such match-up to have been fair.  Maybe some day someone, perhaps Renga in Blue (Jason Dyer) will do this.

While I'm documenting my recent programming efforts, I'll also note another text adventure that I fixed up in terms of memory use and title screen and obscure actions involving improper GOTO statement, references. The Treasure of Elgon Adventure is another neat text adventure.  It has a Grue in it, which if I recall correctly will disappear back into a wall if handled correctly.  Very Creepy.

And I made a few fixes to Jason "Night of the Vampire Bunnies" and Greg Hassett's "Sorcerer's Castle" and "Journey to the Center of the Earth." Some of these fixes involve very obscure in game commands, which would have errored under rare circumstances because of messed up GOTO references.  I also updated the standard word-wrap and reverse subroutines in these old ports and added new title screens:

Night of the Vampire Bunnies:


Journey to the Center of the Earth


The Sorcerer's Castle

Hassett's "Sorcerer's Castle"


Monday 27 November 2023

"Football Manager" By Kevin Toms (1982)

Since I mention a minor (apparent) bug that I think I found in my last post, I should also mention another minor bug that I think I found in another classic BASIC program.  I recently did a port of "Football Manager" to the TRS-80 MC-10. I added some nifty little text graphics to the Dragon 32 version, which I am quite proud of.  They can be seen in the video:

The rendition of games/matches no longer simply displays a changing list of scores of the two teams until the final whistle. Every new score update is attended by a ball being kicked into an ASCII net past a befuddled ASCII keeper. I'm also pretty happy about my modifications to the screen display of stats and numbers and prompts.  The original was a little chaotic, especially in the way it used reverse character messages. I tried to bring some consistency to formatting the screen displays in my final version (completed after the video above).

But on to the bug.  It seems to me that in the Dragon version the variable for storing the amount of your interest repayment was not one of the variables stored when you save the game state while playing.  This means that after you reload the game you are free from interest payments on your loan.  This is a boon and a curse.  It means your loan is not being repaid.  It just remains static.  That is unless you get a new loan, at which point a new value is calculated for your entire amount of debt, so you're back to normal.  So, I imagine that real players are typically getting loans on a regular basis, so perhaps they never noticed this bug.

The problem variable is RE and I just added it to the array that I use to store and then save all the game info to tape.  Here's the line in my code:

53 D(0,0)=RE

I hadn't used D(0,0) yet so I just stuck it there. In any case, if there are any Dragon folks out there who read this, I think there might be a bug to fix the version of the game on the Dragon Archive.

And as I'm writing about national sports, I recently created a new Semigraphics-4 version of the American Flag and a little bit of the American anthem. I'm thinking of using it in some type-in BASIC version of baseball for early 8-bit computers (I've got some code for a small game for the Adam Computer).  But in the meantime here it is:



Sunday 26 November 2023

"O-Jello" by Clyde Perkins (1980)

This is a conversion to Micro Color BASIC of a game by Clyde Perkins for the Bally Arcade/Astrocade game console and early 8-bit home computer. The first "Bally BASIC" version appeared in the Arcadian 2, no. 5, March 24, 1980. The "AstroBASIC" version was released on the "Best of Arcadian, 1980" tape.  I took the source for my port from Arcadian Vol 5 No2, Dec 1982. Perkin's game is an early version of Othello or the game of Reversi with an AI opponent created in BASIC. It also allows for a game between two human players, and it does this on an MC-10 computer with only 4K of memory!  Amazing!

Thanks to the Bally Alley folks for their helpful playthrough:

https://youtu.be/DR6gyQvdR8I?si=LtfETxYljqeicxtL

There's nothing much to report about this port regarding differences in BASIC.  The only real bump regards the diabolically hard translation of AstroBASIC graphics, which are laid out as a grid with the 0/0 coordinates located at the centre of the screen.  The graphics are 160 by 88 pixels:

          44

           |

-80  ---  0,0  ---  80

           |

         -44

I had to do some fancy math to translate everything to a more common graphic grid starting in the upper left corner and then scale it for the MC-10 low res 64 X 32 Semigraphics-4 screen. Otherwise, BallyBASIC is pretty straightforward.  Quite nice in a lot of ways, although very memory restricted.  That's okay though, because it means we now have another board game to add to the BASIC Checkers sold by Tandy for the 4K MC-10. Source code can be found here:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Board%20Games/OJello

I'll post an addendum here when I have a chance to think about the project a little more.

Addendum.

I think I found a bug in the original program.  When I printed the move-weighting table consulted by the AI via its lookup algorithm for reading the table data from a single index array this is what came out:

 5  3  99  2   2   99  3  5 

 15 8  2  -15  -15 2   8  15 

 0  1  15  0   0   15  1  0 

 9  5  8   1   1   8   5  9 

 9  5  8   1   1   8   5  9 

 0  1  15  0   0   15  1  0 

 15 8  2  -15  -15 2   8  15 

 5  3  99  2   2   99  3  5 

When my son Charlie came home for Christmas he looked at the routine that generates the table and also came up with this arrangement using a modern programming language.  It seemed obvious to us that the corners were what should be prioritized with the 99 weights and that there were other weird asymmetries going on. 

I'm not 100% sure if there is something I did in my port, or something different about the BASICs, which can account for this mixed up table.  Apparently Perkins worked from an article in Byte magazine, but we couldn't find anything in the earliest article from 1977 (see refs at bottom) presenting a BASIC version of Othello.  Eventually Charlie figured out that there was a problem with decimal points in the lookup algorithm in line 510 of our test routine below.  This test program includes Perkins' routine (56-57) for generating and storing the 8X8 weighting table in a single index array variable A(2-66) and then uses the lookup algorithm from the program (510) to consult every space on the 8X8 board using the coordinate system for plotting pieces (500):

REM Perkins' original table generating routine for populating the array 
0 DIMA(70):A(0)=-1:A(1)=-1:REM first two elements reserved for storing player scores
56 A(2)=3:A(3)=5:A(4)=1:A(5)=8:A(7)=9:A(8)=0:A(9)=15:A(12)=-15:A(13)=2:A(17)=99
57 FORX=0TO3:FORY=0TOX:FORZ=2TO50STEP16:FORW=1TO4STEP3:A(X*W+Y*(5-W)+Z)=A(X+Y*4+2):NEXTW,Z,Y,X

59 C=0:FORY=1TO8:FORX=1TO8:PRINTA(2+C);:C=C+1:NEXT:PRINT:NEXT:STOP

REM My modified lookup algorithm tailored for the MC-10 screen (jumps by 8s instead of 9s in the vertical) and with Charlie's -4 and -5 fudge factor)
500 FORB=28TO-28STEP-8:FORA=-35TO35STEP10
510 O=(ABS(B)-4)/8*4+(ABS(A)-5)/10+2+32*-(B<0)+16*-(A<0):R=A(O):PRINTR;:NEXT:PRINT:NEXT:PRINT

REM The original lookup and plotting algorithms 
500 FORB=-31TO32STEP9:FORA=-35TO35STEP10
510 O=ABS(B)/9*4+ABS(A)/10+2+32*-(B<0)+16*-
(A<0):R=A(O):PRINTR;:NEXT:PRINT:NEXT:PRINT
Here is the raw table data created by Perkins:


Here is how the table looks using the lookup algorithm with Charlie's -4 and -5 fudge factors, which he added to prevent decimal rounding errors in translating A and B coordinates into an index number for a  single dimension array:


His version produces something we think makes more sense for weighting and when I implemented it into the game and played against it, it played like a boss.  The following is me testing the new routine on high speed mode in the emulator:


Here is the result of another game with the new algorithm being played on Mike Tinnes online emulator: 
Charlie's algorithm for the win!

O-Jello can be played online using Mike Tinnes' JavaScript emulator hosted on my games site on GameJolt:


Just select "Play" from my game page, then select my "8-Bit BASIC A.I. Programs" collection and then select "OJELLO" from the Cassette menu and type RUN and hit Enter in the main emulator screen.  Feel free to list the program (it's really tiny) to see it for yourself in all of its under 4K glory. Only about 1800 bytes long.  I think  he might have been working from one of these:

  • Duda, Richard O (October 1977). "Othello, a New Ancient Game". BYTE: 60–62.
  • Wright, Ed (November–December 1977). "Othello". Creative Computing: pp. 140–142.
  • Frey, Peter W (July 1980). "Simulating Human Decision-Making on a Personal Computer". BYTE: pp. 56.

Addendum to the Addendum

In checking out Duda's article I thought I would try typing it in as well, and seeing what kind of game it plays.  Its algorithm is similar but simpler.  It counts up pieces that will be captured, but it only adds extra weight to such possible moves if they are along the outside edge.  There is no differential weighting of specific positions.  Still, it plays a pretty decent game.  Here's a squeaker, when I just manage to edge it out:


I should thank Peter McGavin from the facebook BASIC group, who noticed two  typos/transcription/OCR errors in the source code when I posted it in the group.

These were in line 3210, which should have read 2310
And 1410, which should have read 1310.

Both of these errors were in the original source which I worked from.  This source was from an article entitled "Analysis of the First Published Othello Game" by Timothy Swenson, which the author generously provided online.  It saved me a lot of typing, but it had some typos so I also fixed some other errors than those found by Peter. But with his corrections hopefully now it's fully working so people can try it out.

How to play

OTHEBYTE can be played at my GameJolt site under the "More 8-bit BASIC game ports" menu item.


Just select Play Game, "More 8-bit BASIC game ports", and then select OTHEBYTE from the Cassette Menu, and type RUN and hit Enter in the Main emulator screen.

Similarly OJELLO can be played as per the above. However it can be found by clicking the "8-Bit BASIC A.I. Programs" menu item.

Tuesday 7 November 2023

"Lines of Action" by Sol Guber (1985)


The game "Lines of Action" was invented by Canadian born Claude Soucie.  He moved to the United States during the Depression as a young child, and learned to amuse himself, and eventually others, by inventing games, Sol Guber created a two player version of the game in BASIC for the 8-Bit Atari Computers. It was published in ROM Magazine Dec/Jan 1985, which was a short lived Canadian Atari publication. This version is a port to Micro Color BASIC on the TRS-80 MC-10. 

I had to rip out all the complex Atari graphics commands for drawing the board and the round playing pieces.  I created a simple Semigraphics-4 grid in white, and some chunky blue and red pieces to replace the original white and black ones.


I had to fix the subroutine for checking if you were trying to jump on one of your own men. The original program checked for if you clicked on your own selected piece earlier than checking for whether you were trying to actually jump on one of your own. By clicking on your own selected piece the program would abort that move, and allow you to select another piece.  But this prevented the program ever getting to the routine to check if you were trying to jump on one of your own players because it just checked for whether you were clicking on one of your own pieces (any piece). The message about not jumping on your own pieces would never print and the turn would simply end inelegantly without removing the old active piece marker, etc.  So I changed the check to specifically look for whether you were landing back on your starting piece. Then the program could also get to the later check for trying to jump on one of your own men.  I also made the routine print a message that your move in progress was cancelled. Also, the routine for ending the turn seemed overly complicated and created issues with screen cleanup, so I simplified it and standardized the screen cleanup done for all the error messages.

There were lots of poor scan issues and just plain old typos in the original listing from the article.

For example

225 T1PT=TPT: U1=T=UPT: IF UPT>TPT THEN U1PT=TPT+Cl: TAPT=UPT-CA

Should have read
225 T1PT=TPT: U1PT=UPT: IF UPT>TPT THEN U1PT=TPT+Cl: TAPT=UPT-CA

I couldn't get the original win routine to work.  It was an interesting attempt to create what was in a essence simply a case of the "flood fill" algorithm. Basically you find the first piece for a player.  Then flood fill from it.  If after it finishes going through and changing any interconnected piece location connected to that original location, if the final total of pieces is the same as the total pieces the player has, then the game knows you have interconnected all your pieces and are a winner.  I think Guber was trying to create a clever way of doing this but it only worked sometimes, on simple shapes like

OO
OO

But failed on complex chains like:
 O 
  OO
 O  O

Not sure, but he might have just given up or have not tested enough. I just replaced it with a simpler more standard flood-fill routine that seems to work fine and is a little quicker.  One problem with his routine was that it sought to search on the 8 locations around a piece 0-7 and then store where it left off in a string (which holds the whole grid of locations) as an ASCII value of where you are in the search around aa piece added to the value of the player piece code (5=blue 10=red).  But he didn't calculate the values correctly.  The 0 value would leave the stored player piece value unchanged (5 or 10) since the first search value for the array storing the 8 directions is 0 (as in 0-7 for the array storing those direction offsets).  I created a test bed routine and as far as I can discern his method would never really be able to  work on complex chains since its doesn't store unvisited locations on stack, and can "get lost" following down side tracks.

It would be nice if someone could figure out a simple AI routine to add to the program, which is for two human players.  I'll have to see if my son Charlie is game for a programming challenge the next time he's home for an extended visit, such as at Christmas.

How to Play

LINESOFA can be played at my GameJolt site under the "More 8-bit BASIC game ports" menu item.


Just select Play Game, "More 8-bit BASIC game ports", and then select LINESOFA from the Cassette Menu, and type RUN and hit Enter in the Main emulator screen.


Thursday 2 November 2023

"Star Trek III" by Lance Micklus (1978)

I've been working on a port of Lance Micklus' Star Trek III game to Micro Color BASIC from TRS-80 Model I/III BASIC, which I did some time back. I had been unsatisfied  from the start with the flat somewhat weird appearance of the graphic that Micklus devised to represent the starship Enterprise. I was also underwhelmed by the chunky, somewhat oversized appearance, of the Klingon ship. So I finally resolved to try to tweak them a little.  Here's how the ships used to look in my original port:

The Klingon looks more like a Romulan Bird of Prey. I toyed with the idea of flipping it upside down and giving it protruding neck, more like the Klingon battle cruisers I was familiar with, but it just looked odd.  And I didn't want to stray too far from the original game's look.  I just thought it would be better to downsize and tweak the images to take account of the bigger semi-graphic 4 pixels of the MC-10.  There was something about the original Enterprise design that just didn't indicate well, to me at least, which direction the ship was pointing.  So I added a bridge, after spotting a small Enterprise icon somewhere on the Net that showed what that might look like.

The exercise of opening up the source code also tempted me into squeezing in some code optimizations to speed up menu display a little.  And also decided to add some more colour. The game now displays the Status screen with the background color of the current operational condition: Green, Yellow or Red.  The flashing "Space Storm" message now has a purple background, and when you collide with something, an orange screen is displayed with that message. I also centred the Status display screen. The old uncentred screen is more obvious on the MC-10 with its contrasting black border to the green text screen background.  I also tweaked the combat routines, which use a flashing alternate text color set effect, and tweaked the SOUND commands.

Finally, I added references to all the main bridge characters and other Paramount Star Trek (C) references.  I hadn't noticed it before, but the early version of the code (1978/1979?) that I used for my port was obviously done at a time when Micklus was fearful of a possible copyright infringement hit.  For example, the Klingons are simply called "Warships", the Enterprise is a "Starship" and the Phasers are a "Beam Weapon."  So based on some videos I watched of latter versions of the game (mine is probably TrekIII.3 or before), such as TrekIII.5, I added Sulu on helm, Checkov on weapons, Uhura reporting damages, Spock making science reports and Captain Kirk and the Enterprise on the main menu.  So now players can have a full copyright infringing experience like any kid back in the 80s could have if they even knew the scantiest about hacking BASIC program code.

It's a very tough version of the classic Star Trek text game genera. Here are three videos in sequence of me trying to complete the game.

Playthrough 1


Playthrough 2

Playthrough 3


TREKIII game can be played from my GameJolt page by selecting "Play Game" and then selecting the Star Tek Games Collection of from the menu of my different games collections.  Here is the link to my page:

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

Click on the above, choose "Play Game" then "Star Trek Games" then select "TREKIII" from the Cassette menu and type RUN in the main (green) emulator screen.


P.S. If my son Charlie is reading this.  There is an easter egg in the code.