RetroChallenge 2018/04: Finishing up Dig Dug

After getting the basic AI working for the monsters I started implementing some features from the original game. In the original, after you kill all the monsters but one, the last one will make a break from the surface and high tail it to the left of the screen. In my version I made so that if any monster gets to the blue at the top of the screen it heads west at high speed.

I also added the inflate attack of the character. It was too difficult to implement a multiple inflate process until the monster pops--that would involve too much processing and overhead. But now you can shoot a hose at the monsters who then inflate to fill their block, before "popping" for 10 points. The hose is short enough that you have to let them get uncomfortably close to launch such attacks.  Also, you have to be pointing in the desired direction. The pipe sections get left in place, which saves processing and keeps the game flowing and has the added benefit of allowing the player to create temporary barriers to slow enemies--All characters have to take an extra turn to clear pipe before they can proceed through that space.  This at least partially covers the role of inflating in the original, which can serve to temporarily stall monsters.

I messaged with my son Charlie over the weekend and he agreed to work up a little fanfare based on one from the original game to play at the end of clearing the screen of monsters. Thanks Charlie!

I also combed through the code and as usual found many ways to speed it up. One neat trick I came across recently was using a FOR/NEXT loop with a STEP 0 for the main loop. This allows an indeterminate loop which you can trigger an exit from by setting the variable.

10 FOR A=0 TO 1 STEP 0

20 INPUT A

30 NEXT

40 PRINT"LOOP EXITED"

50 END

I haven't checked it but I suspect that using a NEXT statement without a variable is a probably a faster way to loop than using IF statements and a GOTO with a LINE NUMBER.  A little less processing involved. Maybe I'll try these benchmarking programs and see what I get:

10 FOR A=0 TO 1 STEP 0

20 B=B+1:IFB=10000THENA=1

30 NEXT

40 PRINT"LOOP EXITED"

50 END

10 B=B+1:IFB=10000THENA=1

30 IFA=0THEN10

40 PRINT"LOOP EXITED"

50 END

Yep.  The FOR/NEXT finished many seconds before the IF/GOTO routine.

I added "flowers" to the top left because when you kill a monster I simply blank its strings and set its coordinates to the upper left. So I needed some characters around the hidden character, which it can't move through. Since I added the ability of the monsters to move into the blue, I had to allow the characters to enter blue spaces, so I put the flowers in to "trap" the hidden dead monsters.

I made it so that when you drop a rock on a monster you get ninety points. This gives the player an incentive to work at trying to trick monsters to go under rocks. As further incentive you get a recharge of your lives every 500 points. Since shooting the monsters at short range can give them opportunities for them to get up close and shave off lives from your initial 10. You need to work at balancing the risks of shooting and crushing to make it to the next 500 points to get a recharge. I also made the seeking AI routine get more acute at tracking you as you clear more screens.

Finally,  I added a random fire breathing/laser shooting routine to the monsters, which is further incentive to crush them at a distance rather than just get up close and fire away and risk getting fried. I reused the same subroutine as the player's pipe shooting routine, except using alternate graphics (yellow lines versus the "pipe" pieces) that disappear immediately as they fly away from the monster (very fast like a flame or laser). The frying gets more frequent as you clear more screens.

It's a very tough game, maybe too tough now that I have sped it up further. Hard to tell. The problem is I don't like playing games--just making them. So I don't do as much play testing as I probably should. Which means I can't really be sure if the game is complete crap, so any feedback would be highly welcome!

RetroChallenge 2018/04: Forest of Doom Port--Beware the Shadows!

Bruce Moore's "Forest of Doom" has been a bit of a sensation in the Coco community. I thought it would be nice to try to convert it to MC-10 so I sent away for Bruce's book and the code to download the game. When the book arrived I fired up Vcc and loaded up the program and LLISTED it to a text file and started pouring through the code. It is a complex game and it took a lot of play testing and watching Stevie Strow and Crew playing it to figure it out. There was a mysterious machine language routine embedded at the heart of the basic program that seemed to do a lot of different things. I'm still not sure if I have figured out everything that it does, but based on watching game play and playing it myself I have uncovered at least the following basic functions:

