Tuesday, 9 January 2018

Underground Adventure (Duckworth)

Nearer Turn Bear
| | |
100ft Drop Bricked Around Gate Mix Large
| | | | | |
Vast Chasm Heart Deep Wall Entrance E/W Tree Twisty Old
| | | (Rope)
Rock Jumble Chasm Rock Cave Chasm
Sharp Twist Main
| |
West Mine Offshoot Choice Long Drop Twist E/W Dead End
| (Axe) \ | (Parchment) (Dynamite)
Panther Bottom Twisty

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

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

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

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

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

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

Here's a vid:

Tuesday, 7 November 2017

Dave Kaufman's "Star Trader"

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

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

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

Apparently the game originally appeared in the People's Computer Company (PCC) newsletter (later magazine) and latter in a book compilation What to Do After You Hit Return. I was able to get a PDF from the Net of the book, and sure enough when I looked at the DATA statements for the "econometric" data, it was different from the data listed in the on-line source code from the Trade Wars tribute site. Swapping in the data from the scan seemed to solve the problem--a fun little piece of retro-programming archaeology! I don't know why the values were changed (transcription error from the scan, weird considerations of a networked version?), but now there is a working version of the program for people out there to try. It includes a save to cassette tape feature, as opposed to (possibly) save to tape reel or paper tape. Here's a vid:
Rogers Cadenhead, one of the many commentator's on the Star Trader and its influence, discussed its history with David Ahl to get his perspective on the game. The following is a quote of Ahl's response:
As far as I know, the game Star Traders originally appeared in People's Computer Company (a newspaper/magazine) published by P.C.C. (an alternative education computer center) in Menlo Park, CA. (It's a bit confusing that the physical storefront computer center and the newspaper both had the same name.) The game also appeared in What to Do After You Hit Return subtitled "PCC's first book of computer games." PCC was a rather egalitarian organization, hence credit was only rarely given to the authors of the various games they published and there is no author credit affixed to Star Traders. So it could have been written by any one of the 40-50 people cited in the acknowledgements of the book. The game, written in "standard" HP Basic, is a monster and, unusual for the time (1973) has both a set-up module and a main playing module. Also unusual for the time, it had the capability of saving the playing data (1) from one session to the next and (2) for different users who logged onto other nodes of the timesharing system. It was this that allowed it to be a multi-player game with games often lasting a matter of weeks or months. The book had some interesting suggestions and ideas for extending and modifying the game to make it more interesting and longer lasting; I believe that over the years many (or most) of these have been implemented.
I can understand how on a timesharing system you could easily have rigged up an ad-hoc way to make the game one of the first multiplayer net-based games (tape reels or paper taps must have been replaced by electronic files at some point). You can save all the main game variables at the end of any round of trading at the prompt for picking your next planet to visit (i.e at the end of your turn). Early players could have organized games with other players on a system. All you would have to do is send the game data file to the other players or save it in publicly open file space. Then the next player could load the data file and continue with their turn and then re-save and so on for each player (it can handle up to 12). The only problem is that in the version of the code as I found it, when you re-load the data, the first thing the program asks for is the choice of next planet for the last player, since that player would have typed 'save' at the prompt instead of their choice. Either people modified the game so each player could enter the choice before saving the game data, or ad hoc solutions were worked out, such as sending a message mentioning one's desired choice to the next player. In fact simply sending a message with a planet name might have been the way players let other players know the file was available and it was their turn. Then they could simply enter it and continue with their own turn.

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

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

Sunday, 29 October 2017

RetroChallenge 2017/10: Gotcha

