Game 49: Star Raiders

Buy 50 Atari games including the 5200 port of Star Raiders in the Atari Vault DLC on Steam:
https://store.steampowered.com/app/1104680/Atari_Vault__50_Game_AddOn_Pack/

Note - Star Raiders' exact chronology is fuzzy. It appears to have been code-complete in September 1979, but not formally released to the market until March 1980. As the date of completion interests me more than the date of official release, I'm considering this a 1979 title rather than a 1980 one.

We’re introducing a new platform, listed on Mobygames as the “Atari 8-bit,” but it’s more of a family of mostly compatible products than a single platform. These were Atari’s line of home computers, and the models available in 1979 were the Atari 800 and the Atari 400.

First produced in November 1979, Atari was a bit late to the microcomputer party. 1977 saw the release of Radio Shack’s TRS-80, Commodore’s PET, and the Apple II, which we’ve dabbled with already. But as Atari was a gaming company, their line were among the first personal computers designed with games in mind, and featured a faster CPU than the competition, colorful game-oriented graphics hardware, TV-compatible video output, joystick ports, and cartridge slots. Two of Atari’s later consoles were based on this architecture; the Atari 5200 which was nearly identical to the Atari 400 internally, and the Atari XEGS which was fully compatible with the computer software and peripherals.

Our first whale from the system was its original killer app, and takes advantage of the computer’s cutting-edge gaming muscle. The 2600 would later get a much downgraded port and the 5200 a slightly upgraded one.

Star Raiders puts you in the cockpit of a state-of-the-art fighter with a mission to clear Atarian space of hostile Zylon starfighters, with a secondary objective to protect friendly space stations, which the Zylons will systematically target and destroy when they aren’t engaging you. Your ship is far superior to any Zylon’s, with a top speed twice as fast as theirs, damage-mitigating shields, and a hyperspace drive for intercepting Zylon Starfighters or retreating to a friendly space station. But you are severely outnumbered, and haven’t got much time to thin out their ranks before they overwhelm and destroy the space stations, which are your only recourse for repairs and refueling.




Starship 1 is an evident predecessor to this game, but Star Raiders adds a great deal of complexity to the simulation (much of it borrowed from Star Trek), making it a trope codifier for the space sim genre. Elements introduced include:

• Navigation of 3D space, or at least a more convincing imitation of it
• Ability to pitch and yaw 360°
• Multiple engine speeds
• Multiple cockpit views
• Enemy ships that can engage from any direction
• Functional ship subsystems (e.g. shields, engines, radar), which can be disabled by enemy fire
• Separate joystick and keyboard controls for managing different ship systems

There’s also a fair bit of strangeness as a consequence of the genre not being fully developed yet.

There is no concept of hull damage. When your shields are down or turned off, a single hit will destroy you. When your shields are up, a hit depletes some energy (not a big deal) and has a random chance of disabling a subsystem (often a really big deal). Your unshielded enemies likewise go down in one hit, though the “Basestar” ship must be hit at a fairly close range.

Trying to get enemies aligned to your crosshairs before firing is actually a pretty bad idea. If an enemy near the center of your screen fires at you, it’s nearly impossible to avoid getting hit. Hit detection seems to be based on sprite collision, and because you fire torpedoes from the bottom of the screen to the center, it seems to be much safer and more effective to keep your crosshairs above the enemy and to the side a bit, so that the torpedo sprite hits the enemy sprite, as little sense as that might make in terms of 3D euclidean space.

Energy management is a thing, and you can optimize energy efficiency by turning off your battle computer and shields when you don’t need them, by making multiple short hyperspace hops instead of a single long one, and being frugal with your torpedoes. But in practice this seems pointless, as on any difficulty level except the easiest, I found myself needing repairs often enough (which also refuel you) that I never came close to running out of energy no matter how wastefully I treated my reserves. Players who can survive the Commander Mission might find energy efficiency techniques useful for finishing with a better score, but I didn’t.

Speaking of the Commander Mission, try as I might, I just couldn’t finish it.



I was able to finish the Warrior Mission, the second-hardest difficulty, without too much trouble, as seen in the first video. But the Commander Mission seems hopeless. Enemies dogfight aggressively, making it nearly impossible to completely avoid taking hits, and your ship takes hits like it’s made of cardboard.  With nearly every sector cleared, something important would get damaged, and I’d have to warp back to a base for repairs, giving the Zylons plenty of time to regroup and overwhelm the bases. And I’m supposed to destroy 54 of them? I’d be lucky to bag 20. Each attempt at the Commander Mission would end long before I reached my 54, usually with a hot-dogging Zylon scoring two lucky hits in quick succession, blowing my ship to smithereens faster than I could blink.

Stellar Track

Star Raiders got a downgraded VCS port later on, but before that, there was Stellar Track, a much more literal interpretation of the mainframe Star Trek game that inspired it, and which I covered previously. A reader alerted me of this game's existence.

Like the mainframe game, it's text-based and plays round-by-round, which is unusual for games on the system. It's obviously downgraded to fit the Atari's limited resources and simple controls, but I am impressed by how much left is intact. Granted, controls are a bit awkward. The menu-based control scheme of the mainframe game is translated to the joystick by having left and right cycle through the available options and the button confirming, with no way to back out of a mistakenly chosen command. There's no option to enter courses along decimal numbers, but I never used that option anyway.

