Game 201: Starfleet Orion

Starfleet Orion, the first collaboration of Jim Connelley and Jon Freeman at Automated Simulations, is just about the most awkwardly designed computer game I've played in my life. Conceptually I dig it; it's a two-player tactical space ship combat game with Star Trek-like battle mechanics but deeper, and up to nine ships per side, each one of them customizable with different stats, weapons, engines, shields, and armor. A scenario editor program is used to create your own battles by defining the fleets down to the individual ships comprising them, setting parameters such as how far the torpedoes can fly or how big the missile explosions are, and even custom victory conditions. But oh man did they have to cut corners on usability to get it to fit in an 8KB PET. And some of its shortcomings can't even be blamed on the memory limitations.

Emulating it properly was a frustrating exercise in trial and error too. At VICE's default settings, missiles would often fly way off-course, torpedoes would travel in nonsensical trajectories, and the game would frequently prompt me to escape when I was merely trying to fly my ship into melee range. I almost wrote this off as unplayable until I discovered my problem; VICE should be configured to emulate a PET 3008, with the Basic 2 Graphics ROMset. Then you must save the settings, restart the emulator, and things should work correctly.

There are two instruction manuals, and it's necessary to read both to understand either. First, there is the rules book, providing a general but incomplete outline of the game's premise, controls, and setup instructions. Also, a (barely legible) printing of the BASIC code, in case the cassette tape becomes unplayable. I don't think I've seen that done before in a commercial game before. Second, there is the battle manual, with historical background, a better explanation of how weapons and subsystems work, and most importantly, wargame-like setup descriptions of each of the game's twelve stock scenarios, each accompanied by a short backstory.

Most of them are really badly written.

The setup descriptions are crucial because, as it turns out, these scenarios aren't part of the game's files! To play one you must run the scenario editor, type in the data listed in the scenario description (itself an onerous and confusing task requiring you to cross-reference multiple sections of both manuals), save the scenario file to a blank tape, and then run the "battle program," from which you can load the scenario data from the tape you just recorded it to. Only then can you play. The original tape did, at least, contain the first scenario preloaded onto it, but the only copy of the original PET version that I could find lacked even this, forcing me to come to grips with the confusing scenario editor before I could play anything.

Scenario #1 is a fight between two medium-class frigates of equal stats except for armaments.

A table that you must cross-reference when entering the ship stats

Through referencing the setup page, the ship table, the rules manual, and a lot of trial and error, I figured out exactly what to type into the builder program.

Mistype anything here and you'll just have to soldier onto the end before you're allowed to re-enter things, which has got to be amazingly irritating when entering data for a full fleet of nine warships.

Once I had the scenario keyed in and saved to a tape, the builder program ended and I was back in BASIC. So I ran the battle program, loaded the scenario tape, and set out to try to figure out how this game works.

So sparse, yet so confusing.

I more or less figured things out, through frequent manual checking and experimentation. This introduction scenario, intended as an exercise in learning the gameplay flow and mechanics, pits two medium-class frigates against each other, which are equal except that one is armed with medium-range missiles and the other is armed with long range torpedoes.

Each ship may be given orders, and to do this, you first hit the letter "O" and then are prompted to enter the number corresponding to your ship. In this scenario where there are only two ships per side, "1" corresponds to player 1's ship, which is to the upper-left and armed with laser beams and missiles, and "101" corresponds to player 2's ship, which has inverted color and is armed with laser beams and torpedoes. It's up to the players to not cheat by looking at the screen while the other gives orders, or by giving orders to the other's ships. After initiating orders to a ship, you are given a sequence of queries.

First, there's a prompt for horizontal movement, followed by one for vertical movement. The Pythagorean vector cannot exceed your engine specs (e.g. 4 right 4 down ≈ 5.66, which rounds down to 5), and the actual distance moved is inversely proportional to your ship's mass (5 movement points on a 0.81m ship = 6 spaces moved).

Once you initiate orders, there's no way to undo them or cancel the process, and invalid moves are countered with terse messages that are incomprehensible without the manual. On top of that, there's an extremely nasty hiccup. If you ever hit "enter" without answering the prompt, the program terminates and you're dumped back to BASIC.

Arghhhh!

After movement input, you're prompted to direct the ship's energy beams.

Here and from here on, it will tell you how much energy you've got left. All ship operations use energy, and you've only got so much of it per turn.

Beam weapons are fairly simple. You don't have to aim them, you only have to specify an amount of energy to direct and to identify your target. The farther away you are, the less likely your beams are to hit, especially against smaller ships. On a hit, damage done is a function of distance and energy. Each ship has a beam strength value, which is 5 in this scenario for both ships, and the amount of energy put into a beam attack can't exceed this number.

Next you'll be asked how much energy to put into shields. This amount can't exceed shield quality, which is 2 for each ship here. Shields and armor reduce damage taken, and the maximum amount allowed here is enough to nullify a weak beam attack and almost nullify a near-miss from a missile, but a direct hit from a missile or torpedo will devastate no matter what.