Okay, I didn't think I would have time for anything else for this month's RetroChallenge, but there was lots of curling going on this weekend, which my wife follows with a passion, so I found myself idly coding away while listening to the Masters (the TV's in our den). What I came up with was a program inspired by a real old game. I'm all the way back into the 1970s now scraping the bottom of the barrel for ideas. The game is called Gotcha. It's one of Atari's first video games. Apparently it wasn't all that popular. The original was two player.  Each player took turns chasing the other. This theme is reflected in its somewhat risque promotional material:
Don't know what's going on there.  In any case, the game mechanic involves a continuously changing maze. The logic of the mechanic of the change is difficult to discern, but I thought I might be able to recreate it, at least to some extent, on the MC-10:
Apparently the original game cabinet used some "breast" shaped cups as controllers.  After complaints Atari changed them to standard joysticks. Seems like a pretty blatant attempt at using sex to market a game to teenage boys, but it wasn't enough to overcome the mediocrity of the game.  It was no Pong. Here's another video of the original, but just the game play:
I changed the game to be single player. You move your cursor to collect coloured dots randomly placed on playing field. You have to avoid running into walls, or, because the walls are continuously redrawn, having the walls run into you.  There is a time limit, so you have to try to move fast.  Dots will move if you don't get them in time.They can also sometimes become enclosed by the walls of the changing maze.  Here is a video of what I managed to come up with.  I have tweaked it a little since making this video.  Now the changing walls can't erase the target dots.  I also have tried a technique of using a period to replace zero numeric constant in the draw statements, which I recall someone saying can make MS Basic run a little faster.  Not sure if it is true, but it doesn't seem any slower either.
So that definitely wraps it up for me for this Autumn' RetroChallenge.  Thanks to John again for organizing and to all the other participants for sharing their retrocomputing hobby.  I look forward to seeing what you folks get up to next year.

Sunday, 22 October 2017

RetroChallenge 2017/10: Dante's Run

This is a weird one. The inspiration for this new game came from a game for the Sinclair ZX81. I was watching a playthrough by Villordsutch of a game called TAI.  It is a Star Wars themed game.  You start by flying a ship through a tunnel in an asteroid. Except this tunnel is not filled with strange space creatures who might inhabit the insides a giant space worm living in the heart of an asteroid.  No, there is a giant skull with stacks of smaller skulls piled on top of it like some kind of Indiana Jones lost temple.  And that's not all.  The temple is protected by "ghost guards."  My first impression was that the game was creepy-temple-themed, but when you get through the cavern you switch to another screen in which you are the Millennium Falcon. A Tai fighter maneuvers around you and you must shoot it out of the sky/space. The mixture of motifs is very weird.
The creepy cavern of the skulls was certainly inspiring. I thought I could achieve the effect of flying upward through a maze using a string array and then just adjusting the pointer variable so you  see a window of the current 15 lines on screen. This way the ship could fly up "towards" the top of the screen instead of the more standard scrolling effect used in basic games that takes advantage of the automatic screen scroll that occurs when you print a line at the bottom of the screen. It turned out pretty well and is relatively speedy.  Now I have completed a Basic game that scrolls up to go along with my games that scroll right, such as Raider, and scroll down, such as my game Boarder (I'm not sure if I'm using the terms up/down left/right correctly--does the window scroll or the information being viewed by it?--I'll let you figure it out).

I thought I would try to create an even more creepy cavern effect. It's nearly Halloween, so I thought skulls and stuff would be neat. I decided as well to do it in the SG6 mode. This means the walls could be made out of the creepy neon mucus green solid character. The ship uses two other characters from the mostly useless lower 128 character set, which are really just random line patterns that represent bit numbers because no external character generator is wired to the MC6847 on the MC10. I chose a block character with two lines on each side for the base of the ship, and a narrow centred line for the "point" of the ship's nose.  The nose part is resilient (i.e. collision detection is only on the base section). 

As the game progressed I realized it was really a descent into hell theme I was developing with the extra graphics I was adding.  I also needed a "goal" stage to replace the Tai fighter-Millennium Falcon stage in the Sinclair game.  I decided to name the game "Dante's Run" and to make the transition stage a showdown with Beelzebub himself. I have been thinking for while I wanted to do a game where you have to shoot through counter rotating shields in order to try to hit the mother ship.  This is that motif, but with the Dark Lord as target. You have a limited time to break through the two fire shields and score a hit on Satan.  If you run out of time before you do, you start back in the cavern.  If you succeed, you score 2000 extra points and you get an extra life.  Your life is measured by the length of your laser when you shoot. You start with 5 lives. You lose a life when you hit one of the dark green guardian specters.  You die automatically if you hit any walls.  Your goal in the cavern is to collect the blue "purgatorial souls." You get 100 points for each one.  When you collect 1000 points you trigger the intermediate stage with Satan.  Shooting the specters can help get them out of your way, but it doesn't score you any points.  Just be careful not to shoot any of the purgatorial souls.  Doing so wont lose you any points,but it might upset the big guy upstairs!  Here's a vid:
I don't know if I'll have any time to do more stuff for RetroChallenge this month. It's mid-term time for me and the term will be heating up a bit for a while.  If I don't get the chance, I wish all my fellow contestants good luck as we head into the final stretch!

Tuesday, 17 October 2017

RetroChallenge 2017/10: Binary Room

Binary Land is a puzzle video game developed by Hudson Soft in 1983 for the MSX, FM-7 and NEC PC-6001. In the game players have to unite two characters (male and female), who are in love. The MSX version features a human boy and a human girl. The player controls the two characters simultaneously, with a timer adding to the difficulty. These characters move in mirror images of each other. The game features many different puzzles stages that the characters must navigate, and there are enemies within the mazes that add extra challenges.
The MSX Version with boy and girl characters
I found out about this game when I stumbled across a Japanese website dedicated to people's computing projects using arduinos and raspberry pie devices. Some of these devices implement versions of Basic to allow for simple programming projects in the style of old 8-bit computers.
This one seemed to display a simple text like game.  The author explained that they had created a puzzle game inspired by the game Binary Land.  He called his game Binary Room. I suspect this was because it involved a simple rectangle with some randomly placed blocks in it, rather than complex set puzzles/mazes.  The movement system was the same though, with two "characters" A and B being maneuvered in a mirror like fashion.  The object of the game was to move them so that they straddle numbers in sequence.  Each stage has a set of numbers equal to the stage number randomly placed in the room, up to stage 9.  Here's the source code for the game as listed by Taisuke Fukuno, who I take to be the programmer, although he might just be the person responsible for the "Create Everyday" website.
10 S=1 15 CLS:LC4,0:?"STAGE:";S
20 FOR I=0 TO 15
30 LC8+I,2:?"#":LC8+I,17:?"#"
50 LC8,2+I:?"#":LC23,2+I:?"#"
90 X=RND(12)+10:Y=RND(12)+4:IF SCR(X,Y) CONT
100 LCX,Y:IF I%3 ?"#" ELSE ?I/3
110 NEXT
120 X=15:Y=16:V=16:W=16:C=1:CLT 125 K=INKEY()
130 A=-(K=28)+(K=29):B=-(K=30)+(K=31)
140 IF SCR(X+A,Y+B)=0 LCX,Y:?CHR$(0):X=X+A:Y=Y+B
150 IF SCR(V-A,W+B)=0 LCV,W:?CHR$(0):V=V-A:W=W+B
160 LCX,Y:?"A":LCV,W:?"B" 165 LC(X+V)/2,(Y+W)/2:IF SCR()-48=C IF Y=W AND ABS(X-V)=2 OR X=V AND ABS(Y-W)=2 ?CHR$(0);:C=C+1:IF C=S+1 LC4,20:?"CLEAR!":WAIT30:IF S=9 END ELSE S=S+1:GOTO 15
170 LC16,0:?"TIME:";TICK()/60:WAIT3:GOTO 125
The questions marks represent PRINT commands.  The LCx,y commands are equivalent to PRINT@ or LOCATE commands in MS Basics.  SCR(x,y) commands do the job of checking the character values stored at specific screen locations.  The rest are pretty much standard Basic.

I found that the logic for placing the numbers was completely random, so sometimes they could be placed in a way, depending on where other numbers and blocks were placed, that there was not room on either side or above and below, to maneuver the characters around it to straddle it.  This would make a stage impossible to complete.  I changed the logic so that after placement, each number is checked to see if there are spaces to the right and left or above and below.  If not, the number is moved somewhere else and re-checked. This vastly decreased the possibility of generating incompletable stages, but not entirely.  Very occasionally you might end up with something like this:

#  #

The check shows that the top and bottom spaces are clear, but not really because the top space is not really accessible but has been blocked off to access by the character.  The number of blocks placed per round is equivalent to the number of the round multiplied by two, so this possibility is very rare.  Even on level nine there will only be 18 random blocks placed on screen.  But to prevent frustration I added the ability of the player to press R to redraw any stage and allow play to continue.  So check your stage before setting out!  The object of the game is to complete the 9 stages before 1000 seconds run out.  The faster you complete, the higher your score.  High score is saved.  When you complete the puzzle Beethoven's 'Ode to Joy' is played.  I tried to translate the music from an updated version that Taisuke also posted.  It's not a very good job, but my son Charlie is away at university, and he's my musical expert.  Perhaps when he comes back at Christmas I get him to take a listen and try to improve on my poor job.

Here's a video that Taisuke posted showing his updated version with music:
Here is a video of my port.  I have made some changes since making this video.  Now the counter counts down to zero and a higher score is the score with the most seconds left on the clock when stage 9 is completed, which is a bit more intuitive.  I also added the R redraw function to the instruction screen.

Anyway, hi to the folks doing the RetroChallenge 2017/10! I've been peeking around a little but hope to have some more time soon to check out the other projects being done.  If you are not one of the participants please check out the RetroChallenge website.

Sunday, 15 October 2017

RetroChallenge 2017/10: Zector Adventure

"Zector Adventure" is a text adventure program distributed by T&D Software in 1984. From a clue in the game itself it seems like the original programmer's name was Darrell Ulm and that he had subtitled it Adventure #1.  It is science fiction themed and based roughly on the original Star Wars film. You must escape from the Death Star with some battle plans that will help aid the rebel fleet defeat the station you are on.
The game has a handy "MAP" command
The original version was programmed for the TRS-80 Color Computer. It has a hires graphics "MAP" command that shows you your progress. In porting it to the MC-10 I had to change the map command to display a simple text graphics map instead.  I used a subroutine to translate the former graphic commands to insert into a text array space "O" characters for rooms and "-" and "!" characters for passages that you haven't explored yet.  I also added a circular "Death Star"graphic into which the unfolding map is inserted.

I also fixed up a tonne of spelling mistakes. So I guess you could call the MC-10 version a bit of a "fix" of the Coco version. The author, for example, had spelled the "examine" command as "exemine" and many of the words with "ie" were spelled with "ei" instead.  I suspect, he was a teen programmer.  The game is a lot like the classic game "Dog Star Adventure" written by Lance Micklus for TRS-80 and published in SoftSide magazine.  I have also ported that game to MC-10:
I played through Zector Adventure and created the following walkthrough, which has been posted on the CASA Solutions Archive website:



I hope you enjoy the Zector Adventure!

Friday, 6 October 2017

RetroChallenge 2017/10: Atanarjuat

This was just a silly little program I put together over the course of an evening. I don't know where the idea came from. Probably while browsing images of 8-bit Basic games.  I think I saw a picture of a simple maze that used the basic principle of alternating vertical lines with random hole put in them.  The thought struck me that the number of random passages would determine the difficulty of the maze. Then I thought, hey could an A.I. beat a human being in navigating such a maze?  I mean, it could be made to ruthlessly search for a way across as it moved up and down, but unlike a human it could not survey the maze as a whole to discern where the zones of parallel horizontal passages were most richly laid out and navigate towards them. So I made an A.I. that just moves up and down the passages seeking a way right.  It takes the first way it finds and continues right until blocked.  If it hits a block at top or bottom, it reverses directions and continues looking for a right passage. Of course, creating an algorithm that is fast took a little thinking, but I got one that allows plenty of time to pole the user for input so that navigation for the player is pretty smooth. The brute force of the computer provides a real challenge for a human player. I fiddled with the number of passages for each row to a point that I felt the game was challenging, but not impossible for a human to sometimes beat the computer. In future I might play a little with the variables that draw the maze and see if making more passages makes it much harder or easier to beat the computer.  I named the game after a legendary Inuit character "The Fast Runner" or Atanarjuat.  There is also a famous film made by an Inuit director of that name. The story originally centres on a clan feud and monumental revenge quest. So in my game I decided to add the feature of being able to hit space and lay down a "block", which can trap the computer player in a row if placed right.
I've managed 3 wins against the computer out of 5 but never higher than that. If you manage better hit the F11 key in the VMC10 emulator to take a screen shot, or snap a picture and send it to me!  Also, the program is small enough and simple enough to fit in 4K, so it's available for those MC-10ers out there who like using the real hardware, but who don't have a 16K RAM expansion.  Enjoy.