I played with both difficulty sliders set to 'A,' which reduces your "phasor" power and makes you more likely to take subsystem damage when getting hit.



I have some gripes specific to this version, which have nothing to do with the system's limitations. Compared to the mainframe version, the time limit tends to be VERY tight, and you're often at the mercy of the RNG. Granted, the mainframe version could sometimes screw you over with an impossible deadline, but it's a lot more common here. A mission with only a few aliens will still spread them across the galaxy and give you precious little time to search the entire grid for them all, and if you take damage to your engines even once, you might as well give up; you can't get anywhere until they are repaired, which takes time that you don't have. It's also a bit obnoxious that your short-range scan isn't a free action; there's no point in trying to dogfight without using it first, so your enemies effectively always get to take potshots at you, increasing the odds that they damage something you really need.

Game 48: Star Trek

Download or view my fixed codebase of Star Trek here:
https://drive.google.com/file/d/1VKuxtBAXf7pWR5NRAnSHdbQT-lQMTKdW/view

Download a compatible BASIC interpreter here:
http://www.moondew.com/basic/

The next whale is Atari’s Star Raiders, which was apparently an action-oriented remake of the popular mainframe computer game Star Trek from 1971.

Star Trek's original code was written by Mike Mayfield on his high school’s Sigma 7 mainframe, and was played on a teletype. That original codebase has likely been lost to time, and I wouldn’t know how to get BASIC files onto a SIMH-compatible disk image or how to use them. Fortunately, his subsequent rewrite to HP BASIC in 1972 does survive, and there is an HP BASIC interpreter that runs natively on Windows.

Unfortunately, I found multiple versions floating around, none quite as suitable as I would like. The first, which I will refer to as “Decode Systems,” has bugs in it which entirely prevent the Enterprise’s warp drives and torpedoes from functioning correctly. Another version has extensive differences and appears to be a relatively recent port to a different platform.

A third, which I will call “Pete Turnbull,” is more similar to the Decode Systems version but has several differences. It does not have the bugs that would prevent the warp drive and torpedoes from working, but does have a bug that prevents the game from even starting, and some misspellings.

My best guess is that the Pete Turnbull version is the original or closest to it, and the Decode Systems version’s differences are from manual transcription errors or deliberate correction. Perhaps the bug that prevents the former from starting is due to a lenient behavior in the original BASIC interpreter that isn’t allowed in more modern ones, and this bug was fixed in the Decode Systems version, while new ones were introduced by transcription error. The bug is easily fixed by copying the relevant line from the Decode Systems version into the Pete Turnbull version, and this is what I have done.

260  DIM G[8,8],C[9,2],K[3,3],N[3],Z[8,8],   D[10] Line 260 from Decode Systems 260  DIM G[8,8],C[9,2],K[3,3],N[3],Z[8,8] Line 260 from Pete Turnbull

Was the D[10] tacked on by a transcriber who discovered the code wouldn’t run without it?

1950  A$="  " Line 1950 from Decode Systems 1950  A$="   " Line 1950 from Pete Turnbull

That omission of a single space in the former line prevents the Enterprise from warping anywhere. A manual retyping error, perhaps?

Star Trek is about exploring strange new worlds, seeking out new life, new civilizations, and boldly going where no man has gone before.

Just kidding. It's a strategy game about blowing up Klingons. And it sort of plays like a cross between Battleship and Minesweeper.

The warning mattered back when this was played on a Teletype.

There are a whole bunch of things that aren’t adequately explained here. The entire game is played by entering series of commands to the Enterprise. The galaxy is a two-dimensional 8x8 grid of quadrants, and each quadrant is a two dimensional 8x8 grid of sectors. Each sector is either empty space or contains one object; the Enterprise, an enemy ship, starbase, or star. Starbases can be docked at to refuel and rearm the ship, and stars are obstacles that block the Enterprise and its torpedoes.

The warp engines are your sole means of navigating space, and require you to enter an angular heading and distance. For instance, course 1 means due east, course 2 means northeast, and so on. Warp factor determines distance moved, and warp 1 moves the distance of a single quadrant. To move within a quadrant, you must enter a warp factor less than one. E.g. – warp 0.125 takes you the distance of a one sector (as there are eight sectors spanning the width of a quadrant), warp 0.25 takes you the distance of two sectors, etc. If the Enterprise collides into an object while warping, it simply stops in its tracks right next to the object.

Courses may also be entered as decimals to move in directions finer than 45 degrees, but I found it better not to. I tried to navigate by using trig for precise headings, but it rarely took me where I wanted to go. Either my trig is wrong, or this game’s approximation of it is wrong. And I doubt it’s using special relativistic velocity calculations.

The short range sector scan shows you the map of your current quadrant. It’s automatically activated when you start the game and whenever you warp anywhere.

The long range sensor scan shows you a 3x3 grid of the nine quadrants in your immediate vicinity, and tells you what you can expect to find in it.

Phaser control fires energy at all Klingon battlecruisers in the current quadrant. It always hits (provided the battle computer is operational), but you are responsible for deciding how much energy to fire. Damage to each battlecruiser is equal to the amount of energy used, divided by the distance in sectors to that battlecruiser, divided by the number of battlecruisers in the area, and multiplied by a random decimal number between 0 and 2. It takes 200 points of damage to destroy one.

