At Totally Games we have always taken pride in doing a license right. Everyone knows that putting licensed assets in a preexisting game is a quick way to get a licensed product out that may grab sales from name recognition, but often these mergers leave both the fan of that game style and the fan of the license disappointed. Not all licenses and game styles are a good match. With the Star Wars X-Wing series of games, Totally Games took the crucial elements of that experience (WWII-style flight, fast action, hordes of enemies) and put them in a game that presented them like the movies. When we set out to do a Star Trek game, the same applied: getting the core elements and then faithfully presenting them.

The license and "feel" issues ruled out the Defiant/fighter-style game. The third-person tactical space simulation satisfied the feel and addressed the tactical awareness issues of large capital ship combat but was still missing a large part of what made Star Trek what it is: the characters and the bridge. The bridge concept satisfied this but was lacking the tactical awareness needed to make a space combat game really work well for a hard-core audience. The logical solution seemed to be a merger of the bridge and third-person concepts, which would give the best of their strengths and cancel out each other's weaknesses. Although far more ambitious than limiting ourselves to one or the other, we felt this was the best way to do the license properly.

Considerations

With these basics covered, we formed a small core team to refine the design and get working on a prototype. This team was me (project lead, programming lead), Morgan Gray (design), Armand Cabrera (art), Albert Mack (programming), Michael Zyracki (programming), and of course lots of guidance from Larry Holland (president and creative director). Over the next few weeks we worked out the design, submitted a concept document, and started pondering the technology needed for such a game.

Getting from the abstract concept stage (bridge sim and third-person outside-view space combat sim) to a coherent concept meant addressing a number of issues. Some of the important ones included finding the correct mix of simulation, action, and adventure. Star Trek is much more about characters and character interaction than space combat. If you watch the shows, you see characters talking to each other and resolving crises on the bridge. Here and there you get beautiful outside shots of the ship in space and occasionally some combat.

This obviously lends itself more to the adventure game genre than to a space combat simulation, but that wasn't what was being asked for nor was it our best expertise. It also turns out the flow and logic of a Star Trek episode plot (or any noninteractive entertainment story, for that matter) doesn't always make for good gameplay. While the plot of a Star Trek may hinge on the engineer making a genius discovery on how to adapt the sensors, in a game, having the "apply genius discovery to adapt sensors" button just isn't fun. And since you can't really build a game to allow for such one-in-a-million insight and cleverness to be possible for everyone who plays, it is hard to capture this essence in an interactive product.

What we resolved was that we could adapt elements of adventure, exploration, and diplomacy into the bridge interaction with characters and story, but to keep us grounded these would fall into the context of a combat campaign.

We also wanted to capture the detail and depth of the bridge stations. Doing a space combat simulation is a large task. Adding a completely new additional interface with a full bridge and animated interactive characters made a large task massive. We knew that a game could be made where each character on the bridge had its own full-screen detailed minigame, but we knew that it was well beyond our scope. We needed to keep the interfaces with the characters limited to what was necessary to control the ship and accomplish the goals of the game. As it turns out, two of the stations (tactical and engineering) wound up growing quite a bit beyond the initial designs.

Then there's the importance of character usage. From our experience with the Star Wars license, we had a guideline for how to use existing characters in the license. While it is a common desire to role-play these notable characters, many issues complicate it as well. The license doesn't work well if you accidentally kill off main characters without ending the game. We also wanted to let the players create an identity on their own. So like with the X-Wing series, we include the notable characters as cameos and additions to the story instead of placing you as Picard on the bridge of the Enterprise. This allows the story to be much more flexible and keeps us out of many gameplay traps. A final decision we made was not to show the character as a physical being. To do so would mean making lots of choices that again would prevent the players from having their own identity. If we were to show the player's body on the bridge, would it be male or female? What skin color would it have? Would it be human or alien? Better to let the players be who they want to be.

Finally, we wanted to realistically re-create and represent the scope of locations in the Star Trek universe. Much of Star Trek involves away teams and different parts of the ship. While necessary for the show (people would get tired of the same location endlessly), it wasn't practical from an art and technology standpoint to do so in the game. Creation of highly detailed sets is art intensive, and we wanted to avoid throwing the gameplay aspects of a first-person shooter into the packed mix of gameplay we already had.

Our compromise was to use the view screen to show different places, in an effort to keep the experience fresh. This allowed us to create a larger number of special sets that would only need to be viewed from one angle and could be built faster because they were not the focus of the player's view for extended periods of time.

With the concept refined, we were ready to grow the team and step up to the next tasks: a more complete design doc, the story, and a demo (a technical and interface proof of concept).