I have done some more tinkering to speed up the Basic part of the program (e.g. renumbering lines). The big change is now smoke only lingers for a few moves and then dissipates, which is more like the original. I think I am coming close to the definitive edition...
As well, I'm still finding the occasional bug regarding the walls, which I fix by changing the numbers in an numeric array representing the map. It uses the basic 4 number code for walls (and zero for open space): 1 v 3 > ■ < 4 ^ 2 So if you hit a wall marked as 3 you will turn left and so on. It took a bit of trial and error to work out the proper system for such deflection. Hopefully I've sniffed out the last of idiosyncratic places that would let the enemy car "pass through walls." But if there's anyone out there who notices any.... https://www.facebook.com/jimgerrie/posts/1261129703922549
Thanks to Darren Atkinson and Robert Sieg for volunteering to do some M/L coding to help me speed up Cross Rally. In this video you can see the latest version in which I have implemented Darren's USR routine. Its speed boost allowed me to add a permanent update of the mini-map with the enemy car's position relative to yours. Also, the game will get slightly faster each round.
There is only about 400 bytes left, so I can't put in any REM statements with thanks to Robert and Darren, but I will thank them here. You can play the game online at: https://archive.org/details/@james_gerrie
This is a video of the demo that Robert worked up for displaying the Map info:
Well I have added the final bells and whistles. The intro screen explains the basic keys of the game. Hopefully the rules are not too opaque. In brief, you must collect the 10 regular Checkpoint flags and then make your way to the Level Checkpoint flag. The regular flags appear on the mini-map on the bottom right of the screen, but the Level Checkpoint flag does not, so you must keep your eyes peeled for it while you rove. You can run over it, but it will not take you to the next level until you have collected the 10 regular flags. Completing the level faster adds a bonus to your score when you level up. There is also a special Bonus flag, which will give you an extra car. Be carefully when collecting these, as you can only have a max of 5 cars and if you run over the bonus with a full car complement, it will be wasted. You can also create a smoke screen (oil slick?) by hitting space. You only can do this 6 times per car. The dark green bar labeled "F:" tells you if you have any left. You can run over these smoke puffs without any problem. Avoid the rocks. They're as deadly as the enemy car. Pressing the "C" key or the "B" key will flash the current location of the you and the enemy car. It would be nice to have this continuously updated, but it would slow down the game too much. You have to make some sacrifices when you make a game in Basic. When you exit the game it will report the last score and the highest score.
Here's a video of the original for comparison purposes.
This project is for Retrochallenge 2017. For more info about retro-programming projects see: http://www.retrochallenge.org/
Well, it's a game now. Just have to fix up a few more fiddly bits and maybe add smoke and some point bonuses. Might be a possibility someone will take my offer on the Yahoo group to program a slightly speedier screen rendering routine for refreshing the map on screen. Right now I use a bunch of MID$ print commands. If that were possible, it could possibly be even speedier. I guess we'll see. I suspect this will be my major effort for RetroChallenge 2017. Hope I can get it finished.
Found a really neat site listing Basic programs for the NEC PC-6001. One of the games called "Car Rally," written by Maiden Artist, looked liker a good prospect for porting or re-programming for the MC-10. Apparently he had ported it from a Pocket Computer version of a classic arcade game Rally X rally. It used semi-graphics 6 mode.
You must collect flags.
While avoiding an enemy car.
And watching the map on the right side of the screen that indicates where the flags are.
You can release smoke to block the enemy.
GAME OVER
The game is over when the remaining fuel runs out. If you collect all the flags you can go to the next stage, but the number of enemy vehicles will increase.
I have been working on a version that uses strings for the map and the MID$ function to display the section you are. Its pretty speedy so far but I have yet to add the enemy care and its search algorithm. Hopefully I can keep the code tight enough to keep the speed up with the tracking added. I'm going to use the VARPTR function to poke the obstacles directly into the map strings, and maybe even the moving enemy car too. Here was the test of concept:
Here is an update with the routines added to prevent hitting walls.
Next, enemy car tracking and collision detection. The routines to randomly place flags in the maze and plot their locations on the little map.
I made a version of the classic puzzle game Sokoban back in 2013. I used some ASCII maps I came across for an OS9 text version I found for the Coco. Because of the limitations of the MC-10 screen I could only use puzzles that would fit on the 20X16 space I had designated on the left hand side of the screen for displaying them. That meant that only the first dozen or so of the maps from the original game would easily fit, after that I had to pick carefully the maps that would fit from the more complex higher levels. I remember at the time that I was able to decode what most of the ASCII characters used to encode the maps represented. There were the boxes, the home bases where the boxes had to be pushed to, the starting point for the character and the walls. But there was also another kind of character that I couldn't figure out. These special characters only appeared on the higher level maps. I didn't play the game well enough to have got high enough in level to know what these special codes were for, so I just left them as blanks. But it always niggled at me that I hadn't properly completed the program.
Well jump forward a few years and the thought struck me that I should be able to find more information about Sokoban on the Net today, including possibly on-line "solver programs" that would help me to check whether the program was working properly on those higher level maps. I had recently used a Minesweeper solver program to help me check whether my Sweeper program (for the 10-Liner programming contest) was working properly. I like programming, but I'm actually not very interested in logic puzzles, so it greatly eases the burden of testing to be able to have a program that will help you complete a puzzle. Well I didn't find a solver program but I did find videos of people solving all the classic maps for the game:
Puzzle Map 50 was one of the maps I had included in my version for the MC-10. When I viewed the video I was able to see that the strange characters I hadn't been able to figure out back in 2013, where just boxes that were already placed on home bases at the start of the level (the reverse Os in the picture below).
New 2015 Version
You can see that in my old version I had left these out.
Old 2013 Version
Another feature that I had regretted not adding to the program was the ability to take back the very last move. Without that feature, one simple slip of a finger could ruin a whole level. On the very high levels this can mean possibly hundreds of wasted moves. So I added the feature to help avoid annoying players too much (if there ever are any besides myself). I was also able to improve the animation of the little warehouse worker dude. Robert Sieg created a little click sound routine using just POKES and PEEKS, which I added as the footsteps for the guy, rather than the excessive SOUND commands I formerly used, which are simply too loud and annoying.
I was able to fix all the maps with the special characters in them by looking for images of the maps on-line. In the course of doing that I was also able to add the original map numbers to the 25 "levels" that I included. So the player can now know which of the original maps they are playing on the MC-10 version.
I committed to blogging about my recent projects for RetroChallenge 2017 and the last two "snow days" here in Cape Breton have allowed me write about the projects that I most wanted to write about. I know that I'm early, but hey when the weather cooperates with you in Canada, you've got to take advantage! And I'm not sure if I'll be able to post in April--I'm a university professor and that's end of term and exam period for me. So in case I can't find the time for more posting, I'll thank John and the other participants for another fun contest this year. I'm sure I'll be able to find time to read about the other projects over the coming month, which will be a fun distraction from marking. For more information about the challenge click here: http://www.retrochallenge.org/2017/03/rc201704-open-for-entrants.html?spref=fb
I know that what I mostly do is port old code from around the Net to the MC-10. But occasionally I feel the urge to make something new. I got the inspiration for my game "Curse of the Undead" by stumbling across a website that had these two interesting images drawn using just text graphics.
Curses of the Undead
I'm attracted to such images because their ASCII text graphics can often be easily translated into lowres graphic images on the MC-10. With that in mind I set out to make some simple graphic streetscapes like those in this Linux text game described as "Your 3D Zombie Apocalypse in ASCII!" The author offers a zombie apocalypse adventure for the Linux console. Apparently he dubbed it “Curses of the Undead” because it used the standard ncurses library used for manipulating the console screen under Unix systems,
The game play sounded very simple with the player basically just responding to a sequence of decision prompts as he navigated a section of town being swarmed by zombies. After I got the street scapes drawn, I though I would try to cobble together a simple 3D engine that would allow you to navigate the streets of a city on your MC-10. I've worked on a number of 3D systems now for ports and original program, so I'm familiar with the basic principles for plotting your view based on the direction you are facing. It came together pretty quickly. Then I had to make some kind of game out of it. I had a number of standard simple zombie swarming text games, where the player gets two moves for the every one move of a bunch of simple X/Y coordinate tracking zombies.
Zombies
One thing I had always thought about such games was that they were always a little short. It usually didn't take long for you to trick the zombies to track into whatever obstacles were spread around meant to kill them (the white blocks in the above). I thought it might be nice to extend this kind of play by placing it in a virtual setting, so that one had to succeed at a sequence of encounters. And adding some animation and perhaps a weapon or two to spice things up a little would be nice too.
So I translated the game play of these standard zombie tracker games to the different street locations you move to using the 3-D engine. You must destroy a total of 60 zombies spread randomly throughout your neighbourhood to rid it of the zombie menace. To aid you, I also have supplied your character with a shotgun, but it only comes with 3 bullets initially. You must find more ammo as you move around. I also animated the fires that you can lure the zombies into to destroy them. But beware of hitting these fires yourself because they can cause you injury. Three brushes with the flame and you will join the zombies in death, but not the still mobile kind.
You might notice in this early version of the game that one mistake I made was listing how many zombies you had "killed" at the end of each game. Oops. Changed that to "destroyed" in the final version. Don't want to mess with the classic "guilt free" destruction that lies at the heart of the zombie motif. No live people were harmed in the making of this game!
