Looks like I could say “It is finished¨. Of course, anyone who ever wrote a computer program knows that you are never finished, but, at least I can say that “Russian Roulette” has been properly “Remixed”.
As I mentioned before, there were only 2 tasks left. I tackled the sound first, and even when the results are not great – there is no way to generate noise from BASIC in the CoCo – I think that they are at least acceptable.
For the “Bang” sound, I changed the original PLAY”V30O2L32CF”, just 2 notes in the 2nd low octave, to V30O1L254T254ACDEFAV20ACDBV10FACD. That is 14 notes in the lowest octave, as short as possible, arranged in a somewhat random fashion to simulate noise. There is also a slight “fade-out” effect by changing the volume from V30 to V20 and finally to V10 while playing.
The “Click” went from PLAY”O5L64;12″ – a single high pitched note – to O5L96T4BABB. Not a great deal, but at least a bit better.
In the original, the sounds will only be played in one place in the code. But as I added computer “players” that can also Click and Bang, I used an alphanumeric variable to store the PLAY string, to save me from typing the whole Bang sound twice.
For the ending, I wanted to do something a little bit fancy, but without going crazy.
I thought about changing the color assigned to the palette entry for the background to do a kind of “fade out” effect, but in the end I went for a kind of wipe-out.
Using 2 FOR/NEXT loops to print spaces with a different background color than the one already on the screen was very simple, and I went to use 2 PRINT statements. One would go from top left to halfway down, and the other from bottom right to halfway up.
But something was not working. For whatever reason, I’ve always ended up with a space in the original background color on the top left.
Eventually, I realized that, regardless of what was PRINTed on the screen, an extra character with the cursor would be placed right after it. Therefore, when I was printing in the bottom right corner (39,23), that extra character would print in the next line, causing the whole text screen to scroll up. This, in turn moved the 2nd top line up (still in the original background color), and caused that “leftover” character.
Since the computer was actually printing 2 characters for each PRINT command, and I should not print on the last position, I changed the loop that tracks the horizontal position to use STEP 2, and to go only up to 38, ending up with this:
510 FOR V=0 TO 11:FOR X=0 TO 38 STEP 2:LOCATE 39-X,23-V:ATTR 0,0:PRINT” “;:LOCATE X,V:PRINT” “;:NEXT X,V
And finally, the simple trick of printing one character at a time for the final message.
520 LOCATE 6,10:FORX=1 TO 25:PRINTMID$(“You are the last survivor”,X,1);:FORL=1 TO 30:NEXT L,X
The reason I did not use the palette fading effect was that I thought to use it for the “death” screen.
In the original, I switched one of the low res screens, set a blue background, and then painted it red from top to bottom by drawing lines.
1130 WIDTH 32:PMODE 1,1:SCREEN 1,0:PCLS 3
1135 COLOR 4
1140 FOR A=0 TO 192 STEP 2:LINE(0,A)-(256,A),PSET
I guess I was trying to do something like a veil of blood falling over the player’s eyes…
Looking for colors that would work for a fade from the magenta background to red, I realized that there were not really too many. By changing the default background to a darker shade, I was able to get another one, which is kind of enough for the effect to work.
340 FOR A=1 TO 5:READ P:PALETTE 6,P:FOR W=1 TO 100:NEXTW,A
350 DATA 9,8,7,6,5
Well, that’s it. A second game remixed. I leave you with some screenshots and the listings for both, the original and remixed versions.
Ooooppsss! I just figured something out. More than a few times, when it’s the player’s turn, the game will just react as if a key had been pressed, and move on. This seems to be because any key pressed after the INKEY$ is stored in a buffer, and goes is used later. Adding an extra, bogus INKEY$ seems to have taken care of this.
95 A$=INKEY$:IF A$=”” GOTO 95
As I went back to rewrite what I had lost, at least I remembered most of what I had done. And is not as if it was a great coding challenge. It is quite a simple program.
One of the first things I did was to include multiple computer players. They are quite dumb and will just pull the trigger when their turn is up.
When the game starts, you are asked “How many opponents” from 1 to 5 will play with you.
Then, after you go first, a simple routine takes care of your rivals.
2010 FOR R=1 TO O:CLS:C=C+1:IF C>6 THEN C=1:B=RND(6)
2020 LOCATE 5,5:PRINT”Rival #”;R;” aims and …”
2025 FOR W=1 TO 1000:NEXT:IF CB THEN LOCATE 15,8:ATTR 2,7,B:PRINT”!-CLICK-!”;:ATTR 3,6:FOR W=1 TO 1000:NEXT:NEXT R
2050 IF C=B THEN PLAY”V30O2L32CF”:LOCATE 15,8:ATTR 3,3,U:PRINT”!!!BANG!!!”;:ATTR 3,6:DP=DP+1:C=0:B=RND(6):FOR W=1 TO 1000:NEXT:NEXT R
2090 LOCATE 0,8:PRINT:O=O-DP:DP=0
Having other players gives you the possibility of having a bit of strategy for the game. If the last 4 rivals “click” their shoots, you know that there is a good chance (2 in 6) that your chamber will have a bullet in it. Time to buy a spin, or aim for the floor.
I followed by modifying the “spin” and “aim” routines. Before, the program went back to wait for you to press any key. Now, after you decide to do either action, you shoot.
Finally, it was just a matter of translating and relocating the text.
After a few test runs to tweak and make sure all was OK in the game’s logic, I added a bit of flash when the gun fires. Nothing fancy, just
That makes the background color a light yellow, plays a short pause (does the same as an empty loop, but is far shorter in code), and then restores the original color to the background.
The last two things I want to add are a congratulations screen if you are the only survivor, and better gunshot noises. Probably something like what I used in “Minecamp”
But is already almost midnight. That will have to wait for tomorrow.
I was still going over whether to make the game for a 16 KB or 4 KB CoCo, when I realized that variables are taking quite a lot. And it is understandable, since basically all graphics are stored in alphanumeric variables. With almost 2 KB in variables, and over 2 KB in code… well, there is no room for it in a 4 KB machine.
Therefore, right now, I’m going for a 16 KB machine, with Extended Color Basic, and disk drive. Once I’m done, I’ll rework it for Standard Basic and tape.
Knowing that I had plenty of room, I started adding some nice things.
First, a simple welcome screen, with the hippo moving it’s tongue and blinking.
Then, I made the worm move up as the teeth are being eaten, to keep it “touching” them, by updating the variables that store the position where the worms is printed, every time that a tooth’s piece is eaten.
I’ve also included a not so good version of the game’s intro tune, and the constant “peek-peek-peek” sound, just as in the original game. Somehow, it does not seem that annoying to me. Perhaps because the game is short, or because I’m the one playing it. It will probably annoy the heck out of anyone around… 🙂
And finally, there is a “Game Over” screen, where you are asked if you want to play again. But… the option to play again does not work yet.
In order to go again, I will have to redraw the teeth. But they are not actually drawn in the game, they are part of the background that is loaded form a separate file. And I don’t want to load the file again and again every time that the game is replayed. I got something half figured out, that will (should) take very little additional code. I may try that tomorrow.
Here is a new video of the game.
In the “to-do” list, I have: 1) Improve the sounds and music 2) Get the “Play again” option to work, and 3) Compact the code.
Once everything is ready, I’ll try to get it to work in the more limited Standard Basic, and who knows, seems like porting it to other old micros (C64, Spectrum, etc) should not be that hard…
Well, yesterday I spent a few hours coding the “Hippo Teeth” game, and I was surprised at how easy it all seemed to flow.
After saving the background image as a BIN file, that could be LOADM’d from the main program, I went ahead with creating and animating the “Sprites”.
The player’s controlled Doc can be in just 3 positions, one below each tooth. So I used a variable P to track those. As the graphic of the player is made up of 5 lines of 3 graphic characters each, I also use P$(5) to store the 5 strings. Then another array P(3,5) to store where each of the 5 strings should be printer for each of the 3 possible positions.
That is, when the player is in the 2nd position, I print P$(1) at P(2,1); P$(2) at P(2,2); P$(3) at P(2,3) and so on.
I did the same with the Worm and the Tongue, but for the Smoke, it was a bit more complicated, since it can be in located in a 3×4 grid.
Actually, my first problem was that the game was running too fast!
Each teeth has 40 “life points”, and I was subtracting one for every loop that the worm was under a specific tooth. I had to cut that down to 0.25 for each loop, which actually gives the teeth a life of 160 points.
I made a single change to the game play.
In the original, the tongue could move to “cover” the worm, and stood there, blocking your shoots, while the worm ate the tooth.
Now, if you shoot a “clean” tooth, the tongue may move to that position, leaving the worm open for a shoot.
So far, the game is taking 2570 bytes of memory, and I realized that I’m using some commands that are not in “standard” BASIC (STRING$, TIMER).
I will need to figure out if the game will target a 4 KB machine with tape, or a 16 KB one with Extended BASIC / Disk BASIC.
If I go for the 16 KB machine, I can make some extra animations, and with Extended BASIC, probably nicer sound.
Here is a video of the game after under 3 days of work, with sounds mostly as “placeholders”
And yes, I need to figure out why sometime the smoke cloud is not deleted…
And for the last post of the weekend, my “Second Challenge”.
write a game that will run in any TRS-80 Color Computer, using the low-res graphics mode (64×32) and no more than 16 KB RAM.
A great way to save time, is to “clone” an existing game. That way, I don’t have to come up with the game mechanics, and I will already have a fair idea on what the graphics should look like.
And it turns out that there is one game, quite simple, that I used to play a lot many years ago, and that as far as I know, was never available in any computer.
A small handheld LCD game called “Hippo Teeth”
The Hippo has only 3 teeth, and a nasty worm is trying to eat them!
Your task, as a veterinarian dentist, is to kill the worms with your gas spray. Nut that is not so easy. The worm moves around a lot, and the Hippo’s tongue gets in the way….
As the gameplay is already set, I decided to test if I could do some decent graphics in the 64×32 mode. One of the difficulties, is that each 2×2 block can only have 1 color and black, a limitation similar to the one the ZX Spectrum has in the high res-mode.
Instead of trying to design the graphics using a regular “Paint like” program, I took advantage of the excellent online SG graphics editor at https://daftspaniel.neocities.org/tools/sgeditremix/
With this tool, it didn’t take that long to come out with what I believe is a decent design for the graphics.
There you have the Hippo with it’s big open mouth, the 3 teeth, the nasty orange worm, red tongue, “cyan” gas cloud, and the Doc.
Except for the Doc’s feet, everything else happens over a black background, making it easier to design the graphics and animate them.
I will save the Hippo’s picture as a ML file, and load it at the start of the game, perhaps even keeping a copy in another memory location, to make it easier to redraw it if needed.
I have to do some tests to see what is faster, if printing the semigraphic characters, or POKEing them. I guess print will be faster, as each “sprite” will use 3 commands, instead of 9-12 POKEs.
On a side note, something that caught my eye, is the way that the cyan color looks like. I would have sworn that it was a sky-blue like color, as it should be according to Wikipedia.
But my CoCo 3, and all the emulators I tested show the same greenish hue… well, not all. The original Java based “Mocha” emulator does show the color I remember from all those years ago…
I really don’t know what happened to that color that was perfect for bright skies or clean waters. Do you?
My First Challenge, as you may remember, is to fully load an AcerNote730i laptop, with software to match it’s manufacture date of 1995.
I guess I can divide it in three.
1) Choose the software,
2) Get the software, and
3) Load the software.
Even if the computer is from 1995, Windows 95 is clearly out of the question.
Windows 3.1 should not be a problem, perhaps with the computer booting to DOS, and loading Windows manually when needed.
X-Tree was one of my favorite programs back in the day, and it will find its way in there.
Norton Utilities, or at least Norton Disk Doctor should also be there.
Other programs that I used back in the day were Quattro Pro, Arj, Compushow…
Some games must also be there. Maniac Mansion, Master of Orion and Doom seem like a good way to start.
Getting the software should not be that hard. I still have copies of some of the one I was using back in the 90’s, and sites like “Vetusware” make it relatively easy to find almost anything from that time period.
The real challenge will be to get the software into the computer. As I mentioned before, it has no PCMCIA slot, nor network card. That leaves only the serial port and the floppy drive.
I do have a P-III with a floppy drive, and I could get the software to it from either a CD or a CF card reader. But I have not used the floppy drive in years…
And to use the serial port, I will fist need to get a terminal program into the laptop, so I would still need to use the floppy drive for that.
Well, I guess my next step will be to test that floppy drive, the few disks I still have around, and perhaps try to get a few more from somewhere. Let’s see how it goes.
OK, not that they were going to reject me or anything like that, but the last 2 times I tried to participate in the RetroChallenge, something got in the way. (The last time was a trip to the US that allowed me to go to my 2nd “CoCoFest”, so I can’t complaint about that one).
At least, this time I’m writing the first blog post, and that is much more that I managed before.
I decided to take 3 challenges, 2 of which have been in my mind for quite a while, and I will try to write individual posts for each.
The first one is related to an old laptop a friend gave me for free some 10 years ago. An AcerNote730i (486SX,4 MB RAM)
It was clearly designed from the start to be a limited machine, as it has almost no expansion options. Just a parallel port, serial port, VGA, PS port and a floppy drive. No PCMCIA slot or network card.
The hard drive was clean except for some leftover DOS files (From a Windows 95 boot disk).
Eventually, I got to install “Maniac Mansion“, but never gave it the attention it deserves.
Then, the First Challenge is to install a full DOS and software package, including some games, utilities and productivity software in it.
The second challenge came to mind after writing a couple of games for my Tandy Color Computer 3.
I realized that I was always using the high-res modes, full 128 KB memory, and requiring a floppy disk (real or emulated).
But I had nothing that would run in the old Color Computer 1 or 2.
So, my Second Challenge, is to write a game that will run in any CoCo, using the low-res graphics mode (64×32) and no more than 16 KB RAM.
The third challenge is somewhat related to the second.
Not long ago, loaded all the programs I wrote in BASIC from 1985-ish to around 1995 and created disk images with them, to play them in emulators or in my real CoCo using the SuperIDE card.
A few weeks ago, while optimizing one of my latest programs, I realized that I could probably improve some of my old ones, creating perhaps a “Director cut” or “Remix” version of them.
Therefore, my Third Challenge is to look through my old programs, find some that could use some cleanup, and try to update them.
Well, maybe I’ve overextended myself…. Time will tell. I have 30 days and counting.
6 years ago, I started to write “Furious Felines”, and 6 months later, it became the most complex game I had written to that date.
It has quite nice high resolution graphics (320×192), the graphics and levels are loaded from individual files, making it easier to maintain, and allowing me to go past some of the memory limitations of BASIC, and people seemed to like it.
I did like it too, but there were some things that I’ve always thought could be improved.
The “wind” was the one that I really did not like, and some of the graphics, specially the trampoline onto which the cats jump, were kind of…. off.
A few weeks ago, I finally made up my mind and starting re-coding it.
And then I could not stop.
I changed the way the wind works, then cleaned up the code, and then added new features, and then improved some sounds, and then improved some graphics, and then… STOP!
If I kept going, instead of version 1.1 it would be 2.0! (And I have plans for a 2.0)
Here is what I finally decided to change / update / add:
Used to be part of the level, loaded into VV, and then modified this way:
It will then affect the cat’s horizontal position by H=H+VV+0.1+LO*0.5
Now, it simply is initialized as VV=RND(3)+1 and then used as H=H+VV+LO
A lot simpler, and always an integer.
Enhanced some graphics.
Since I was redoing the way the wind works, I changed the indicator, from simple “>” characters to actually DRAWn arrow shapes.
The spring onto which always looked to ugly. I’m not sure if it looks any more like a spring as it did before, but at least I gave it some “shading” and color.
In the background, I added a second type of window for the buildings in the background, simply by adding a black cross on top of some of them.
And now there are stars in the sky!
And then… I said to myself: “What the heck, I’ll do it.” and added a change in the gameplay.
I added a new element. A piece of cheese that the mouse will try to steal. This will give the game a sort of time limit, and put some pressure on the player to catch the mouse as soon possible.
Now the mouse had to be able to chew trough the walls. To do this, I just draw a black vertical line ahead of the mouse when it collides with a wall and is pointing to the cheese. This effectively “eats away” a small part of the wall.
By making this change, most of the levels of the original game had to be changed. Just dropping the cheese anywhere would not make it a good level, so I went ahead and updated most of them. As I was at it, I added another 2 levels, for a total of 8. (It is still quite easy to edit the levels file to change them or create new ones)
This, of course, required testing and retesting all levels to make sure they were winnable, even in the second round when the wind is stronger, and also tweaking the screens where the score is shown to make room for the higher scores that are now possible.
With this changes, the game became “Furious Felines 2, Save the cheese”
At this point, the game was almost ready.
The flickering in the cat’s graphics as they flew across the screen annoyed me at some point – it is mostly created by the time the computer needs to draw the cat on the screen – and with the help of the great CoCo community, it got mostly under control.
Finally, I changed a bit the intro’s music – which can be skipped, most of the times, by pressing any key – and added a not very neat way to change the color palette to make it look as it should in a TV or RGB monitor.
Well that should be it.
You can download the game from my CoCo website, where there is some information on how the game works, and how to tweak the levels. There is also a manual, in printable and a PDF versions.
If you try it, please let me know what you think of it.
That is why, a few days ago, when feeling a bit bored and finding some time in my hands, I started another project. Let’s call it … “Trench of Death”
Just as “Furious Felines” was inspired by “Angry Birds”, “Trench of Death” draws from another modern classic, “Plants vs. Zombies”, but with a scenario changed from a garden to the Death Star.
I guess that everyone remembers the attack against the Death Star at the climax of the original Star Wars movie. The attacking ships have to go through a long, straight “trench” to get to their final target, while turbolasers and TIe fighters try to shoot them down.
In this game, you’ll have to set the defenses along the trench, to prevent the attacking crafts from reaching their target. The ships will be coming from a trench 10 cells long, were you can place guns at 3 sides.
Each gun will have different cost, a “time to build” and power ratings. After the player selects the type of gun to be installed, they will place it either on the sides of the trench, or at the end, meaning that the incoming crafts will be fired upon from the sides and the front.
I have already coded 10 types of gun turrets for defense, and 8 types of attacking crafts, and done some testing to evaluate the game balance.
So far, I don’t have much to show. I have coded the attacking craft movement routines, and tested it with a squadron of 8 ships. Speed seems to be acceptable even with fake routines added to represent the joystick input and gun firing routines.
Next up, allow the player to select a type of gun, and place it in one of the designated spots.
I hope I’ll be able to do it this weekend.
After the success(?) of Furious Felines I started thinking about which would be my next project.
For some time I considered a port of “Felines” to PC, or to mobile platforms. Perhaps, but not right now.
But that reminded me of another game I wrote years ago for the CoCo, “Submarine Hunter“.
I did port, or actually, create a much improved version for the PC platform in 2012.
The PC version has, of course, far better graphics, but also the gameplay was improved. (I hope).
I realized that a far better CoCo version is possible, and decided to get on with it. I’m almost sure that most of the code can be reused from either the original CoCo version or the PC port, and with that in mind, I started creating the graphics. I plan to manage the graphics as I did in “Furious Felines”, drawing all the graphics in an intro screen that will then be loaded from the main program. This makes it easier to update the graphics, and keeps the file with the program’s code smaller.
So, here is a preview.
After the last change, when the game is run, there is a few seconds delay while the screen is being loaded.
At first, I was just going to add a simple “Please wait, loading” message, but I couldn’t help myself.
While adding more graphics, I realized that the initial screen was taking longer and longer to draw. It’s not fun waiting for a minute or more while the game “loads”. But there is a solution for that.
I moved the code that draws the graphics and intro screen to a separate program. Then, using the code from HSAVE, saved the screen and color palette into 3 files.Now, the main game file, FELINES.BAS loads those files to display the intro screen, and then captures the in-game graphics (HGET) from there.
Now it takes less than half the time to finish the intro screen than before, and I can add as many graphics as I want without affecting loading time. The only drawback is that the files that make up the screen, – FELINES.PAL, FELINES.SC1, FELINES.SC2 – are quite big, +32 KiB total. The whole game is now almost 38 KiB. quite big, but still fits comfortably in any floppy disk
With just a few days left before the Annual “Last” Chicago CoCoFEST!, I had to get in gear. I had submitted a preview version of “Furious Felines” for the CoCo Coding Contest, but it was far from what I wanted the game to be.
First, I had to discard the idea of playing music while drawing the introduction screen. I had hoped to play a recognizable tune, playing one note after drawing each line in the cat’s graphics, but it slowed everything too much, and the music did not work fine.
The biggest change came when I decided that the game will allow you to, once you have finished all the levels, replay them, with a higher level of difficulty. To do that, I moved the levels data outside the program, to a data file. In this FELINES.LVL file I could store as many levels as I wanted, and could load and reload it as many times as I wanted. This worked out fine, and will allow me to create a level editor at some point.
Also, I added a random factor to the wind in each level, to give a better replayability (is that a word? Or what?), and a wind speed indicator at the top left of the screen.
With this changes, and 6 playable levels that could be replayed until the mouse escapes, version 1.0 of “Furious Felines was ready for the public unveiling.
Interpreted BASIC, in a 25 year old computer, is not fast. That is a fact.
Trying to improve the animation speed and reduce flicker, I did something I have never tried before. A look-up table of sorts.
The idea is simple. Calculate all the points in the cat’s trajectory while it jumps, and store them in a matrix. Then, animate the jump reading the graphic’s position from that matrix instead of calculate it while drawing the animation.
But I found two not totally unexpected problems.
- The calculations took about 5 seconds. During that time, the game had an ugly pause in the action.
- I found out that most of the flicker is actually because of the time it takes for BASIC to draw the graphics in the screen. Having no delay between the command that deletes the cat’s old position, and the one that draws the new one did actually create a flicker that was in some aspects nastier than before.
So, back to the old code.
The good thing is that it was not hard to implement at all, and I’m sure I will find another chance to use it.
Here are some updated graphics, showing the 3 different cats.
The length of the jump depends on the one on top of the pile, and the one that is going to jump.
The Tabby is heavier, and the Siamese is the lighter one.