Here's the progression: 1974 Maze War by Steve Colley for the Imlac PDS-1, 1978 Escape! by Muse for the Apple II, 1979 Ratrun by Code Works for the Commodore PET. These are the origins of the entire first person virtual world games of today. I wanted to add at least one to my collection of classic games for the TRS-80 MC-10. Maze War and Escape were machine language games. The first one was for an early minicomputer system. Here's the blurb from Wikipedia:
Maze, later expanded and renamed to Maze War, is a 3D networked first-person shooter originally developed by Steve Colley, Greg Thompson, and Howard Palmer for the Imlac PDS-1 computer. It was largely developed between the summer of 1972 and fall of 1973, at which point it included shooter elements and soon after was playable over ARPANET between multiple universities. It is considered the earliest first-person shooter; ambiguity over its development timeline has led it to be considered, along with Spasim (March 1974, on PLATO), to be one of the "joint ancestors" of the genre.
Very few people would have been directly influenced by Maze War. Most people would have got their first exposure to such games by playing either Escape! or Ratrun. The Digital Anitquarian has a nice write-up on Escape! He reveals that Lord British was inspired to write Akalabeth by Escape!.
These early attempts at rendering a virtual reality are hilarious when compared to today's ray-traced wonders, but every software revolution has to start somewhere. And Ratrun is part of that revolution-- a very BASIC part. Because it was first published in Cursor Magazine (#13) it would have got fairly wide distribution. People could simply borrow the magazine from a library and type it in for themselves. Very few would have been able to purchase Maze War, but very many might have had their first experience of a computer generated artificial reality in the form of the slowly rendered lines of Ratrun running on a school PET. As one commenter on the video of my version states "Such fun to see these old machines work like the ant that could." For more info see:
Another early classic game I got around to porting this week was the original Star Trek game from 1971 by Mike Mayfield written HP BASIC.
The source code I was able to locate was copyrighted in 1972, but the literature clearly indicates 1971 as the beginning of this prolific line of games. Mayfield must have continued to tweak the program just like everyone else. For one thing, I found a bug in it that affected the way that it handled the Photon Torpedo "trajectory calculator" menu option of the #7 "Computer" option. It seems to have a problem with a FOR/NEXT loop to allow you to do multiple calculations for the different Klingon battle cruisers in your quadrant. It runs into a NEXT without FOR error.
The code also seems to provide you automatically with a calculation for one of the cruisers when you first select the option but then flick a variable switch, which then means you must type in your own and the cruiser's sector coordinates for subsequent calculations. It almost seems like there was some uncertainty or reluctance on the part of Mayfield about introducing this powerful feature, which can guarantee a "one-shot kill" of the enemy. Part of the charm of the game as I played it in other (of the multiple) versions, is trying to develop the knack of figuring out shooting angles for your limited supply of photon torpedoes. This feature seems to have been left out by others.
In any case I fixed the bug by getting rid of the NEXT statement and simply looping back to the prompt that asks if you want to do further trajectory calculations. I also made an alteration to the symbol used for the Enterprise. I changed it from <*> to <^>. I've seen many version that use <E> too. The original one using the asterisk was difficult to distinguish from the asterisk stars, and looked sinister-- more like an enemy.
Finally, at the suggestion of Paul Berg, one of the Aussie members of the MC-10 Facebook group, I was able to obtain an old Australian Coco magazine listing for the MC-10 "Cattle Baron". Paul said he had some very fond memories playing this game back in the day. I had some fun cleaning up the text that I was able to copy from the scan. There probably hasn't been a working copy of this interesting board game/simulation of the Australian cattle industry for many decades. I added a little graphic of a cow multiplied across the screen to create a "herd," which I added to the round up screen. I also fixed what I think was a typo in the original listing for a little graphic of a bunch of blokes wearing Aussie hats at the "cattle auction." I think the graphic characters translated to letter keys to be pressed listed in a REM line just above the actual PRINT line was missing one character. By looking at the graphic in actual PRINT line and counting the jumbled graphics that appear in the place of what are supposed to be the actual graphic characters, I was able to see that a character was missing and guess which character it was.
Paul will hopefully add some of his copies of the magazine to the small number available on the Coco archives. That way I can look for a correction in subsequent issues, and perhaps find some more interesting type-in programs for the MC-10.
Well that wraps it up for my programming activities for the last couple of weeks. Now I just have to wait to hear about whether any of efforts earn any recognition from the "The Double-Do" contest being run by www.trs-80.org.uk
Greg Dionne has been working on a TRS-80 BASIC compiler. In the midst of corresponding with him about the developments we discussed my normal PEEK(2)ANDPEEK(17023) routine for continuous polling of key input. He then mentioned the "debounce" key delay, which could apparently be adjusted by way of a couple of POKEs. Here are his comments, which might be helpful for MC-10 BASIC programmers:
More
notes for you now that I'm looking at the keyboard routines.
1.
If you want the interpreter to go faster when a key is pressed, set the
debounce delay to 1. (POKE 16925,0 : POKE 16926,1).
2.
To examine the state of the BREAK key, (well, for the compiler at least), take
a PEEK at 16955. 255=PRESSED 0=NOT PRESSED
3.
The keys for the KEYSCAN are stored in 16945 to 16952. This gives you
access to each individual key. So you can tell if more than one key is
pressed and which keys.
4.
CONTROL, SHIFT and BREAK do not have dedicated memory allocated for them. You can
query the SHIFT key state via doing a PEEK(3). But the others will be
lost since the interpreter will immediately stomp on the keystrobe after
catching a key, so only SHIFT can (reliably) be caught this way. The
compiler will have no trouble querying the other states.
To
see all of this in action:
10
POKE 16925,0:POKE 16926,1 : REM MAKE IT SNAPPY
20
MC=16384:KS=16945
30
FOR I = 0 TO 7:POKE MC+I,PEEK(KS+I):NEXT
40
POKE2,254:POKE 16393,PEEK(3):REM CONTROL
50
POKE2,251:POKE 16394,PEEK(3):REM BREAK
60
POKE2,127:POKE 16395,PEEK(3):REM SHIFT
70
KY$=INKEY$:REM NEEDED FOR COMPILER ONLY
80
GOTO 30
I have added his debounce delay POKES (set to 1) to the following programs and updated my compilations:
DMCHASE
ADVENTUR
ALPHAFOR
BERZERK
BIGRED
BOARDER
CAVERAID
DANTE
DIGDUG
ELAVATOR
FROG
HEIANKYO
LODERUN
METEOR
MOUSE
PENGUINO
QBERT
ROVER
SABOT
SCRAMBLE
TOMB
XRALLY
NOSTRO
ABM
BRICKOUT
FARTGOAL
FLYWHEEL
GRIDFACT
LITTLEBR
MEANIES
MILLIPED
RCHASE
RESCUE
SHOPIFT
SPACEWAL
MCJOUST
PONGNEW
GOLDHUNT
GOTCHA
RCHASE
TANK
MILLI
CAR
It seems to make a noticeable difference. Movement seems much smoother and responsive. I'll be adding the POKEs to other programs over the next little while.
I've been working on a conversion of "Warren's World: The Lost Colony," which is an old game written in GWBASIC for the PC. The following is a description I found on the Net, which I have fixed up a little (I think it was translated from Russian or the author was a Russian speaker). I have also added a few highlighted terms for items that are needed during play):
Lost Colony is a turn-based economic strategy game that tells the story of the difficult fate of a human colony in a distant solar system. The game is based on the mechanics of the popular early 1980s game Hammurabi (the progenitor of the "construction and management simulation" video game subgenre), the essence of which boils down to the extraction and distribution of useful resources among the constantly growing population of the state/city/society.
There is a Lost Colony and the plot is as follows: In the distant future, during the exploration of deep space, a planet suitable for life was found, and since resources on Earth were dwindling, it was agreed to seek to colonize the newly discovered world. The first people sent were farmers and construction workers to prepare a new "home" to receive the rest of the settlers. But alas, everything did not turn out as planned. While the first starship was getting to the colony another war broke out on Earth and the colonists were left to fend for themselves. The pioneers, abandoned to their fate, suffered significant losses in the first years in a new place until they developed an ability to supply a minimum number of necessities. These had to be carefully issued per person. To organize production and distribution of these benefits an elected position was established-- "Chief Economist." This is the role the player takes on.
Goal: To hold the position of Chief Economist for 15 years (i.e. 15 moves).
Management is quite simple: At the beginning it is necessary to distribute people and robots (the latter are intended only to increase productivity-- machines cannot completely replace people) across five sectors of the "economy" (Transport, Mining, Energy, Farms and Manufacturing). Then, each turn, the computer asks a series of questions: What products will be produced (Robots, Transports, Manufacturing Plants, and Consumer goods) and in what quantities, what amount of "wages" will go to the workers, and what percentage of those wages will go to taxes. Nevertheless, the player is not limited to being a mere "accountant"-- You will also be asked to explore new territories. To do this, a map of the entire colony is displayed divided into regions; just indicate the regions you wish to select with the cursor and the computer will display information on the resources located there. But it is not enough just to explore new lands-- full-fledged mining and expansion of farming of these lands requires that they be populated. Finally, at the end of the turn, a certain event can happen (or maybe not)-- as a rule they are not very pleasant, such as: epidemic, explosion, etc.
Remember, in Lost Colony you will have two "opponents"-- these are the ever-growing population and proper adjustments to the wage level required each turn. If you cannot provide people with everything they need, you will lose your post as chief economist, which will automatically lead to the end of the game.
Summarizing all of the above: this game, despite the relative simplicity of mastering it, is not suitable for only "a couple of evenings" of play. It requires a very detailed approach, preferably with a calculator. Also be prepared for the fact that Lost Colony does not have much in the way of graphics and looks more like a specialized piece of software for financial workers.
My TRS-80 MC-10 version is a port of a GW BASIC version for the PC. It's a work in progress. My progress right now is hampered by my inability to play the game very well. So if there's anyone out there willing to do some play testing, the game can be played online here:
Just select WARRENS from the Cassette menu and type RUN. I'll leave it open to be played for a while during the debugging process before removing it until I can fully determine the original author's intentions regarding distribution.
Here is a screenshot of the PC version of the game map:
Here's another Description of the game that I found online:
Lost Colony is a resource management game which takes place on another planet, site of the first human settlement off Earth. As the economic administrator of the colony, your job is to keep the population happy and occupied, and to generally run things smoothly until the next supply ship arrives from Earth - in 15 years.
Each turn tasks you with allocating resources for the upcoming year, by dividing them among the five major industries (farming, mining, energy, manufacturing and transportation). These resources include human labor, robotic machinery and the planet's raw materials; production quotas can be diverted towards various goals, consumer goods handed out to keep the populace contented (and obedient), and new areas can be explored and settled.
Along the way, you'll have to deal with such misfortunes as labor strikes, famine, industrial accidents, plagues and natural disasters. Savvy governance will ensure that the struggling colony prospers, while continued mismanagement will have you booted out of office in disgrace.
I have ported Steve Wozniak's Apple II Integer BASIC source for a "Breakout" clone known as "Little Brick Out." This game was according to Wozniak, one of the first action games for a home computer. He had worked previously at Atari on the arcade cabinet version of Breakout. Part of his motivation in making the Apple I was to allow him to create such games not having to to use dedicated circuit boards but completely in software. This would allow games to be easily changed and customized by users. So it is interesting to note that in such a small game (it fits in less than 4K) the Woz provides the ability of the user to modify the screen colours. The second half of the video demonstrates this ability.
While I was at it, I added the ability to choose which keys to use for the up and down motion of the paddle. I thought this would be useful as the game is very quick and very tricky. Also, the MC-10 doesn't have a paddle input device like the original Apple did. I chose to make the screen paddle move in jumps of two, which makes it quick enough to jump from top to bottom after the ball is served. The paddle is 3 spaces tall so there is a little overlap for each move, but this can make it a little tricky to figure out how to best cover the space where the ball is likely heading on the left wall. I have only managed to almost clear the board twice in many dozens of games. Here is proof of one of these:
The game is very addictive, if only because the Woz has put in comments on your final score that range from "Terrible" to "Nearly Perfect". However, since the bricks on the first rows are worth far fewer points than those on the far right near the wall, you seem to get a disproportionate number of "terrible", "lousy" and "poor" scores. If you don't seriously whittle down those last two or three rows the "good and excellent" scores will likely remain out of reach. If you clear all the bricks you "Win the game!" There is no continuing to get the highest score possible. This is probably a blessing as the random motion of the ball will make hitting those last few blocks an exercise in extreme patience.
Apparently Wozniak programmed the game in less than half an hour. It was meant as a test for his Integer BASIC interpreter. However, as the Apple community moved on to Applesoft BASIC with floating point integer BASIC games were largely left behind, and so it has been difficult finding copies of the source. I have yet to locate a place to allow the game to be easily played in an emulator or online. Here is where I located the source in the 1978 "Apple II Redbook" reference Manual as an example program:
I have added the details of the game to my Type-In Mania website. You can't launch the code from there, as that is my faculty web space and I am trying to make a "Clean" page that only includes games permitted by original authors. So I hope to be contacting Mr. Wozniak very soon. I'll keep you posted.
My son Charlie and I have made a port of the Commodore VIC-20 Version of The Sword of Fargoal to TRS-80 MC-10. Because of the more limited nature of the graphic abilities of the MC-10 it renders its dungeons as ASCII text, which provides gameplay more like what Jeff McCord's unpublished forerunner game Gammaquest II on the Commodore PET might have been like.
It was quite a challenge to get the game working on the MC-10. I had to figure out how to use the BASIC's CLEAR command to allocate protected memory at the top of the memory map. The VIC version pokes the map for the current level into memory, and then just uses PEEK to plot that information back onto the text screen area as the player moves. One's surroundings are revealed only immediately around the player, which is what provides the "fog of war" view that has come to define the "rogue-like" genre of which Fargoal is one of the first.
A complexity that I had to deal with is that I also wanted to store a short M/L timer routine created by Darren Atkinson in higher memory. I needed this routine because the game uses the TI function of the VIC to give you 33 minutes to get back to the top level after you recover the sword somewhere on level 15-20. So I had to figure out how much memory I needed for both functions to fit.
I also had to work around the limitation of Darren's timer to only go for 15 minutes (or so) before it loops back to zero. So I changed the time keeping variables quite a bit. Now every time the monster movement routine is initiated, the time since it was last run is added to a time-keeping variable (T). This along with the fact that the timer must be turned off every time sounds (other than the step sound) occur means some time accuracy is lost. However, Charlie and I worked in some fudge factors to offset for the time when sounds are being played. On the whole our testing indicates that the program keeps a close approximation to the actual number of seconds passed. We erred on the side of generosity (we think), so you should actually get a little more than the standard 33 minutes to get out after collecting the sword.
The VIC version uses a loader program to load some custom fonts, with certain uncommon punctuation characters redefined as small graphic images of the character, monsters, stairs and pits, etc. Redefining the characters was not available on the MC-10 and since the punctuation characters used were somewhat arbitrarily assigned a fair bit of re-adjusting for aesthetic purposes had to occur. Instead of square and round brackets for monsters I used some of the unique punctuation characters, such as right arrow, up arrow and hash symbols. Instead of using the right and left slashes for gold, I assigned these to up and down staircases. Pits and ceiling holes became different round characters: O, 0, and @. Gold became the dollar sign. Magic/trap squares became the question mark. Each of these changes required careful searching and replacing of all the places in the code where the original character code was used. Fiddly, but after much testing, I think it has been done thoroughly.
The most important part of the conversion was changing McCord's ingenious dungeon drawing routine from a 22 X 23 character VIC screen to a 32 X 16 MC6847 screen. Also, all the movements for drawing those maps and moving the characters had to be switched from +22 -22 for up and down movement to +32 -32. The re-dimensioning was something I had done for other conversions so it went pretty smoothly.
PRINT commands also had to be switched from using the VIC's embedded control codes in strings method to using PRINT@ commands. When VIC listings are printed from WinVice, these codes generally get converted to periods. They are most commonly used for clearing the screen and in this game repositioning the cursor to the top left for printing messages on the top line "window", so it was not too hard to figure out. Watching Youtube playthroughs provided information about what was going on, on screen.
Youtube was also very helpful for replacing the sounds from the original. The VIC, of course, as a Commodore machine, uses a ton of PEEKs and POKES for all its sounds. All these routines were neatly lined up (for the most part) in one section of the code. By looking at which subroutine (death, theft, combat, pit falling, etc) one could guess what sounds were meant to be produced. Charlie, as usual, used his wonderful musical ear to recreate the main game refrain from listening to playthrough videos. He also went through the VIC code for clues from the various POKE commands to try to decipher musical note information and possible note duration. Through this combination he got the refrain to his satisfaction. With my tin ear, I'll leave it to others to judge the quality of his work.
After I was finished the main part of the conversion, the biggest thing was trying to speed up the program execution. The VIC has the ability to declare certain variables as Integer variables, which helps speed execution. You just have to put a % symbol after the variable name. The MC-10 only uses floats, so it was important to make sure that variable names used for graphic intensive actions, like moving monsters around on screen and tracking the character should be switched to single letter variable names (e.g. T for treasure was switched to GP and E for experience was switched to EX freeing up T and E for other uses). Single letter variables are interpreted by Basic more quickly. Also, removing redundant variables and using scratch variables can help keep the variable lookup list shorter and speed up execution. Finally, I declared all the graphic intensive variables in the initial DIM statements to speedup their execution. Variables declared earlier are placed earlier in the variable lookup table and therefore can be found and operated on faster.
After I had a working copy I thought it would be good to shoot the project by the original author to see how he felt about us sharing it more widely. The wikipedia page for Fargoal indicated that McCord was still vitally involved in modern variations of his classic program, and had collaborated with some programmers who had created a modern iPhone version. So I looked up the page for the new app and left a message about my project. A few days later McCord got back to me. He asked some questions about the project and when he was sure that it was just a retrocomputing homage he generously gave his blessing to share the game with others. All he requested was that his copyright be updated (1982-2020) and a note be made of his permission. So I replaced the "Epyx presents" part of the old title screen with a reference to McCord's permission to create the game as a retrocomputing "pet project."
He told me that he appreciated my enthusiasm for his original game and desire to bring it to the TRS-80. He also mentioned that he actually used a TRS-80 (Model 1 or 3 as it turned out) at school as one of his first computers to learn BASIC coding as a teenager in Lexington, KY. But his dad bought a PET, which he ended up using to create the precursor to Sword of Fargoal, Gammaquest II, while he was in high school.
That program was never published. It was my hope in pursuing this project that not only would I get another working program for my favourite orphan 8-bit system from the early 80s, but also a program that is somewhat evocative of that now missing classic precursor program to Fargoal. So if you have a hankering to relive what playing Gammaquest II might have been like you might find that our version fits the bill. It can be played at my website for early BASIC games from the 8-bt era. Select "FARGOAL" from the Cassette menu. Then type RUN and hit Enter. Enjoy.
This line is the one that initiates the sword (and gold) stealing routine. The first part of the IF seems to check for whether you are being attacked by a non-humanoid monster (D=0) or a humanoid monster (D=1). Then it checks whether you have gold (T>0) or you have found the sword (SF=1). But by not having brackets around the (T>0ORSF=1) it means that no matter whether a humanoid or non-humanoid monster attacks you, the sword can be stolen. We found that after collecting the sword (see last video below) it was very hard to make it to the top level without sometimes being attacked. Then if the monster is less than half as weak or is stronger than you, the sword will immediately be stolen. At the deepest levels, just after you have stolen the sword there will be many chances for strong monsters to jump you--They move fast and you will be struggling to make it to safety. As you go higher, you will start to encounter weaker monsters but you will also be feeling increasingly rushed as time runs out, so it is easy to rush to find stairs and end up being jumped by a weak beastie. Since the sword immediately goes all the way back to its original level, it's really game over, which seems unfair. So we changed it to:
McCord seemed to intend that at higher levels, even weaker monsters could try to make a grab for the sword. This way those levels wouldn't just be a cake walk, but it seems excessive that if you stumble across *any* monster (especially unseen assassins or dimension spiders), it's game over. It makes more sense to us that you should certainly be wary of being jumped, but it shouldn't be an exercise in perfection. And there should be a real possibility to recover, so we changed it so that the sword is relocated on the current level. You will have to leave the level and return to it to make the sword reappear, so it represents a frustrating, possibly fatal, delay, but not instant failure. I'm not sure if we have disrupted some critical element of the game dynamic, but we will continue our testing and try to determine if it results in a slightly more enjoyable game.
We also considered nerfing the movement for monsters at levels below 15. At level 20 the monsters have 1 to 1 movement turns with you, whereas at level 1 they move only every 19 turns.
2 GD=0:P1=0:L1=0:R1=50:S=20-L:IFS<1THENS=1
We thought it might be nice to change it to:
2 GD=0:P1=0:L1=0:R1=50:S=20-L:IFS<5THENS=RND(3)+1
It seemed to us that if you got stuck with the sword being on a lower level than 15, that should be enough of an increased challenge in itself. It didn't seem fair that the monsters should also become ludicrously difficult to avoid (and your movement excessively slow). But we tested playing it with one to one movement, and it wasn't impossibly slow, and there were some techniques for avoidance, so we decided to leave it. McCord seemed to want to allow players to also have other goals than simply getting the sword, such as testing themselves at going deeper.
We also ran across a bug in line 262 noticed by some of the early reviewers of the VIC version of the game.
This error occurs if a currently searched monster (variable M) is not found among the list of monsters stored in N(J). This check occurs after combat has been initiated by you. For some reason no monster location M has been properly assigned yet if you jump on a monster immediately after level startup so we also initiate M to a monster location at level startup.
We added some instructions outlining the basic operations of the game that you can access at program startup by hitting the H key. We also highlighted the key letters used for the various spells on the Magic report screen. So now, anyone should have the basics in hand for playing our version of the game (such as online via the link above) without having to consult the manual. For example, the 8-way motion of the joystick is recreated using the keys:
QWE
ASD
ZXC
SPACE is the "panic button." The S key operates as down key so you can also use the WASD combination for basic motion. So we relocated the "S" for shield spell to the ENTER key.
Here's Shot97 having trouble trying to win the original Fargoal. Hopefully my edits might resolve some such frustrations:
Addendum to the Addendum
We think we found another bug in the following routine (this is the original VIC source):
The fl variable is initialized to zero, but only at line 283 inside the loop processing the movement of the non-humanoid monsters on a level. A similar loop begins at line 286 for the humanoid monsters. However, it doesn't initialize the fl variable to zero. This variable is the trigger for the teleport routine being jumped to if player hits the panic button while being attacked by a monster. This jump to the teleport occurs in the IF commands at lines 283 and 288 for the non-human and humanoid monsters respectively. Everything is fine if there are at least some non-humanoid monsters to process on a map. That means the fl variable gets reset to 0. But the "goto286" in line 282 can lead to the entire non-humanoid monster processing routine being skipped. In that case, the fl variable never gets reset. So in the rare occurrence where you initiate a panic teleport when attacked, and there happens to be no non-human monsters left on a level, you can end up automatically teleporting again and again every time the monster movement routine is processed. And don't try to get out of the problem by trying to take a stairway and go to another level, because that will lead to a NF (next without for) error in line 12. The reason for that is that the "if fl=1 then 52" command sequence is a jump back up to line 52 (the main loop) from within a FOR/NEXT loop for processing each of the monster types. In other words, the FOR/NEXT loop is never formally completed/properly exited, which can lead to all sorts of confusion in the interpreter about how to process subsequent NEXTs, as one can see here in this test worked out by Charlie on the Vic emulator:
Never reinit a FOR loop inside other FOR loops!
This is likely a very rare occurrence and it is possible that something in the original code that we somehow messed up prevented it from occurring. But we fixed it in our version by properly shutting down the FOR/NEXT loop before jumping back to the main loop. We also initialize the fl variable at the top of the monster movement routine (line 282) before either the monster-type loops are entered. This is okay since any panic button aborts the entire routine (282-290), so it really only needs to be initialized once. This will also mean a speedup of the first loop as fl will not be reinitialized each time that loop is run.
If you make it, you get a message that says "Your quest is complete!" and then a screen of your overall statistics. If the clock runs out, next time you change levels, you get a message that says "out of time!" but then it takes you to the same statistics screen. Except for that brief flash of "Out of time!" or "Your quest is complete!" you wouldn't really be able to tell if someone won the game or not.
In our version if time runs out that message will stay at the top of the statistics screen. If you win a little refrain will play before you are taken to the stats screen. You can see this in the video of my son Charlie actually winning the game. Thanks to Charlie and his patience and dexterity, I think I can know call this project complete. The Sword has been recovered! Peace is returned to the Great Forest lands.
Charlie for the Win!
Addendum to the Addendum to the Addendum (2023/12/04)
I decided to take advantage of my son Charlie's newly minted Mathematics and Computer Science BSc from Dalhousie and the fact that he is trapped in the house because of Covid-19 to attempt to fix an old game of mine. I made Mahjong many years ago, but all it did was throw the tiles into the traditional "turtle" format at random. This meant that winning was a very rare occurrence. Most computer versions of the game have an algorithm to ensure that there is at least one way to solve every puzzle from the beginning. Then when you lose, you know it is because you somehow screwed up in removing the tiles. This provides a much more rewarding play experience because you can typically play longer before running into dead ends and you know the puzzle is solvable (in principle).
I had vague ideas about how to implement such an algorithm, but they were really vague and all involved starting with a blank sheet and then placing pairs of tiles until the 3D turtle shape was built up of the stacked tiles. So I set Charlie to the task of thinking about how to solve the problem of finding a solution. Next morning he presents me with the idea that it would be better to play the game forwards rather than backwards. That is to say, start with the turtle populated somehow, have the computer play the game by removing sets of tiles randomly until none were left, then using that configuration. He had a simple method worked out for mutating the values of the positions of tiles to map their "openness" or "closedness." You can only remove a tile if it is free on one side, left or right, and not covered by a tile above.
Basically Charlie's method starts with a coding system for the original positions:
3-Win Graphic
1=open left and right
2=open left or right
3=not open left and right, but open above
4=not open left or right and above
5=not open left and right and above
Then whenever you remove a tile you subtract one from the positions left or right and 2 from the position below to adjust their values. Then just solve the puzzle forward using blank tiles. You randomly select two free tiles (<3 tiles) and assign them a pair of tiles (1-36), then "remove" as per above. Repeat until you get to 0. If it runs into a block (which is relatively rare) where it can't find a final pair-- Restart. See lines 20-74 and 2000-2045: https://github.com/jggames/trs80mc10/blob/master/quicktype/Puzzle/Mahjong/NEWMAHJ12.TXT
I had done some research of my own and had come across a similar tip originally from the Stack Overflow coding site. Basically the author, Merlyn Morgan-Graham, suggested the same idea as Charlie, but he made it clear that what you do is start with a blank set of tiles in the turtle shape. He also provided insight into the problems you will face with this method, as occasionally you can end up with an odd number of tiles that are free (i.e. 1) and you will have to restart. His estimates for how often this happened were very helpful and encouraging.
Long story short, we got the algorithm to work and the initial version timed to just under 2 minutes for program setup and algorithm completion. Obviously, it took a little longer if the algorithm hit an uneven completion and had to restart. Just running the algorithm (not including program initialization) timed to just over a minute, but in subsequent re-writes I think I have got this down to just under a minute.
Lots of data had to be stored, including a 3 dimensional array (15 X 9 X 5) to store all the initial position data and openness data. Other info was also required such as top tile, and the current height of each stack. We made use of many 144 element long 2-dimensional arrays to store pointers to the x, y and z of the valid positions and the current tile type in those positions. 144 represents the total number of tiles (i.e. 4 of the 36 types of tile, or two sets of every tile type). Processing these 2-dimensional arrays was great for speed, but we did have some difficulties moving back and forth between references to these lists and the 3-dimensional space with the info about each tiles' openness.
So I had to really streamline and pare down my initial routines for generating the unique low res tile set I had worked out for the original game. I was able to store all the tile info in strings and then just use MID$ to get to any particular tile I needed. This was much better than my old version which stored tile detail in data statements and then constructed the strings in string memory.
I also added an undo feature that was lacking from the original, and since everything was pretty much stored in arrays already, a game save feature using the MC-10's CSAVE* command which allows you to easily save arrays to tape. Charlie's system of coding the open tile info also really sped up the searches for possible moves for the HELP/GAME OVER feature. In my old version every search required determining whether a tile was free by consulting its neighbours, instead of just storing this info permanently (and "mutate" the array every time you remove a tile as per Charlie's method). The help feature simply presents the open tile pairs a set at a time. If no such tiles exist, it presents the game over prompt.
So here's a video of me playing the new version:
As I mentioned, the algorithm has been speed up even further from this initial release. Here is a video of a speed test that indicates that even with initial program initialization you can be playing in just over a minute and a half:
Enjoy! The game can be played here. Choose the "Play Our Original Micro Color Basic Games" option, then select "MAHJONG" from the Cassette menu and type RUN:
I've ported the code of a game for the TRS-80 Model 1/3 from the Book Golden Flutes and Great Escapes: How to Write Adventure Games by Delton T. Horn. The game "The Golden Flute" is a simple adventure game with CRPG elements. The action takes place on a 10 X 10 grid. I added a nifty title screen graphic of some of the members of the whimsical party of adventurers in the game.
I've also been engaged in some other hi-jinks. The winner of this year's Type-in Mania cup was Darren Ottery of Australia. Darren wrote a prominent early game in the MC-10 community, "Micomania." I remember playing this game as one of my first programs obtained through the Internet. Darren played it recently and posted a video of it online, because he couldn't get my game Miner running on MCX. So I fixed Miner to work on the MCX and then I tried Micomania again myself just for the nostalgia of it. Well, I couldn't resist trying some of my speedup techniques on it. This morphed into making a better tracking algorithm for the enemy. Finally I did a little graphic editing using SKETCH to spiff-up the title page. In the end I sent it to Darren and he made a few more edits including putting me on the title page, which led to "Micomania 2."
Finally I have worked on some programs from a book for the Dick SMith VZ-200 computer, VZ200 Giant Book of Games by Tim Hartnell. One of the games I have got running on the MC-10 and (hopefully) fully debugged is "Rural Pursuits." Another one I am working on currently is "Chairman of the Board."
Rural Pursuits
There are just so many type-in programs out there it is hard to figure out which one to work on next. Some other folks have also been getting into the Basic program business. I was made aware of the Hartnell VZ-stuff by Mike Hawkey and David Maunder, who are trying to get the programs running on the VZ-200. Fabrizio Caruso posted a completely new puzzle game (with some arcade elements) in the MC-10 Facebook called "Mines Plus." It's for next year's 10 liner, but although a small program, it is very addictive. Curtis F. Kaylor posted a math skills game for kids on the MC-10 called "MathCom." Darren Ottery added to MMania with TypeAttk, which is a typing skills testing program (made even more challenging on a real MC-10 I'm sure). I have added these folks programs to the "Programmers" directory in my distro of the VMC10 Emulator.
Here is the (somewhat sinister) map of the game Mazies & Crazies. In this update of my hand drawn map of my last post you can really discern the coherence of the underlying structure of DaCosta's game. This structure repeats itself 3 times. The map restarts at rooms 31 and 61, which are cognates of room 1.
Since room 1 doesn't allow a return through the top door because it has a pit trap going in that direction (i.e. the door is only one way from room 90), you can only get to room 90 by traversing the 3 levels. That makes room 90 an ideal place for a final boss battle. So I have modified the program a little to provide this. I have renamed the "DemiLich" monster I had been using to simply "Lich". But in room 90 this character gets renamed "Demilich" and gets a bonus on its strength. I also made the program put its highest ranked treasure in room 90. All other treasures and monsters only get distributed to rooms 4-89.
So now, you must seek the Demilich in its lair. This makes the game somewhat like the classic D&D dungeon adventure "The Tomb of Horrors" created by the legendary Gary Gygax. In keeping with ambiance of that adventure (if not its actual limited set of monsters), I have renamed the monsters yet again. Here's the current list in my version of Mazies:
Asp
Evil Dust
Live Axe
Skel-eton
Mum-my
Gray Ooze
Ogre
Lich
Demi-Lich
For those who don't know, a lich is an undead corpse of a powerful wizard. A demilich is the animated skull of an extremely powerful undead wizard who has gone beyond the need for the rest of his body. Great wizards usually became liches in order to continue their pursuit of magic and power beyond death. The boss of Tomb of Horrors is the Arch Demilich Acererak. He's pretty powerful, so you'll need to marshall your powers to be able to kill him in MC-10 Mazies. You'll need the shield (at least) to have a chance. Don't think the arrow will help, although it can't hurt. You might try getting the bomb and then try to lure him onto it, if you want to ensure victory.
I have also added a few more fixes and speedups to the program. The victory sound and the sound for the magic portal and pit trap have been improved. I fixed a bug that made the portal only take you to room 11. Now it will take you anywhere in dungeon except room 90.
I'm pretty sure that this program is pretty obscure, if not completely missing from the Net, by which I mean it doesn't have any playable copy available that I can find. My version of it is even more obscure again. But in case there are any hardcore fans of 8-bit BASIC RPG's out there, this is an adventure for you.
P.S. Added a listing for this game to the Wikipedia's List of role-playing video games: 1975 to 1985
P.S.S. I final read other chapters of the book, and discovered that DaCosta actually presents the map of the layout, so all my careful mapping was unnecessary. Lesson: Don't just read the chapter about the source code.
High score of 744 After Boss Fight (and a few deaths)
I have been able to clean up the map I made last night (and wrote about in my prior post). There is definately a coherent structure, which my poor sketching skills pobably obscures a little.
The other levels just repeat this basic map, with their "Room One" occuring at 31 and 61. Each of these can be looked at as different levels of the dungeon. So You could say that DaCosta has constructed a 3 level dungeon. Room like room 30 on this first level leads back to Room One, but you cannot go back to room 90 because of the "pit trap" which prevents going that direction.
I think another line of possible improvement of the game would be to make each level's monsters harder than the prvious. Perhaps, this could be done simply by adding a number of more powerful monsters unique to succeeding levels and with a boss fight in room 90. At the very least, I think I will add a "Lich King" to room 90. Or perhaps I will change all the demilich's to just "lich"s and put the demilich as the final boss. This will make DaCosta's game a little more like one of the most famous dungeon campaigns (modules) of the classic game D&D, the infamous "Tomb of Horrors".
Cool.
P.S. Corrected a bug today in the MC-10 version. I had used the "I" variable in the FOR/NEXT for my sound routine for the magic portal, that was also used by the portal routine for the room number of the random location you were to be sent to-- Result, you were always being sent to the same room number (the last number of the FOR/NEXT). Fixed it to use another "scratch" variable C. Now you will be sent to a random location anywhere in the dungeon. I have uploaded a new version to all my storage locations.
I've moved to real MC-10 hardware and finally started to seriously play the game now that I've got (I hope) all the bugs out. I've been trying to apply some technique to play so that I don't just end up being killed. I have managed to penetrate all the way to the "end" of the dungeon. The room layout is not completely linear and is a bit convoluted, as you can see. Don't think this is from errors on my part. There is a basic coherence.
In brief, I think the maze consists of a basic plan of 1-30 rooms, which is repeated again 31-60 and 61 to 90. I have made it to room 90 and returned to Room One, although I didn't explore most of the rooms in the 31-89 range. As I noted in prior posts, I "corrected" the program so you can't go back from Room One to Room 90. Don't know if that is another "error" introduced into the code on my part, but I don't think so, since the "pitfall" routine is called nowhere else, and its use makes the most sense in Room One. It makes the game more exciting trying to figure out how to get to the higher numbered rooms and ultimately to Room 90. It is just silly to have room 90 accessible to Room One.
Made it to Room 90
Checking my Score
Step through bottom door and I'm back to Room 1
Perhaps DaCosta corrects the Room One-Room 90 bug somewhere in the text of the book as he discusses the program. Perhaps, he suggests that you correct it after having tested the higher levels by jumping to them directly from Room One. I don't know. I've only skimmed the chapter. I'll go back and read it in more detail now. Perhaps, he wanted to give people a way to create a boss fight in room 90, and to be able to get there quickly for testing purposes. It's an example program afterall, so there are bound to be rough edges and opportunities designed to be filled in by the reader.
I can certainly think of some nice features to add. Like I said, a boss fight of some kind in room 90 would be nice. Some additional monsters from the core 8 would be nice too. Different rooms for the levels 31-91 would be a possibility too, as there is no obvious technical reason for why they should repeat. It's certainly not to save memory, since they have their own data lines in the source code. One thing that would be really nice would be a game save feature. I think this should actually not be hard to implement since, almost everything of importance is held in one numeric array, and so should be able to be saved using CSAVE*L,"FILENAME" command of the MC-10. Such possibilities are what I will explore next for RetroChallenge, if I have time.
I felt a little like a real pioneer exploring the Mazies maze. It was a virtual space that possibly hasn't been explored by anyone in over 30 years. Or maybe never, at least by anyone else than DaCosta. If no one ever actually bothered to type the whole thing in, who knows, I might be the only one besides Da Costa, to have traversed it.
Two posts back I discussed an apparent bug in the Quit/Score routine of Mazies & Crazies.
I thought line should be changed from this:
240 J=0:FORI=17TO48:IFL(I)=1THENJ=J+I
to this:
240 J=0:FORI=17TO48:IFL(I)=91THENJ=J+I
because otherwise it would not count which treasures you had in inventory, which are marked as being in Room 91 (your sac presumably) and not one of the 90 rooms.
However, given my last post about the rooms and the trick of not trying to return to room 90 after returning to Room One from there through the final door, it occured to me that DaCosta might have been expecting people to take treasures back to Room One and drop them there in order for them to be "counted" by the score routine. That way you could only receive reward for treasure that you had "brought back" from the dungeon. If you made it all the way to Room 90, you would not have to go all the way back through the maze. Instead, you could be transported directly back to Room One, where you could drop your latest items and check your score.
If you select quit anywhere else in the game your score only represents the number and power of the monsters you had killed, and not any treasure, even treasure you were carrying. This had seemed a bit weird to me, but I now see the reason for it. The style of play is to foray from and return to Room One and to only check you score there. Additionally, you might use techniques for collecting treasures and taking them to way stations, before making return to bring them to Room One. Such an approach certainly adds complexity and nuance to the game play that wouldn't be present if your inventory was all that mattered in terms of score.
But why then not make it only possible to use the quit command in Room One? Or at least give credit for treasure being carried if quit were chosen somewhere else?
There are advantages either way, but only counting treasure dropped in Room One could have been DaCosta's way to prompt the player to figure out that the game was a treasure hunt with a preferred "home base." This would need to be recognized if collected treasures were to register and a high score achieved. Whereas, if you count stuff in inventory and also Room One, as the following change would allow,
240 J=0:FORI=17TO48:IFL(I)=91ORL(I)=1THENJ=J+I
the player might never figure out the real goal of play.
It had struck me as odd that the player could not carry all of the 16 treasures hidden throughout the dungeon. So I had thought that the goal was to find as many of the highest numbered treasures as possible, while dropping any lower ones and to kill as much as one wanted before choosing to "quit the game." In other words, I had presumed that someone would decide when they had had enough adventuring. But it now seems likely that Da Costa felt that one should play until one died, and that the real goal of the game and the way to "win," would be to quit while in Room One, with your treasure hoard all around you.
Presumably killing every monster and returning every treasure to Room One, without any "resurrection" restarts, would be the ultimate high score. This is because every time you die and are resurrected, you get a score penalty, but anything you are carrying is dropped in the room where you die. Also, anything you dropped previously in Room One will be left there. So there is a trade off to choosing resurrection and going back to retrieve treasures, or simply rerunning the game to start fresh. More nuance to game play. It all makes sense.
So I'm changing the Quit/Score routine back to its original form.
But there must be some way to inform the player about this. Perhaps in the instructions...
New Instruction: Return treasures to Room One
As the old saying goes... you live, you learn.
P.S.
I see on page 202 of Writing BASIC Adventure Programs for Your TRS-80that DaCosta says "J will be used to tally the score. To evaluate the treasures, a loop counts through the location array, finding treasures that reside at home home base (room 1). For each safe treasure, points are added to score J based on the treasure number." Treasures are worth anywhere from 17 to 48 points each, which means there is a total of 1040 for treasure.
The score for creatures is killed is based on the "size of the creature," according to Da Costa. Points range from 9 to 16 points each. There are 48 creatures in 6 groups of the 8 "sizes," So a max score of 8 X 16 + 8 X 15 + 8 X 14... (totally to 800) is possible.
That means the max high score for this game is 1840 if one plays without ever dying and needing resurrection, kills everything and brings every treasure back to Room One. That doesn't sound too hard.
I made some changes to the monster names, so they will format better in the 4 character space available on the right side of the screen for messages in the MC-10 version:
1. Spider -->Rat
2. Snake --> Bad Elf
3. Land Crab
4. Scorpion --> Were Wolf
5. Huge Bee
6. Amoeba --> Gray Ooze
7. Troll --> Ogre
8. Dragon -->Demi Lich
These form better in the 4 character 2-line message space at the top right.
Allen Huffman wrote on facebook about Mazies & Crazies:
"I am really growing fond of these BASIC games you are doing. It was a really exciting time."
I replied:
"Exciting but a little tedious at times. I'm still editing this one and just found a few more typos. I can understand why the program went missing-- No one wanted to type in 90 sixty character strings (of numbers)!"
I noticed something strange in the code. There was a routine for a "Pit" you could fall into, but I hadn't noticed any pits yet in my playthroughs. In looking at the code I could seed that the Pit routine was triggered when you enter Room 92. This sent me to look closely at the room data to see if a Room 92 was ever listed among the exits for any of the rooms. In the course of checking, I noticed some more typos. Mostly 8s that were interpreted by the OCR of the scan as 3s. But I couldn't find any 92s.
Then I recalled being a little baffled by the ability to leave through the top door of Room One and being taken to Room 90, which is the highest number in the dungeon. It would seem to make more sense that part of the adventure is to work your way through the dungeon to higher and higher room numbers, with 90 being the ultimate objective. Indeed the room numbers seemed to be listed in an ever increasing crescendo, with the rooms in the high 80s finally leading to Room 90.
So it seemed weird that Room One should simply let you get to Room 90 through its top door (see line 1000 above and the screen shot above). So I changed it to 92:
Now in Room One, if you try to leave through the top door, which the two walls in the room seem almost to point you towards, down in a pit you go! I added a little falling sound for the MC-10 version. For the TRS-80 senior version I had to fix the pause from a "I=1 TO 20" to "I=1 TO 2000," since otherwise you couldn't even see the "You've fallen in a pit" message." Now, you must struggle to get to Room 90. When you finally get there and through the final door, your are taken back to the beginning (Room One). But don't try to backtrack and return to Room 90. If you do, down in the pit you go! This is a more fitting and somewhat ironic ending for an "epic" foray into a "mysterious dungeon."
I wonder if DaCosta had left this change in to allow allow himself the ability to get quickly to the higher levels for debugging purposes, and never changed it back before sending his book to the printer.
I also noticed that when you eat the "magic fruit" you get some random amount of healthup to several 1000s. Since the fruit returns to the rooms in which its appears whenever you leave and return, you could just pop into and out of a room many times to bump your score way above the normal 10,000 (or the 9999 in the MC-10 version since I only have 4 characters to play with on the right side for messages, instead of 8). There were no checks to prevent you from going above "full strength," which seems weird and counter to the goal of making the game a challenge.
These bugs, along with the one I found in the Score routine (discussed in my last post), and the slowness of the TRS-80 version probably annoyed anyone who actually typed in the game and left bad taste in their mouths. So when it came to people having enough affection for the game to prompt them to make sure it was preserved somewhere on the Net there was simply too little good will out there.
By replacing INKEY$ with continuous key polling PEEK(2)ANDPEEK(17023) of the MC-10 and adding some other speedups, I think the MC-10 version is really much more playable. The smaller screen size also makes moving around much less tedious. The added sounds and the color don't hurt either. With these improvements, it really is more fun.
DaCosta put a lot of thought into its construction. Without its bugs and typos, a little more speed and an instruction screen, I think it would have been fun game to play back in the day. I could see my friends and I competing for high score, which would truly represent your ability to penetrate to the higher numbered rooms, find the highest numbered treasures and defeat the largest number of the strongest monsters. If all of this could be achieved only by carefully marshalling your strength, instead of artificially pumping it up though the magic fruit bug, a high score would be truly meaningful.
But the absence of these features probably left people cold after having engaged in the monumental task of typing in and checking 90 lines of room data. Their disappointment might have prompted some to seek (literally and figuratively) to erase the game from their memory.
I've got a more fully debugged version working of Frank DaCosta's example program from Writing Adventure Games for the TRS-80 from TAB Books (1982). You can see demonstrated in the following video, the technique of using the bow and arrow by way of a cheat on startup, that puts them in the main room. I won't tell you the secret code, but Basic programmers should be able to figure it out.
I also found what I think is a genuine bug in the printed source code. Line 240 of the QUIT and SCORE routine reads like this:
240 J=0:FORI=17TO48:IFL(I)<>1THENNEXT:GOTO242
241 J=J+I:NEXT
But it should read like this:
240 J=0:FORI=17TO48:IFL(I)<>91THENNEXT:GOTO242
241 J=J+I:NEXT
The number 91 indicates that an item, such as a piece of treasure, is in the player's inventory. This line is a part of a FOR/NEXT loop which is supposed to count up which items you have in inventory and add their value to J, which is the score variable. By searching for 1 instead of 91, the treasure items you collect never get counted and you never get any credit in your score for collecting the highest value ones (they range in value from 17-48). Since this is an open ended RPG game, in which the purpose is to explore the 90 room dungeon until you have found the highest valued treasures and killed as many of the strongest monsters possible, this bug is kind of a bummer.
Some other changes you can see in the video besides the use of the arrow, are some slightly fixed up walls. Some of them needed adjusting because they didn't work well once condensed to half the screen width, such as the room with the chevron at the top. It didn't have a one space entrance at the bottom of the chevron as in the original. I also changed the "fire" character from a solid orange character to a checkered orange character. Looks a little more like fire.
Some less apparent changes involve speed. I rearranged the IF checks of the monster movement routine to process blank spaces and walls first. These are the most common characters to be met as it moves, so they should be processed first so all the less frequent checks are only done when necessary-- Things like whether it runs into a potion or a fruit, for example. Found out that if the monster does run into such helpful items it gets the benefit of them instead, so don't let them get to them first.
At the end of the video you can see a 0 character. That's a bomb. If you can lure a monster onto it, it will be blow up. You can also pick bombs up to bring with you. Just make sure to not run into it or you blow up. Move up gently and then (T)ake it into your inventory for later use.
I've got the program basically working now in both the TRS-80 Model 1 version and for the TRS-80 MC-10. I think these might be the only working versions of this program available on the Net. At least to the best of my knowledge. I've searched pretty intensively.
I will send the TRS-80 code to Ira Goldklang's TRS-80 Revived Site when I am a little more satisfied that I have got all the bugs out. Still haven't managed to play to the point of getting both bow and arrows to test arrow shooting. I have spent most of my time tweaking the maps in the MC-10 version, since the shrinking from 64 to 32 character wide screen messed up the plotting of some of the walls and doorways for a few rooms. Basically these rooms:
28,58,88
24,54,84
6,36,66
29,89,59
20,50,80
and
4,34,64
There is a lot of repetition, so these triplets represent the same room layout, but different places in the 90 room dungeon. I think I've checked every room string for typos now. Lots of number checking for lots of lines of code from the scan I was working from. It runs faster on the MC-10. And I have used key rollover PEEKing, rather than INKEY$ so the movement is smoother in the MC-10 version. Also added a help screen at the beginning.
Next step more play testing to check fighting and scoring. I think the goal is simply to play for high score. If you restart, items will be left where you died, but it will be a score penalty for the next round. One neat feature is if you pick up the bomb you can drop it in the path of monster and lure them onto it, which will blow them up. Lots of neat little features to discover. It's an interesting program, so I'm a little perplexed as to why copies don't seem to be abundant. Perhaps I've missed something obvious. Here's a link to the scan:https://archive.org/stream/Writing_BASIC_Adventure_Programs_for_the_TRS-80_1982_Frank_DaCosta/Writing_BASIC_Adventure_Programs_for_the_TRS-80_1982_Frank_DaCosta_djvu.txt