Photon torpedo control requires you to enter a course for your torpedoes, which is a bit pointless because the battle computer can compute it for you. Stars will block them, and they will blow up friendly starbases if they hit one. Torpedoes are limited in supply but kill in one hit and do not drain energy.

Shield control lets you transfer energy to (or from) the shields. If your shields are not charged, then a single hit from the Klingons’ disruptors will destroy the Enterprise.

Damage control lets you see the status of the Enterprise’s systems, which function badly or not at all when damaged. Taking hits causes subsystem damage, but the parts also spontaneously fail as you cruise around the galaxy. Fortunately, Mr. Scott repairs damage over time.

The computer’s function 0 shows you an 8x8 grid map of the known galaxy, and is automatically updated whenever you perform a long range scan. Could this be the first automap in a computer game?

Function 1 and 2 are explained adequately. The photon torpedo calculations are a free action, there’s no advantage to doing the calculations yourself.

So, onto the game:

Just started, and I’m already dumped into a quadrant with a Klingon! Red alert, shields up, diverting 1000 energy, and activate the battle computer.

Battle computer indicates a direction of 3.25. Mr. Chekov, fire.

Scratch one Klingon. With this quadrant now quiet, I performed a long range scan, which is a good thing to do whenever killing a Klingon or entering a new quadrant.

Nothing in this vicinity but stars. I checked the computer map.

I’m in row 2, column 3. The quadrants surrounding me were scanned, but everything else was blank. So I decided to warp west one quadrant so that I could view the top three rows of column 1.

Nothing there. I checked the map again, which gets filled out more with every long range scan you perform.

Quadrant 5,2 is right in the middle of a totally unexplored 3x3 grid. Mr. Sulu, plot course 7, warp 3.

Nothing here either! I warped further south to complete my search of the left side of the galaxy.

Again, nothing. On to quadrant 7,5. Course 1, warp 3.

Three Klingons are nearby! Let’s head east first.

Another easy kill. Another map-updating scan:

Two nearby quadrants contain Klingons, which I warped to and killed with my torpedoes.

I continued this search and destroy technique, and soon found a quadrant with two Klingons!

No problem. The closer Klingon was directly course 3.

I don’t even need the battle computer here.

The battle computer and another torpedo take care of the second.

Eventually, I started to run low on torpedoes.

Two torpedoes left, six Klingons nearby. Time to check the map.

There’s a friendly starbase in quadrant 8,7 directly to the south. Lucky me. Course 7, warp 3.

To dock, just move the ship to an adjacent sector. Each sector length is 1/8th of a quadrant, so course 1, warp factor 0.375 will take me three sectors to the east.

Don’t forget to reactivate the shields after undocking.

After impulse driving around the stars and warping north, I found a quadrant with three Klingons! I was surrounded.

And the poor bastards didn’t have a chance. No need for the battle computer here!

Warping again, another set of three.

Two of these are behind stars. I torpedo the first.

Then I decided to try phasers on the remaining two. It takes 200 damage to kill a Klingons. The closest one is 3 sectors away, and there are two of them. The random factor should have an average distribution of 1. 200 * 3 * 2 = 1200, so I tried 1200 energy.

The RNG worked in my favor, and both were destroyed.

I warped one more time and found two more Klingons, who I torpedoed.

And that’s the game. I have no idea how the mission time is calculated, but the method probably just doesn’t work right on a modern BASIC interpreter.

Figuring out the game was kind of fun, but there just isn’t enough depth or complexity for it to have lasting power. The hardest parts were remembering what directions the course numbers correspond to, and occasionally navigating around stars in particularly dense sectors. The battle computer makes bagging Klingons a turkey shoot, and I’m sure the aiming algorithm is simple enough for a human to figure out and perform manually. I just didn’t care enough to try.

Game 47: 3-D Tic-Tac-Toe

Buy 3-D Tic-Tac-Toe and about 90 other Atari games in the Atari Vault on Steam:
http://store.steampowered.com/app/400020/Atari_Vault/

Read the manual at AtariAge:
https://atariage.com/manual_thumbs.php?SoftwareID=798


Figuring out the chronology of this game was tricky, but from the looks of things, freshman Atari programmer Carol Shaw began work on the VCS version in late 1978, finished in 1979, and made an enhanced port for the new Atari 400/800 computers the same year. The strongest clue for this was an inventory of Carol Shaw related items archived at the National Museum of Play, including dated printouts of code for “Qubic” and “Colleen Qubic.” As “Colleen” was the development name for Atari’s computer systems, this would indicate the VCS version was the original, despite the fact that the 400/800 version was more fully-featured, may have been released first, and that the much weaker VCS simply was not up to the task of playing this game at a high level.

This variant of Tic-Tac-Toe was first popularized by Parker Bros. in 1965 as the board game Qubic. With a 4x4x4 grid for a total of 64 squares and 76 possible winning plays, most human players aren’t capable of mastering it to the degree that young children are capable of mastering conventional 3x3 Tic-Tac-Toe. To win, you must get four of your symbols in a row or diagonal, which can be difficult to visualize when the diagonals span multiple planes. Casual observation suggests an upper boundary of {64!} possible games, which is a much larger number than there have been Planck seconds in the history of the universe, let alone something the VCS could calculate in a reasonable amount of time, or hold in its 128 bytes of memory.

