The Quicksilver Story: Chapter 8

Welcome to Quicksilver!

This is the eighth post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1 and to the previous chapter here: The Quicksilver Story: Chapter 7

Our story is four decades long, and still going strong. It involves more than 50 games for numerous different publishers, including some where we were delighted to revisit old classics. This is the story of two such classic game projects.


Next-Generation Classics: Star Trek: Tactical Assault

We were thrilled to work with Interplay in the 1990s to create the real-time combat game Star Trek: Starfleet Command, based in the “original” Captain Kirk era (“The Original Series”, or “TOS”) and leveraging the popular board game Star Fleet Battles. We were excited once again when we were contacted by Bethesda Softworks to produce a new mobile game also based in the TOS universe. This would be targeted at the Sony PSP and the Nintendo DS.

This would be a big challenge for us -- a first working with both Sony and Nintendo and the unique challenges of getting approval for their highly controlled platforms. We knew that this is one area where PC developers often fumbled, so we studied the console manufacturers' processes very carefully and instructing the team on what they needed to do in order to smooth the process. In the end, we were delighted that the approvals went through very quickly, with only a few "you have to be joking" moments.



T E C H N I C A L  N O T E

(ignore if not interested)

Having a strong understanding of cross-platform development was a huge help here. Since we'd done so many Mac-PC games and other products, we were used to the concept of abstracting platform-agnostic functionality and "wrapping" the platform specifics into conditionally compiled sub-modules. Knowing from the start that we needed to support two very different devices made it easy to just design the code from the start with all of the necessary cross-platform hooks.

Writing the code in C++ was also very helpful, since the language naturally provides good ways of conditionally compiling code when needed.

One of the best parts of the project was initially a big problem: we had trouble getting smoothly-lit ship textures on the PSP. Our 3D artists knew that the very small ship models would look a lot more sophisticated if we could just give them more than the simple default lighting. But the PSP's processing tools didn't seem to have controls for that. However, one of our technical artists was also a skilled programmer. He deciphered the XML-based format used by the Sony tools and found a flag that turned on an advanced lighting mode but which didn't exist anywhere in the documentation. The Sony execs were floored when they saw the game for the first time, because it turned out that our game was one of the first to employ such techniques.


While combat would be a key element of the game, we knew that story also needed to play a big role. The unique capabilities and personalities of each Star Trek race play a large role in the series, and we wanted to be sure that carried over to the game as well. Fortunately, we had previously developed some very nice story management tools that were based on Excel spreadsheets. Modifying and expanding those for this title was a straightforward task. The tools were able to export complete stories that could be used in the game, a huge time-saver that ultimately proved critical to the quality of the game.

Star Trek has a long history, and a large canon of officially approved information. But knowing exactly how a Klingon captain would behave in a branching storyline with several possible outcomes was still very tricky and required a master storyteller. So we were thrilled to be able to work with one of the true masters of the TOS universe, author DC Fontana, who personally wrote some of the best of the TOS episodes we knew and loved. Working with her and her writing partner was one of the highlights of the project, and definitely made it a better game.

We decided to create two unique gameplay tracks: one where the player is a Federation captain, and the other a Klingon. Each would have about 15 unique scenarios of varying complexity, and would feature a unique user interface, just like we had done with Starfleet Command. Much like Starfleet Command, we created new, custom ships for specific situations to add depth and color to the universe.

The game also featured wireless two-player combat mode, so in addition to the scripted content we also had to contend with the usual complexities of local-area wireless communications.


R E V I E W S   &   A W A R D S

  • “…an outstanding simulation, and easily one of the better Star Trek titles available."
  • – Nintendojo
  • “Star Trek: Tactical Assault does a fantastic job with giving the player a feel of the Star Trek universe and what the commander of a starship had to go through in the shows."
  • – Gaming Age
  • "Where the PSP version of Tactical Assault really shines is its graphics. From the first menu screen (a faithful recreation of the USS Enterprise-A's bridge) to the detail and smoothness of each ship, I was just amazed by the game's ability to fit so much detail onto the handheld."
  • – Game Vortex
  • "Star Trek: Tactical Assault from Bethesda Softworks brings the Star Trek license to the handheld format. However, instead of just being another half- baked title with a license thrown on it, Tactical Assault is shaping up to be a very deep space-sim, putting you in the role of a Starfleet Commander and all the assets therein."
  • – GameZone
  • "Controls in this game are a big shining point as Quicksilver seemed to pay attention to the small little details of the Trek universe. The layout feels genuinely Trek-like when you glance down and look at the display."
  • – Nintendo Gal


Next-Generation Classics: Master of Orion III (MOO3)
Master of Orion is one of the great, classic PC strategy game franchises. We were very excited to be offered the opportunity to create an ambitious new chapter in the Master of Orion series.

