TREKCORE > GAMING > ARMADA II > Designer Diary

Courtesy of GameSpot, this is Mad Doc Software's only Designer Diary entry for Armada II.

Entry #1 - 09/21/01

By Dr. Ian Lane Davis
CEO, Mad Doc Software

Today, as we feel the very first claws of a New England autumn, Star Trek Armada is rapidly approaching beta status. The team is hard at work putting in the last features, balancing the strengths of the units, and testing, testing, testing.

Mad Doc Software's new offices are located on the fifth floor of a 140-year-old textile mill in Lawrence, Massachusetts. We have exposed brick walls, rock maple floors, and 14-foot-high ceilings. My office is at the south end of our space, and as you go down the development hall, you pass by designers, artists, and programmers, in that order. Going down the other hall brings you to our conference rooms, sound recording area, and testing center. The entire place is running at full steam right now.

Armada II has been a challenge for us. Although our staff is loaded with industry veterans (most of our folks have four, five, six, or more games under their belts), it's our first complete game as a team. Thus, we've been making not just a game, but also a game-making machine.

When we (and Activision) decided to make Armada II, we needed to do a lot of research. The first game had been a strong sales hit and had quite a following of fans. We needed to figure out which elements attracted fans and what we could add to make the game even more appealing.

We found that people enjoyed the fast-paced combat and that the traditional RTS model of research, build, and attack was a strong selling point. The combination of RTS, Star Trek, and large capital ship combat was really the sweet spot for this license.

At the same time, people wanted more ships. With well more than 600 hours of TV or movie content, the Star Trek universe contains hundreds of ship types, and every fan has a favorite. Players also wanted deeper campaigns. In the first game, we had a short campaign for each race--just a taste, really, of what each race was about. Additionally, many fans wanted the different Star Trek races to play very differently. For the first game, each race had very similar ships and capabilities. Likewise, the resource model and technology tree in the first game just touched the surface of what you could do in a Star Trek RTS. Finally, fans felt that the franchise was ready for 3D gameplay.

So our principle design was quite simple: (1) add lots of ship types, (2) add new races, (3) make each race distinct (with special attention paid to making the Borg and Species 8472 play uniquely), (4) focus on deeper single-player campaigns, (5) deeply expand the economic model, and (6) make the game play well in 3D. The game as it stands now has nearly 100 ship classes (compared to about 40 in the first game), and each of our three campaigns has 10 missions. We chose to forgo a short campaign from each race and focus instead on deep, story-driven campaigns featuring fans' favorite races. In multiplayer and instant action, all six races are playable: Federation, Klingon, Borg, Romulan, Cardassian, and Species 8472. We now have additional resources, which are harvested differently and which are spent differently by each different race.

Making the game play well in 3D without it becoming confusing is a big accomplishment. We've found that 3D just for the sake of 3D can often lead to inefficiencies and confusion in the user interface. What we decided to do was to keep a traditional "strategic view," by which players view their ships from a top-down angle, as well as one that has canonical directions (easy to think of as north, south, east, and west). But we also added actual 3D depth to the map. The map is what we call the "deep dish pizza xox" in that it is much longer and wider than it is tall, but it's still tall enough to allow 3D formations and enough spread of ships up and down to add tactically useful depth. We incorporated a "tactical view," which allows much more camera freedom but still retains all the information and command-giving capabilities from the strategic view. The entire game can be played from either view. In practice, we frequently find the strategic view to be superior for base building and the tactical view better for careful combat management.

The Borg

In upgrading races that existed in the first game, we paid particular attention to the Borg. We adjusted both their appearance and their gameplay. Virtually every model was redone, and every texture was reworked. We adjusted their scale to make the big Borg ships much larger and more imposing than the other races' ships. From a gameplay point of view, we realized that the one thing the Borg exist for in Star Trek was missing from our game: technology assimilation. Now we have two different ways for Borg players to steal technology from other players for use on their own ships. The resulting race is a more frightening presence in the single-player campaigns and a more accurate representation of the Borg in multiplayer.

For example, if player A has a Borg cube and has researched the appropriate technology, he or she can use the cube's assimilation beam to steal the chain reaction pulsar off a Federation Akira class cruiser. From then on, that one cube can fire the chain reaction pulsar. Alternatively, player A could drag a captured Akira back to his or her technology assimilator station, break up the ship, and all cubes on the map that have a special weapon slot open can use the chain reaction pulsar.

Species 8472

In its Delta Quadrant adventures, the USS Voyager encountered a mysterious race that even the Borg feared: Species 8472. This race's ships are actually living entities, and the race is immune to many of the Borg's tactics.

Only two ships from Species 8472 were ever shown in the TV episodes, so we needed to create an entire fleet of organic-based ships that reflect the 8472 battleship shown on Voyager. We decided that most of the 8472 stations would be movable, as they are entities in their own right, and that has led to a very different dynamic. Additionally, we've made the 8472 ships individually more powerful than other races' near-equivalents but balanced that by adding to their cost. The economic structure is very different in that 8472 uses just one resource--biomatter--and the cost structure is so different for their ships.

So far we've met the challenge. We've created a game that builds greatly on the successes of its predecessor and extends the franchise and the genre with new depth, new UI innovations, and new gameplay. And along the way, we've maintained a professional working environment and presentation: Our developers work normal hours, and our clients/publishers seem uniformly ecstatic with our product. Additionally, we are that rare breed of development house that actually delivers milestones ahead of schedule.

My immediate challenge is balancing the nearly 100 distinct ship types in Armada II. Being a musician, it strikes me as a similar challenge to tuning a guitar with 100 strings. If any one string is out of tune with any other, the overall sound is discordant. For game balancing, we're combining a holistic approach (playing frequent multiplayer and instant action matches) with a scientific approach (tools that automatically construct hundreds of thousands of battles in which each ship type takes on each other's ship type, with automatic generation of cost-effectiveness measures). Even starting out with a decently balanced set of ships, we're finding the improvements in pacing and balance to be quite striking.

Beta will be upon us in a heartbeat, and then we'll be tightening the last screws. We're at the point where we've added great depth and are focusing on polish and balance. It's exciting.