The AI plays a strong game at the highest level, but at a price. It plays semi-randomly at first, putting O’s exclusively on the eight corners of the cube and the eight spaces in the middle, without a clear pattern for the first few moves. Then, at some point, it decides it’s done playing around, and the screen goes haywire, as it starts developing an elaborate plan to beat you. At this point, it can take minutes for the AI to make its move. During this midgame, it will skillfully place complex networks of two-in-a-rows across multiple planes, until it suddenly makes an alarmingly quick move and you notice it has placed a third O in a row. Now you’re screwed; you have no choice but to block the fourth space, and it will continue forcing you down a sequence of blocking moves that ends with the AI creating a forking pair of three-in-a-rows. Since you can only block one of them, you will lose on the next turn.

The manual claims the AI can look up to nine moves ahead and can take up to 20 minutes, but I don’t think I ever saw it take more than three. That’s still a long wait, even with warp speed emulation.



I did eventually beat the AI on its hardest setting, but it took many tries, and felt kind of like trial and error. Playing first was key; the AI plays first by default, which is to its advantage. By losing enough, I got a feel for how it constructs its multiplanar traps, and was able to construct one of my own while also blocking the AI’s own trap before it could be sprung. During the above game, the AI was cooperative in not blocking my trap, and I was able to force it down a sequence of blocking moves until I was able to force a victory.

The Atari 400 version, which may have been released before the VCS version but appears to have been developed later, is a general improvement. It features an AI at least twice as fast, doesn’t glitch out the screen while thinking, and has several more gameplay options. Among them is an alternate mode called “Bottom-Up” which only allows you to place your marks on the bottom grid or on a square directly above an occupied space, sort of like a 3D Connect Four.

One last thing that I found interesting. This isn’t the first 3D Tic-Tac-Toe computer game. Mobygames has versions as early as 1962, several of them even called “Qubic.” But one version that predates this Atari version is for the TRS-80, released by Adventure International in 1978.

Big deal, right? Well, they later ported it to the Atari 400, and this is how it looked there:

And the box art even looks suspiciously familiar.

Scan by Giantbomb

Scan by Atarimania

Game 46: Polo

Download a copy of the Polo ROM and manual here:
http://www.atarimania.com/game-atari-2600-vcs-polo_14046.html

The next whale, 3-D Tic-Tac-Toe, was not the first game by its developer and programmer Carol Shaw. Her first, also developed for Atari, was never officially released, but was dumped and distributed in 2002 by hobbyists with Shaw’s permission.

As with other Atari games, there are a multitude of game modes, 24 in total, each representing a combination of gameplay options.

Shaw's notes, scanned by Atarimania, digitally manipulated for clarity

As with some other Atari VCS games, the combinations are fairly comprehensive. Modes 1-8 feature ball rebound and one horse per team. Modes 9-16 have no ball rebound; instead the ball warps to the other side of the screen when hitting a goal edge or boundary and continues its trajectory. Modes 17-24 feature two horses per team. Each set of eight games covers every possible combination of three binary options; 1 player or 2 player, slow ball or fast ball, large goal or small goal.

There was an issue of particular interest to me. Take a look at this screenshot:

There are two horses in this screenshot. Can you see both of them? If so, either you aren’t colorblind, or your monitor is better than my laptop screen. I am colorblind, and on my laptop, I can’t see the horse on the left at all, even in motion, and I can barely make out its differently-colored saddle.

Luckily, the Atari has a black & white mode, which eliminates this issue for me. Incidentally, I had no trouble seeing the left horse in color when playing on a TV or when playing on my 10-bit desktop IPS monitor, but I decided to use the black & white mode anyway, if for nothing else than the benefit of colorblind readers with portable or 6-bit screens.

It’s been awhile, but I had another session with “R” to explore the game modes, with focus on the two player modes, and I played the solo modes by myself later.

Modes 1-2

Mode 2: Vs player

On first glance, this looks like Pong blended with air hockey. The button isn’t used; the riders are stuck in a looping four-frame animation of swinging their mallets. In an unexpected but welcome bit of attention to detail, the riders backswing when facing their opponent’s goals, and frontswing when facing away, ensuring they always hit the ball in the direction of the correct goal.

To hit the ball, it must come in contact with the mallet’s head, and only during the three active frames of the swinging animation. Hitting it with the downswing hits it at a downward angle, the upswing hits it at an upward angle, and the transition frame between them hits it straight ahead. Hitting with the downward swing is difficult, because the mallet normally strikes the ground at the horse’s hind legs during its downswing frame. The horses also have a subtle element of inertia to their movement, and the ball travels faster if the horse is moving when you hit it.

Mode 1: Vs computer

The AI plays rather competently, which is unusual for an Atari game of this era; you were lucky if your game had any AI at all. Its strategy isn’t very sophisticated, but it makes up for it with computer precision in its timing and aiming. The AI’s horse slows down to a crawl when it is ahead in the score, giving you a chance to catch up. Because of this built-in handicap, it only beat me by one point.

Modes 3-4: Fast ball

Mode 4

I kept ricocheting the ball into my own goal. After a few, R yelled “Luigi wins by doing absolutely nothing!”

This pretty much characterized the match. I scored most of the goals, and lost by a lot.

Mode 3: Fast ball vs computer

With a bit of practice against the AI, I was able to cope with the speed. The AI doesn’t play quite as well with a fast ball, and seems to have trouble predicting where the ball will go. I had no trouble beating it by multiple points.

