Some time ago, I wrote here about the Habitat project, an effort to relaunch the first massively multiplayer online game. This is an effort led by my non-profit, the Museum of Art and Digital Entertainment, an all-volunteer videogame museum reopening in Oakland on Feb. 5.

Last week, that project made a major stride forward as we began to upload code assets into GitHub for the first time. Just as with most software projects, when writing a game, you must first sit down and write your tools. To this end, we’ve pushed Macross, one of the tools used to make Habitat, to GitHub.

Why am I writing about Macross, here, on SD Times, where we write about hardcore enterprise software development? Because Macross is fascinating.

Just what is Macross, aside from a 1982 anime about giant transforming jet robots? To understand Macross, we must first understand the architecture of Habitat.

Habitat was a client/server online game, with the client based on the Commodore 64, and the server running on a Stratus VOS machine. The C64 has a 6502 processor, the Stratus a 68000. Between these two systems was Q-Link, the immediate predecessor to America Online, and a system that had grown out of a skunkworks project to get the Atari 2600 online.

Let us pause here to ruminate upon the ridiculously high levels of optimism required to make any of these systems work, let alone bring them to market. The idea of bringing a C64 online may seem crazy today, as the device only had 64KB of RAM, but the Atari 2600 had only 1024 bits of RAM. How Steve Case and the gang at AOL ever planned to bring an online service into 1KB of RAM is beyond me.

So, clearly, the AOL/QLink team were just phenomenal developers shooting for the stars. To enable their online service to be highly available and run non-stop, QLink ran on the Stratus VOS system. Stratus systems are highly redundant, and can be chained together to work in a group. They come from the days when highly available software was, essentially, dependent upon highly available, super-redundant hardware.

Before someone even decides to write a 1,000+ player game for these systems, they’d have to figure out how to get them all to talk to one another, and how to develop software for three platforms at once.

Chip Morningstar and Randy Farmer were tasked with the goal of making a game for this environment, however. Morningstar is an absolutely amazing programmer, and Randy is a visionary who, essentially, predicted the entire MMO revolution 20 years before it took place.

For this discussion, however, as we’re zeroing in on Macross, we’ll be talking about Morningstar. Today, he works as the architect at PayPal, so rest assured his enormous talents are not going to waste.

Morningstar was working day-to-day on a 68000-based Sun machine running the SunOS. He and the team at Lucasfilm Games (now LucasArts) were never called upon to build games for SunOS, however; they were building for the consumer market machines (the C64 and the Atari 400/800).

As Lucasfilm Games was often publishing to these consumer platforms, they needed a better way to build for them on their UNIX workstations. Thus, Morningstar built Macross, an assembler for people who hate assembly language. Michael Steil has been an absolute superstar on the Habitat project, and he has a terrific technical write-up of Macross on his blog. He’s also the fellow responsible for pushing the code to GitHub and maintaining the repositories. Those repositories include the 6502 version, as well as a 68000 version that Morningstar claims is incomplete.

On that blog, Morningstar chimed in with some more info on Macross:

Macross was not written as part of the Habitat project. It was a general tool that predates the start of Habitat by a year or two. It was used on every 6502 (Atari 400/800, Commodore 64, and Apple II) game that we produced at Lucasfilm Games, from 1984 up until those machines ceased to be relevant to the games market.

Macross was my first job assignment at Lucasfilm. They urgently wanted to replace the existing assembler they had been using. That one was written in Lisp—you wrote 6502 code in S-expressions, which looked amazingly weird. It was awesomely powerful, because you could use all of Lisp for a macro language, but it was also awesomely slow. It took about 45 minutes on our VAX 750 to assemble a 16K ROM cartridge game, mainly because doing this took 2 megabytes of RAM, but the machine only had 512 kilobytes, so it page-swapped horribly. My mission was to create a more conventional-looking (and performing) assembler without sacrificing much of the macro programming power they had gotten addicted to, hence Macross.

…There is some code in there for the 68000 version, but it’s incomplete. That version was never finished, because the 68000 machines were powerful enough that you could afford to use a compiled language like C. The cult of fast (a tribe overrepresented in the games industry) argued for a 68000 assembler anyway, and so I started on one, somewhat half-heartedly, but got to abandon the effort once reason prevailed. (Nowadays we laugh that C was once considered a high-level language, and the cult of fast people have graduated to whining about the overhead of OO and garbage collection.)

So here we have a large collection of C code from 1986. The first order of business has been to bring the codebase up to 1989 standards. That means working through the base and pulling includes out into .h files, and generally bringing the whole codebase up to ANSI-C standards. If you’re interested in helping out, the project is MIT license, and we’re always looking for more help!

Stay tuned for Habitat, soon to be uploaded to GitHub!