·         clearing to bottom of screen from current cursor position

·         screen bounds checking for cursor movement on map screen

·         time keeping and sound for countdown till next hit

·         time keeping for checks for wandering monsters

·         “Inn now” secret key press (still don't know how many it will allow)

There may be more mojo hidden in there, but I'm not sure. Bruce has told me he'll try to dig up the source and send it to me, by the time of Cocofest.  He's busy with another project to follow up on FOD.

The big challenge in converting the program was coming up with a memory efficient way to try to recreate all the nice music and sound in it. It is impossible to recreate everything using just sound commands, but I tried to come as close as possible without the help of my son Charlie, who is away at university. I came up with a simple routine for encoding a string of note letters and a number (for length) which could be sent to a subroutine.  I came up with this:

0 DIMN(21)

1 CC=1:FORC1=1TO63STEP3:N(CC)=VAL(MID$("073093102119134141154166176180189196200206212217219221227229232",C1,3)):CC=CC+1

2 NEXT:GOTO10

4 FORCC=1TOLEN(M$)STEP2:SOUNDN(ASC(MID$(M$,CC,1))-64),ASC(MID$(M$,CC+1,1))-48:NEXT:RETURN

10 M$="G4G4G4A4B4B4":GOSUB4

Line 1 is the initialization of the routine with the note info. You create a string M$ and GOSUB4 to call the routine. Line 10 demonstrates such a string and call. The routine uses ABCEDFG and then HIJKLMN and OPQRSTUV for the next two octaves up. I actually used the O-V range to encode some flats needed for FOD, so that version is slightly different from the generic one above.

Like my port of Caves of the Unwashed Heathen I also had convert the graphics into simple strings of semi-graphics characters. Vcc allowed me with the help of a little basic subroutine, to print these out to the printer port (i.e. text file on my PC). Then I could edit them into text strings condensed as much as possible to save memory space. I also had to figure out ways to use some of the graphics for multiple purposes, such as the iconic red tree, which is used for the title screen and final death screen. On the Coco version there is no need to use such memory saving techniques.

I worked out rough equivalents for many of the sound routines from the original, at least to the best of my limited musical abilities  Here’s a vid of an Alpha version:

I have left it to Bruce to decide if he would like to pursue sharing my version with the wider MC-10 retro community.  I think he's waiting till Cocofest where he might be able to have some of his game testers take my version a spin to see if it really works. I’m sure MC-10ers would be very pleased to participate in the excitement he created in the Coco fold.  In the meantime I am continuing to play and bug test. Here is a vid of the latest version with the most recent music and sounds:

Had to do a lot of condensing to make space for some new sound routines related to the combat subroutine. When I was doing this I came across some REMed lines, that I think were an attempt to implement some special behavior of the Shadows on the first level. One of the clues given by Innkeepers is that "A shadow is not always what it first appears."  However, I had never found anything obvious in the code in terms of printed messages that would indicate anything special about shadows. But I did notice two REMed lines referring to monster #5. A quick look indicated that this was the number for shadows. It looked like what the lines were supposed to do was present a message when you were attacked by a single shadow (which can only happen on level 1) that you were being attacked by a Shadow and then swap the monster number for a random monster (1-10). Not sure why it might have been taken out but it might have been because of complexities with the monster names which are processed to deal with plurals or single monsters and then saved in three strings for different purposes.  Or maybe the shadow routine got put in the mysterious machine language helper program somehow.  In any case, I re-implemented the REMed lines and made them report an attack from a shadow and then choose and list a random monster in the upper area of the screen. So if you don't check to confirm what is attacking  you, it could be something you don't expect!  Beware the shadows, they may not be what they first appear!

RetroChallenge 2018/04: Dig Dug's Artificial Intelligence

The next major task at hand was to give the monsters intelligence.  I did this with a sequence of ON/GOSUB checks.  Here's the main LOOP

20 K=K(PEEK(2)ANDPEEK(17023)):C=1:ONKGOSUB2,4,6,8,50:FORC=1TO3:ONK(PEEK(R(C)+M+32))GOTO21,21,11,21,10
21 NEXT:FORC=2TO4:IFRND(20)>GTHENON2+SGN(X(1)-X(C))GOSUB2,19,4:ON2+SGN(Y(1)-Y(C))GOSUB6,19,8:NEXT:GOTO20
22 OND(C)GOSUB2,4,6,8:ONRND(9)GOSUB2,4,6,8:NEXT:IFJTHEN20

In line twenty there are two ON/GOSUB statements. The first is for the player's movement. It jumps to line 2, 4, 6, or 8, which process legal moves and then place the character. The next FOR/NEXT loop for three iterations checks the rocks and then drops them if they only have black space under them.

Line 21 and 22 are where the enemies move. They use the same character arrays as the player character to store their positions and strings (looking left, looking right) and so they can use the same 2,4,6,8 move check subroutines as the player character.

The first IF checks if a random number is higher than a level variable G. If so, then Xs and Ys coordinates for the character and the monster are compared to allow the monster to home in on the character's position. A direction for X is chosen first and checked with a GOSUB to 2 or 4 (horizontal directions) and the same happens for 6 or 8 (vertical directions). Then there is a jump to the beginning of the main loop.

Line 22 is done only if the IF level G variable check failed in line 21. It just tries to move the enemy in the last direction chosen in line 21. It also tries to move the character in a random direction.  It then checks if the character has been killed yet and jumps to the top of the main loop.

This is the basics of AI of the enemies. Next post I'll discuss some cleaning up and improvements to the main loop and the behavoir of the monsters.

RetroChallenge 2018/04: Dig Dug in BASIC

Welcome to my first post for RetroChallenge 2018/04. Carlos Camacho posted in the Coco Facebook group some semi-graphics 3 mock-ups.  They were meant to be inspirations for games using that mode.  He used the drawing tool that Davie Mitchell came up with for the Dragon. His mock-ups included Mario Brothers, Joust and Dig Dug. I thought I would try to bring one to life. I chose his Dig Dig graphic to start with.  I converted his idea to semi-graphics block characters for the MC-10 using my SKETCH program. Then I just printed the screen to text output and used Wordpad to edit that output into 16, 32 character lone screen lines with PRINT statements added. Also drew some simple characters. The astronaut character is cyan and there are also green dragons and a nondescript purple crawler of some sort.  This video shows the simple random motion I started with:

Next step will be to add some intelligence to the monsters and decide how much of the game dynamics can be implemented in a tight main BASIC loop that still allows for a challenging game.  Here's a video of the original arcade version:

Carlos also sent me a helpful link to the basics of the history of Dig Dug.

Underground Adventure (Duckworth)

I have ported the text adventure "Underground Adventure" by Peter Gerrard found in the book series "Exploring Adventures" by Duckworth publishing house. I worked from a Dragon 32 version. The game is evocative of Colossal Cave Adventure (the original text adventure), in that it involves a descent into an apparently ordinary cave, which quickly turns from a mundane to a magical realm. There is a magical bridge in both and mysterious mists and twisty passages. And a sinister "living gargoyle" (instead of a dwarf) occasionally shows up to throw knives at you.

There are two other Exploring Adventures games. The main purpose of all three programs was to illustrate how to program your own adventure games in BASIC on a variety of 8-bit home computers systems (C64, Atari, Spectrum).

The map above is incomplete. It only illustrates the preliminary rooms. The adventure is quite extensive and took quite a bit of squeezing to get it to fit into the 20K of the MC-10. Most of the classic 8-bit systems had a least 32K to work with. Using my standard techniques described elsewhere in my blog posts, I got it below 20K. I condensed and simplified descriptions and you have to load the direction data from a separate file to avoid reading them into an array variable from DATA statements which then are redundantly left in memory.

In the course of doing the port I changed what I felt were some unclear or inconsistent descriptions and items. The most significant "alteration" was the use of the terms "track" and "cave." For example, there is an instance in which a track must be "oiled" so that it can "slide away" to reveal a blocked entrance. The use of these terms seemed to indicate to me that the "caves" were actually an old abandoned mine and the obstruction was actually an old mining cart, so I "fixed" the use of these terms in various descriptions to fit that theme better.

There were also several errors in the code I got from the Dragon. The axe could be thrown even if it had been dropped somewhere else. It then would appear in the room you threw it in and could be picked up. Also there was a place where you could go east but not back west for no apparent reason.

I maintained a save-game feature, but it involves saving and loading two separate array variables. The first file is called "UNDRGAME" the second "UNDROBJS." Couldn't unify them into one array as I have done for other games. Just not enough memory. Little clunky, but workable.

Here's a vid:

Dave Kaufman's "Star Trader"

Star Traders Original

Having completed a conversion to Microsoft Basic of the classic text-based 8-bit computer games "The Wizard Castle" by David Power and the first text adventure "Colossal Cave" by Will Crowthers, I went in search of another kind of classic game program that I recalled from my youth and which I wanted for some time to add to my collection-- a "Space Trader" type game. I had been aware of a version of such called "Star Lanes" for a while, but I wasn't overly enthused by its "corporate" theme (company creation and share buying and trading) and determined that it was neither the game I recalled playing and nor the first text-based space trading simulation. So it was a pleasant surprise to discover that the original granddaddy of such games, called "Star Trader" by Dave Kaufman, was less corporate in character, and more in keeping with the spirit of Issac Asimov's "Foundation" series of novels-- with its developed Galactic core planets, and wilder less developed frontier planets.

The only problem with getting a version of this program up and running was that there seemed to be nothing on the Net regarding running versions. The original source I was able to find was for some kind of DEC minicomputer (HP Basic?). It came in two parts that were run in a "CHAINed" fashion. The first set up basic parameters and variables, which were left in memory when the second program was loaded by the CHAIN command. The source also mentioned "loading the tape into the tape reader" (tape reel? paper tape?) as a means of saving and loading games in progress. Yikes! I could find some tantalizing screen shots of an Atari 8-bit Basic version by someone who had a tribute page for the program, but that page now existed only in "archived" format on the "way-back machine." Most of the links were broken, and I could find no reference to the program in any of the Atari software archives that I searched. So I had to work from the original source helpfully provided by a tribute webpage to the multiplayer on-line "Trade Wars" games that descended from the original program by Kaufman.

When I finally got the two programs merged and running and most of the bugs worked out, I noticed that there seemed to be something wrong with the economies of the various star systems. They did not seem to develop or change their demand for products in the way I expected. However, after combing my source for possible errors introduced during porting, I could find nothing that would explain the weird behaviour of their economies. I began to suspect that there was simply something wrong with the data used to define the subroutine calculating the productivity for each system. It seemed skewed towards high production of goods, which resulted in very low demand for new goods. So I went in search of the original publication of Kaufman's program.

Apparently the game originally appeared in the People's Computer Company (PCC) newsletter (later magazine) and latter in a book compilation What to Do After You Hit Return. I was able to get a PDF from the Net of the book, and sure enough when I looked at the DATA statements for the "econometric" data, it was different from the data listed in the on-line source code from the Trade Wars tribute site. Swapping in the data from the scan seemed to solve the problem--a fun little piece of retro-programming archaeology! I don't know why the values were changed (transcription error from the scan, weird considerations of a networked version?), but now there is a working version of the program for people out there to try. It includes a save to cassette tape feature, as opposed to (possibly) save to tape reel or paper tape. Here's a vid:

Rogers Cadenhead, one of the many commentator's on the Star Trader and its influence, discussed its history with David Ahl to get his perspective on the game. The following is a quote of Ahl's response:

As far as I know, the game Star Traders originally appeared in People's Computer Company (a newspaper/magazine) published by P.C.C. (an alternative education computer center) in Menlo Park, CA. (It's a bit confusing that the physical storefront computer center and the newspaper both had the same name.) The game also appeared in What to Do After You Hit Return subtitled "PCC's first book of computer games." PCC was a rather egalitarian organization, hence credit was only rarely given to the authors of the various games they published and there is no author credit affixed to Star Traders. So it could have been written by any one of the 40-50 people cited in the acknowledgements of the book. The game, written in "standard" HP Basic, is a monster and, unusual for the time (1973) has both a set-up module and a main playing module. Also unusual for the time, it had the capability of saving the playing data (1) from one session to the next and (2) for different users who logged onto other nodes of the timesharing system. It was this that allowed it to be a multi-player game with games often lasting a matter of weeks or months. The book had some interesting suggestions and ideas for extending and modifying the game to make it more interesting and longer lasting; I believe that over the years many (or most) of these have been implemented.

