D E S I G N  N O T E S

Early in the project, this title was handed off from one publisher to another. This significantly delayed production startup, but it gave us a unique and valuable opportunity to design the galaxy in unprecedented detail. During an otherwise-quiet winter season, our design team created a massive (for its day) Excel spreadsheet that created entire galaxies full of stars, planets and moons based on mathematical models derived from astrophysics (the Hertzsprung-Russell Diagram, for example). Here's what two of the several dozen tables looked like:

Is this "overkill"? If we'd stopped there, yes. But we didn't just say "it's accurate, therefore it's good." Instead, we used this model to generate a playable universe -- one in which the habitability for each race was carefully balanced in order to ensure that the game was differently fun for everyone.
Cool tools are fun, but it's critical never to lose sight of why you're building them. What matters is creating a good experience for the player. And in other areas of this project, that's where we fell down.

We're really proud of the way the diplomacy module turned out. Given the severe platform constraints imposed on the project, we were limited as to the techniques we could use to animate the various characters. We could not do real-time animations synchronized with audio, as would be done today in 2024. Instead, we fell back to the techniques we successfully used in the past, pre-recording and pre-rendering the sequences.

But we didn't want the animations to be simplistic. We wanted them to convey emotion, even when using made-up languages, and to be unique based on the player's specific situation. So we created a series of short segments, each with different emotional tone (and a few variants of each), which we could then string together to make an applicable short animation.

MOO3 had one of the largest AI teams for a game of its class -- four programmers, in total. And that doesn't count the designers backing them up, who provided extremely detailed and carefully tuned tables of capabilities, technology trees and dependency diagrams needed in order to make the AIs smart enough to play the game effectively. Together, the team created roughly two dozen separate AI modules that handled everything from ship design and production to individual planet management to trade and diplomacy. They could play an entire game on their own. Amazing, but so good that they became a problem.

