"Bally's Alley" by John Collins (1980)

Jason Dyer made a post about an interesting little text adventure for the Bally Astrocade system. He was able to get a version of the game running from source code typed-in by Paul Thacker in November 2022 from a printed listing and handwritten notes of the original author, which were preserved by Bally Astrocade hobbyists. This game fits in 4K of memory, which is quite a feat of programming by the author. Jason wasn't able to complete the game because he ran into some apparent bugs. My MC-10 version contains bug fixes to ensure that it can be played to completion. 

The following is a map of how far Jason got (pink box) from the start (green):

The problems were probably a result of a few slightly misinterpreted numbers by Thacker from the handwritten notes.

I have two proposed fixes to the hand recorded list of variables:

• @(17) change from 370 to 3170. This allows the player to move on to room #19 of the Color Maze, which I don't think Jason would have been able to do. This was my best guess of where a typo would most likely have occurred to prevent a move to room #19 (and the whole subsequent section), as the method of room number parsing only allows jumps from 1 to 2 (plus or negative) from the current room number. So the problem had to be either #17 or #18 that was preventing movement onwards in the Color Maze. The handwritten note for room # 17 looked like it had a possibly partial "1"that needed to be added to its 3 digits (370)-- just the hint of a "1" in front of the "7." When I tried it, it worked. 
• @(14) change from 1603 to 10603 (this one is optional). Thacker's version just lets you go N from the WELL directly into the COLOR MAZE, which I think undermines a puzzle Collins wanted/was working on. I suspect he had some problems with his room number parser, possibly due to rounding errors (a problem for the MC-10 version) that might have been frustrating him. I've fixed these problems now, but Collin's handwritten notes have numerous scribbled-out numbers and replacements for the room data. This data had to be entered directly by the user, to help conserve memory.

