Working on an idea for a new game for Cocofest. Here's a screenshot:
The premise I'm working on is the following:
YOU ARE AT THE HERON POINT CONVENTION CENTRE. IT'S COCOFEST. THE CONVENTION HAS BEEN TAKEN OVER BY RETROBRITE-NEEDING COCOS. YOU MUST GO AROUND THE CONVENTION CENTRE SWAPPING OUT 10 YELLOWING COCOS FOR 10 SHINY NEW MC-10S. HOWEVER YOU ARE BEING CHASED BY THE 'B'. THE B IS FILLED WITH RIGHTEOUS INDIGNATION AT THE MC-10 (FOR RUINING THE CHANCES OF THE DELUXE COCO). HE WILL STOP YOU AT ALL COSTS.
The game is based roughly on the idea of 3D Monster maze. I will release it at Cocofest. Got lots of work to do to get it to a playable state (if that's even possible). Will keep you posted.
I have been fiddling away on both Dig Dug and Forest of Doom. On FOD I have been able to make some real improvements to the sound routines around combat and random messages. To make room for these new routines I have been combing the code for more memory savings. I found that I could really pare down the input routines. While doing so, I was also able to add a T structure for directional key input. Now TGFH can also be used in addition to the cardinal directions NSEW. I also found some redundant code that seemed to have been related to the Break key. And I improved on screen formatting. Since I have been playing the game quite a bit, I found a few places where I needed to add clearing the screen from the current cursor position calls. I sped up the sound and slightly fixed the music for Inns and also added back a few routines I had left out for space saving. I think I have sounds now for all the routines in the original program. And I have more space left (300 bytes) than I had a week or so ago (250 bytes). Here's a vid:
I have also been combing through DigDug. Found some more speed ups there too. It's quite fast now. In playing it, I felt I should re-adjust the scoring a little. I made rock dropping worth 80 if you kill the monster and inflating them worth 20. The disparity struck me as a little bit too extreme (90 versus 10). Also adjusted the fire breathing and laser blast a little so they appear a little more clearly on the screen before being erased.
Played Dig Dug to the point that I confirmed that you earned a life recharge at 500 and 1000. Should also work for 1500 and so on. I still haven't played FOD to a win. Whenever I get to level 6 I run into something like a Dragon that just does me in. At that level, especially after you get the scepter, the monsters just come thick and fast, almost every time you move a space. I haven't had much luck with getting the mirror or magic book from the innkeepers, nor much success with digging up X's. I play at level 2 so I can find the Xs but I just don't find them that often and they're usually a trap. I think you must have to win the sword and find the mirror and book to have a chance to make it out alive. I have tested these routines by way of breaking and using GOTOs to get to them, as you can see demonstrated in the video. I have even won this way. So I know these routines work. But I wonder if there is some bug in my port that somehow makes it impossible to win. It would be nice if some of the pros out there could play the MC-10 version to see if it is operating comparably to the Coco version. Maybe some folks at Cocofest?!
Anyway, I'll have to send the latest version on to Bruce.
Next postings I'll talk about my recent 10-Liner submissions to the 10-Liner Basic game contest.
I thought I had finished Dig Dug but Carlos Camacho, the graphics design artist on the project, posted in the MC-10 Facebook the notes for the background/intro music of the original game. He thought that when Allen Huffman gets his sound-through-the-serial port device working it could be added to play in the background in some future rendition of the program. I'll certainly do that. In the meantime I had been feeling the existing game start routine that flashes our names could use a little music. It only had a silent pause between my name and Carlos' name. So I used my sound routine developed for FOD to play the refrain while our names are being displayed when the program is first run.
Here is what he posted: 10 PLAY "T8;O1;F#;G;G;G;G;G;G;G;G;G;G;G;G;G;E;D;E;D;E;D;E;D;D#;E;E;E;E;E;E;E;E;E;E;E;E;E;E;D;E;D;E;D;G;F#;G;G;G;G;G;G;G;G;G;G;G;G;G;E;D;E;D;E;D;E;D;D#;E;E;E;E;E;E;E;E;E;E;E;E;E;E;D;E;D;E;D;G" 20 PLAY "T8;O2;F#;G;G;G;G;G;G;G;G;G;G;G;G;G;E;D;E;D;E;D;E;D;D#;E;E;E;E;E;E;E;E;E;E;E;E;E;E;D;E;D;E;D;G;F#;G;G;G;G;G;G;G;G;G;G;G;G;G;E;D;E;D;E;D;E;D;D#;E;E;E;E;E;E;E;E;E;E;E;E;E;E;D;E;D;E;D;G" 100 GOTO 10 I'm posting it here in case anyone else might find it useful and because its a convenient place to go back and get it from when I need to use with Allen's device. I also (of course) found a few more tweaks to the code to make the main loop just a little bit faster (I think). I should also mention that I built in James Diffendaffer's M/L speed-up routine. It's one little tweak to Microsoft Basic (something about using the 0 page), that he estimates speeds up execution by 1-2%. Only a little bit, but every little bit helps! 0 REM01234567890123456789012345678901234567890123456 1 CLS:GOSUB3000:GOSUB10000:GOTO100:REM program start line number 9998 DATA60,54,55,150,246,129,126,38,25,220,247,195,1,5,131,1,1,221,252,206,67,113,236,1 9999 DATA221,246,236,3,221,248,236,5,221,250,51,50,56,57,240,129,58,37,1,57,126
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!
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:
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!
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.
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.