Modes 5-8: Small goals

Mode 8: Small goal + fast ball

Smaller goals mean defense is easier, and the scores are lower, even when playing with a fast ball.

The slow ball mode still felt more skill based, and the fast ball mode felt more luck based. R liked how the pitch of the bounce sound got higher with each rebound.

Modes 9-16: Wrap-field

Mode 10

Or, as R put it, “ghost horses!”



There’s no rebound, and the only way the ball can change direction is if the opposing player hits it. It seemed advantageous to go on the offensive, which I put to the test in mode 12, featuring a fast ball and wrap-around.

Mode 12: Wrap-field + fast ball

R tried to play defensively, like he did in mode 4. Big mistake.

Mode 9: Wrap-field vs computer

The AI really doesn’t understand the wrap-around mechanic, and always chases after the ball instead of trying to intercept it. Beating it was easy. It fared a bit better in mode 11 with the fast ball, but only a little.

Modes 17-24: 2 vs 2

These modes feature 2-horse teams spaced evenly apart horizontally, so that each can cover half of the playing field.

Mode 18

With two riders, this felt the most strategic out of all of the game modes. The fast variants still felt like it traded skill for luck.

Mode 19: 2 vs 2 computer

The AI, once again, doesn’t play very well with doubles.

Overall, I was pleasantly surprised by this game. It’s not the best VCS game I played, but it’s as good as flagship title Combat, and has a learning curve and enough depth to make it interesting to players who are completely sick of Pong. Our favorite game modes were 2 and 16, Polo singles and doubles respectively, with the slow ball and wide mouth goals.

One thing I wish was different, was that the button could have been used to swing the mallet instead of having the riders perpetually spin them around in circles in that rather silly looking animation loop.

I’m sure there’s a good reason why Shaw did it her way, and manual mallet control might have raised the learning curve more, but mastering it would make us feel more in control, and would add more depth to the game.

That and I also wish the color scheme was different.

Game 45: Asteroids

Buy Asteroids and about 90 other Atari games in the Atari Vault on Steam:
http://store.steampowered.com/app/400020/Atari_Vault/

Atari’s most successful game of all time is in many ways a throwback to their debut Computer Space. Once again, you control a space ship flying around a computer screen, and move by rotating freely and thrusting to move forward, with the inertia of space being a major factor that can help or hinder you depending on how well you master it.

This time, you’re mostly shooting at giant rocks to gradually smash them into smaller rocks, though occasionally the UFOs from Computer Space drop by to take pot shots at you, and you can score big points by shooting them first. Big UFOs are mostly harmless, but small ones are crack shots, smart enough to lead you when firing, and just unpredictable enough to prevent simple evasive maneuvers from working all the time. A hyperspace button will warp you to a random part of the screen, and is meant to be a panic button of sorts. In practice, I found that this had a very good chance of getting me immediately killed, and whenever I got into a situation where I realized only hyperspace could save my life, my reaction time was always a bit too slow.



My best score came from playing somewhat recklessly, firing into the thickest asteroid fields, causing the screen to overflow with small and fast moving debris. The smart approach would be to play cautiously, giving the smaller and more isolated rocks priority, so that the screen gets whittled down and more safe areas remain instead of less. The problem with this approach is that it’s boring, and I lost interest and focus before I could beat my best reckless score. Another problem is that by dragging the rounds out longer, the deadly UFOs will attack more often, but perhaps a player who got really good at fighting them could use it to their advantage and score even higher, by maximizing the UFO encounters per round.

Asteroids is a decent game. The vector graphics are put to good use, if not quite as atmospheric as the Lunar Lander game they were designed for, the controls and physics are relaxed and easy to get to grips with while still offering a challenge in mastering the inertia and making it work for you, the sound effects are satisfyingly crunchy, and the difficulty is surprisingly fair for an arcade game with no definite endpoint.

Addendum: The real thing 

On March, my friend "R" and I played this game at Funspot NH, on a real vector monitor. The difference has to be seen to be believed.



What really blows me away here isn’t the smoothness of the vectors, but the brightness effect. Those shots, which look like moving dots in MAME, look like brightly glowing photon torpedoes on a real vector monitor. The video doesn’t do it justice, and I doubt any flat panel or raster display could truly reproduce the effect. But they could certainly do a better job of approximating it. You’re probably watching this recording on a flat panel, and I’m sure you can tell from it that the bullets should be much brighter than the asteroids. Emulation just draws everything at uniform brightness, but there’s no reason why it couldn’t do better than that.

Games 43-44: Lunar Landers

Computer scientists of the transistor age clearly loved space. As popular early software like SpaceWar and Computer Space show, these formative years of computer technology were driven by space just as much as by war. It’s difficult to appreciate how exciting the Apollo missions must have been in the 1960’s, but they once represented impossible heights of human achievement and technology, and given the need to perform inhumanly immense amounts of precise calculations with no room for error, computers played no small role. The appeal to space and math obsessed nerds is obvious, and it’s no surprise that computer hobbyists would try their hand at writing space simulation programs.

On July 20th, 1969, NASA’s lunar module undocked from the command module orbiting the moon, and landed on the moon’s surface after a 2 ½ hour descent, bringing a climax to one of the most thrilling episodes of human history, and was broadcast to the world in real-time.