One of the hallmarks of previous Master of Orion games was the elegance and simplicity of their gameplay at different levels. Planetary production was easy to manage, and the technology tree offered useful choices without being overwhelming. One of our early design choices involved deepening this significantly, with far more choices for technologies (including social and governmental developments) and management of planets on a region-by-region basis (so a watery planet's land mass worked one way, but the oceans had different parameters).
This was cool, and it worked. Players had far more ability to make choices for designing and optimizing their worlds, building unique ships and exploring vast numbers of interesting and believable planets.

In this era, online multiplayer capabilities were just beginning to mature. Network connections were slow and unreliable (our office had a single ISDN line operating at 64K bits per second, and that was considered top-of-the-line for its day). So, in addition to offering real-time play, we offered a turn-based model in which players could send games out in round-robin fashion via email or other messaging and play whenever it was convenient for them.
Making this work was extremely tricky; if the games ever got out of sync, disaster would follow as each player had a different idea of the state of the galaxy. We wrote a sophisticated system in which the random-number generators relied on pre-arranged "seed" values, so every game running on every machine (even MacOS versus Windows) would get the same answers. This meant that we had to use fixed-point math for everything, since floating-point calculations differ slightly on different hardware.

MOO3 has a huge number of unique screens that enable management of everything from movement to planetary production. We established a very clean visual style that enabled us to display extremely complex data in a clean and understandable manner. We used a "drill-down" approach in which summary panels showed the numbers most likely to be important to the player but which could pop open and fill the screen with additional detail, if needed.

Note that this once again comes back to playability. It's not just about having tons of cool numbers floating around. It's about clearly understanding which numbers matter most in decision-making and putting those in the most prominent and clearly represented form so the player can make smart decisions easily. This exact same philosophy of design is the reason we landed future projects such as our medical device work -- we know how to make complicated things seem easy.

D E S I G N  N O T E S

We wanted to set the bar high, but we set it too high to be achievable. The Game Design Document ultimately reached more than 200 pages and featured large numbers of complex data tables for numerous game subsystems. But every game has a budget and a schedule, and it became apparent after months of design and early production that we would never be able to do everything that we wanted. Unfortunately, we waited a little too long to pull the trigger on reducing scope and scale.
For example, the original design called for 32 and then 16 unique races. But due to the many production elements required, including large numbers of ships, aliens and audiovisuals, we needed to reduce that scope to eight races -- still plenty for a challenging game, but far less than the first "vision" documents proposed.
Likewise, there was originally an extremely complex hierarchy of personnel, each of whom could have loyalties to particular factions. That could have been the basis for an entire game on its own. It also turned out to be very tedious and uninteresting when actually played, so we had to kill it off after a lot of code had been written.

Lesson: The game isn't done when you've put in all of the features that you want. It's done when you've removed all of the features that you don't need.

This is a real killer. The simulation aspects of the game were very detailed and produced very interesting results. But they were so complicated that simply overseeing things like planetary production became tedious and boring. There were simply too many numbers to manage easily.
We designed the user interface screens to optimize what was displayed, and that helped a lot. But, too often, the player still had to dig down into some element or another and make an adjustment, which felt like debugging an Excel financial model.

Also, it was very easy to delegate many functions to the AI. Sounds like a great idea. But, in practice, what it meant was that the player lost a feeling of being connected to the game and felt that the game was playing and having all of the fun by itself.

Lesson: A simulation is not a game -- the player needs to feel that they are given interesting choices and that those choices will have a predictable effect on the outcome of the game. If they lose that connection, then it's no longer fun.

This, too, is a lesson that we've incorporated into every following product. Whether it's a game, a restaurant ordering system, or a medical device, it's important that the user always knows what to do next and what to expect from such actions. Super-popular console games like the Mario series have this principle down to a science.
There are a couple of key pieces to this. First, choices need to be meaningful. If I do "X" instead of "Y", but I get what looks like the same result, my actions have no real purpose. With simulation-based games, it's easy to think that simply having the ability to control parameters will create interesting results, but that's not always true. In the case of this game, some decisions had such opaque or seemingly random consequences that the players felt that they had no purpose.

Second, the game needs to explicitly help the player know what to do next. Don't just put in a huge number of control panels and "let them explore." Give them specific guidance about which subset of actions will be meaningful. We actually did some of this in the final version of the game, providing direction by highlighting issues that were important and creating a "sitrep" (situation report) screen to summarize key events each turn. That helped a lot. But it's hard to completely fix a fundamentally overcomplicated design.

Lesson: Start FIRST with what you want the player to experience each turn. Then build the simulation (or rules without a "real" simulation) to support that user experience.

The original concept with the AIs for this game was to give the player the ability to choose to focus on certain parts of the galaxy while delegating details of the "boring parts" to AIs. Thus, every player could chart their unique path while not getting lost in the details of parts that didn't interest them.
In practice, though, the AIs were so good that players found they could largely just run their entire empires via AI and watch what happened, because the AI choices were at least as good as their own. Net result: the players lost the vital experience of being needed.

Lesson: Decide what's best to automate and what's best left to the players. Design the game so they have plenty of interesting choices that actually affect the outcome, then design AI players and other game mechanisms to make them feel like they're in control and that their decisions matter.

Our publisher wanted the game to work on as many platforms as possible, including relatively low-end PCs and Macintoshes. This was a laudable goal. But the threshold was ultimately set too low -- so low that it meant we could not rely on having access to useable 3D graphics hardware, and had to fall back to software-only rendering even for the real-time combat playback. We had a superb solution for this: a custom voxel renderer that we'd written. But using real 3D would have been better, in retrospect.
This also meant that we had to stick with a single, moderate screen resolution of 800x600 pixels because that's the best that some machines could offer, and we had no way of scaling the visuals (and the fonts) for larger screens. As a result, on top-end machines, the visuals looked rather blocky and the fonts were far less clean than the otherwise would have been.
We spent a very large amount of time implementing the turn-based play-by-email mechanism. It worked great, but it imposed a number of complex constraints on development and required a mid-stream rewrite to remove floating-point math calculations, which was time-consuming. It would have been nice if we could just rely on more modern, real-time connectivity.

Lesson: Design your product to support as many platforms as practical, but, if your platform choices begin dragging down the design and usability, push back and change to a better minimum performance requirement.

Even the best backup plans can fall short. We stored all of the master art assets for this project on a large RAID5 array in our office. This dedicated unit had eight high-capacity drives, with not one but two hot spares in case of failure.
One day, about two years after the project was completed, we came into the office to see blinking warning lights on the control panel. The array was rebuilding itself because of a drive failure. Then, the worst-case situation happened: not only had two primary drives failed, but during the reconstruction a third drive went offline.

Apparently, the night before, there had been a severe thunderstorm near the airport. Our office was a short distance away. There were several lightning stikes, and we believe that one of them hit close to the office, sending huge spikes that blew through our power protection systems. We lost the entire array, and almost all of the original assets like these for the game.

Lesson: RAID5 arrays are great, in principle, but don't assume they'll never fail. Make at least two backups of your critical assets, storing one of them off-site.