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:
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:
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. Perkins' 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:
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:
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
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.
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.
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:
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.
This game is a conversion of a BASIC program made by "Free Game Blot" for the Matra Alice to its cousin system, the TRS-80 MC-10. The game is called "World War 3" in its docs, but "Third World War" on the game title screen. The original program used high resolution graphic images to represent tanks and artillery units, although the artillery symbols really look more like infantry rifles, which leads me to think that the documentation and programming teams were quite separate entities at Free Game Blot. I have replaced the high res symbols in my version with low res graphic characters. I used an L-shaped block character for tanks, and diagonal line block character for artillery units.The flag graphics from the intro screen have also been re-rendered using low res semigraphic-4 character graphics.
Fancy hires unit display of Alice version
The game is a kind of combination of Risk and Battleship. Like Risk, you must maneuver military units on a map, combine and split units, and engage in combat with enemy units to conquer spaces on the map. Like Battleship, the map takes the form of a grid and you cannot see the enemy units. Instead you must rely on the limited reports of scouts and captured soldiers, who can tell you about specific spaces. Also unique to the game, units can have different levels of morale, which influences their effectiveness
In addition to the graphics, the computer uses musical refrains to indicate which of the sides is victorious. Since the Alice shares with the MC-10 only the simple Microsoft BASIC SOUND command it was not very difficult to translate those refrains. However, the Alice uses a much more feature-rich but complex Thomson graphics chip that also allows 40X24 and 80X24 text screens. Many machine language subroutines had to be used to allow these graphics to be displayed on the Alice. After much trial and error I was able to strip out these routines and replace them with a simpler set of PRINT@ commands using low res block graphics of the MC-10's 32X16 text screen (and the Alice, when it is in 32X16 "MC-10 mode").
To figure out the conversion process I had to translate (with the help of Google) the instruction sheet from French (The Alice was an early French 8-bit home computer developed from the Tandy MC-10). Here are those instructions (with some added notes by me in red):
WORLD WAR THREE
By Free Gameblot
Au debut de chaque bataile, vouse et votre ennemi (l'ordinateur) disposez de 18 unités chacun. Vospositions, artillerie et chars sont dessinees sure un échiquier de 45 cases reérees verticament de A a E et horizontalment de 1 a 9. Seuls vost poistions sont visible a l'ecran, celles de l'ennemi demeurent invibles. Le but de jeu consiste a aneantir toutes less armées adveses en ayant le minimum de perts possible.
1) Description des unités: 1. l'artilerie, reprsentée par les fusils; 2. les blindés, par chars. Moral des troupes: a chaque unité est associé un niveau de moral: N: moral normal; F: moral fort. Le moral des troupes est déterminant dans un combat. Par example, deux artilleries avec un moral fort ont beaucoup de chance de remporter un compat face à une unité de blindés au moral normal. Le moral de vos unités est variable en fonction des combats livrés. Si une troup au moral normal remporte une bataille, son moral devient automatiquement fort. Inversement, si une troupe au moral fort perd une bataile, son moral devient normal.
Les combats se font avec les déplacements de vos unités. Il n'est donc possible de déplacer au maximum que le nombre d'unités inqiqué sur une position de l'échiquier.
2) Déplacement des troupes.
Les positions sont repérpées horizontaiement et verticalement. Il est donc possible de déplacer ses unités latéeralement, verticaiment ou en diagonale, mais toujours à partir d'une case contigue.
Pour déplacer les unités, indiquez d'abord la position d'origine (lettre puis chiffre), puis la position finale (lettre puis chiffre).
Enfin, indiquez par un chiffre 1 de à 4 le nombre d'unités à déplacer.
Ce nombre doit être inférieur ou égal au nombre d'unités indiqué sur la position concernée.
Il est possible de regrouper vos unités sur une même position, mais à condition de ne jamais dépasser 4 unités par case.
Les regroupements de troupes ne peuvent se faire qu'avec des troupes de même arme, c'est-à-dire artillerie avec artillerie ou blindés.
Les regroupements avec des unités au moral différent (F et N) entrainent automatiquement des unités au moral normal (N).
3) Les Eclaireurs.
Avant chaque déplacement, vous devez envoyer un éclaireur sur l'échiquier pur essay de repérer les positions ennemies. Il est prudent d'envoyer l'éclaireur à proximté de vos positions pur déjourer toute tentative ennemie. Ses indications sont précieuses:
- Nothing to report: Rien à signaier, pas d'unité ennemie sur la case désignée.
- Champs de mine: tout déplacement sur cette case entrainera une destruction de votre unité déplacée.
- Une position ennemie, l'enemi a des troupes sure cette case, l'éclaireur vous indque alors le nombre d'unités, le type de l'armée (artillerie ou blindés), et le moral des troupes.
- Un prisonnier a parlé: vous avez capturé un prisonnier qui vous révele less positions de l'ennemi, mais sans doner de quantité.
4) Les coups de main et les accrochages.
Les coups de mainadverses peuvent survenir à tout moment et se soldent par des gains si des perts d'unités pour vous et votre adversaire.
Si vous restez maitre du terrain, vous conservez la position acquise. Si l'ennemi gagne cette bataille, vos troupes disparaissent de la case et celles de l'ennemi prenent leur place sur l'échiquier.
Si vos unités remportent une bataille, leur moral se renforce. Dans le case contraire, il devient (ou il resté) normal.
5) Fin du Jeu.
La guerre se poursuit jusqu'à la destruction totale de vos unités ou de celles de votre ennemi.
A vous de déplacer judicieusment vos troupes au bon moment pour détruire le maximum d'unités ennemies. Mais attention aux contre-attaques de votre adversaire... Bon Courage!
ENGLISH INSTRUCTIONS
At the start of each game, you and your enemy (the computer) have 18 units each. Your positions, artillery and tanks are drawn on a board of 45 squares labelled vertically from A to E and horizontally from 1 to 9. Only your positions are visible on the screen, those of the enemy remain invisible. The goal of the game is to annihilate all the opposing armies with the minimum possible losses.
1) Description of units:
1. artillery, represented by an upper angled graphic piece;
2. armored vehicles, represented by lower angled (L-shaped) graphic piece.
Troop morale: each unit is associated with a morale level: N: normal morale; S: strong morale. The morale of the troops is decisive in a fight. For example, two artillery units with strong morale have a good chance of winning a match against an armor unit with normal morale. The morale of your units varies depending on the battles fought. If a troop with normal morale wins a battle, its morale automatically becomes strong. Conversely, if a troop with strong morale loses a battle, its morale becomes normal. (Note: This instruction is confusing as all battles are resolved with one side or the other being annihilated in the particular square of the grid. In other words, there is no possibility for units to "become normal" again after "losing.")
Combat takes place with the movements of your units. It is therefore only possible to move a maximum of the number of units indicated on a position on the board.
2) Troop movement.
The positions are marked horizontally and vertically. It is therefore possible to move your units laterally, vertically or diagonally, but always from a contiguous square.
To move the units, first indicate the original position (letter then number), then the final position (letter then number).
Finally, indicate with a number from 1 to 4 the number of units to move.
This number must be less than or equal to the number of units indicated on the position concerned.
It is possible to group your units in the same position, but on condition that you never exceed 4 units per square (Note:My son and I noticed in examining the code and playing the game that this limit doesn't appear to apply to the computer. We both have seen groupings of 5 artillery-- a case of do as I say, not as I do? Perhaps it is a accommodation to help compensate for the computer's weak AI?)
Troop groupings can only be done with troops of the same weapon, that is to say artillery with artillery or armored vehicles with armored vehicles.
Groupings with units with different morale (S and N) automatically result in units with normal morale (N). (Note: I have found that the game allows strong morale units to join with normal morale units with the high morale preserved, but if normal morale units join with strong morale units, the morale returns to normal-- I am not sure if this is a bug or a feature)
3) The Scouts.
Before each move, you must send a scout onto the board to try to locate enemy positions. It is prudent to send the scout near your positions to thwart any enemy attempts. His indications are vital:
- Nothing to report: Nothing to report, no enemy unit on the designated square.
- Mine fields: any movement on this square will result in the destruction of your moved unit.
- An enemy position, the enemy has troops on this square, the scout then tells you the number of units, the type of army (artillery or armored vehicles), and the morale of the troops.
- A prisoner has spoken: you have captured a prisoner who reveals the enemy's positions to you, but without giving any quantity.
4) Hard strikes and skirmishes.
Main attacks can occur at any time and result in unit gains or unit losses for you and your opponent.
If you remain in control of the terrain, you retain the position acquired. If the enemy wins this battle, your troops disappear from the square and those of the enemy take their place on the board.
If your units win a battle, their morale increases. Otherwise, it becomes (or remains) normal.
5) End of the Game.
The war continues until the total destruction of your units or those of your enemy.
It's up to you to carefully move your troops at the right time to destroy as many enemy units as possible. But watch out for your opponent's counterattacks...
Courage!
ADDENDUM:
I think I found a bug in the code. A couple actually, although the first isn't really a bug as such, but perhaps more a calibration and game testing issue. I found the game impossibly/unfairly hard to win on levels 2 and 3. I thought this was just me being a crappy player, but having played quite a bit now and figured out some simple strategies (basically seeking local preponderance of force wherever and whenever possible, otherwise avoid combat), I realized the AI was just unfairly advantaged at level 2 and 3. The raw level numbers were used to weight the formula for determining the outcomes of battles and also in a latter check about who won (there's some "compounding weighting," as my son Charlie put it, going on). But on level 2 and 3 the scale is tipped way too far in favour of the computer AI. I found that 1, 1.3 and 1.6 worked better as a scale factor. On level 1 it can be won by novices, 2 is a tough slog, and I haven't won 3 yet, although I think I came close once. Charlie recommended getting rid of the double weighting, but I felt my re-scaling changed the game the least from the original, which is more in keeping with my preservationist goals, so I'm sticking with it (for the time being). Here's the edit:
350 A$="CHOOSE LEVEL (1,2 OR 3)?":JJ=7:II=4:FA=0:NM=128:GOSUB30000:A(0,0)=3:GOSUB9500
355 IFN<1ORN>3THEN360
356 NV=1:IFN=2THENNV=1.3
357 IFN=3THENNV=1.6
358 GOTO420
We also noticed that there is a compounding element to the combat formula involving a turn counter that slowly makes it more difficult to defeat the computer as the game goes on. This seems to be a way of encouraging making bold strikes at the beginning of the game, and discouraging simply meticulously avoiding combat until you can build a local preponderance of force.
The real bug in the code resulted in enemy units disappearing from the board. Random numbers for possible next move coordinates were generated, but the routine used a division by 2 operation that would sometimes result in .5 on some coordinate numbers. These would just get INTed out when used in checking the board array. However, in some checks done to throw out coordinates, such as the one comparing the current coordinates with the newly generated ones to make sure they were not simply the same, they would sometimes not be discerned as being the same because some new coordinates would have a decimal number in them. This would allow a move to the very same location and then erase the old location (which was that same location) essentially wiping the units from the board. So I simply added INTs to the new random coordinate generator lines of the subroutine. Here is the new code:
REM RANDOMLY MOVE ENEMIES
2100 S1=INT(S+(RND(8)-3)/2)
2110 IFS1<1ORS1>5THEN2100
2120 T1=INT(T+(RND(8)-3)/2)
2130 IFT1<1ORT1>9THEN2120
2140 IFS=S1ANDT=T1THEN1072
2150 IFTD(S1,T1)<>TD(S,T)ANDTD(S1,T1)<>0THEN1072
2160 D(S1,T1)=D(S1,T1)+D(S,T)
2170 TD(S1,T1)=TD(S,T):D(S,T)=0
2180 TD(S,T)=0:XD(S,T)=0:GOTO1072
I also fixed an improperly exited set of FOR/NEXT loops, as this always worries me as possibly causing problems. And an unRETURNed GOSUB after you win. The game would restart by jumping to the start of the main part of the program. I made it reRUN that line number instead so all variables and unreturned GOSUBs would be reinitialized. Otherwise, if you played enough you might blow the lid off the RETURN stack.
I'll keep testing a little more to ensure that my fixes have worked and there aren't other bugs. On the whole, I'm a little underwhelmed with Game Blot's quality control and game testing performance. It seems this game had most of its effort poured into its fancy graphic interface, rather than the game itself. Which is sad, because it's a simple but fun little text game when it works, even if its AI is, as Charlie puts it, a wee bit "stochastic parrot," whatever that means.
I came across a very interesting article in "Input Magazine" with a simple AI BASIC program. "Input" was an early 1980s computer publication by Marshall Cavendish. It was dedicated to teaching the basics of computer programming. Every issue included both BASIC and machine language programs with detailed explanations of the listings. The magazine also included very engaging artwork in the form of playful cartoon characters and scenes illustrating aspects of the programs.
In order to illustrate simple AI techniques like the Alpha-Beta algorithm the authors of the magazine chose a simple board game to automate (rather than a complex game like chess) called "Fox and Geese." In his comment on my Youtube video about the game @me_fault provided a nice little synopsis of the game:
Only the green squares are used. The four Geese on the green squares at one edge; the fox on a green on the opposite edge. The objective of the Fox is to cross from one side of the board to the other; the Geese's objective is to prevent it from doing so. The fox is trapped when it can no longer move to a vacant square.
The Geese move diagonally forward one square (only one goose per turn); the fox diagonally forward or backward any number of greens. There is no jumping, occupying the same green, taxes or removal of animals.
Here is a graphic of the game to illustrate the elements of @me_fault's description:
The geese are the yellow objects at the bottom, the fox is the red object in the top half of the board.
As was normal for "Input" magazine, listings were provided for Commodore 64, Sinclair Spectrum, Coco/Dragon 32 and Acorn Electron. The Coco version illustrated the game board (standard 8X8 chess board) using hires graphics. The scan of the magazine was very good, so the text capture required (relatively speaking) much less editing to get it into an operating condition. The latest version of the VCC Coco emulator includes a feature to paste text directly into the emulator and BASIC. Unfortunately, it randomly drops lines during the pasting process, so I had to go back to my utilities that transfer Windows .txt files to virtual disks to get a clean transfer. Once that initial task was done, I could use the paste function to input lines fixed in the Windows file into the emulator.
I had a hard time getting the program running because there were some errors in the magazine listing. The most vexing was a missing minus sign in the following line:
2026 BX=B(31)*2-B(24):E=1E30:H=1E30
Which should have read
2026 BX=B(31)*2-B(24):E=1E30:H=-1E30
I only spotted this one because I gave up on getting the program running and had started working on the Commodore 64 source code to try to convert it to an MC-10 version using lowres graphics. Since I had combed through the Coco code so many times looking for transcription errors, when I saw the minus sign on the H variable I remembered that the Coco code lacked that. I think I noticed this because it seemed odd to assign two variables (probably constants) with the exact same value. So when I saw the C64 code with two values that were different, it triggered a recognition. When I fixed this, the Coco version finally worked.
Another problem I ran across involved some DEFN mathematical functions (there are a bunch). The program kept throwing errors when two of these functions were called. It turned out that this was because there were some extra brackets in one of the formulas and a misplaced asterisk in another:
2140 DEFFNX(B)=(B=G(1) OR (B=G(2)OR (B=G(3) OR B=G(4))
It's difficult to understand how these errors could have crept into the listing. They are quite catastrophic. I fixed the DEFfunction errors first, because they could be spotted just in terms of bad BASIC syntax. After I had fixed those the program would run, as long as the player only chose level 0 for the computer opponent for the geese or fox. So the best I can imagine is that the Coco conversion was based on one of the other versions and that perhaps the programmer only tested human player versus human player function. Or perhaps the Dragon is somehow more tolerant of bracketing in its implementation of Color BASIC.
Another problem I ran into was that there are places where Color BASIC (on the Coco, not the MC-10) absolutely needs spaces in front of certain commands for the parser to recognize those commands, which is a problem if they are preceded by an purely alpha variable name. Otherwise, the parser can't spot the command (i.e. differentiate it from the alpha variable). This is the case for
AND
OR
THEN
TO (in an FOR/NEXT loop construct)
For example the following packed lines will not work
IFA=BTHEN
FORA=BTOC
IFA=BANDC=DTHEN
These need to be re-written as:
IFA=B THEN
FORA=B TOC
IFA=B ANDC=D THEN
Since the magazine used proportional spacing, some spaces were not always evident (to either a reader or the OCR software). So all such instances had to have spaces added. At the same time I was able to eliminate unneeded spaces, which should help speed up program execution.
Another problem that I ran into was that the emulator kept running out of memory (OM ERROR). I've run into this before, most commonly because a program assumes a tape based system. When a Coco disk cartridge is added some memory is reserved for disk activities. So programs made for a purely tape-based systems have slightly more space to work with. This seemed to be the case here. I was able to try to condense the program in various ways such as shortening messages and removing redundant code, such as consolidating multiple identical win messages into a single subroutine.
Finally, a graphic message is flashed when a player makes wrong moves or provides improper input. In the original program this involved flashing a simple red box with a buzzer sound. The box was unclear (to me at least) in terms of the message it was meant to convey. I chose to replace it with a simple flashing X with buzzer, which seemed clearer to me as an indicator of illegal input. So I replaced:
The directory is in my MC-10 repository because, as I mentioned, I was going to try to make an MC-10 lowres conversion. I might still try that. But in the meantime the Coco version of the game can be played here:
According to the Giant Bomb game website "Space Mouse" was created in 1984 as a "type-in" program in the Japanese computer magazine I/O. The following blurb from Giant Bomb regards a modern 2016 re-make of the game in celebration of its 25 Anniversary:
Space Mouse: 35th Anniversary Edition is a deliberately-retro vertical-scrolling sci-fi maze game developed and published digitally by Mindware for the PC on November 8, 2016.
The sixth game in the studio's "Video Game Classics" series, Space Mouse is a remake of the NEC PC-8001 game of the same name, which was originally created by Takanari Suzuki as a "type-in game" for the September 1981 (Vol. 6, No. 9) issue of the Japanese microcomputer magazine I/O.
In the game, players must guide Alice up each floor of a tall building to its roof while avoiding being caught by space vermin. She is under a time limit (with a limited air supply), but can make use of power-ups to smash through walls and ceilings.
This version features numerous enhancements from the original, including smoother gameplay, additional levels, a key/door system, chiptune audio, and redrawn 8-bit pixel art. Additionally, players can play a port of the original PC-8001 version and an alternate arrangement (based on the Sharp MZ-700 series of computers).
If I recall correctly, I made my variation of the game in BASIC back in 2016 too, inspired by some online images I had seen of a version for the NEC PC6001. I somehow (perhaps asking my son to translate some Japanese description) came to the conclusion that the game was by a fellow named "Seiji" from 1983. Perhaps this was simply a NEC PC6001 remake of this "classic" of the Japanese home computing era. But it is hard to confirm the facts of the original game, including the author's name. The site strategy wiki mentions that the author also went by the name "Geimu Kyoujin." But I can't locate the source in the magazine proposed by Giant Bomb to confirm whether it was a BASIC program or some kind of machine language listing.
The date provided in the quote doesn't seem to point to a scan of I/O with an obvious listing of Space Mouse. I even asked my son Charlie, who knows the Japanese alphabet systems, and can use Google translate to do searches, to look for it. Here's the link for where I think the volume can be found on the Internet Archive:
It states in the top corner of the front page that it is Vol. 6, No. 9. for 1981. But I can't find any article in it that would seem to be for Space Mouse. And my son did a search for the Japanese for "space" and "mouse" and only came up for the word "space" in a few adds for space-themed games.
The Youtuber Highretrogamelord provides a playthrough of a NEC PC-88 version of the game:
Space Mouse is a vertical-scrolling maze game. The player controls a cat who is travelling up through an infinite maze. The player gains points as they travel, and the goal is to travel as far as possible. Space mice travel down throughout the level, blocking the player's progress; the player must dodge the mice, and loses a life if they come in contact [with] them. The mice have simple movement patterns but move quickly, and there are often several on-screen at a time.
Space Mouse was released as a type-in BASIC game in a 1981 magazine, and was later included in other type-in software books. A port was bundled with a number of enhanced remakes as a part of Space Mouse 35th Anniversary Edition for Windows in 2016.
He suggests that the original game was in BASIC, but as I said, I have not been able to confirm that. I think his reference to PC-8000 is probably for the original PC-8001 mentioned in the Giant Bomb quote. There seem to be a lot of versions of the game out there, including one for the FM-7 home computer. On the P6ers web site (retro users of the NEC PC6001) there are multiple entries. It suggests that the program has been made available by the author. I think this refers to the PC-6001 version that might have been the inspiration for the version I made back in 2016, but I can't seem to find any video playthroughs for the PC6001 version now.
This site mentions that the game was very popular:
This is a link to a 40th anniversary celebration conference for the PC-8001. In addition to mentioning that Space Mouse was one of the systems most popular games it also mentions Heiankyo Alien. Both are included built for a modern mini-emulator version of the PC8001. Although the game was popular, today this popularity mostly extends to later variations of the game. Once again, we might have an example of a "classic" game that had its beginnings as a humble type-in, maybe even a BASIC type-in, but for which the majority of the historical recollection focusses on the professionally published commercial versions and not the type-in that inspired the entire family of games.
My Recent Update of the Game
I have been editing my version to improve it. I have added key sensing using the PEEKS provided to me by Greg Dionne. They give better response, don't get "stuck" and allow multiple key presses to register, so you can use diagonal directions. I have also added the feature of Power Boosts that move you upwards at a fast rate, including smashing through floors. However, I have made some changes to the backstory. The Japanese call the game "Space Mouse" but it should probably be "Space Mice" because in the original the antagonists are mice moving downward as you try to move upward. You are supposed to be a cat climbing a tower/"building." When you reach the top, you enter a rocket ship and blast off becoming the first cat in space. I suppose the fast moving downward objects are kind of like scurrying mice, but in my version I chose to change the premise. This is mostly because I am using orange blocks for the energy objects that you need to collect as you climb. For technical reasons I want to use orange blocks (they're at the end of the ASCII character list of the MC-10). Orange reminds me of cheese, so I think of the player as a mouse scurrying to the top of the tower chasing a trail of cheese left by workers. Meanwhile, Taby cats living in the tower are trying to thwart your assent. The small orange pieces renew your energy and allow you to continue to ascend. When you have a run-in with a cat, you lose energy. You need one energy unit for each new stage, so don't let if fall too low. If you collect the large orange block, you will shoot to the top of the stage, so don't select it if it makes more sense to simply eat more ordinary cheese blocks on that level.
I was working on trying to port to Micro Color BASIC "Cribbage" in Microsoft BASIC. The program was ported to MS BASIC by Steven Williams from Sheppard Yarrow's original source from Creative Computing (May 1979) and then published in David Ahl' Big Computer Games book (1984). I can't play Cribbage, but my volunteer tester, George Phillips from over on the MC-10 Facebook group, told me it couldn't score runs properly. So I combed the code for typos, compared the original Creative Computing listing and the MS version. The only major typo I could find was in line 560 which read:
540 C(1,J)=M(I1,J)
550 C(2,J)=M(I2,J)
560 C(3,J)=M(I3,J)
570 C(4,J)=Y(I4,J)
It should have read:
540 C(1,J)=M(I1,J)
550 C(2,J)=M(I2,J)
560 C(3,J)=Y(I3,J)
570 C(4,J)=Y(I4,J)
The first 2 cards are the computer's discards being assigned to C() from M() done at lines 540 and 550 and the second 2 discards from you are done at line 560 and 570. These make up the "crib" and George reported that the crib was messed up. So, I looked and noticed the asymmetric distribution between the M()s and Y()s being assigned to C().
But besides that typo and a multitude of improperly closed FOR/NEXT loops (which I fixed) I couldn't seem to get the runs search subroutines to work.
So I began digging deep into these subroutines by creating a test-bed routine for just the 3 run subroutine and discovered it was definitely not working. The program has to figure out complex runs like 4,3,2,2,2, which give you 3 separate 3 runs, and the like. Yarrow obviously felt he had an algorithm that worked, but I couldn't get the 3 run subroutine to recognize even a simple run fed to it directly in my test-bed. How could a game published in Creative Computing, and then David Ahl's Big Computer Games in BASIC (conceivably another million seller) be so broken? How could all 3 subroutines break at once?
Well I think I finally cracked it. The sorting before doing the run check subroutines (5,4 or 3), says in the REM comments that it orders in ascending sequence, but it actually does descending. When I turn my test sequences around, the subroutine worked!!!!!!!
George was also doing some looking at the code. As he commented,
Yeah, you'd think that if it had a flaw it would be a subtle one. I took a look at the original code. It looks like it is kinda doing the right thing. Sorting the cards and then looking for a sequence of increasing values. That should find simple runs though it is far from obvious that it handles double runs and the like.
I'd come to the same generals sense of the subroutines. But when I looked at the sorting routine I began to wonder if it really was ordering the list of cards (by values 13-1) in an ascending way. From test input, and the output of the test-bed it looked like the cards were actually going into the subroutine in a descending sequence. You can try it out yourself.
Here's my test-bed routine for the 3 run search subroutine:
10 CLS:S(1)=1:S(2)=2:S(3)=3:S(4)=3:REM** THESE ARE READ FROM DATA IN THE ORIGINAL ONLY ONCE
But if I reversed the sorting (at least by my updated test-bed routine above) it worked!
5280 REM** SORT HAND INTO ASCENDING
5290 REM SEQUENCE
5300 FORI=1TO5
5310 FORJ=1TO5
5320 IFW(I,4)>=W(J,4)THEN5360
5330 K=W(I,4)
5340 W(I,4)=W(J,4)
5350 W(J,4)=K
5360 NEXTJ
5370 NEXTI
Try an card order like 2,2,3,4,12 or 2,10,11,12,12
I'll let you folks know with an addendum here whether the reversal fixes all of the search routines and whether it is actually able to find double runs and the like.
If folks want to help, the current "fixed" version can be tried here using the online MC-10 Emulator by Mike Tinnes. Select CRIBBAGE from the Cassette menu and then type RUN and hit Enter in the main (green) emulator screen:
I also, on the recommendation of George, added in some "Press ENTER to continue" prompts and the ability to type "Y" at most prompts to have your cards re-displayed. And I altered most PRINT statements to use my 32 character screen width word wrap routine.
ADDENDUM
George told me that it seems to recognize runs now. Including double runs. Here's one hand he said it scored correctly:
Hopefully, we've got all the major bugs out now....
Nope, Spoke too soon. Looked through subsequent issues of Creative Computing and found a correction by Yarrow in Aug 1979 issue:
I implemented it for the Microsoft version as follows:
2710 IFC<>1THEN2840
2705 IFM5<>1THEN2840:REM CORRECTION CC AUG 1979
2720 FORJ9=1TO4
I also found this discussion in the Oct 1979 volume:
CRIBBAGE Debugged
Dear Editor:
Several readers have contacted me concerning my
CRIBBAGE program (May 1979) and brought to light three
problems. The first is a real bug: the computer will on occa¬
sion after a “GO” situation, replay a card it has already
played. The correction involves the addition of a line of code
as follows:
2605 IF M5 <>1 THEN 2730
The second problem is an irrelevant bug in that line 2710
should be 19=VC(B9,1). The lijie as currently written causes
no problem, and may be entirely eliminated. This section of
code is only used when the computer’s hand consists of four
5’s. The correction will cause the computer to play the first 5
in its hand; leaving the line as is or removing it causes the
computer to play the fourth 5 in its hand.
The third problem turns out to be a bug which will appear
or not appear depending on how a particular BASIC language
processes FOR/NEXT loops. Consider the following
instructions:
3210 FORK=lTOI
3220 FOR L=K+1 TO I
...
3270 NEXTL
3280 NEXTK
IBM BASIC evaluates the limit of the FOR/NEXT loop
before processing the loop; therefore, when K reaches the
value of I the FOR/NEXT loop on L will not be executed
because I + 1 is greater than I to start. On the TRS-80
however, BASIC evaluates the limit of the FOR/NEXT loop
at the end of the loop and therefore will execute the loop with
L equal to 1+1 which causes all sorts of problems during the
play of the hand. To eliminate this "bug" (?) change line 3220
to read FOR L=K TO I.
I couldn't find any mention of the correction of the problem with the sort routine I discuss above. Which is weird. But I did notice a reference to the game on a database of video games site: https://videogamegeek.com/videogame/247086/cribbage-1979
No one has rated the game on that site, which makes me wonder whether its "brokenness" meant that people were excited by the game, but ultimately disappointed by its performance and few ever really played it. However, that speculation is frustrated somewhat by another reference I found in Czech computer magazine from back in the day:
A little Google translate done on the article reveals that the bulk of it is simply explaining the rules of the Cribbage to a non-English speaking audience who are unfamiliar with the game. However, there is a small discussion at the end of the Microsoft version:
At the "Remove" prompt, enter a number between 1 and 52 in this space
will remove the package for the cards. The cards in your hand are in the game
numbered 1 - 6, for inputs use the numbers, not in card values. If you are forced to say "GO" write "go" or "GO" instead of numbers and cards.
The computer shuffles and deals the cards, generates a reversed card,
keep track of the score and correctness of the points obtained during the game. He won't let
you go past 31, but he does not check if you have a card that
you could play If you miscalculate the value in your hand or
in the game, you don't have to doubt that the computer calls out mercilessly
"MUGGINS".
The program uses a relatively simple strategy consisting of
the cards whose point total has the highest value are also held.
There are many more sophisticated strategies that you can play with
introduced in a book about card games. Here, however, there is too much
it didn't work out.
Nice game
TOPSOFT
Kralupy nad Vltava
1987
==============================
Mr. Vltava says "Nice Game" at the end of his review. So obviously there must have been a working version out there that didn't suffer from the catastrophic error of the reversed sorting routine. But I can't find mention of a correction of this anywhere. But I can't see how the source as printed could do anything except reverse the order. It's not a typo by me. Here's the original article.
It kind of makes me question reality. Maybe my MC-10 and its Micro Color BASIC are part of some parallel universe, in which sort routines work backwards?! If anyone could shed light on this matter, I would really appreciate it if they could leave a comment and put my mind at ease.
The author of the Retroprogammez blog made a nice post about this game. It is an example program from a fairly regular contributor to the French computer magazine Jeux & Stratégie. Garry over on the CASA Adventure forums noted that in terms of items in the CASA database:
The only games I'm aware of from Jeux & Stratégie are 'Nordal le Magicien' and 'La Route de Samarcande'. Both are role-playing games for the Amstrad CPC written by Michel Brassinne.
Garry wasn't sure whether Mission Adventure would be worth translating to English (it might be an RPG given its pedigree). He also pointed out that the source I was working with from Retrprogrammez had been modified by a number of individuals.
1 REM ====MISSION AVENTURE====
2 REM Auteur : MICHEL BRASSINNE
3 REM Jeux & Strategie numero 29 - pages 44-48
4 REM Reprise : DOMINIQUE RIOUAL
5 REM Version : 1.0 du 17/12/2017
6 REM 1.1 : 16/09/2022 - Corrections avec VSC
I can confirm that it is definitely a text adventure, but it is not going to be a historically pristine representation of the original listing. It's unclear what if any "corrections" were made by Rioual or drawn from the follow-up article in VSC (See below). Taking a look at the scan of the original code I couldn't notice anything obvious. But I found that the code still seems to have some bugs, or oddities that perhaps I simply couldn't figure out correctly. There are some uncompleted or redundant (non-operative) lines and a number of other issues.
There is a "candle" listed among the items/objects in the program, but I couldn't find any aspect of the code that would seem to allow a player to find that item. That being said, I did find a reference to an unmentioned single word command. If you typed "LUX" at the "Action" prompt the variable for turning on light in the cave areas would be switched on and the French equivalent (at least according to Google) for "cheater" would be printed. This seemed to be a kluge, perhaps used by Brassine during the debugging process, and maybe he mentions it in the original article. I changed it to a formal "QUIT" command instead.
There is a routine for uncovering a hatch in room 5 of the cave. You "move" the green foam, and then the hatch appears. Then you can open the hatch and see a lead box, which you can also open. Inside is a key. But there isn't any apparent function for the key. The box, however, will turn out to have a use.
The main source of light is to "search" the "uniform" of the skeleton in room 3. You must issue the right command of "look skeleton" to find that he is wearing a uniform. "Search" and "examine" also produce various messages throughout the game, but for the most part the heavy lifting is done by using "look" in combination with an object. That being said, "search" is needed for finding the matches in the pocket of the uniform and "examine" to find a paper in a book-- so standard "guess the verb stuff." Also using "open" or "move" with many objects will produce interesting results.
"Look" normally must be used with any object, but I added the function of a single word version of it redisplaying the current room description and object list, which seemed absent. Otherwise, you might find that you had to leave and re-enter a room to observe it. Normally for most rooms, you need to periodically "light match," to get room descriptions displayed instead of the message "It's pitch black" because most of the adventure takes place deep in a cave complex (only the first few rooms do not require matches).
The main objective is to find the "portrait" in room 15, "move" it to reveal a hidden safe, and then use the hint written on a note found in room 8. The note is inside a book in a cupboard in that room. If you "examine" that book a "paper" falls out, with the cryptic message "U40.W25.U12" on it. I took the "U"s and "W"s to be references to the directions for a combination lock, with German annotations. Google translate produces "Uhrzeigersinn" for clockwise, but "counter clockwise" doesn't" produce an obvious "W" word. But I went with that interpretation in trying to make the combo dial routine work for the safe in room 15. A walkthrough in the next issue of the magazine mentions that the letters should actually be "L" and "R" as "in German (rechts and links)" (the words for "right" and "left"). But the original source definitely looks like "U" and "W". Weird. I left the message as at is. I changed the routine that runs when you "read book" to make the output look more like actual text rather than simply a scoll of random characters. I also added descriptions to make the messages clear that the book is a manual about special "hydraulic safe" installation.
For some reason the safe routine expects that you will reach a final total of 37. But +40-25+12 only totals to 27. I'm not sure if this was a typo or not. Or whether I was missing something obvious. But in the end I changed the number to reach after 3 turns to be 27 not 37. As long as you get the dial to 0, which prompts a restart to your number of turns, then you can get the safe open by ending on 27 after three turns. Inside are a bunch of "Bars" or "Ingots" depending on how Google feels like translating at any particular moment. I standardized on "Bars" and added a few elements to the descriptions to clarify that these are solid gold bars.
Another aspect to the game is that you must carefully choose the number of bars you will try to get out of the cave. If you select more than 3, then a gate will fall at the entrance. If you try to "open" that gate you will be dropped down by a trapdoor to your doom. You can increase the number of bars you can escape with up to 10 if you get the lead box and drop it in the safe. If you do that the hydaulic mechanism will lift the gate. There was no accurate way to report the number of bars. The variable that keeps track of the "weight" you are carrying seems to count other things as well. So I added a dedicated bar count variable.
Another change I made was a better check for whether items are in a room when you try to interact with them. No check was made for whether an item is actually in the room, or your inventory. The only check was that you typed the item name correctly, and that it was one of the items recognized in the game (I changed this check to look only at the first 5 characters-- this allows you to type "light match" instead of "light matches" while still allowing "matches" to be the default item name). The lack of full checking meant that you could issue commands regarding items from anywhere in the dungeon and actions could work. Now you must either be in the room with the item, or have it in your inventory.
I also fixed up the "dropping" and "taking" items routines so that items consistently get dropped in the room you are in, instead of some original room in which you might have found the object containing that item. For example, you could get the skeleton's uniform, take it to another room, search it and then the matches would appear back in the skeleton room. Similarly, if you took the book and examined it in another room, the paper would fall out back in the room where you originally found the book.
Finally, nothing would happen when you got back outside with your loot. I made the game print a message with the number of bars you manage to "liberate" from the NAZIs. Also, just for giggles, I added a graphic for the "portrait." It's an ASCII image of der Führer and is displayed when you "look" at the portrait.
Here is my attempt at a walkthrough map:
“Mission Adventure” by Michel
Brassinne (1984)
12 Narrow Corridor
13 Narrow Corridor
14 Narrow Corridor
10 Narrow Corridor
11Room (NESW Exits)
15 Room (NW Exits)
-Portrait
-Safe
-Dial
(R40,L25,R12)
-Bars
9 Narrow Corridor
8 Nearly Empty Room
-Wardrobe
-Book
-Paper
-(Code:
R40,L25,R12)
6 Passage (N.E.S)
7 Slippery (E-W) Corridor
-Move
east until Dead End is reached, then W
5 Damp N-S Corridor
-Foam
-Hatch
-Box
-Key
4 Dusty Room
-Calendar
2 Crossroads
-Gate
(Don’t try leave with more than 3 bars)
3 Dark Room
-Skeleton
-Uniform
-Matches
1 Start
-Entry
-Exit
(to win)
Map: Jim Gerrie (2023)
Here are some of the details from the follow-up article that was published in the next issue of Jeux & Stratégie translated into English (curtesy of Google Translate):
Solution... of the Mission Adventure game
You had to discover that the cave was occupied by a German soldier (green uniform), who died on July 25, 1944, as the ephemeris indicates, that is to say during the Liberation. The exploration of the central corridor to the north is only possible with a means of lighting. This one is discovered by searching the uniform: a box of matches is there. Each match has a lifetime corresponding to three actions or moves. Then you had to strike a new match to see clearly. In one of the rooms, a portrait is visible. As is often the case in reality, there is a safe behind it. The order to move the painting makes the safe appear. However, you still have to open it.
Looking at the safe, you could see that it has a dial. The combination of the safe was written on a sheet of paper, slipped into the book placed in the cupboard (when leafing through the book, the paper falls out). The letters accompanying the numbers were the initials of the words "right" and "left"... in German (rechts and links). You could therefore turn the button of the safe to the right, to the left then to the right again, the number of notches indicated on the sheet providing the combination. And this, after having reset it. As the title of the book found in the cupboard suggested, it was a safe with hydraulic protection. Indeed, the bottom of the safe is like the plate of a scale, capable of knowing at any time what weight it supports. As soon as it detects a difference in weight compared to that initially indicated, it triggers the fall of a gate which condemns forever the intersection near the entrance. Grid which, in turn, triggers the opening of a hatch as soon as one tries to force it.
Cutting the Lines Several readers have rightly pointed out to us — after having tried in vain to type in the listings for the adventure game and checkers (J & S micro of n°29) — that their machine did not accept 255 characters at the sequence of a single instruction number. It is therefore necessary to cut the lines and to include each of the sections under a different line number. Two cases can arise: simple instructions and tests. Simple instructions can be split into as many lines as there are instructions separated by “:”. For example: 345 A = 2: Z 3: PRINT "ACTION —" T can become 345 A = 2. 346 Z = 3. 347 PRINT "ACTION -" T. Care must be taken when it comes to testing , i.e. lines of instructions where there is an IF THEN, because if what follows the IF is verified, then everything after the THEN will be carried out. If the condition following the IF does not hold, then nothing following the THEN will be read, and the program's read pointer will jump directly to the next line. You must therefore split the test in two, or even divide it into as many successive tests as necessary so as not to exceed your capacity of signs per line. Let's take the following example: IF A = 2 THEN B = 3 : C = 4 : D = 5 :.../... Z = 27. This test modifying the value of all the variables from B to Z will be much too long for one line of instructions. So you can do:
340 IF A = 2 THEN B = 3 : C = 4 : GOTO 350
345 GOTO 1000 (case where A is different from 2)
350 IF A = 2 THEN D = 8
5: E = 6: GOTO 360 355 GOTO 1000 Another way to proceed, this one faster, by reversing the test:
350 IF A < > 2 THEN 1000
360 B = 3: C = 4: D = 5: F=6
370 G=7: H=8: I=9: J=10 etc.
If A = 2, the pointer does not jump to 1000 and reads all lines that follow the test. Reversing the test is often the most practical procedure. NOTICE NOTICE NOTICE Adventure game on Commodore Philippe Peltier, from Juan-Les-Pins, tells us that owners of Commodore (Pet, Vie. 64) must very slightly modify the program proposed in J & S n°29, page 44 to respect the syntax of the Commodore, otherwise it is guaranteed to crash. It is particularly necessary on this machine to concatenate (paste!) a space at the end of the string A$, otherwise MID$ (A$, I, 1) will cause a “BAD SUSCRIPT ERROR” when it reaches its maximum value. On the other hand, there is memory loss of the loop pointer because of the ON T GOTO in line 1 100. Here is the remedy proposed by Philippe Peltier:
My version of the game can be played online at the following. Just select the MISSADV from the cassette menu and type RUN in the main (green) emulator screen:
Another fix I made was to the parser. The French language parser was actually a neat variation of the standard English 2-word parser. Because of the standard use of definite articles with all nouns in French, it was actually a 3-word parser. "POUSER L'ARMOIRE" for example, would be the standard command structure, with the directive verb form followed by the definite article and then the noun. This meant that the parser had to search not only for spaces between words, but also the apostrophe, for contractions between article and noun, as in this example. Took me a bit to twig to that before I realized I had to modify it to the English 2-word format. It is interesting in the original article to read Brassine's comments on the origins of the "text adventure" game form. He attributes it to American college students and mentions Colossal Cave "Adventure" as a founding program of the genre. It obviously took until 1984 for this type of game to start to become more common in France and Brassine felt he was helping to introduce it (and modify it as necessary) to a French audience. Another example of this is the need to include gendered indefinite articles for the objects (UN, UNE, DES). It provided an interesting case study for seeing how one culture appropriates the technological practices of another. And a fun little adventure to boot once I got it working.