Game 43: Lunar

Download my VB.NET port of Lunar here:
https://drive.google.com/open?id=1HIncHN5H9ikUBbijrOFeKByyVX5lhUxQ

Before the end of the year, the first known hobbyist lunar lander simulation was written by Jim Storer, a high school student. This was written in FOCAL-69, published in a DEC newsletter, and subsequently ported to BASIC in many versions and iterations.

The FOCAL-69 source code is easily found on the Internet, and three different BASIC derivatives were published in David Ahl's seminal book 101 BASIC Computer Games. I’ve compared the original to the BASIC versions, and decided that all of the BASIC versions deviated from the original enough that I would try my hand at porting it myself, the goal to preserve identical gameplay behavior. I used VB.NET, and found I could translate the FOCAL-69 without too much trouble. GoTo commands work in VB.NET, Do commands can be replaced with function calls, and other than a tricky order-of-operations gotcha in line 8.10, the effort was straightforward, and my initial output matched a sample output almost exactly. There was only a very minor variance in my impact velocity and remaining fuel, likely attributable to differences in floating point precision.

So, what’s going on here? Well, the lander is 120 miles above the surface of the moon in free fall, descending at 3,600 MPH with 16,000 pounds of fuel, and your job is to land safely by ensuring the lander touches down at a slow enough speed. Your only method of control is to adjust the amount of fuel burned by the downward thrusters, which may be re-adjusted every ten seconds. We’ve spent the first 70 seconds in freefall, descending down to about 47.5 miles above the surface, and accelerating to 3852 MPH. Then the descent thrusters are engaged for the next 80 seconds, burning most of the fuel and quickly slowing the descent as the lander reaches the final mile of its drop. Thrusters are disengaged, the lander falls again, and one final thrust is given during the last 652 feet to slow the descent before impact. As you can tell, it isn’t enough.

After hours of trial and error, over a hundred lives lost and billions wasted, I was able to land poorly but intact, with an impact speed of 3.13 MPH. Then while fine-tuning my descent, I realized that I could enter fuel rates in decimal format, not just integers. I don’t know if the FOCAL-69 version would have allowed that, but it makes sense to me that it would, as variables in FOCAL-69 are stored in floating point format. With that epiphany and just a bit more trial and error, I landed perfectly.

Now, the descent here only took three minutes and 17 seconds. Apollo 11’s descent lasted more than two hours. I don’t think this is an entirely realistic depiction of lunar descent. Even with that considered, there’s one thing in particular that really bothers me.

We burned more than 98% of our fuel just to land. How exactly are we supposed to get back up?

Unplayed: Moonlander

I haven’t got a lot of information on this that isn’t from Wikipedia. But this was the first graphical iteration of Lunar Lander, and looks similar enough to the famous Atari version that I expect it influenced it in some way. From the fuzzy photograph, we can see that there’s sinusoidal terrain, the lander appears to be rotatable, and the top of the screen has readouts for fuel, altitude, and velocity.

The source code for Moonlander was easily found, but it’s in some kind of RT-11 assembly and is well beyond my ability to understand, much less convert.

Game 44: Lunar Lander

In 1979, Atari developed a new arcade graphics engine, which used sharp monochrome vectors rather than chunky colorful pixels, and decided to use it for a Lunar Lander arcade game. BASIC adaptations of the text-based Lunar were already widespread at this point, but Atari’s take on the concept is the game that would be best remembered for decades to come.



It’s clearly a very different game from the 1969 original. In the original you only had to worry about altitude, descent velocity, and calculating when to begin thrusting and how hard in order to slow your descent to zero just in time to land. There is no steering, the lunar terrain is not a factor, and of course there is no skill or dexterity involved.

Here, the lunar terrain is comprised of peaks and valleys, and you must decide where you are going to land. Only flat terrain is safe to land on, and certain zones are worth more points than others. The lander has horizontal velocity as well as descent velocity, and must be thrust at an angle in order to steer.

Also, while the original gave you just barely enough fuel to land safely, Atari’s gives you quite a bit more than you need. In fact, once you do land (or crash), if you have remaining fuel, your lander instantly goes back into high altitude, and you can try to land again for more points. The challenge here is more in the dexterity of pulling off landing maneuvers than in performing space calculations. I was able to land multiple times on a single coin’s worth of fuel… at least on the easiest difficulty setting.



Higher difficulty settings increase the strength of gravity. The stronger the gravity, the more fuel you spend fighting it. Gravity peaks on the second highest difficulty, at which point the lander free falls so fast that if you stop thrusting for even a second, it will very quickly reach an uncontrollable falling speed. Even thrusting at an angle is risky, and might not be enough to counteract gravity.

Once I found myself aligned with my landing zone and my horizontal velocity at zero, I straightened out the lander and used the altitude and velocity meters to guide my descent. At maximum gravity, it took almost constant thrusting with light releases to allow a slow fall, and it burned so much fuel that there was no way a second landing would be possible, but I did it.

Interestingly, you can change the difficulty setting any time, even in the middle of a landing. If you’re going for a high score, you might as well stick with the easiest setting. No matter how good you are, stronger gravity means more fuel burnt while landing, which means fewer landings and fewer points. That said, score is a bit pointless, as you get more fuel by inserting a coin at any time. You can keep buying more fuel and playing indefinitely.

