Made a few further last minute (after contest) fixes. There was a bug in the Bat routine so that it wouldn't necessarily steal an item from a room that it found you in. Left out a NEXT in the item search subroutine so it would only find the sword (item 0) if you dropped it in the room with the Bat flying at you. While I was at it, I added a new death scene for Dragons, which I have been thinking about for a while. A dead dragon is now displayed upside down when you stab successfully. Here's what it looks like now. Skip to the end, if you just want to see the death scene:
Here is the link to the RetroChallenge to see the results of this year's challenge: http://www.retrochallenge.org/p/entrants-list-201809.html P.S. Fixed a problem with moving objects. There are two unused rooms, 21 and 22. I send anything you are carrying, or dragons that are killed, to room 21. You could think of it as the Valhalla room. However, there is another room that does not appear, room 22. When randomly moving objects around the program should avoid sending anything to room 21 (Valhalla), room 5 (the secret room) and room 22. However, I hadn't included code to avoid sending things to room 22, so occasionally items and dragons would go missing, at least for a time, from the accessible spaces of the map. In making these changes, I also changed the moving object routine to avoid moving objects placed in the micro dot room and the room where the chalice is initially placed. This means that both of these items stay put and don't get moved around. But now, once they are moved from their starting rooms, they are able to be moved by the bat like any other object. In other words, these objects themselves used to be off limits for moving, but now it's just the rooms they are placed in that don't allow movement of items from them. I had also forgotten to prevent dragons from being selected when the bat was randomly moving things, so they could be brought back to life after being sent to Valhalla (room 21). Now items in room 21 are not allowed to be selected for random moving. This includes dead dragons, but it also includes the item being carried, so I was actually able to simplify the selection routine. It just excludes items in room 21, and things in the micro dot room and chalice room. Finally, I also fixed the map in the White Castle. Now you have to pay close attention to the map in order to find a way into the hidden section... and out again!
A big thank you to the Solar Penguin for noticing a spelling mistake on the final screen when you win (take a look at the end of the video in my last post). I fixed it and found a few more speedups. Also tweaked the game levels and fixed the bat movement timer so it didn't reset every time you moved from screen to screen. Now the bat's activities should occur on a more regular basis. Here's a new playthrough, in which the chalice turned out to be fairly easy to secure. But I still manage to get killed a few times.
Hope this fix makes it into the RetroChallenge. I also added a REMark to the code with a shout-out in honour of the contest (you can see it at the beginning of the video). Thanks to all for sharing in the fun!
Made a few final bug fixes that quash minor non-critical visual quirks. The dragons didn't initialize properly if they showed up on the first screen at the Gold Castle. Tried to deal with the possibilities of "spawn killing" when you enter a room and a dragon is right on top of you. Now placement is confined to the centre area. This should leave a little space for you to enter rooms, and if you're quick, get out or move away before the dragon or bat can get you. Replaced all two character string variables with single character variable names. Anything to help a little with speed.
Think the game is winding down to completion. Can't think of any major changes, besides adding some better sound or music. Still might put an upside-down dead dragon graphic in, but I'm not feeling motivated to create such flourishes. Perhaps, when my son Charlie is home for Canadian Thanksgiving he'll be able to give me some feedback for improvements. But the contest will be finished by then. So I think this might be it for posting.
Noticed another quirk in game play that needed ironing out. If you entered a room with the bat in it and dropped the item you were carrying, the bat would fly to you, notice you weren't carrying anything, exit the screen and choose a random item from anywhere in the dungeon to move. This made it too easy to avoid the bat stealing important stuff from you.
Now you can't just drop an item to avoid the bat stealing it from you. The bat will always steal an item from the room you're in, if it catches you and if one is available. If not, then it will pick a random item from somewhere random in the dungeon and move that.
Also, I sped up the whole routine of the bat moving things. This means that when you're moving around and the bat is moving things off screen, the pause in your movement is much less noticeable (I hope). Also I tweaked the levels so there is more delay between mouth opening and closing at the lowest level than at the highest. There was too little difference between level 1 and level 3, at least when it came to killing dragons (i.e. striking when their mouths are closed). Also, I increased the contrast between the three types of dragon, so purple (Barney) is more clearly less threatening than the blue dragon (Blue Streak).
Made it so items and dragons can appear in the Yellow Castle room. For some reason I had considered this room out of bounds for items and dragons being placed there. Can't recall my thinking, but it will help speed things a little not to exclude it. This change also allowed me to tweak the routine that places the sword at the beginning of the game. Now, on levels 1 and 2, the sword will always show up in one of the rooms near your starting position at the Yellow Castle or by the castle itself. But on level 3, there is a chance the sword will be hidden in one of the big rooms near the White Castle, which will make for a little more challenge in getting armed.
I'll put the new version up in the regular places soon. Until then it's on Github. ADVENTR37.TXT
Last month my son was home from university. He's pretty good at Javascript, so I got him to help me download Mike Tines Javascript MC-10 emulator from Github and get it up and running from my own file space at the university where I work. He was able to figure out what needed to be tweaked in the code to get it happily running from another net space. I then set to modifying the code to change some modifications Mike had made to the standard MC-10 font. Lots of folks complain about the font. It's pretty quirky, with its square O and narrow 0. Mike didn't like the original G either. But I'm a bit of a purist and I have used some of the quirks to my advantage in games. The square O makes a nice box for example, for use in Sokoban. So I switched the byte codes back to recreate the original font.
Then I set about reorganizing the web page launcher for the code to contain menu listings of my programs. I have over 300 programs now for the MC-10 so I had to figure out a way to break the list into categories. I eventually settled on 4 categories: (1) Classic Basic Games, (2) My Own Original Programs, (3) My Text Adventure Ports (and 2 original adventures), and (4) All My Other Ports. This meant that each menu could be a more reasonable length. I started editing my web pages so that if you clicked on a picture of the game it will take you to the appropriate Javascript page that will contain a menu listing to the program. I haven't fully completed the process, but I have got the process mostly completed for 2 of my web pages:
Thanks Charlie for your help. Thanks Mike for putting your code up on Github and for letting me host it on my GameJolt page. It's a useful resource for the MC-10 hobby community. I am hoping to integrate the Classic Game page into a course I am working on for the history and philosophy of computing. Charlie might even trying modifying the code further to autolaunch games directly from a html link.
This demo shows a lucky placement of the chalice in the outer part of the White Castle. Only one dragon death. I have decided to keep the limit on lives to 3 respawns before you "fail in you quest." Made a few other final minor fixes and dummy proofing. Can't drop items in doorways or the very edges of rooms. This prevents you from overwriting them when you enter a room. It also prevents misplacement of objects when they wrap around to the other side of the screen. I could get rid of this visual quirk, but I would rather have the speed.
There is some further complexity to the hoops you must jump through to get the micro dot. Specifically a time limit on how long the hole made by your bridge will work/stay open. If you are not quick and don't time your movements right (you'll have to notice the rhythm of the bat moving stuff in the background. It is possible the wall you have bridged with the H can be redrawn trapping you, if you're not careful. Pretty tricky on level 3 when the time limit (i.e. time span between bat moving things in the background) is shortest. Tricky, but possible (I've tested it). It will be a rare breed who can figure out how to obtain the micro dot, that's for sure.
Project is pretty much done. Fun Retrochallenge. Thanks John!
So the more I thought about it, the more I realized that the game really did need a way to lose. So I modified it so that you have three respawns from being eaten, but then failure. I also found some more efficiencies in the main avatar movement routine, so the motion is just that little bit faster and smoother. Hope I haven't introduced any novel bugs. It's getting tedious to play to test every minor mod--the maps are getting pretty familiar and the novelty of exploration has worn off. Still, I need to do some more testing to fully determine if three respawns is the right number, or perhaps it should be that on the third strike you're out (i.e. just two respawns or three "lives"--there's something existential about reckoning "lives").
Also, I fixed a bug in the bat routine that was preventing it from disappearing after it swoops in and hits you.
I've posted the new version to my VMC10 distro, Google files directory, and Github.
The following video shows a walkthrough to an ordinary win of a game played at level 3. But there is also an easter egg to figure out, which will be reported on the final screen if you succeed in that task. Hope I have got all the essential elements in place and that the code is as efficient as possible. I might place a limit of three on the number of times you can be killed before you "fail in your quest." Right now the game seems a little too forgiving.
I have been adding lots of tweaks to the bat routine to make it run as quickly as possible in the background. Still, you will notice an occasional pause of your avatar as the bat filches something from a room off screen. Occasionally this will result in something, including dragons, being dropped into your current screen.
Now when you get eaten, you respawn without the item you were carrying. It is randomly placed in the room where you were killed.
The sound is minimal. We'll see if my son Charlie can suggest or come up with any interesting additions. Not sure if it is a very exciting game, but it is an interesting exercise as least in creating a virtual world in BASIC. Quite proud at how the mazes turned out and that I was able to cram them into a 20K MC-10.
What's missing?
The magnet. My random item placement routine doesn't put objects where they can't be reached. This effect would simply have slowed the game too much, and I wasn't convinced it was a particularly significant part of the game play. Maybe there is another element or item that can be added in its place to add complexity?
Complex Behaviour. Robinett was quite proud of the complex interrelationships between objects. In variations of the game the objects affect each other differently (attracting/repelling). A bit too much to render in BASIC without slowing things down terribly. In my version dragons just attack, bats swoop in and then out. And there can only be one enemy on screen at a time. Yet I think I have come as close as possible within the limits of BASIC to present the essence of the game.
Dead Bodies. There are no dead dragons lying around where you slayed'em. Just a little blood from your sword. I might still add an upside down dragon death scene. My code cleaning has turned up some extra space for flourishes to be added.
Well my semester is heating up now so I'm not sure I will post much else. This is where I hoped to reach in this particular project. Good luck to everyone else doing the RetroChallenge!
Here's a first distro of my new Atari Adventure-like game for the TRS-80 MC-10. It can be played on Mike Tinnes Javascript emulator. Load the first file on the menu "ADVENTR" and type RUN and hit ENTER.
I've got the bat routine to a point where it will swoop in and steal items you are carrying. It will also occasionally swoop in and just knock the item you are carrying out of your hands. It also moves items in the background, but not the chalice or the micro dot. But it will move dragons, which it will occasionally drop into the room you are in.
I've also added levels. This just makes the dragons faster and increases the frequency of the bat's annoying activities just described.
As usual, I've also found some speedups. Reworked the declaration of the variables, killed some dead code from the earlier variations. Removed repetitious actions between interacting subroutines. That kind of thing. Always amazes how many of these things show up even when I feel I have sifted the code so thoroughly there couldn't possibly be a more efficient way of getting things done.
Just can't catch a break in this one. Lost my sword and just keep running into bats and dragons. I have added random "Bat" movement of items off screen. Sifted the code for speedups, including renumbering by increment of 1. Added instructions. Here are the instructions:
Also added a T-pattern for the keys-- IJKL. My son Charlie likes the T, and he's my beta tester, so he gets the T. Found a neat graphic online that I tweaked. Might use it as a new online avatar now that I am into my 50s.
Hope to get a peek at everyone else's RetroChallenge projects shortly. Been working intensely on Adventure, but now I should have some time. I can just glide into the final stretch with some game testing and combat tweaking. I might add some levels to the game. Perhaps the amount of bat background item moving, bat speed and the speed of the dragons (movement and length of time between mouth-open-mouth-closed cycling) can be adjusted.
Got combat with the dragons working, although there is an error that appears near the end of the following video because the Red Dragon conflicts with the characters for the Red Castle. That dragon is now blue (as in blue streak). It's the fastest!
The Bat also works (I think). It will steal your item if it touches you and then fly off. The item will be randomly redistributed somewhere in the maze, but not inside any castles. so you can get it again. The bat will also then relocate. Fixed up the win routine a little as well.
I think all I have left is cleaning and speeding up. Possibly some refinement to the speed and behaviour of the dragons and the sound. Maybe some simple instructions if I can cram them in (I'm down to only 1000 bytes or less). Any suggestions are welcome.
I have worked out most of the kinks in all the moving objects routines and have a simple win routine. I have added a routine to distribute the objects randomly at the start of the game. The only hurdles left are dragon combat and bat object snatching. Think these routines should be relatively easy to implement.
In the video above I search first for the "micro dot." I must use the bridge "H" to gain entrance to the secret room in the Red Castle (my replacement for the "Black Castle"). When the dot is dropped in Room 4 access is granted to the secret room with my version of the easter egg. Then I continue searching for the chalice "X" which I take and drop in the Yellow Castle. This wins the game.
I'm going to have to make some decisions about combat with the dragon. I have two main options I am considering. (1) When you have the sword Dragons run from you and try to escape the room. So you will have to be quick and stab them before they leave. But if you don't have the sword, then they chance you and you have to be quick to escape the room before they touch you.
(2) Dragon has a mouth open phase and a mouth closed phase, it always tracks you, not matter what. So you must be quick in getting hits in while it is in mouth the closed phase.
In either case, I'm not sure how many hits will kill either you or the dragon. I'm thinking of starting with 3 strike and either is out (versus the original's 1 hit kills). I will have some ability to have different speeds for the dragons, but I'm unsure whether higher speeds will disadvantage the player too much, so I might just go with one speed. I could also have more than 3 dragons if the game requires higher challenge. We'll just have to see which of all these variables works best. There will only be one dragon or bat in a room at a time.
Got some item movement mechanics working for the TRS-80 MC-10 version of Atari Adventure in BASIC. Dragon is moving a little faster too. The drawbridge goes up now
Had to make some compromises in my graphic design for items for the sake of speed. Still worried about the combat and whether I can make it challenging but not arbitrary. If that can be done, then I'll move on to also using the dragon routine as the basis for bat movement. Probably will have to limit things to one monster per room at a time as a concession to the limits of BASIC. Then it's just a question of creating routines to distribute items and monsters and detect the winning conditions. I'm pretty confident now I can get a functioning game of some sort completed by the end of the month. It's now just a question whether it will be mildly interesting (about the best you can hope for any BASIC game), or a functioning dud.
Worked up some simple graphics for a kind of a dragon that will track the player. Not sure if it is fast enough to be challenging or how exactly to work out combat. I have a version of my duck-dog-dragon with its mouth open, so I will probably have it cycle between mouth open mouth close. You'll have to get your attacks in while its mouth is closed. Here are some of the other graphics possibilities I have been working on:
Starting to run into some of those barriers of speed that I mentioned last post. I uncertain at this point whether BASIC will allow me to move the program to a point that it represents an actual game. It might simply end up an interesting demo of some aspects of Atari Adventure. But, if I had a Basic compiler...;)
I've completed a routine to render the partial sight of the catacombs in Atari Adventure.
I've been watching videos of game play. Hadn't realized that some of the screens allowed only a partial "torchlight" view around the main avatar. Had to shift the map routine from straight printing of the current room, to assigning those strings to a 0-15 string array. Then I could just use MID$ to print a 5 X 5 selection of those strings around the main character. Seems to work. It has a little flicker, because I have to use CLS0 continually to erase the previous draw, but I notice that the original has a little flicker too.
Next steps will be tougher I think. I need to create routines for moving dragons and the bat around the world, even when they are not on screen, but to display them when they are in the room as the player. They'll also after to track the character in interesting ways like in the original. Here's a neat video where the Robinette (the author of the original) outlines some of his unique approaches to managing the behaviour of objects and beings in the world:
I don't know if I'll be able to recreate in BASIC all the complexity he describes without slowing player movement down to an unacceptable level. I might have to make some compromises. Perhaps more but slightly less interesting dragons (I'm thinking up to 8--one for each colour). Same for the bat. It might have to be swapped for a less dynamic random re-shuffler of objects routine, with a little stock animation. We'll see what's possible.
This kind of uncertainty is part of the charm of retro-programming in BASIC. You just never know if something is going to be possible--like the partial torch view. Feels great when you do succeed. But then again, even if you don't, this just provides a challenge for having to work creatively within the limits of BASIC. Coming up with a reasonable BASIC alternative to a faster more complex M/L routine can be lots of fun too and equally rewarding. Or sometimes not, and then one must simply learn to accept that the fun of an adventure can be simply the quest itself. How Vedantic... your have a right to your labours, not the fruit of your labours Arjuna!
I've added color and some mechanics for entering and existing castles.
Keys next and then combat and bat stealing and moving stuff, items (randomly placed), bridge for going through walls and the microdot to unlock the secret easter egg. I'm thinking I will use something of the mechanic of the Fyrdracas (or whatever they're called) in my Dig Dug game for the Dragon attack in Adventure:
Instead of the original's mouth-open mouth-closed cycle, my dragons will occasionally breath fire at the character. You'll have to get your attacks in between those attacks. The Bat will simply fly in, and unless you can exit the screen quickly enough, it will hit you and fly off with any item you have and drop it somewhere randomly in the dungeon.
I think I will not have levels in my version. Instead, all items and monsters will start in random locations. Except maybe the key to the yellow castle, which will start somewhere close to the yellow castle. My sound and music will be pretty primitive, unless I can convince my son Charlie to send some help from his his home at Dalhousie university.
Jerry Young on the MC-10 Facebook group page (I think, or maybe on the Yahoo group) suggested a while back that Atari's Adventure would be a great project for recreating on the MC-10 in BASIC because of the simplicity of its graphics and gameplay. His suggestion has been in the back of mind ever since, so I decided to try to get a variation working for this Autumn's RetroChallenge. I have the maps worked up and tested (somewhat). No combat or items yet. I will be posting updates here throughout the month. I'm hoping Jerry might be willing to come in on the project as a expert consultant on the Atari 2600 console and the game play of the original.
While wandering the net I found a post on Bjars.com and AtariAge about a game called Indenture, which is a DOS based Adventure game written by Craig Pell in 1995-1996 based on Adventure. The nice thing I noticed was that Pell had turned all the maps of the original into ASCII text listings in his source code. Looked a bit weird when I loaded it up into Wordpad:
Transferring it to Notepad and saving it as pure ASCII text cleaned it up. The rooms were formatted for an 40 column screen so I had to do some narrowing. Most of the vertical walls were two characters thick, so I just had to cut these in half. If I could do that 8 times I had a screen that would now fit on the MC-10. Then I just had to make sure that screens that attached were thinned in a similar way so that all connecting passages lined up.
The source I borrowed from contained many additional rooms. Had to do some research to find out what rooms were needed for the original game. There are only 0-31, as far as I can determine, including the famous "easter egg" screen (and an apparently unused room 21). Then I had to compress the images by replacing common strings with variables. This brought the size of the program down quite a bit.
I should have lots of space now for adding some combat routines. Not sure if I will slavishly follow the original, or try something a little different for combat. I'm thinking some kind of arrow shooting routine might be nice, rather than the simple sword thrust. The graphics for the characters will also probably be a little chunkier, but we'll see. At one point in the past I was thinking of these:
But with the maps I have, I think these images will be too large to be workable, but we'll see. I might just use something like these for the dragons and the bat (and sword or key):
I think I will use a simple block for the main character and possibly some ASCII text characters for items, such as a "Y" for the chalice. Not sure how I am going to handle the bridge or the "micro dot" that unlocks the easter egg. So much to be done, such as adding color to the maps. Here's a vid of some simple testing of the maps:
I decided to enter the AdventureJam 2018 contest. The challenge was to create an interactive fiction game in just two weeks. Just? I didn't think it would be a problem to come up with an original two-word parser game in that time.
And I was right. It took me less than a few evenings and a weekend. The toughest part was coming up with a story. I have been very disturbed by the development of pipelines from the Tar Sands to transport bitumen to world markets. For example, I recently wrote a letter to Minster of Finance Bill Morneau against pipeline development. I'd also read about anti-pipeline protesters who sabotaged pumping stations. These protesters had claimed they had carefully researched how to shut down the pipelines that they tampered with. This struck me as an interesting premise. How could they be sure that they knew what they were doing? They would have to have obtained documents to explain how to operate the equipment. I thought that could serve as a central premise to some adventure.
I was also thinking it would be neat to incorporate an element of decision by the player to contribute to the protests or remain a bystander, since this was what I was doing by simply sitting at home writing letters to government ministers. A response acknowledging receipt of my letter from Minster Morneau arrived on the same day that he went on TV to announce that the Federal government was going to indemnify Kinder Morgan while the challenges to its pipeline were ongoing. It was like he was flipping me the finger personally.
So I created a little fantasy called Kinder Morgan to try to highlight the importance of the issue and the critical moment in history we are living through. My son Charlie had helped me write and mail the letter to minister Morneau while he was home on Spring Break, so I suppose I was also thinking of the game as kind of a teaching moment for him. I hope he will join the political struggle for the future and move beyond mere clicktivism. It was truly a child's morning when I walked to the mailbox with him after our protracted political discussion and writing session.
He graciously agreed to to play test the game. He discovered a bug/quirk. He realized that he could easily use the game save feature to simply restart and try different responses to the final puzzle, until he got the right answer. So I made the program notice whether you had made multiple failed attempts, or had actually figured out the clues to allow you to choose right on the last puzzle. It only gives a fully positive win message and musical fanfare if you solve the puzzle on the first try. My wife also noticed a spelling error on the win screen when reading my sons's text with the image attached showing he'd solved the game. Thanks to both of them for their contributions.
A few years back I stumbled across some screenshots of a game for the NEC PC6001 called Nostromo. Since the name of the spaceship from the movie Alien was "Nostromo" it seemed likely it was based roughly on that movie franchise. The goal of the game is to foray into a series of hallways and raid 8 lockers/rooms to retrieve various items while the alien hunts you down. I didn't have a fully operating emulator for the PC6001 back then so pretty much all I had to go by was an animated gift:
Based on that gif I came up with the following rendition of the game. I found the 8 box layout a little boring, so I added a little variety. So I alternated a second style of map. Since I didn't have a clue about the scoring or what the second number meant of the two number at the top left of the screen, I just had the player hit a key when she returned to base in the red area to signal that she was finished collecting.
Fast forward to today and Robert Allen Murphey on the Coco Facebook group mentioned that he was going to take a stab at playing my port. But he used a Japanese title for the game "Uchuu Yusousen Nostromo," which means "Space Freighter Nostromo." These additional words gave me some additional terms to search for to find out more about the game. I also had been able to get a working PC6001 emulator in the meantime, so I was able to download the game rom image load it up and extract the Basic source code. Although the game is credited to Akira Takiguchi and Masakuni Mitsuhashi on many sites, I noticed that the Basic source code had a set of remarks at the top indicating it was copyrighted by Hiromi Ohba. Here's the link to the original website I found that gave me access to the source code:http://seesaawiki.jp/chitentai/d/PC-6... Although I was able to load the game into an emulator by James "the Animal" Tamer called "VTrek" (for virtual NEC Trek--the name of the version of the computer unsuccessfully distributed by NEC in North America) either bugs in the emulator or differences between the NEC Trek and the PC-6001 wouldn't allow me to run the game. So I had to rely on a video in which a Russian vlogger, Panteryasha, does a walkthrough/review of the game:https://youtu.be/xUDRF9JGlfk
Later my son Charlie used some of his computer voodoo skills to download the subtitles of the video and translate them into English, which was really helpful. For one thing, Panteryasha noticed a bug that occurs in higher levels where you are required to collect 7 of each item, but the algorithm that randomly creates the layout of the items in the rooms/boxes (versus blank spaces and purple barriers) can only guarantee a maximum of 6 items for each item type. So you could end up with a screen that it was impossible to clear. However, unlike Panteryasha, I was able to see in the code that there was a possible out. You could let yourself be killed and then hit the "h" key and the screen would be re-drawn with new resources and a time penalty. I changed the 'h' key to "H" and instead of a time penalty I made it so that you lost any points you had accumulated on that screen.
This feature is not just useful for higher levels. Even on lower levels, if you are killed while carrying a load of items, you must then go back out and get at least enough new items for one of the item categories to push your number over the number required for that screen (the second number at the top left). Unless you reach that number the computer will not register that you have collected any items or give you a score for them when you return to the red home base. However, if you have collected all the items on the screen before returning to your base and are killed, then you will not be able to have those items scored so you can complete the screen. I suspect the programmer added the "H/Help" restart feature to allow you to sacrifice a life in order to continue. The moral of the story is that you must get back to the red base area with at least one category of items at the target number if collected items are to be registered for scoring purposes.
I also replaced with pure Basic all the machine language calls and code in the original that handled player and monster movement. The NEC PC6001's Basic was a little slow, so I suspect that the programmers had to use machine code routines to get speed for the player and monster movement. Luckily the programmer used Basic for all the scoring and screen transitions. I did use a M/L Timer USR function provided by Darren/Mechacoco to handle the countdown timer part of the game, so it should portray accurate seconds. Thanks Darren! And thanks Charlie for translating the comments of the Russian reviewer for me. Here's what I came up with:
The sound routines were still petty rough. It took me a while to figure out some of the quirks of how the NEC's SOUND and PLAY commands work. Turns out some of the SOUND commands are just meant to reset the sound chip in various ways and not actually produce noises, so some of the sounds I thought were in the program were not really supposed to be there. I thought I had got a pretty good bug-free version when I noticed a really bad bug. I had never tried shooting at the outside white wall when I was play testing because I knew shooting was for the rooms in the interior, so I didn't notice that you could shoot the exterior wall and escape the screen and have your character POKE into memory areas where you shouldn't be allowed to go. I also added a saved high score feature. This necessitated re-working the main loop a little. Because the original program would simply re-RUN the whole program every time you lost, the programmer didn't care about properly RETURNing from the various main subroutines or resetting variables to zeros, etc. But since I wanted to save the high score from game to game I had to fix these problems. I also noticed that the nearest item type was worth more points (25) than the farthest (10), which seemed odd. I reversed this order so that risking a longer journey to the left of the screen would be rewarded with higher points. I also changed the original T key layout to be further right on the keyboard, which was more comfortable. And I reduced the time allotted for each screen, as the original amounts seemed excessive:
It has been a long journey getting to a working rendition of this apparently classic Japanese early 8-bit game. It's even, if Panteryasha is correct, considered one of the first examples of a horror game. This is apparently a result of the cut scenes with the monster and the higher levels when the monster flicks in and out of view, which is kind of creepy and a bit suspenseful. Still, I wonder whether it is true that is the first horror game. I'm aware of at least one game "Alien" for the ZX81 that has similar features, also based on the Alien movie, which might possibly be as early:
Both programs are dated to 1982 by various sources on the Net. I'll let retro-gaming archaeologists figure this out. In the meantime, I hope some folks might have some fun playing the MC-10 versions of these classic games. If you are interested you can now download all my games and the VMC10 emulator by James "the Animal" Tamer from my GameJolt site: https://gamejolt.com/games/jgmc-10games/339292. There are some instructions there that will help you get whatever program you are interested in running. Here's a link to a full list of my games: https://jggames.github.io/Type-in-Mania.html. My most recent version of Nostromo is called "NOSTRO.C10". The older version is called "NOSTROMO.C10". I have left it there for historical purposes, but I really recommend playing the newer version.
Addendum:
I finally uncovered a mystery I had been pondering regarding the counting of items in the original code. I had not fully decoded the inventory logic of the original source and with the substantive changes I made re-coding key key input and movement, I think I obliterated a 5 item carry limit in the original game. I had always wondered why my version seemed much easier than the original seemed in videos I had watched. But that was because I could just venture out of the safe zone and collect items at will from any and all the rooms. This meant that there was no need for path planning and item accounting as you snuck around the hallways avoiding the monster and no need to make multiple return trips to the safe room to deposit those items when the item limit was reached. It drastically changed the time needed in the time-trial intermediate challenges. The multiple return trips really require careful decisions about what to grab and where for best effect. Now that I've fixed my mistake there is actually a challenge getting all the required items within the time limit. In my original version, you just went around gobbling up all items in an indiscriminate and returning to the safe zone, mostly with plenty of time left. I have to thank the following blogger to tipping me off:
He also discusses Manbiki Shounen and shows a very interesting version of it being played that I have never seen before. There are so many versions out there. It's nice to see others exploring these classic and influential BASIC games.
Since I was viewing his video I decided to revisit some other playthrough videos. As I watched them, I noted that there was also another aspect of movement logic that I had failed to implement accurately. I hadn't noticed it but the gun (or whatever it is the player shoots with) only seemed to work on the outside of the walls to the rooms with the items. In other words, you could use that weapon to break into rooms, but not out. In my version you could just shoot into a room and out the other side, effectively "mouse holing" your way around and avoiding the main halls and the monster. Again, this made things easier than the original.
I began to look for other things I might have missed. And I noticed two more. First, I didn't zero the items you were carrying (contrary to what I say in my original post) if you got caught and presumably slaughtered by the alien. I didn't "see this" in the video playthroughs as much as remember reading about it when doing my original research into the game. There is a feature that you can hit H when killed (when the screen goes to the organ alternate colour palette for a brief time after you get caught. Then the screen will refresh with a complete supply of items in the room again, but it will cost you a life. I remembered reading that people had to use this only some of the higher levels because the random populating of items sometimes wouldn't supply the 7 items that your were required to retrieve on those levels. So I had changed the max item you could be asked to get as the levels went up to 6. There will always be at least 6 items from the room item populating algorithm. But I recalled surmising that the feature was also needed sometimes if you simply got killed while carrying a lot of items.
The second thing I noticed as I watched the playthroughs again was that it seemed to take 3 shots to break through the walls. My routine only required two shots. So I upped to to 3. Again, something that might make mine a little easier. Given all these changes I also had to return the time limits to their original 100 second and 300 second amount, which I had brought down in my version because it runs faster and was easier. Now you need all that time to do the extra maneuvering that was required in the original and the time limits really do loom as a threat. So now the game mimic more accurately the challenge of the original and maybe even adds some challenge because I think my version runs faster despite being all BASIC and not really on some M/L routines for key input and player movement.
In the following playthrough I make it to the stage, often missed by commentators, that really demonstrates the suspense and horror aspects of the game. At higher levels the alien appears and disappear at random while moving, creating a creepy suspenseful atmosphere conducive to jump scares. These levels are preceded by a graphic image of the baby alien (around 10:02 in the video), which is a reference to the scene when the alien first appears from the stomach of one of the characters in the movie Alien and then disappears into the bowels of the ship...
The Matra-Hachette Alice was a home computer sold in France starting in 1983. It was a clone of the TRS-80 MC-10 produced through a collaboration between Matra and Tandy. The Alice was distinguished from the MC-10 by its red case.
Unlike the MC-10, the Alice became a fairly popular computer and Matra later released two successor models with much improved graphics and a built-in assembler. The Alice 32, released in 1984, shared the case of the original, but was a different computer inside with the EF9345 video chip in place of the MC-10's Motorola MC6847. It had 16K memory as standard. The Alice 90, released in 1985, featured 32K and a full-size keyboard.
Because of the introduction of the EF9345 not much of the Basic software for the Alice will work with the MC-10. The EF9345 is capable of 40 and 80 column text and most of the software you can find on the Net uses one of these modes. However, a few programs still use the 32 character mode. In order to maintain some backwards compatibility, Matra made a special screen using the 40 X 24 screen with a 32 X 16 window positioned in the middle and a black border around it consisting of the unused rows and columns. This means that you can still gain access to the columns and rows around the 32 X 16 screen through the use of PEEKS and POKES. I found a Basic game for the Alice that uses this 32 X 16 mode (mostly) with only a few hires embellishments and a few screens that use 80 column mode directly: The Sphinx d'Or.
As you can see from its intro screen (with the pyramid--not the Sphinx), there is a colourful banner around the standard semigraphics screen. There are also some hires embellishments to the standard semigraphics block graphics of the MC6487. The sides of the pyramid have been smoothed, and in the second picture there are some rays that have been added to the sun.
But besides little details like these, it is essentially a Basic graphic text adventure that uses mostly standard SET/RESET block graphics. Of course, it is in French, but with the help of my son Charlie, who was home from Dalhousie University and a graduate of late French immersion for grades 6-9 here in Sydney, and Google translate, it wasn't long before we had English versions of all the text messages. Thanks Charlie (there's an Easter egg in the code in honour of you)!
Then I just had to convert a few of the screens that used the 80 column mode. Also, the original program from the Alice was split in two parts and had a multiple- loading process for different parts of the story. I think this was because the Alice 32 only has 16K RAM (and a 16K ROM--hence the name Alice 32). But I was able to combine both programs into one that fits entirely in a 20K MC-10 (4K + 16K RAM pack) by using the RENUM command that comes with MCX Basic. The first part of the program had the starting screens and also the final game completion puzzles and win routine. A value was POKED into memory that was preserved between loadings that re-directed program execution to the intro or completion routines depending. So you had to load the game, then load the second part, and then re-load the first part to complete the game. There is a version of the Master Mind game in the completion routine that used the 80 column screen and graphics. I was able to create new semi-graphic images for this and all the other aspects that used hires. The only hires thing I couldn't recreate was that fancy permanent woven banner around the screen. But you can't have everything. But, banner aside, we now at least have a new piece of software for the MC-10 compliments of the French. Merci beaucoup citoyens du france et Monsieur Schwartz!
I still have to solve all the riddles of the adventure, but I have tested most of the individual parts of the game. When I'm confident that it is bug free I'll post about in the Interactive Fiction Database, etc. and see if I can find some volunteers willing to try to solve the game and test it more fully.
Original tape cassette box art
I also have completed some minor projects such as adding James Diffendaffer's speed-up POKE to a bunch of my existing arcade games and Darren's Atkinson's (Mechacoco's) keypoll routine that allows multiple keys being pressed at the same time on the keyboard to be registered at the same time. This allowed me to create a version of Tandy's two player Pong game that does't allow the other player to block your key input by holding down his keys. This represents true two-player arcade action coming to the MC-10 for the first time.
Here is a partial list of my activities over the last several months that I have been wanting to blog about:
STORM an original game using Semigraphics 6 mode.
ALATTACK is original game for the 10 Liner Basic Contest. Roughly based on game "Alien Attack" by Scott McCann and Peter Lear.
RACEDRIV is a port of some obscure code from a Dragon 32 Magazine I found on the net. Taken from a page scan.
ALERT10 is an original game that tries to recreate a Defender style game in 10 Lines of Basic code. Little slow in starting up, as it has to build the scrolling map, but interesting once it gets going.
MAZERACE was also for the 10 Liner contest. Mechcoco moded it with some machine code to draw the maze in a blink of an eye! Not a legitimate entry for the contest but still amazing; literally! Thanks Darren!
TEMPEST is a port of a Coco game created by Carangil for the 10-Liner contest. It requires the hires commands of the MCX pack.
C-TREK is a port from a Coco Version of the Classic Star trek game. I have about a half a dozen different variations of this type of game now for the MC-10. I added a little text graphic of the "Enterprise" to the title screen.
VAMPIRE is a text adventure from Australia, originally for the TRS-80 or possibly one of the other TRS-80-like clones. I took my source from the Commodore 64 version though (if I recall correctly).
Robert Moore posted on the Coco Facebook page asking whether there were any other "Stellar Empires" addicts out there. This prompted me to look this game up. STELLEMP is a port from the Coco variation, although I started using TRS-80 Model 1 source code that lacked an AI computer player. It's another variation on the space-trading-empire-building genre. This one has lots of combat and up to 4 can play. I have converted a number of similar games to MC-10, including what is likely the original of the genre, "Star Traders" by Dave Kaufman, and "Andromeda Conquest" by Avalon Hill.
Star Traders
Andromeda Conquest
Stellar Empires
I think this is likely my last post for the RetroChallenge month. To sum up: I was able to finish working on my MC-Chase game for the MC-10 and then convert it to Coco Basic in time for Coco Fest. And I did the same for Dig Dug. I also accomplished some bug testing of my port of Bruce Moore's "Forest of Doom" Coco hit. I'm pretty confident that version is bug free too. And I have a working version of the Golden Sphinx ported from the Matra Alice.
I send thanks to all the other RetroChallengers. I've been a very busy at work this month so I have had little time for looking at everyone else's projects, but I look forward to browsing them over the coming months. And thanks to John Lineville for running the contest.
In honour of CocoFest. MC-Chase! And a contest. Get your name on the splash screen by deciphering the secret mystery message!
10005 ' IF YOU CAN MAKE IT 10006 ' THROUGH 6 SCREENS AND 10007 ' DECIPHER THE SECRET 10008 ' MYSTERY MESSAGE OF 10009 ' MAP 3, AND CAPTURE IT 10010 ' SEND THE IMAGE TO 10020 ' JIMGERRIE@NS.SYMPATICO.CA 10030 ' AND YOUR NAME WILL 10040 ' APPEAR ON THE OPENING 10050 ' SCREEN OF THE OFFICIAL 10060 ' VERSION OF THE GAME! 10070 ' WIN ETERNAL COCO GLORY!
I got a coco version working just in time for the Friday night start of CocoFest. In the course of completing it I was able to sniff out a few bugs in the later two maps. Hopefully got them all, but I'll have to wait till I have some more free time next week to do some through play testing. In my haste, to post the Coco version, I let a bug slip past. It involved the routine for managing the coloured sections of the walls. You can see in this video, when I move towards the end of the long side wall. The end section remain the same color as I move towards it:
I also had a spelling mistake in the REM instructions for the contest. See if you can spot it (watch both videos)! 3DMCHASE.BAS can be found on JGGAMES12.DSK in my zip distro of my Coco BASIC games.
Not sure if anyone will even take notice of my challenge at Cocofest. It's difficult trying to participate from a distance. And I don't have the promotional flair of Bruce Moore. But I hope someone might eventually take up my challenge. The trick is to get to the third map and then examine the maze structure for a secret mystery message. Tell me what the message says and show a picture or video of the screen, and send an e-mail to jimgerrie@ns.sympatico.ca and you will get you name on the splash screen in the official version of the game, eventually to be uploaded to the Coco Archive. The winner will be the person with the earliest e-mail time stamp.
Also made a coco version of DigDug and included on JGGAMES12.DSK. The semi-graphic design was by Carlos Comcho, and he also contributed the intro theme song based on the original game. My son Charlie (just home from Dalhousie University), contributed the fanfare when you complete screens. A real cooperative effort. Thanks fellas.
And greetings to all the Cocoers at CocoFest 2018! Have a great time. Wish I was there!
P.S. My son Charlie came home from University and helped me with testing both games. More certain now that the MC-10 versions are clear of bugs. Thanks Charlie. However, when we looked at my sister's old Coco2 (which lives in his bedroom), it turns out it had been left on for who knows how long, and I think some of its ICS got cooked, so no way to test the games on a real Coco2. Will have to swap out the Coco 2 for a Coco 3 and see if I can get the games running on it. Will let you know.
I've been working on speeding up the wall rendering part of the program and a few other speedups. Renumbered the code at one line increments, because that can also help a little with speed, as the main routines are at the top of the program and switch them from 3 digit line numbers to 2 means one less digit to interpret for GOTO and GOSUBs. You be the judge if you can discern any speed increase from prior versions (maybe turn the music off, as my choices might influence your perceptions:). Here's the latest:
And the prior version (demonstrating the multiple screens):
Also been testing the 3 new screens I added. I have yet to play three three whole maps to get to the next map. Will have to do a full playthrough without tricks to make absolutely sure everything works. Right now you get a new map after completing the prior map 3 times. The third map/maze has a secret message, which you will be able to see if you get to it, or if you can read the code very carefully. But I think it will be hard to discern using the code reading method. Maybe this will entice someone to try to get to the third screen (i.e. nine successful clearings of the mazes). I won't, however, be offering an MC-10 mug for the first person who does and deciphers the message. But maybe someone out there who might be willing to put up a piece of MC-10 swag to encourage some friendly competition. Who knows...
My plan is still to port the code to Coco. Hopefully with the speedup poke it will be even faster. I'll wait until I've got all the bugs out of the MC-10 version before doing the conversion, as its annoying to then discover bugs and fixes and have to work on both versions simultaneously. I might also try to convert my DigDug program too, if I can find the time. I've been very busy with marking, as it is end of term at the University and I did an overload course. Still, Basic coding is a nice way to wind down after a day of marking exams and papers. Ah the joys of pure logic!
I've added two maps to the game. You get a new map every 3 completions of a map. The third map contains a "secret message." The maps are saved as DATA statement lines. Since the speedup routine by James Diffendaffer also uses DATA statements, I had to create a routine to restart at the first map DATA statement after you lose your last man. Pippa's POKE/PEEK routine for doing a RESTORE to a specific POINT in the DATA statements was helpful in accomplishing this: 1 GOSUB8:PRINTJ:GOSUB9:GOTO1
8 OD=PEEK(173)+256*PEEK(174):READJ:RETURN
9 POKE174,INT(OD/256):POKE173,OD-256*PEEK(174):RETURN
10 DATA 1
Her routine effectively provides the same ability that other Basics have of including a specific line number with the RESTORE command to have data reading begin at that line. In fact, it is even more flexible because it allows you to choose which specific data item to restore READing to once you repoke the saved value (in the example above OD is used to restore the memory address located by the PEEKs done at line 8).
My plan is to convert the game to Coco after I've got all the bugs out. I'll then release both versions during Cocofest. I won't need Pippa's routine for the Coco version because I won't be using Diffendaffer's speedup M/L routine. Instead, I'll include a routine giving the option to use the standard Coco 2 or 3 (or Dragon) high speed POKES.
