Tuesday, 3 August 2021

Sorcellerie/Sorcery by Rafi Deryeghiyan: Inspiration for Harry Potter?


It was quite a while back that I translated to English and ported the source code for a text adventure written for the Matra-Hachette Alice 8-bit computer called "Sorcellerie" (Sorcery) by Rafi Deryeghiyan. This is a fascinating game: Here is the brief intro provided to the program:

Until 2036 the world was at peace, then unrest began to stir in society.

22 June 2037: Sorcerers reappear with terrifying powers. Small in number, they are easily controlled.

Christmas 2037: A wizard coup--all armies are destroyed. The dictatorship of witchcraft is proclaimed.

February 2038: Wizards are about to break the will of human resistance. Aware of the danger, some have tried to combat this evil power, but in vain.

After 6 years of research, you finally find a clue: the ultimate weapon is in a castle. What is this ultimate weapon? That is for you to discover!
This game was published in the December 1985 of L'Ordinateur Individuel, as a generic Basic listing. The IF Database site reports that machine-specific variations are known to exist for the Matra Alice and Thomson computers as well as my TRS-80 MC-10 port from the Matro version. I know that a French retro-hobbyist has also ported it to Applesoft Basic:

https://www.retroprogrammez.fr/listings/aventure/sorcellerie/

One thing that has always struck me about this program is the parallels it has with the Harry Potter stories:  The idea of sorcerers appearing from a "parallel universe" hidden existence; The attempt by them to take over the non-magical world; A mysterious castle.  It makes me wonder if there was some possible path of inspiration that helped contribute to J.K. Rowling's development of the wizarding world of Harry Potter?

I know that she studied romance languages. A quick search of the internet reveals that: 

"Between 1983 and 1986, J. K. Rowling studied French with a subsidiary (i.e., minor) in Classics at the University of Exeter in Britain."

I'm sure she might have travelled to France in that time period, or after. Who knows, maybe she met someone with an 8-bit computer and played a game of "Sorcellerie" and it helped plant a seed of a parallel world of wizards?  Perhaps the author Rafi Deryeghiyan might deserve some credit in helping inspire one of the most influential stories of our age.

The storyline itself is clearly very different. You can get a sense of the game from the following game map:

Progenitor of Hogwarts?

Here's a text walkthrough by Alex Dijkstra for the Alice 32 version of the program:

"E, E, E, E, PRENDS GANTS, O,  N, OBSERVE LIT (you find some batteries), PRENDS PILE, S, O, DEVISSE
AMPOULE (you need the gloves to do this else you'll burn your hands),  PRENDS LAMPE, POSE
GANTS, E, S, POUSSE TABLEAU (you find a cave behind the painting), ALLUME LAMPE (you need the lamp
and the battery to see in the dark), VA GROTTE, E, PRENDS SCIE, PRENDS FIOLE, O, O, LANCE FIOLE,
PORTE (the acid from the flask burns a hole in the door), VA PORTE, POSE LAMPE, POSE PILE, N, PRENDS
DRAPS, S, O, S, PRENDS GATEAU, S, O, OBSERVE MUR, POUSSE BOUTON, VA PASSAGE, OUVRE FENETRE, OBSERVE
FENETRE, SCIE BARREAU (wit saw), POSE SCIE,  ATTACHE DRAPS, ANNEAU, DESCENDS DRAPS, DONNE GATEAU,
CHIENS (the dogs are killed by the poison inside the cake), S, PRENDS ECHELLE, N, N, N, MONTE DRAPS,
N, E, N, N, E, N, OBSERVE PLAFOND (you see an opening where you can pass), POSE ECHELLE, MONTE
ECHELLE, OBSERVE STATUE (it's an image of satan), EMBOUTIS STATUE (if you don't do this
you will get hit by lightning in the next location), E, PRENDS PARCHEMIN, E, INSERE PARCHEMIN, FENTE
(the text of the parchment now is readable), PRENDS PARCHEMIN, LIS PARCHEMIN. 
You've found the secret weapon you were searching for!! The parchment reveals a way to get rid of all the sorcerers. You obtain the title of superman of the 21st century."

The game is your basic "Basic" text adventure. You explore the castle, figure out puzzles by collecting items and interpreting clues. These lead you to do certain actions that allow you to penetrate deeper into the castle. Eventually you find a parchment that allows you to destroy the wizards.  No Voldemort or "Hogwarts," obviously, but there is a basement with a long abandoned room (Chamber of Secrets?).  Yet the idea of Wizards taking over after coming out of hiding is intriguing. Unless someone can ask J.K. Rowling whether she played a manky 8-bit French text adventure from the mid-80s, we'll never know...

Monday, 2 August 2021

"Sunrise Over Bethselamine" by Armadillo Soft.

"Sunrise Over Bethselamine" is a text adventure program I have converted to the MC-10. I've made many bug fixes and spelling and grammar corrections.  There were sooooo many spelling and grammar mistakes I'd have to guess this program was written by a 13-year-old British kid.  However, it is officially attributed to Armadillo Soft with a release date of 1986, and apparently had a commercial release.

My interest in converting this game started with a comment by posted by boldir (Fri Jul 23, 2021 5:50 pm) over on CASA The Solution Archive.

"I'm currently playing this adventure and I have even fixed it, but nevertheless I get stuck when I have to use the comlink in order to get the code number for the terminal in the small computer room (37). When I PRESS BLACK inside the alien craft (having the comlink and the translator) the message "A voice comes from the comlink, the translator translate it for you, 'calling agent 29326'" should appear. Instead of this, the comlink says 'gargle gloop gleep glop zing. In this context there are two conditions I can't explain to myself: w=0/1 and ww=0/1 (see BASIC lines 663 => 955 and 1050 - 1070). Is there anybody who has any idea?"

My response was the following:

boldir,

That's some messed up code.

The original:

1050 IF X=43 THEN FOR F=1 TO 10: IF G(F)=22 THEN W=1
1051 IF X=43 THEN IF G(F)=7 THEN W=1
1052 IF X=43 THEN IF G(F)=22 THEN WW=1: IF X=43 THEN NEXT F
1057 IF X=43 AND W=0 THEN PRINT "YOU DONT HAVE THE COMLINK": GOTO520
1060 IF X=43 AND WW=0 THEN PRINT "A VOICE COMES FROM THE COMLINK,'GARGLE GLOOP GLEEP GLOP ZING'": PRINT : GOTO520
1070 IF X=43 THEN PRINT "A VOICE COMES FROM THE COMLINK, THE TRANSLATOR TRANSLATES IT FORYOU,'CALLING AGENT 29326'"

Here's what I would recommend:

1050 IFX<>43THEN1080
1051 FORF=1TO10:IFG(F)=22THENWW=1
1052 IFG(F)=7THENW=1
1054 NEXTF
1057 IFW=0THENPRINT"YOU DON'T HAVE THE COMLINK":GOTO520
1060 IFWW=0THENPRINT"A VOICE COMES FROM THE COMLINK, 'GARGLE GLOOP GLEEP GLOP ZING'":PRINT:GOTO520
1070 PRINT"A VOICE COMES FROM THE COMLINK. THE TRANSLATOR TRANSLATES IT: 'CALLING AGENT 29326'":PRINT

Basically this routine was supposed to be checking that you have both the Comlink and the translator when you push the button. If you don't have the Comlink, it was supposed to tell you that you don't have it. Or if you have the Comlink, but not the translator, it transmits a gibberish message. But if you have both, you get the message with the code number.  The problem is that the programmer uses multiple IF statements sandwiched between a FOR/NEXT loop, with the NEXT actually in one of those IFs, so it doesn't necessarily get triggered.  So the loop doesn't function properly.

My new version works. It disentangles the IFs from the FOR/NEXT loop and properly organizes the variable flags W and WW for signaling whether you have the translator and the Comlink.

Boldir also posted this concern:

"I think the problem lies deeper. It's not enough to get the comlink and the translator to receive the necessary message; I've noticed that the program (randomly?) swaps the collected objects, eg at room 15 (the apartment of the hotel receptionist) it happened that, when I dropped the glass cutter and took the comlink, the cutter was in this room when I looked again, but the inventory still shows the glass cutter, and the small box that I had before was gone! It has also happened that I had two laser pistols in my inventory, so I suspect that the comlink or the translator could be exchanged for another object without being noticed in the inventory. I have no idea what's going on here; I've played the adventure many times and only happened to get the correct message once although I've always owned comlink and translator."

I was able to find this problem as well.  There was simply an incorrect variable used in the loop used to reorder the "items carried list" after you use the Rope. That item needs to get removed from the items list once it is being used (i.e. dangling down the side of a building).  But the incorrect variable would simply corrupt the items list instead of reordering it after deleting the Rope item.

I made many fixes (but there are other minor one's I can't recall).  Here's a rough list:

  • Player of the Sinclair original will notice some corrections to the directions involved in entering and leaving the apartments on the floors above Steve's.
  • The routine for using the rope is fixed. Now it doesn't garble the items list.
  • Now Steve does not make his "gormless" remark until after his initial speech when you enter the room.
  • To get access to Steve's room you had to say your name into a "speach grill"--> "speech grill" (microphone would have been better).  This is the kind of typo stuff I corrected.  I also replaced lots of commas used to separate clauses with separate sentences using periods.  I added lots of missing apostrophes to contractions.
  • The routine for wearing the crampons and removing them from the items list now works as the programmers intended (I think).
  • The routine managing the Comlink and the translator interaction so that you can hear the secret code number is now working properly.
  • Some quirks with the card routine sorted (it was a little mixed up with the "WEAR" routine.
  • The directions from the West and East sides of the bottom of the cavern were fixed. When you select "DOWN" in those locations, you would be taken back to room 1 (your ship on the landing pad at the start) as the missiles came in that were launched by the GLOBE ship at the bottom of the cavern.

Additions/changes:

  • Instructions at the start (so you can know your own name, which is necessary for the game).
  • Line numbers point to specific line numbers for subroutines.  The Speccy allows pointing to non-existent line numbers and just jumps to the next line number in sequence in the code.  This should allow for easier porting to other versions of Basic
  • Use of my word wrap subroutine at line 1 for printing most messages.  Just change the "32"s in that routine to switch it to other screen widths.
  • Lots of shortening of descriptions to fit within the 128 character word limit of the MC-10.  My hope is that nothing of value has been lost.
  • New simpler graphics replacing the ones for the Speccy version. Just change line 2150 to a CLEAR SCREEN command for your system and a RETURN to get rid of this feature.  It doesn't affect game play.
Original Sinclair Version

I'm not sure exactly how the graphics worked. But guessing led me to have four basic graphic images for four main "stages" of the game.  When you (Jason) are exploring, you just see a human figure.  When you're in the "planet hopper" you see a little ship graphic.  When you hanging from the building, you see a figure with a rope.  And when you're using a "computer terminal" you see a little graphic of a computer and keyboard.  If anyone can enlighten me about the graphics in the original, it would be much appreciated.

For a complete listing of the code look for the highest numbered "SUNRISE" file here: https://github.com/jggames/trs80mc10/tr ... es/Sunrise

And here's a complete walkthrough (SPOILER ALERT):

https://youtu.be/4Rpj5X2KrGc


Friday, 30 July 2021

"Euchre for Two" by Victor J. Raybaud

I have converted the program "Euchre for Two" Victor J. Raybaud to TRS-80 MC-10. It's from a listing in The Best of Creative Computing (Vol. 3, 1980). Originally for the Univac 1106, I had to debug it for Micro Color Basic operation. For example, it contains many uncompleted FOR/NEXT loops, which needed to be dealt with. Also, there was a recursive use of GOSUB. I suspect that the Univac could easily handle these techniques without problem, but they were causing hiccups for 8-bit Microsoft Basic. I also found some formatting bugs for the main card layout screen, which I also fixed. Or at least they seem like bugs, but perhaps there is some strange nuance to Univac Basic string formatting that somehow eluded me.

It was somewhat puzzling why I couldn't find  working version of this program that you can run in any of the regular online software repositories that I keep track of. I think that it is possible that the quirks of Univac Basic that I had to find work-arounds for might have frustrated enough people back in the day, that the program was unable to make the leap from the Univac to the 8-bit personal computer world. Lack of 8-bit distribution could easily prevent copies from surviving to the current day. It's a big complex program, that would be very intimidating to type in. The line numbers skip by 100s and have leading zeros, which adds to the intimidation factor. Coupled with the quirks, which would have been very frustrating to hunt down in the old line editor environment of the home machines of the day, and you have a perfect recipe for a "missing program."

It's sad that the game seems to have been lost, because it is a wonderful piece of early artificial intelligence programming.  It plays what appears to me to be a reasonable version of a complex card game.  There's bidding that requires predication. Some of your cards are hidden and some are displayed, which demands strategy to manage well. Like many of the programs of the Creative Computing crowd, it has an elegant simplicity to its user interface.  I typed it in with the idea of converting it to a new small graphic "card set" that I had developed recently:

But in the end I didn't want to mess with the elegance of the original.  So perhaps on some other future card game project I'll find an opportunity to use the new graphic card set.

I've also been fiddling with another David Ahl/Creative Computing conversion. I did "Hockey" this week.  It's a simulation from David Ahl's 1978 collection. There were a number of typos, such as wrong line numbers and garbled variable names, in the TRS-80 source code that I worked from, which I corrected. There was also an error in the original source.  In the routine  that allows you to take a shot from the Red Line (i.e. no passing selected), the option 2 subroutine just bleeds into the option 3 routine, so that you would get both result messages.  Since most people would only select option 1 (slap shot), I suspect the original programmer didn't notice the problem in his debugging.

I had to use my word wrap routine for the messages, since the MC-10's screen is so confining, but I think it looks pretty good.  It plays like the transcript of an old fashioned radio broadcast commentary.

I am currently working on the Ahl card game "War." It's a very simple game, so there is not a lot of incentive to complete the project, but I'll get to it eventually.

I've also done a number of conversions from Australian Coco magazine, including "AUSMAP" which I blogged about last week.  But I also did a game called "Space Bar Bandit," which is a simple slot machine simulation:

I also spent a little time working on some variations of the classic 10PRINT program. I was inspired by Robin of 8-bit Show and Tell, who looked at a neat new "orthogonal" variation of the program created for the Commodore 64.  That version was supposed to fit in just 32 bytes and was written for a programming contest.  Inspired by his vid, I created a new shorter version of my own "orthogonal" version of the 10PRINT program.  As typed in, it should be less than 32 bytes. In the video jump to the 50 second point to avoid my excruciating typo at the beginning:


All this prompted Emerson Costa to a do a little refining of his own for the Brazilian MCE-1000 8-bit computer:

https://www.facebook.com/groups/mc1000/posts/2573299429388227/

https://www.facebook.com/groups/mc1000/posts/4456715507713267/

I also created a version of the program using the SG6 screen mode.  This one creates a maze that should be functionally equivalent to the one created by Commodore version:

Finally, I don't think I have blogged about a simple game I converted from the Sinclair ZX81 last week. It's called "Space Taxi" which many folks pointed out was the name of a famous Commodore 64 action game. Robin from 8-Bit Show And Tell mentioned:

"this is both 1) a super-early example of an "infinite runner" game and 2) has the same name as a legendary Commodore 64 game, but was made 2 years earlier! Neat game, too bad it's so unfair at the beginning of each screen with random spawn positions."

So the game is not a rip-off but a trailblazer for a neat game title!




Monday, 26 July 2021

Some Australian Coco Magazine Stuff

5 REM*****************

6 REM*  AUSTRALIA    *

7 REM*BY ALAN BRIDGES*

8 REM* SEPTEMBER 1984*

9 REM*****************

Published in Australian Coco Feb 1985.

This is a screenshot of the original map:

The following is a recommended change by Mike Garcia who I'm assuming is a dinkum (us Nova Scotians would say "right good") Australian:


I've moved the 3 and the 2 up one space and to the right one space each. That's my best guess from looking at a map. What do you think looks more accurate?

Addendum:

Darren Ottery, who  I know for sure is a dinkum Australian, confirms that the second version is "as close as it can be on a 32x16 grid."  So I have uploaded that version to my repository sites.



Wednesday, 7 July 2021

Elon Musk's Early Type-in Game "Blastar"

I have ported the Basic game "Blastar" to the TRS-80 MC-10. This game was made by Elon Musk at the age of 12 for the Spectravideo 328, a relatively rare 8-bit computer of the time. More info can be found in an article from the Verge e-zine and in this thread from a Commodore forum: https://www.lemon64.com/forum/viewtopic.php?t=71960&sid=0f7d81624f50e2fd49b87e30b92dba9c

There is a modern web port, which allows you to play the game online. It can be found here: https://blastar-1984.appspot.com/

I hope my version might provide an experience a little more like the original program, since it is still in Basic and running on a 8-bit system architecture, rather than being a port to a modern web language/environment. The web update strikes me as something of an amalgam of sped-up features and artificially slowed down features. I'm not sure if the author is using some kind of emulator for the Spectravideo 328 or has translated the features of the program to a modern web language environment. The following shows an update of my first version of the program (as seen in the video above):


In most of the blurbs discussing the program on the Net, there are two statements made that I think might be errors. It is often mentioned that the program was made for the Commodore VIC-20. This is not the case, unless there are different versions out there about which I am unaware. The Spectravideo 328, an early MCX-like 8-bit computer, seems to be the system used by Musk. Also, it is often stated that Musk was paid $500 dollars for this program. This seems too high compared to my sense of what people typically were paid for programs by magazines at the time. I wonder whether Musk was paid something worth approximately 500 Rand, and simply failed to properly translate that amount into "American dollars" in his discussion of his first program. My sense would be something like US$50 - $150 would be more normal, but I could be wrong about this estimate.  However, Simon Goodwin's article "Writing for the early UK Home Computing mags" suggests that something between £5 to £90 (exchange rate was about 2.3 at that time) was closer to the norm for what he earned early in his career.

The magazine in question is "PC and Office Technology" from December 1984:


The game code for my port can be found here:
https://github.com/jggames/trs80mc10/tree/master/quicktype/Arcade/Blastar

Thursday, 1 July 2021

Walter Bright's "Empire" in Basic: Updates

 


Once again I'm indebted to my son Charlie for making invaluable suggestions for the improvement of the game.  The main one is that he pointed out some inconsistencies in the movement of units.  I hadn't made it so that an attack on a unit was counted as a "move."  Nor had I made it so that an attacking piece, if possible was to occupy the space of the defeated unit.  In our first attempt at a real game together, Charlie pointed out that this would allow a unit to launch an attack, and then effectively outrun any attempt at pursuit by nearby enemy units.  So I made some major revisions that now mean when an attack is launched, the winning piece will, if possible,  occupy the space of the unit being attacked.  Also, for units with higher than 1 Str, attacks will continue until a resolution of combat has been determined.

Of course this also pointed towards other issues.  If an attack was launched by an Army unit from the shore on a sea unit, what happens?  The rule document I was working from noted this possibility.  It explicitly states that even if an army unit is victorious over a naval unit, it is "drown."  So I added that feature too.  The naval unit, of course, in reverse, can't occupy an army's space, but a move is at least registered for it.

A similar problem of movement was also noted by Charlie.  I hadn't registered it as a move when an army was disembarked from a Transport onto the shore.  Each army started with a fresh move count.  But as he pointed out to me, this could mean that an army could be disembarked to reveal areas of coastline, then reembarked, the Transport moved down the coast, and repeat.  It's little things like these that I often overlook, but Charlie, with his mathematical mind,  notices right away.

Charlie also requested and contributed some aesthetic changes.  Not having been raised on the MC6807 screen, he didn't like the fact that the normal uppercase characters of the first player blended into the green colour of the ground.  He felt this was like ships "carrying around" pieces of ground with them. It also made it hard to distinguish where channels were.  So I changed to the alternate text colour set.  This way the units of both players are separate from the green land colour, and the message bar at the bottom of the screen is also distinguished from the land.  Of course, because of quirks of the MC-10, this makes playing sounds problematic, because their use automatically switches the VDG back to the regular text mode.  So I changed the beep I had been using to provide feedback for key presses. This beep was necessary because sometimes minor delays could make it seem like a key press hadn't registered.  So I used POKE commands for a key click that doesn't switch the VDG back to regular text mode.  Charlie also provided some musical refrains for victories and defeats.  So the screen flashes back to regular mode briefly for these.

Finally, Charlie pointed out that if two players were physically present with each other during play, they would be able to glimpse the screen of the opposing player between turns, after a player had hit Y to the "End Turn" prompt.  So now, there is an intermediate pause screen, which also prompts the user with the possibility of quitting and saving the game.  This addition was good, because previously I had not given any notification of the game save feature.

I was able to have memory space for all these changes because I had noticed that I had assigned the main string array elements directly using their numbered variable elements, like this:

M$(30,2)="......

Instead, I switched to DATA statements, which I just READ at the beginning using a simple FOR/NEXT loop:

DATA"....

I had forgotten that Microsoft Color Basic is smart enough to assign strings initialized in this way, simply by pointing to the original READ location of the string, rather than using string space.  Then, when I POKE these strings with new information, the string in the DATA statement in the source code is modified in memory.  This change gave me an extra 500 bytes or so, which allowed for more elaborate messaging, and the updates described above.

All these updates can be viewed on my Github:

https://github.com/jggames/trs80mc10/tree/master/quicktype/Strategy%20%26%20Simulation/Empire

Thanks to Charlie, who is off to Halifax to look for work and begin his life away from home. I'll miss his invaluable contributions to my programming efforts, but he's off to pursue programming efforts of his own.  God speed my boy!

The game "EMPIRE" can be played online here: http://faculty.cbu.ca/jgerrie/MC10/JG_MC10.html


Sunday, 27 June 2021

Walter Bright's "Empire" in Basic

I've made a version of Walter Bright's 4X Ur game "Empire" re-coded in Micro Color BASIC for the TRS-80 MC-10. It's for two players. The control is by arrow and Enter key and Yes or No prompts.  Running into enemy units initiates combat or other actions, such as repairs.  My re-code is based on a description of the game play and unit stats found here: http://www.catb.org/~esr/vms-empire/vms-empire.html 


The most important information from that site was the details about the units and about how combat is carried on. The units are as follows:

PieceYouEnemyMovesHitsStrCost
ArmyAa1115(6)
FighterFf81110(12)
Patrol BoatPp41115(18)
DestroyerDd23120(24)
SubmarineSs22320(24)
Troop TransportTt21130(36)
Aircraft CarrierCc28130(36)
BattleshipBb210240(48)
SatelliteZz10----50(60)

I think I have all the basics of combat working.  In brief, you have a 50/50 chance of doing your strength ("Str")  worth of "Hits" damage to an opposing unit.

Saving and Loading Games

If you hit Enter when your cursor is on open land or sea, you will be prompted to end your turn.  Hit Y to let the other player have their turn, or N to continue with your turn.  If you hit Q you will be prompted to save the game.

The program creates two files when you select Q: The self-modified game program (EMPGAME) and a data file (EMPDATA) for the main array. By this method, games should be able to be played across the Net by sharing these two files between two people with VMC10. My son Charlie is moving to Halifax. I hope we can have a few long distance "mail-chess"-like games to keep in touch.  When you CLOAD and RUN the EMPGAME program file, just select N in response to the "New Game" prompt, and then hit Enter to load the EMPDATA file created along with that specific EMPGAME file.  Don't mix and match these files, or the game will be confused and not work.

The self-modification of the game source is to a 30 element string array with 64 character long strings.  There are three such array structures.  One for the base map.  The other two for storing the "fog of war" that each player sees.  There is also a 2 X 50 array for the Unit information for each player, with the base 0 element for storing basic info about what is under each unit being moved.  So each player can have a max of 50 units.  The original game had a 100 by 60 map, which apparently was the largest matrix that could be printed on a DEC printer of the time.  But compromises had to be made to fit the map into a 20K Tandy MC-10.  Still, I don't think it feels particularly cramped.


Movement

A feature that also might not have been in the original is map edge wrapping.  When your cursor or units move across the edges of the map (64X30) they wrap around to the other side.  As Charlie pointed out, this is hardly like a real globe represented in 2D, but again compromises had to be made.  In my version, the satellites take advantage of this feature to be able to engage in continuous diagonal movement to reveal portions of the map.  Also, in my version, you have to activate satellites each turn for them to make their 10 move sweeps.  This is perhaps something that should be done at the beginning of a turn.

There is also no dynamic updating of the fog of war (so a satellite might be especially handy). Your units only see what they last saw in the 8 units around them as they moved in your last turn.  In between your turn and your opponent's turn, this information might become "outdated," which can cause some ghosting of enemy units.  However, whenever you select one of your units, it will re-scan the immediate surroundings.  It's up to you to figure this all out, by careful use of units to get updated information.  The Fighter is particularly useful for getting up-to-date information, since it can move 8 spaces each turn.  But be careful it runs out of gas after 32 total moves.  So gas up regularly at cities or aircraft carriers.

The movement uses Greg Dionne's trick for key sensing, which makes it possible also hit two keys together (from the AWSZ keys) to get diagonal cursor movement.  However, you have to to be careful to hit both keys simultaneously.  Motion is reasonably fluid (given all the fog of war stuff) and the keys can be held down for continuous movement.

Unit Reports

Messaging and other flourishes have been kept to a minimum since so much memory is used for all the string and numeric array data.  There are no explosion sounds or verbose messages.  Destroyed units just disappear.  Old messages stay on the bottom of the screen until replaced by new ones.  The messages are terse.  When you select units you will usually see:

UNITNAME #

The # is the amount of hit points/strength the unit has left.  Many units simply have 1 unit of strength, and are one-hit-kills, so this info is only useful for units like Carriers and Battleships.

Loading and Unloading Transports

For units like the troop transport you first get a report of the number of armies contained and a prompt to unload if any are present.  The Fighter adds a prior # which represents the total range left before it must be refueled.  Armies can bump into your own Transports, at which point they will be loaded.  They can then be transported across water.  Just choose "Y" to the prompt to unload when you select transports to disembark armies on adjacent land.  You must do this for each army individual by reselecting the transport and hitting Y.  There must be available land in the surrounding 8 spaces.

Repairs and Refueling

Another compromise is that fighters can't be landed and moved around on carriers like armies can in transports.  Instead, fighters can accompany carriers and simply bump into them when they need to refuel. Similarly, when ships are damaged, they simply need to bump into a coastal city to get a repair point back.  They can only do this once per turn.

The two players are demarcated by different cursor colours. The first player is red, the second is cyan.  The first player has light green characters.  The second player has "reverse" characters (i.e. lowercase as in the table above).  You select units by moving the cursor over them and hitting Enter.  The cursor then disappears and you can just see the unit.  Move it using the arrow keys.  When you run out of moves, the cursor reappears.  You can end a turn early though by hitting Enter again.

City Menu

Selecting a city unit shows what is currently being produced by the city and the number of turns to go before it is ready.  If you hit a number from 1-9 you can see what else can be produced and how many turns they take (plus a additional amount for the first unit produced--see the last column in the table above).  You must hit Enter to make such a change in production.  Otherwise, hit 0 or any other key to abort the city function and return to cursor movement.

Winning

When one of the players destroys all the units of the opposing player, they are declared the winner.  To play again the program must be re-loaded because the array strings have been modified in the actual Basic source code.  To prevent possible confusion, a NEW command is issued at the end of the game to wipe the game from memory.

So, if you have a hankering for playing what Bright's attempt at originally coding the game in Basic might have been like before he abandoned it in order to code it in the "superior" language of Fortran, this is your game.  If you want to find out more about the history of the game, see Bright's page: http://www.classicempire.com/history.html