Next there's missiles, if the ship has any. Each missile launched costs one energy point, and you can not launch more missiles per turn than you have tubes. For each missile launched, you must enter coordinates relative to your ship's position, and the distance from your ship can't exceed the scenario's missile range limit. Your missiles will explode at those coordinates, and can damage ships close to the explosion or provide cover against torpedoes.

Finally, torpedoes, unlike missiles, only need a specified direction, and they will travel from your ship in that vector until they fly out of range, hit a ship, or hit a missile explosion. Torpedoes generally have longer range and higher damage than missiles, but cannot do damage without a direct hit. This scenario is missiles vs. torpedoes, but on ones where ships have both, you only fire torpedoes if you did not fire missiles.

After all ships on both sides are given orders, or earlier if you prefer, hit "M" to execute all orders in sequence.

With these mechanics figured out, I played this scenario out with my friend "B" (with reasonable allowances for social distancing). He took the torpedo ship, and I took the missile ship.

For a few turns, we did a lot of maneuvering around at medium range, where I theoretically had an advantage. Landing hits other than beams seemed nearly impossible; it's hard enough to figure out the space coordinates necessary to launch missiles, but you also need to launch your projectiles into the coordinates where your opponent will be, not where they currently are, and you're supposed to look away when your opponent enters orders, and therefore won't know where their ship will move to. Beams didn't seem to be doing very much damage either.

Eventually, he landed a direct torpedo shot after correctly guessing where my ship would jump to, and while this didn't kill me, it did enough damage to put me at a significant disadvantage. More damage means less energy per turn, which means fewer things you can do, and damage can also affect specific subsystems, making them perform worse. I forwent maneuvering and focused on my shields and weapons, beamed him again and landed a few accurate hits with my missiles, but before long he landed a second torpedo on my drifting hulk, blowing me up.

One of the battle program's limitations is that it doesn't know who won, even one player annihilates the other side. It's up to the players to recognize and judge victory conditions, which can be very complex in some scenarios.

We tried a second scenario, called "Blockade Runner." In this one, a crappy little corvette called the "Rum Demon," armed only with missiles and with enough energy to move at full speed or fire missiles but not both, has to take off from a planet and flee the screen off the left side, while pursued by two slightly better corvettes.

The starting setup.

"B" took the Rum Demon, and frankly this scenario seems stacked against it. The blockading ships are just as fast as the Rum Demon, better armed, possessing both beams and missiles, and with 7 energy points compared to the Rum Demon's 4, allowing them to match its speed and still fire weapons after chasing. Should the Rum Demon take any damage at all, and fail to damage at least one enemy, then the undamaged pursuer will quickly overtake it and finish it off, being able to move at full speed and fire on the same turn.

"B" evaded my attacks for a little while as he inched his way to freedom, but didn't get far before a beam attack hit his engines, leaving him unable to do anything but move one space at a time and fire a few ineffective missile attacks. My ships cornered him and missiled him to death.

Maybe there's a good strategy that the Rum Demon can use to survive, but I can't see it.

That was all we played of Starfleet Orion. There are twelve scenarios in total, and even though we both had fun, there's a significant time investment involved in coordinating a multiplayer game like this, and even this much was trying his patience. The final scenario, a skirmish involving full fleets of battleships, cruisers, and a planetary defense system is estimated by the manual to involve a six hour play session!

I've therefore decided not to rate this game, but am very impressed with the gameplay balance and depth crammed into its tiny 8KB footprint. This is probably the most involved 8-bit BASIC strategy game I've seen yet, and Jon Freeman's experience as a game designer shows. It remains to be seen if it holds up with extended play, but given the requirement of finding a partner willing to tolerate its arcane presentation, spartan interface, and coordinating time for both of us to play, I doubt I'll revisit its two-player action any time soon, and certainly can't recommend it to general audiences. But if you're into wargames and old computers, can tolerate some seriously awkward design, and have a likeminded friend, then by all means give this a try.


In the sequel, Invasion Orion, the Orion cluster, now controlled by the Stellar Union, is invaded by a race of robots called the Klaatu, who were built by the Krell in order to replace themselves, for some reason. Worlds collide, and facing an invasion of the body-snatchers, the Stellar Union marshals a desperate and total war of the worlds of Orion against these things from another world, to send them back to where they came from outer space.

Invasion Orion adds an AI routine and its scenarios focus on the singleplayer experience. In fact, multiplayer is discouraged; the scenarios are often heavily weighted against one player, and are only interesting to play because the stronger force is given to an AI incapable of understanding victory conditions other than total destruction of the enemy, and will not use tactics other than aggressive, single-minded pursuit of this.

But I couldn't get it to work right; the scenario builder program kept outputting corrupt files that the battle program couldn't read. What makes it even more infuriating is that I got this to work exactly once, and just haven't been able to replicate this a second time even with the same scenario data input.

So I'm moving on, to Temple of Apshai, and the finicky world of TRS-80 emulation. Wish me luck!