I can understand how on a timesharing system you could easily have rigged up an ad-hoc way to make the game one of the first multiplayer net-based games (tape reels or paper taps must have been replaced by electronic files at some point). You can save all the main game variables at the end of any round of trading at the prompt for picking your next planet to visit (i.e at the end of your turn). Early players could have organized games with other players on a system. All you would have to do is send the game data file to the other players or save it in publicly open file space. Then the next player could load the data file and continue with their turn and then re-save and so on for each player (it can handle up to 12). The only problem is that in the version of the code as I found it, when you re-load the data, the first thing the program asks for is the choice of next planet for the last player, since that player would have typed 'save' at the prompt instead of their choice. Either people modified the game so each player could enter the choice before saving the game data, or ad hoc solutions were worked out, such as sending a message mentioning one's desired choice to the next player. In fact simply sending a message with a planet name might have been the way players let other players know the file was available and it was their turn. Then they could simply enter it and continue with their own turn.

It's funny but similar systems could easily be worked out today for people wanting to play the game on the Web for "1970's" experience of early network multiplayer gaming. Just fire up the virtual MC-10 and save your game data "STRADATA.C10" file (the emulator will create this for you when you save) to Yahoo public file space or e-mail to a friend. Then text your opponent the name of your desired planet. They can download the file and load it up into the VMC10 on their computer running the game. A little clunky perhaps, but it would give you a feel for early network computer gaming.