We had a stellar team working on the game (pun intended), including designers who had assisted in the creation of Master of Orion II, and a powerhouse 3D and 2D art team. So we knew we were in good hands.

We also had an expansive vision for the game – both the visuals and the gameplay. We would add far more races, much greater detail, extensive space combat and even a sophisticated trade interface. The game would have numerous AI assistants that would allow players to delegate some tasks and focus on the parts of the game that were most interesting and fun to them.

As a CD-ROM title, we also had the opportunity to compose a long, very high-quality soundtrack that also included voices for each one of the planned 16 races in the game.

Many pieces were in place for a first-class production. Many of the final elements were very cool and worked exactly as we wanted. But, overall, the game fell short of what we wanted. This is one of those projects that served as a valuable lesson on what not to do in creating a top-tier strategy game. We’ll show off the many great features of the game here, but we’ll also share the equally important lessons that we learned, and talk about how this game has made all of our subsequent titles far better.

Some of the limitations we faced would prove to be more limiting than originally anticipated. Chief among these was the decision early on to make the game run on as many computers as possible, including those with limited or no 3D graphics capabilities. This influenced every aspect of the design, sometimes artificially limiting creativity.

Why are we sharing less-than-perfect news in this blog? It’s simple: by doing this, we make it clear that we are humble enough to admit when we fall short, and that we can learn from our mistakes. What we learned from this project has significantly affected future projects. We won’t make these mistakes again. And that process of learning and growing is exactly how top teams stay on top of their games, so to speak.

The following sections will delve deeply into game design and project management details; some readers may wish to skip them.


MOO3: What Went Right

D E S I G N  N O T E S

Galaxy Modeling

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.

Diplomacy Visuals

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.

AI Players

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.

Depth of Simulation

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.

Multiplayer Functionality

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.

Visual Style

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.



MOO3: What Went Wrong

As noted earlier, MOO3 was an incredibly ambitious project. We wanted to do every aspect of predecessor project Master of Orion II in a manner that was better than before – deeper, subtler, more visually compelling. And we succeeded at much of that. But, at the end of the day, the game fell short. It lacked a feeling of coherence, and it was hard to play well because players sometimes didn’t know what they should be doing.

Here, we’ll delve into some of the key reasons for this, and the key lessons that we learned.


D E S I G N  N O T E S

Overly Ambitious Design

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.

Not Fun. "Plays Like a Spreadsheet"

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.

Hard to Know What to Do

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.

AIs Are Too Useful

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.

Technical Compromises Driven by Platform Requirements

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.

Make Backups!

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.



Master of Orion III sold over 300,000 units. It wasn’t a disaster, and many people enjoyed it a lot (see the many positive reviews, below). But it still wasn’t what it should have been, and it taught us important lessons that have made subsequent projects far better.



R E V I E W S   &   A W A R D S

  • "With years in the making, Quicksilver Software has taken its time to enhance and streamline its powerful game system. With a fresh new look, tons of new options and a host of new races, MoO3 is set to rock the strategy genre once again and show gamers that space IS the final frontier."
  • – ActiveReviews
  • "I absolutely adore Master of Orion III. The gameplay is so addictive, I often found myself saying, "Okay, just one more turn", 267 times in a row. This game is immersive, richly detailed and full of strategy. Furthermore, multiplayer support is quite fun when friends are involved. All in all, Master of Orion III is a turn-based strategy fan's dream."
  • – Inside Mac Games
  • "Diplomatic AI has never been anywhere near as clever as in MOO3... Combat has never been so strategically focused. Colony development has never been so detailed and intensive, and computer opponents so well-balanced that literally any of them could win. Galaxies are much bigger, available researches are more extensive, and there's far more information to track than in any previous 4x space game."
  • – IGN
  • "MOO3 certainly has a legacy to live up to, but from what I saw it will have no trouble satisfying or even surpassing expectations. The game has been in the hands of testers for about a year and the Quicksilver team has had constant feedback and support from a beta community that they couldn't praise enough. "[We've] often had a new build out every three days to our beta team," I was told, "even recently... We want this game to be solid." It certainly seemed solid -- which is good as the game will be going gold any day now and should start hitting store shelves just in time for the holiday rush. Which is also good as I now have a Christmas present for my alien masters."
  • – GameSpy
    – Gamespot
    – Amazon.com


Coming Up Next: Chapter 10 – An Award-Winning Military Project

But first we’ll take a side-trip to talk about our other great passion: career development. What does it take to get into the game business? And is it something you’d actually want to do? Find out here:

The Quicksilver Career Blog: Part 1



Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.


For more information:

You can find us on the Web at www.quicksilver.com.