The hardest difficulty setting has less gravity than the penultimate one, but has one very strange feature; the lander’s rotation becomes subject to inertia. Start spinning clockwise, and it will keep spinning clockwise, until you counter-spin in the other direction just enough to stabilize your angle. The natural inclination to press and hold a rotation button quickly leads to the lander spinning out of control.



Once I got over the shock of this new feature, and came to grips with how to get the lander to point in the direction I wanted, I actually found this a bit easier than the previous difficulty, as the weaker gravity made the act of landing more forgiving. I learned to tap a rotation button, wait for the lander to rotate to the position I wanted, and then to tap the reverse rotation button to halt the rotation. This took more time than the conventional control scheme of holding the rotation button until the lander was at the right angle and then letting go, but the lower gravity meant I had more time.

Atari’s Lunar Lander is an interesting idea, a novel break from the shooters and sports games that dominated arcades even by 1979, and showed that an action game needn’t be fast paced in order to be challenging. The barren atmosphere and sparse sound is well fitting for the moon landing scenario, and the physics feel spot-on. It would have been very interesting to play the 1973 Moonlander just to see how similar it really was to Atari’s incarnation of it.

Unfortunately, it’s just not that interesting to replay. Without any kind of opponent, the only challenge is in coming to grips with the lander’s controls and physics, and the moon terrain isn’t varied enough to make one playthrough any different from another. I landed the craft on a high scoring landing zone on the hardest difficulty setting, and could probably do it again, but why bother?

Game 42: Video Pinball and the road to Asteroids

The next whale goes back to Atari with their smash hit Asteroids, but there are some milestones along the way that I want to try out first.

Asteroids was directly influenced by a previous Atari arcade game, Lunar Lander (no relation to the Atari VCS game by the same name), for its vector graphics, physics, and controls. Wikipedia states that it was also influenced by Space Invaders, Computer Space, and SpaceWar, which I already played. Atari’s Lunar Lander is considered to be the epitome of its genre, which first existed in 1969 as Lunar and had its first graphical iteration in 1973 as Moonlander.

Asteroids was conceived and developed by Atari employees Ed Logg and Lyle Rains. Rains’ first design credit was Atari’s Jet Fighter, which I played already, and Logg’s first was Atari’s Video Pinball, which I haven’t.

And so, a slightly tangled roadmap to Asteroids:

There are possibly three completely different Atari games called Video Pinball; a dedicated console from 1977, an arcade game from 1979, and a VCS game from 1980. The relation between them is unclear; Mobygames lists the dedicated console separately and lists the VCS game as a port of the arcade game. Wikipedia lists the dedicated console and VCS games separately and makes no mention at all of the arcade game except as a category label on the dedicated console page, implying it is a port of the dedicated console.

I believe Wikipedia to be incorrect here. From the looks of things, the dedicated console is a set of Breakout-like games with only the barest trappings of pinball present in a handful of them. The arcade and VCS games look more like what the title suggests; a video rendition of pinball. Only the arcade game credits Ed Logg with a design role, so it’s the one I will be playing here.



This Video Pinball takes a novel approach; inside the cabinet is a miniature foam pinball playfield with real working LEDs, which is reflected onto the screen with a half-silvered mirror, while the ball, flippers, drop targets, and score displays come from the monitor image projected onto the screen through the mirror. The two images merge and create the impression that a 3D pinball playfield is on the screen. Of course I’m using MAME, so the pinball playfield is just a flat image.

This does a pretty impressive job of simulating pinball physics, if nothing else. Gravity feels convincing in a way that nothing before it really pulled off, and the flipper action feels satisfyingly forceful. But it’s not that much fun to play. I always found the electromechanical era of pinball to be a bit boring, and the disco-themed table design feels bog-standard for the era, doing nothing to take advantage of the inherently solid state nature of the hardware except for having simpler maintenance, and doing nothing to distinguish itself from any number of real tables out there, which would have been more fun to play just from having actual moving parts that you can see and feel. The nudge function didn’t even seem to do anything, though I can’t tell if it’s because of an emulation issue or not.

Games 40-41: Gee Bee & Galaxian

The next whale is Galaxian, Namco’s first big success in the arcades. Prior to that was a trilogy of sorts, Gee Bee, Bomb Bee, and Cutie Q. I’ll be taking a look at the first of them, which is considered to be Namco’s first internally developed video game, designed by Toru Iwatani who later designed Pac-Man.

Game 40: Gee Bee

Flyer provided by flyerfever

From the poster, you might think this is an early mascot game, right? Nope. It’s a video pinball game with elements of Breakout. Or maybe it’s a Breakout clone with pinball elements. Either way, the bee mascot is conspicuously absent, and there isn’t a thread of original gameplay to be seen here.



This is certainly the easiest arcade game I’ve played yet, in terms of prolonging the playtime. As with most other arcade games of the era, there is no victory condition, and your only goal is to play for as long as your skill permits and get a high score. Two of my three balls were lost simply because my attention lapsed from boredom.

The ball moves a lot more slowly than in Breakout, the paddle is larger, and there are two of them, separating the playfield into two zones. There’s even a spinner mechanism that slows the ball down for a few bounces if you direct the ball through it. There are also two pinball drain outlanes in the lower zone that the ball might fall down into and immediately end the round, but I didn’t have much trouble keeping the ball in the upper zone for most of the playtime.