I think the problems with transcription and the parser combined were what was preventing Jason from being able to initiate interaction with the WELL and also the similar PURPLE room puzzle. Both these rooms need to have 5 digit numbers to initiate a COMMAND prompt after typing a DOWN direction. But only the PURPLE room (room #20 on my map) had 5 digits. It is possible that Collins had switched to 1603 for the WELL room (#14) just as a kluge, to temporarily deal with these problems.

# of Room Jumps------>
Rooms	Get a Command?	+2	+1	-1	-2
17			3	7	0
New 17		3	1	7	0
20	1	0	6	0	8
14		1	6	0	3
New 14	1	0	6	0	3

The trick with the WELL is to be carrying the KEYS, have just tried to move DOWN, and then issue the command UNLOCK when prompted. This should take you to the COLOR MAZE room with the LAMP (I'm sensing that Collins was inspired by Crowther's original, Adventure and its formula of "get lamp").

Similarly, in the problematic PURPLE room (it's red in my MC-10 version), the player must have just tried to move in the DOWN direction, and then must issue the command "F."  I'm not sure what "F" stands for, but perhaps "Find" or "Fire," because the player must also be carrying the OIL (but the LAMP doesn't seem to be required in the original). I changed it so that if the player types "F" or "L" (Look) or "S" (Search), a descent downward to a new section which I call the "Echoing Cave" is initiated (room 30 "No Way Up" in my map below). It also might simply be for "Fall" (If so, wouldn't "J" for jump be better?)  However, since the COMMAND parser only looks at one or two characters (G for Get, DR for drop, L in unLock), it doesn't much matter. Apparently Collins mentioned that people could play the game "for weeks." I can understand why.

The descent takes the player to an area, where the rooms don't have descriptions. Instead, I'm pretty sure each room makes a different noise. I don't have Jason's patience to get an Astrocade emulator running, so I'm guessing based on a rough knowledge of Astrocade BASIC (original and extended versions). Maybe there are some screen effects too. I'm not super familiar with the system but I was able to build some knowledge converting Clyde Perkin's classic "O-Jello"4K "Othello" game, which has a wicked AI opponent for a 4K game. Each room has a slightly different tone/pitch to its sound. This is an absolutely intriguing game dynamic. I don't think I've ever seen a text adventure from this era that uses sound as a critical part of the navigation/description system. It could be a first.

My new MC-10 version fits into 4K like the original (I am in total awe of Collins) and has a few other "fixes" (possible improvements). I added an "L" Look command that can be used in any room to redisplay the description as well as other function ("S" for search will have a similar effect, and both will also accomplish the "F" Find/Fall action). I also added save/load to the main menu and an extra hint to help with the purple room puzzle. I made it so that the player must have both the LAMP and the OIL to descend into the Echoing Cave, based on the assumption that the player needs these items to navigate "the darkness." BALLYSAL.C10 for MC-10 emulators can be found here, but people should be aware that my colors for the Color Maze will be different from those of the Bally Astrocade original:

The MC-10 version can be played online at the Internet Archive.

BALLYSAL.C10 can also be found and played online at the Color Computer Archive (Thanks Guillaume!)

I have managed to play it to completion. I'm not sure if 956 is a good score, but your score is decreased by how many moves you take. Since I was using maps and cheats (most importantly reading the source to know what to do), I suspect it's a pretty high score compared to what a real player, working from scratch, would be able to get:

Unlike Jason, I used maps and a temporary modification to the room display routine to print the room numbers (and to allow me to jump to rooms). This helped keep me well-oriented for my own map making. The following are two maps that I created, the first one based on those he posted:

Adjustments to Jason's Map for my new MC-10 version:

My additions to Jason's Map (for the MC-10 version):

Thanks to Jason for the inspiration for such an interesting "Reading Week" coding project, and for his map making and game history and links, which are so helpful when it comes to bug chasing. I'm curious if any of the Astrocaders will figure out other more accurate fixes to Thacker's groundbreaking work. I never know when I bug fix whether I am helping to restore/complete a programmers original vision, or mangling a classic piece of software. I hope it is the former. This one certainly deserves it.

"Computer Dominoes" by David Smith (1982)

I've typed in another game with an AI opponent and modified it to work on the TRS-80 Micro Color Computer ("MC-10") using Micro Color BASIC.  It's from source code in Your Computer Magazine, February 1982, and originally was for the Commodore PET.  The game plays a variation of the "All Fives" game of Dominoes.  But instead of just multiples of 5, scores are also awarded for end totals that can make multiples of 3.  A single point is awarded for each possible multiple of the two types. The computer and human player start with 9 dominoes. When a player uses up their dominoes or neither can place a domino, then a new hand of 9 is dealt. The goal is to be the first to earn a total of exactly 72.  If points are earned over this amount, they are ignored until the exact amount is achieved.

As usual, I had to chop out the Petsci text-graphic part of the program (involving lots of POKEs), and replace it with an MC-10  semi-graphic-4 character printing routine (using lots of PRINT@s).  I created a routine to lay down a string of dominoes that snakes around the screen so that all 18 possible dominoes can fit. The routine had to print horizontal and vertical dominoes, depending on their location in the string.  It also is used to list the human player's dominoes at the bottom of the screen.  The very low res. nature of the Semigraphics-4 (64X16) mode called for some compromises. The 6 dot domino looks like two solid bars instead of 3 discreate dotes for each bar and in order to differentiate between individual touching tiles, I alternate the colors of the tiles between white and yellow.  It is based on my recollections of  "mixed" sets of dominoes from my youth, which had pure white tiles and more yellowish "ivory" tiles.

Also as usual, I found what I think are some bugs in the original code, which would have affected play on the original PET version too.  One involved the zeroing of the array holding the tile info for the player's hand.  This array is a 0-6 by 0-6 grid.  But the routine meant to put the hand back to an empty state didn't start from zero for the "J" dimension:

1540 FORI=0TO6

1550 FORJ=1TO6:D(I,J)=0:NEXTJ

1560 NEXT

The result was that sometimes, after the first hand, some un-discarded low numbered tiles could be left in the array. Then, when the array was searched for tiles belonging to the player, more than 9 could be found. This error might not have caused an crash in the original program, but in mine it caused the program to try to print a domino to an undefined 10th screen location.  Since those locations were stored in an array (which only went up to 9 locations), an out of array bounds error was triggered.  So I just changed line 1550 above to:

1550 FORJ=0TO6:D(I,J)=0:NEXTJ

This ensures that when the array is repopulated with 9 tiles for a new hand, there is no possibility for old data to be left behind in the first J column.

The other error involved sensing when the computer had played out its final domino. The routine to select the piece would, if possible, select the last tile and designate it as played (=3), and then increment the number of pieces played variable (CD) for the computer. Then it would immediately check if that was the last tile or not (CD<>0).  If it was zero it would proceed to a message that it was "out of dominoes" and then go to the deal a new hand routine.  But this meant the routine would never get to the routine to print the tile on screen and would also miss the end of game/win checks, which follow line 3950.

3950 D(X,Y)=3:D(Y,X)=3:CD=CD-1

3960 IFCD<>0THEN3990

3970 M1$="OUT OF":M2$="DOMINOES"

I noticed that when the computer ran out of tiles it would always flash the "last domino" message and then go directly to a re-deal. Did it win?  Was it a good play?  Did it earn points? The lack of any domino played animation was weird.  So I switched the CD=0 check to the end of the display routine instead.

4140 IFCS<>72THEN4190

4150 M1$="COMPUTER WINS!":M2$="":M$=""

4160 IFPS<66THENM2$="MORE PRACTICE!"

4170 IFPS>65THENM2$="GOOD GAME!"

4180 GOTO2340

4190 D(X,Y)=3:D(Y,X)=3

4191 IFCD=0THEN3970

4195 GOTO1670

Now it displays the domino played (line 3990 - 4130) and then does the win check.  If the computer doesn't win it goes to 4190 and then checks if no tiles are left.  If there are none, it jumps to the no more dominoes message and does a re-deal.  Otherwise, it heads back to the input routine for the next player's move (1670).

I find that it plays a pretty tough game.  But then again, I'm no Dominoes player (no game player of any sort actually), but I forced myself to test it to the point of a "human win."  It was actually kind of fun.

Human for the win!

The game source can be found on my Github:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Artificial%20Intelligence/Domino

It can be played online at the Internet Archive:

https://archive.org/details/domino_20250125

Another Human for the win!