Recently, I created a Google files site for all my MC-10 programs, including STARTRAD.C10, which contains WAV sound file versions of the programs. These sound files can simply be played with your original MC-10 plugged into the sound-out jack of your PC. I find a half volume setting seems to work best and make sure to turn of any "noise reduction" features in your player software. Of course, they can also be obtained as .C10 emulator files in my MC-10 zip compilation, which includes Tamer's great Virtual MC-10 emulator (VMC10.exe).

RetroChallenge 2017/10: Gotcha

Okay, I didn't think I would have time for anything else for this month's RetroChallenge, but there was lots of curling going on this weekend, which my wife follows with a passion, so I found myself idly coding away while listening to the Masters (the TV's in our den). What I came up with was a program inspired by a real old game. I'm all the way back into the 1970s now scraping the bottom of the barrel for ideas. The game is called Gotcha. It's one of Atari's first video games. Apparently it wasn't all that popular. The original was two player.  Each player took turns chasing the other. This theme is reflected in its somewhat risque promotional material:

Don't know what's going on there.  In any case, the game mechanic involves a continuously changing maze. The logic of the mechanic of the change is difficult to discern, but I thought I might be able to recreate it, at least to some extent, on the MC-10:

Apparently the original game cabinet used some "breast" shaped cups as controllers.  After complaints Atari changed them to standard joysticks. Seems like a pretty blatant attempt at using sex to market a game to teenage boys, but it wasn't enough to overcome the mediocrity of the game.  It was no Pong. Here's another video of the original, but just the game play:

I changed the game to be single player. You move your cursor to collect coloured dots randomly placed on playing field. You have to avoid running into walls, or, because the walls are continuously redrawn, having the walls run into you.  There is a time limit, so you have to try to move fast.  Dots will move if you don't get them in time.They can also sometimes become enclosed by the walls of the changing maze.  Here is a video of what I managed to come up with.  I have tweaked it a little since making this video.  Now the changing walls can't erase the target dots.  I also have tried a technique of using a period to replace zero numeric constant in the draw statements, which I recall someone saying can make MS Basic run a little faster.  Not sure if it is true, but it doesn't seem any slower either.

So that definitely wraps it up for me for this Autumn' RetroChallenge.  Thanks to John again for organizing and to all the other participants for sharing their retrocomputing hobby.  I look forward to seeing what you folks get up to next year.