The upper zone is also where most of the action is; the bumpers, the bricks, and the slowdown wheel are all there. Clearing a set of bricks in the upper zone “upgrades” one of the pinball features to award ten times as many points, and also gives a 1000 point bonus. Clearing the left or right set of bricks will also create a single safety brick in the corresponding outlane, saving your ball from a single drain. Any cleared sets of upper zone bricks will be reset when the ball hits the lower zone paddle.

The lower zone features five rollover targets spelling NAMCO which will double your bonus if you light them all at the same time, but controlling the ball well enough to hit the targets is tricky, and puts the ball at risk of falling into the outlane drains. There are also two ramps each containing a single column of bricks. Clearing one of these columns and then hitting the safety brick in the outlane below it awards you a free ball, but getting the ball up into these ramps is nearly impossible. I found the lower zone not really worth it, too much risk for not enough reward.

An interesting technical detail is the use of color. Like so many other arcade games of the era, the screen is black & white, and fixed regions of the screen are covered with a colored cellophane overlay to create the appearance of color. Unusually, the internal graphics can produce gray in addition to white, which when combined with the cellophane overlay, allows for objects to change color, such as the spinner which changes from green to bright yellow when it lights up. This isn’t quite the first arcade game I’ve seen that allows for greyscale graphics (Atari had several), but it is the first to my knowledge to simulate color with the combination of greyscale and overlays, and this is the most colorful game on a black & white monitor yet.

How was Namco’s first real video game? Kind of boring. Objectively, there’s more interesting stuff on the board than in Super Breakout, but it’s slow, and there’s no satisfying “breakout” moment.

Game 41: Galaxian

Galaxian, at first glance, looks like a clone of Space Invaders. And it isn’t far removed from the formula; a phalanx of aliens fills the upper half of the screen, pacing the width of it, and you control a slow horizontal-moving space ship at the bottom that can fire upward, one shot at a time. Annihilate the invaders to pass the level, and do it all over again, until you can’t any more.

The most immediately clear difference is that Galaxian is a lot more colorful. In fact, this is the first game of any kind I’ve looked at that really uses color video without serious limitations. Space Invaders, like most arcade games before it, used a black & white monitor, and had rows of cellophane to provide a color to each region of the screen, and you could see this in effect as your laser moved upward to the top of the screen, changing its color whenever passing through a new region. Some of the earliest Atari arcade games had color monitors, but their use of color was limited to one color per object, as was also the case with most Atari VCS games. Here, the Galaxians are multi-color sprites, which swoop around the screen freely without any sort of color clashing, and the background itself is filled with a colorful scrolling starfield.

The next obvious difference is that the Galaxians do not advance downward, nor do they shoot at you from their rank and file, but instead break off from the phalanx in groups and dive-bomb you, firing clusters of lasers and sometimes kamikazeing your ship. This puts less pressure on you to be efficient, and encourages focusing on precision aiming, but it’s still dangerous to dawdle, as the longer a round goes on, the more chances there are for the Galaxians to catch you in a deadly pincer attack or to force you into a corner.



In my best playthrough, I made it to the fifth round before losing my final Galaxip. Although there are no shields to hide behind or punch through, there is still plenty of strategic decision making involved. For instance, the Galaxians do not attack at all for the first few seconds, and also will cease fire for a few seconds more whenever you destroy a flagship. There are a number of possible strategies already.

• Attack a side-column. As with Space Invaders, eliminating a column means the phalanx is narrower, and will therefore take longer to move across the entire screen width and change direction less often, making them easier to hit. It also means the Galaxians will have less horizontal spread when they attack; the Galaxians on the far sides tend to have the widest swoops. The risk here is that you’ll need to spend your time close to a corner, making it more likely that you get driven into the corner once the Galaxians start attacking.
• Attack the bottom row. By getting rid of the closest row, you’ll have slightly more time to react when the Galaxians from the rows above it start attacking. It’s also safer than attacking a column, as you won’t need to spent as much time close to a corner, and won’t be at the same risk of being driven into it. But you will need to move around a lot more, which makes aiming all the more difficult.
• Do nothing, and wait for the Galaxians to attack. This can be rewarding because Galaxians are worth twice as many points when charging, but dangerous because you are ensuring that any and every Galaxian has the opportunity to attack.

Attacking Galaxians as they dive-bomb you is encouraged in a number of ways. Most directly, the point values are doubled. Hitting them mid-dive may be easier or harder; easier because they’ll be closer, but possibly harder if their horizontal swoop is fast enough. Because they are closer, a correctly aimed shot will hit them in less time, and you can fire again that much sooner. But this is also risky, as they often flank you, and going out of your way to line up a shot can wind up getting you trapped or caught off-guard by another attack formation. The ultimate challenge is the flagship formations, which always attack with two red escorts if they are alive and bombard you heavily. Taking out both escorts and then shooting the flagship before it completes its dive is worth a combined 1,000 points, but only if done in that order and all during the same dive. For comparison, a solo flagship is only worth 120.

Galaxian’s pretty good! Comparisons to Space Invaders are unavoidable, but it’s an iterative improvement. It’s a bit slow paced compared to later games, but the strategy and precision involved makes it satisfyingly challenging. I enjoyed the sound and visuals, and found the skill bonus from shooting the flagship formations to be a lot more interesting than shooting Space Invaders’ UFO.