Starship Operations in a Star Trek MMORPG

INTRODUCTION

Welcome! What follows is a design vision of how groups of players can work together aboard starships in a way that powerfully communicates the spirit of Star Trek.

The "complex and functional places" approach to designing starship gameplay in a Star Trek MMORPG has not been a popular one with previous Star Trek Online developers. For example, Daron Stinnett of the now-defunct Perpetual Entertainment said, "Space gameplay will [be] from an exterior point of view where you’ll have the best understanding of the tactical situation. This is a result of gameplay testing where we determined that playing from a interior point of view put the player at a significant disadvantage." The usual summary of this position was, "Star Trek Online will not be a starship simulator."

With respect, I think that position needs to be challenged, and it needs to be challenged hard. Why is tactical effectiveness for the combat-oriented gamers dictating for everyone else the design of one of the most crucial elements of a Star Trek MMORPG? Why not "simulate" some of the cooler aspects of operating Star Trek starships? That's one of the things people enjoy the most about Star Trek! Using the advanced technology aboard a starship to solve problems has always been an essential part of what makes Star Trek fun. Lose that, and you instantly lose a significant portion of Star Trek's appeal. Offering a conventional tactical combat MMORPG as the only interface to the wonderful ships of Star Trek won't make up the difference.

Of course an online game will be different from a TV show or movie. Some things will need to be cut; that's understood. And it's also understood that there will be some gamers who only want to experience ST:O as a tactical combat game. Supporting them is fine, but what about everybody else? What about the people for whom the spirit of Star Trek is its humanism and intelligence in creative problem-solving? How does making a tactical fighting game with a Star Trek skin serve their interests?

The problem with designing Star Trek Online's starships as just mobile spawn points in a 3rd-person tactical fighting game is that this fails to make full use of the Star Trek license. As the example of Star Wars Galaxies shows all too painfully, if a game makes too many compromises to conventional MMORPG play, rather than insisting on features that capture the spirit of the license, the many people who were drawn to the license won't be attracted enough to the game to subscribe to it (and stay subscribed). That might work for a combat-only World of Warcraft, but who here truly believes that Star Trek is that kind of license?

So of all the things to cut, such a critical part of the Star Trek experience as starship operation should not be on the hit list. Not only does that eliminate a core Star Trek experience, it fails to take advantage of a rare opportunity to offer innovative and enjoyable group gameplay beyond the conventional tactical combat of every other MMORPG. Not letting players work together to operate the systems of their ships means fewer subscribers to the game because there's not enough stuff to do that feels like Star Trek. Nobody will win when that happens.

I don't just mean "ST:O needs to do ship interiors," either. I'm not talking about how stuff looks. It's nice if ship interiors are rendered prettily, but enabling players to wander around inside a ship and stare at the walls is not what this proposal is after. What I will be discussing here is functionality. Players of a Star Trek MMORPG need and expect to be able to interact with the individual systems of their ships: modifying shield harmonics, transporting objects with strange bio-signatures, reprogramming the sensor array to pick up a garbled and faint distress signal -- the looks of such things are far less important than the gameplay content of letting players do the things that characters in the Star Trek universe are supposed to be able to do.

I believe whoever eventually develops Star Trek Online will find that many of the people who come to such a game for the Star Trek experience will expect starship operations to be a core gameplay element. Those potential subscribers will be disappointed if they discover that the core design focus for starships is "exciting" destruction. A fully satisfying Star Trek MMORPG needs the exploration-focused group vehicles that are a fundamental part of Star Trek, and it needs them to be standard-issue by design.

I realize that this proposal runs counter to the prevailing "we're not going to make a Star Trek simulator" attitude, and I'm definitely not trying to annoy anyone, so I won't be offended if the general feeling is that I've wasted my time on all this. Even if the core vision described here has no chance of being applied in a Star Trek Online, perhaps some of the associated ideas may prove useful elsewhere. And if nothing else, I had fun developing these ideas -- it's been an interesting exercise in systems design.

So to anyone who's suffered through this introduction and who braves the following exposition -- thank you! I hope you find something you like here.

A VISION FOR CRAFTING IN A STAR TREK MMORPG

In the universe of Star Trek, characters always face challenges.

Sometimes these challenges are physical, requiring the character to face a fear of injury or death. Sometimes the challenges are social, such as negotiating a peace treaty, establishing a trade agreement, or initiating a first contact. And sometimes the challenges are ethical, as when a character's fidelity to the Prime Directive is tested. If Star Trek Online's gameplay fairly represents the license, we can expect to see plenty of all these types of situations.

But the Trek mythos is nearly unique in popular fiction in how often characters are required to surmount intellectual challenges -- in particular, technological challenges. In the world of Trek, there are innumerable occasions when neither brute force nor diplomatic savoir-faire will work -- the only way to solve a difficult problem is through the creative use of advanced tools.

I think the path to providing fun intellectual challenges to ST:O players can be summed up in one simple word: "crafting." Not crafting in the sense of manufacturing, of making stuff to sell in an in-game economy, but crafting in its larger sense of creating interesting new things. The art and science of crafting is the exploration of technology... and that, in the service of an ethic of curiosity about and respect for sentient beings, is exactly what Star Trek has always been about.

In short, Star Trek Online needs crafting. And the best way to get it is by designing all of the hardware and software objects in the game -- especially including starships and their systems -- to be decomposable into components that can then be recombined in novel ways.

Although this concept should apply to every object, from handheld tools to warp cores, by far the most important vehicle for it is the starship. Not only are starships crammed with groovy technogadgets and clever software programs, they are full of that most glorious of resources: systems. For all their advanced hardware and software, without the systems that organize and control those things a starship would just be a box full of parts. When they're pieces of an intelligently-designed system, however, and those systems are operated by people, the whole supersystem becomes more than just the sum of its parts -- it becomes an incredibly powerful tool for exploration.

Working with the many systems that constitute this exploratory tool is what characters in the Trek universe do. They travel to distant places, seeking out new life and new civilizations, and they use the powerful systems of their starships to solve the problems that explorers inevitably encounter.

Which means that to see how crafting can work in ST:O, we need to look at how Trek characters use a starship's systems. Anyone who's tried their hand at designing a starship knows that there are many pieces, but how do those pieces fit together as an organized collection of systems? And how do Trek characters interact with those systems to achieve specific goals?

The answer is analysis and synthesis -- break it down, then put it back together again. So our first step will be to enumerate the best-known systems of Star Trek starships. Then we'll examine those systems according to their organizational structure. Finally, we'll consider the functional interactions that bring these systems together to form a fully operational starship. At that point we'll have a good idea of how a starship works, which will enable us to discuss in a concrete way how players can interact with these systems.

Ultimately this should demonstrate how starships are a crucial mechanism for enabling players to craft new things in ST:O in a way that's both consistent with the spirit of Star Trek and fun as a set of MMORPG features.


STARSHIP SYSTEMS

So let's get started, already! Here's the list of popularly recognized shipboard systems as I've developed it so far:

COMMAND

• Command
• Helm
• Conn
• Navigation
• Saucer Separation

ENGINEERING / OPS

• Engineering
• Power
• Matter/Antimatter Reaction Assembly (M/ARA)
• Electro-Plasma Power Distribution System (EPS)
• Propulsion
• Warp Drive (incl. transwarp & slipstream)
• Impulse Drive
• Reaction Control System (RCS) Thrusters
• Defenses
• Deflector
• Shields
• Armor
• Cloaking Device [non-Federation]
• Auxiliary
• Environmental / Life Support
• Artificial Gravity
• Inertial Dampener
• Transporter
• Force Field
• Tractor Beam
• Holoemitter
• Replicator
• Escape Pods
• Self-Destruct
• Structural
• Operations (Ops)
• Computer
• Core
• Processing Nodes
• Optical Data Network (ODN)
• Library Data
• Sensors
• Short-range
• Active
• Passive
• Long-range
• Astrometrics / Stellar Cartography
• Fighter Operations
• Shuttle Operations
• Cargo Operations

TACTICAL / SECURITY / COMMUNICATIONS

• Tactical
• Tactical Sensors
• Targeting
• Direct-fire Weapons
• Phasers
• Disruptors [non-Federation]
• Torpedoes
• Photon
• Quantum
• Plasma [non-Federation]
• Security
• Internal Security Sensors
• Hazard Teams
• Communications

SCIENCES

• Science
• Computing
• Research & Analysis
• Physics
• Life Sciences
• Medical
• Pathology
• Sick Bay

The first thing to observe about this list is that I've divided up shipboard systems into basically the standard branches: Command/Helm, Engineering/Operations, Tactical/Security, and Science/Medical. These correspond to the modern era uniform colors: Command and Helm in red, Engineering and Ops in gold, Tactical and Security in purple, and Science and Medical in blue or teal.

With the exception of Tactical/Security (discussed below), I think this list of managed systems fits the accepted conventions for Trek organization in the modern era; that is, from 2351 through at least 2405 according to the excellent "Spike's Star Trek Page" of uniforms. But there are a number of reasonable questions that could be raised.

The first concerns the inclusion of Medical as a subsystem of Science. After all, the medical staff from ST:TNG onward wore teal- or green-colored uniforms rather than blue. For that matter, they probably have their own department within SFHQ (I expect someone can tell us that for sure). But for purposes of simplicity and consistency within ST:O as a game, it seemed to make sense to include Medical as one of the major departments within the Science branch despite their wearing the teal/green uniforms rather than the standard blue of Science. Does anyone feel strongly otherwise?

Speaking of Medical, where's the Ship's Counselor? I went back and forth on this one for a while, but ultimately concluded that while it might be an appropriate role on a ship's Table of Organization, there's no "ship system" that is operated by a Counselor. (Having an office doesn't count.) Since ship systems are what I'm trying to represent here, I decided that Ship's Counselor didn't need to be shown. But I'm open to alternative viewpoints on this one, too.

Another issue I had to wrestle with is the relative paucity of Science systems. When does a duty posting include enough scientific activity to need a Science Officer? In reviewing the various Trekanalia, I found that there's very little consistency on when a posting might or might not include a Science Officer to handle a large science department. The original NX-01 Enterprise included a Science Officer. So did the Constitution-class Enterprises, as did Deep Space Nine. But neither the Galaxy- nor Sovereign-class Enterprises had a dedicated Science Officer (rather surprising for the NCC 1701-D), nor did Voyager. In the latter cases, science seems to have been one of the (many) responsibilities of the Ops officer. (There's also a story that Gene Roddenberry didn't like the way Brent Spiner looked as Data in Science blue. Putting Data in the gold uniform wound up creating the concept of the Operations department.) To try to reflect this, I've assigned the systems related to applied sciences to Ops, and the basic sciences that remained (including Medical) I assigned to the Science branch. That meant Ops got Astrometrics / Stellar Cartography. I think that makes sense, but moving it to Science (under Physics?) might be worthwhile if there's a good case to be made for it.

Yet another reasonable question might be why Ops and Engineering (and Tactical/Security) are divvied up the way they are. With a few exceptions (primarily Shuttle Ops and Cargo Ops), all these systems are maintained by Engineering but used by Ops or Tactical... so who "owns" them? Given the practical need to balance these departments so that no one wound up with too many responsibilities, I chose to organize their systems on the basis of whether an individual system was primarily related to information collection or operational processes -- either of those went to Ops, everything else went to Engineering. The exception was Communications, which somehow wound up being a duty of the Tactical officer. So obviously this distribution of the subsystems is somewhat arbitrary, but I think it's a pretty close approximation of what the Ops officers on the various TV shows did. It also seems to produce a reasonably balanced grouping of systems within each department, which is important for gameplay. Still, if someone wants to quibble, there's room to do so.

Something most Star Trek fans will have noticed is that although modern era (Star Trek: The Next Generation and "later") shows have Tactical/Security personnel in the same gold-colored uniforms as Engineering/Ops personnel, this is something that probably ought to be changed for an online game. (And change is not without precedent here -- after all, TNG+ changed Security from the "redshirts" they were in the original Star Trek series to the newer gold uniforms.) To minimize disruption to the modern uniform colors, and since red was already taken (by Command), purple seemed like an appropriate choice to once again distinguish Tactical and Security personnel from staff in other departments of Starfleet.

A final item worth pointing out is that not all starships will implement all the systems shown above. The bigger ships will have most of them, but smaller ships won't. For instance, an in-system tug might have multiple tractor beam emitters but no torpedo launchers or warp drive. And even most of the bigger starships won't require a "space boss" to manage fighter operations because only a few ships are carriers. (I'm assuming carriers can exist in ST:O even though they never got much use in any of the TV shows or movies... and why not, I wonder?) So the fact that some ship system is on this list doesn't mean it's installed on a particular ship. I'm just listing the possibilities.

OK, then -- taking into account all these exceptions and questions, how do these systems look to you? I didn't go into great detail -- for example, I didn't list "densitometer" as a type of passive short-range Sensor, or "dilithium articulation frame" as part of the Warp system -- because I was trying to list operational systems, not specific devices. With that distinction in mind, are there any systems I failed to list that ought to be included? Are there things I listed that shouldn't be there? And what about the organization of the systems I did list -- in your opinion, are they shown where they should be, or is there a more appropriate way to group them?

ORGANIZATIONAL STRUCTURE OF STARSHIP SYSTEMS

Assuming this list is reasonably close to the kinds of things that players would like to be able to do on a Trek starship, let's now move up a level and look at how these systems are organized in terms of shipboard personnel:



The Command branch includes Command functions plus Helm and Navigation systems. Personnel assigned to Command and Helm departments wear red uniforms. Note that serving at the Helm of a starship is usually considered an important milestone in a career path eventually leading to command.

Engineering, Operations and Tactical departments share numerous systems -- Engineering maintains them, while Ops and Tactical use them. (This distinction will be made apparent again in the functional diagram of systems that follows this discussion.) That said, Engineering and Ops typically handle support systems, while Tactical/Security officers focus primarily on offensive and defensive systems.

Engineering/Ops systems thus include the crucial support systems of a starship: Power generation, Computer services, Sensors, Propulsion, and several other valuable subsystems which I've aggregated as Auxiliary systems. Personnel assigned to both Engineering and Ops wear gold uniforms to reflect their close working relationship.

Tactical (offensive/security) and Defensive systems are the purview of Tactical/Security officers, who wear the new purple uniforms to indicate their special responsibilities for preserving the ship and her crew from all threats, external and internal.

Under Sciences generally are Medical and the specific Science units of Life Sciences and Physics. Ships of any size will usually have a Medical department (and some ships, such as the future Hope-class ships as seen in ST:TNG "All Good Things", may have large Medical contingents). Personnel assigned to the Medical department have in the past worn Science blue (or a light-blue variant), but after the 2370s began wearing teal-colored uniforms. That usage is preserved here.

Ships designed for long-range exploration and of a sufficient size are likely to have Physics and Life Sciences departments. Physics and Life Sciences departments will report to the Science Officer if one is posted; otherwise they will be under the direction of the primary Operations officer. General Science officers wear blue uniforms.

Each of these branches is represented at Starfleet Headquarters by appropriate members of the admiralty, who are responsible for setting policy and making high-level personnel assignments for each branch under the direction of SFHQ leadership.

Star Trek fans will have observed once again that this organizational arrangement makes a significant alteration to Starfleet's TNG+ era branch organization. Instead of sharing a department (and the gold uniform) with Engineering and Ops, for the purposes of designing an online game based on Star Trek I would (as I mentioned previously) give Tactical/Security personnel their own department and put them in spiffy new purple uniforms. Not only would this better reflect the distinct life-or-death kind of decision-making performed by Tactical/Security officers, from a gameplay standpoint it would shift some of the systems from the overloaded gold-branch to a separate branch. This would reflect the unique responsibility of Tactical/Security officers for the defense of the ship and its personnel.

With these organizational assignments in mind, let's next consider the functional structure of a ship's key systems.

FUNCTIONAL STRUCTURE OF STARSHIP SYSTEMS

This next diagram offers one possible interpretation of how the different systems of a large starship could interact:



Obviously this diagram is a little busy, but that does serve to make the point of how deeply interconnected all of the many systems of a starship are with each other. There are a lot of things to do on a working starship!

The key resources that need to be communicated are control, power and information. Command receives information from the officers in charge of the ship's key systems and gives control commands to these officers. Power must be supplied to each of a ship's systems as requested (under the watchful eye of the Ops officer). And the computer not only provides control to certain systems (such as Power), its primary function is to provide information to any systems that ask for it through a control request. Finally, some systems (such as Sensors and Auxiliary, or Medical and Life Sciences) share information directly with each other.

This complexity is not arbitrary. The reason why starships are able to function so effectively in the hostile space between the stars is because their systems are so well integrated -- the systems that need to talk to each other are connected so that they can do so. And because there are so many connections, there is redundancy of control. If a system is damaged, it is often possible to route control or power or information around the problem. (We'll examine this in more detail in a moment.)

You'll also notice that I've grouped certain systems into "elements." For example, the Helm element contains the Helm system (comprised of Conn and Navigation) and the Propulsion system; the Tactical element includes Tactical and Defense systems; and so on. (For various reasons, the Command system is its own element.) This additional level of organization helps to show the interplay among high-level systems during the actual operation of a starship -- some connections are closer than others.

Another somewhat subtler aspect of the functionality diagram that bears comment is that while the Command element normally controls the other elements, in a pinch those elements can operate autonomously. In other words, with Helm being its own element, the duty helmsman has the capability to take action without control from the Command element if warranted by circumstances. And the same applies to Ops, Engineering, Tactical and Science -- in a pinch, each of these elements might be called on to save the day, and each is capable of doing so. There might be an inquiry afterwards, but the capability is there by design for those occasions when it's needed. So although there are obviously a lot of connections between systems, those systems are also grouped in ways that enable ship elements to function when cut off from other elements.

A last point on this diagram is in some ways the reverse of the previous point (but they're not mutually exclusive). Although elements are to some degree independent of each other, there are also many connections between elements. Not only does this support the concept of rerouting power and information, it also enables the related concept of allowing control of systems by alternate elements. For example, a severe ion storm might cut off some parts of a ship from other parts -- if the Helm system were destroyed and its duty officer lost, the Tactical officer might be called on to maneuver the ship to safety. Having multiple connections to systems would allow the Tactical officer to command the ship's computer to route power to the propulsion system, as shown in the functional diagram. It might not be efficient, but it might be just enough.

STARSHIPS AS COMPLEX SYSTEMS

So, even after all these points, it's fair to ask: would starships in ST:O really need to be this complicated? I think so. In the first place, this level of complexity in a starship's form and function is a critical aspect of many Trek storylines. People and their relationships are always the most important thing, but the technology -- in particular, the operation of a starship -- helps to highlight those stories. If that's not a core component of ST:O, it just won't feel like Star Trek.

Dramatic effect comes into play here as well. Probably the two most common words regarding ship systems in all of the Trek shows are "reroute" and "divert." It seems like captains are always directing their Ops officer or Chief Engineer to reroute power around damaged systems or divert all available power to a key surviving system. It would be very strange, I think, if a game that allowed players to be responsible for various ship systems didn't include this capability, or the similar requirement that nearly all ship's systems require an active link to the ship's computer. (How many times have we heard exclamations like "The starboard power coupling's gone!" or "I've lost helm control!" when a critical system loses its access to power or the main computer?)

Implementing starships in ST:O according to the functional structure diagram above would support this dramatic redirection of ship resources. Players with the appropriate authority, like their fictional counterparts, could help save the ship and its mission by diverting power from life support to the shields at a critical moment, or by restoring helm control by rerouting it to a workstation in Engineering that still has computer access, and so on. These kinds of actions would be creative tasks that would allow ship's personnel to shine by devising novel solutions to tough problems... just like they do on Star Trek.

An important second reason for giving starships some serious depth is that many of those who'll be drawn to a game like ST:O will, I think, be the kind of people who find complex systems more interesting (read: more fun) than trivially simple objects. Certainly there's room for simple objects in any MMORPG. But ST:O, if it's really going to honor the Star Trek ethos of exploration, is exactly the right game to offer more exploratory depth for the people who appreciate that kind of play.

CRAFTING AS STARSHIP-BASED GAMEPLAY

Which brings us -- finally! -- to "crafting."

Here's the summary: many of the tasks performed on a starship are routine. I call these "control tasks" to indicate that they're about normal control of ship systems. These are things like repair tasks or general maintenance. For the most part, this is one thing even I can agree is best not implemented in a game!

But some tasks can't be accomplished by routine actions. I call these "creative tasks" to highlight their dependence on creative thinking and novel solutions to unexpected and difficult problems. This is what ST:O's design should be focused on offering to players, because this is what makes characters in the Star Trek universe special.

Creative tasks break down into two kinds: new ways of using existing tools (where "tools" means hardware devices and software programs), and the development of new tools. In turn, the development of new tools comes in two flavors: writing short programs to alter an existing device's default behavior, and creating new devices.

Here's how this looks in outline form:

• Control tasks
• Creative tasks
• New processes
• New tools
• New programs
• New devices

The creation of new programs and devices is what I mean by "crafting" in the world of Star Trek. Using existing tools in new ways to solve a problem is definitely a creative task, and I hope ST:O is designed to reward that kind of gameplay. But it's also important for ST:O to reward the fabrication of new things, which is a little closer to the notion of crafting in current MMORPGs (and so may be more familiar to current online gamers).

To provide a better idea of these categorizations, here are some examples of each type of creative task from the various Star Trek TV shows and movies.

New uses of existing tools:

• Spock recreates a transporter mishap to retrieve personnel from the mirror universe (ST:TOS, "Mirror, Mirror")
• Scotty and Spock adapt the transporter system to accept power from the impulse drive (ST:TOS, "The Enemy Within")
• "The Picard Maneuver," a very short warp jump to confuse sub-lightspeed sensors (ST:TNG, "The Battle")
• Picard applies ship's thrusters to use an asteroid's gravity in a slingshot effect (ST:TNG, "Booby Trap")
• The ship's phasers are used to perform a kind of Caesarian section on a space alien (ST:TNG, "Galaxy's Child")
• Geordi "sours the milk" of an alien by changing the frequency of the ship's energy (ST:TNG, "Galaxy's Child")
• Data uses a very sensitive phase discriminator to precisely control a subspace force field (ST:TNG, "Time's Arrow, Part 1")
• Scotty survives 75 years in a transporter buffer by recycling his pattern (ST:TNG, "Relics")
• Picard disables the safety protocols in the holodeck to use a submachinegun to kill two Borg (ST:First Contact)
• Torres locks onto a person's bone marrow when a conventional transport lock fails (ST:VOY, "Scorpion, Part 1")

New programs:

• Kirk as a cadet reprograms the "Kobayashi Maru" simulation to be able to win (ref. in ST:The Wrath Of Khan)
• Data writes and adds a romantic relationships subroutine to his programming (ST:TNG, "In Theory")
• Lefler has Wesley manually sequence subroutines to recalibrate a detector (ST:TNG, "The Game")
• Wesley reprograms an antimatter regulator to spray chili sauce (ref. in ST:TNG, "The Game")
• Wesley programs a site-to-site transport routine (ST:TNG, "The Game")
• Ezri Dax and Kellin reprogram the Jem'Hadar "Houdini" mines (ST:DS9, "The Siege of AR-558")
• Torres alters a missile's goals (ST:VOY, "Dreadnought")
• The holographic Doctor creates numerous additions to his program (e.g., ST:VOY, "Darkling" & "Tinker, Tenor, Doctor, Spy")

New devices:

• Kirk builds a crude cannon in his fight with the Gorn (ST:TOS, "Arena")
• Spock constructs a mnemonic memory circuit using "stone knives and bearskins" (ST:TOS, "The City on the Edge of Forever")
• Dr. Daystrom builds M5 to replace (unsuccessfully) an entire starship's crew (ST:TOS, "The Ultimate Computer")
• Barclay invents a neural interface to the Enterprise main computer (ST:TNG, "The Nth Degree")
• Data constructs an android daughter (ST:TNG, "The Offspring")
• Bashir develops an in-utero vaccine to cure a Dominion-produced disease (ST:DS9, "The Quickening")
• The Doctor develops Borg-inspired nanoprobes to treat Harry Kim's cell degradation (ST:VOY, "Scorpion, Part 2")
• Kim (with Seven of Nine) constructs an Astrometrics lab (ST:VOY, "Year of Hell, Part 1")
• Paris designs and builds the Delta Flyer (ST:VOY, "Extreme Risk")
• Seven of Nine designs and builds a containment system to hold the Omega molecules (ST:VOY, "The Omega Directive")

The point to listing all these examples is to demonstrate that the creative use of technology to solve problems is a fundamental part of Star Trek. Exploration means encountering new situations that don't respond to old ways of doing things. Being able to adapt to the unexpected is thus a hallmark of the explorer.

What's important to see here is that this creative adaptability -- building new tools and using them in new ways -- is both interesting to do in its own right and exciting when told as a story. Solving a problem that only occurred because we made the deliberate choice to expand the horizons of our knowledge makes for a dramatic story. All the best Star Trek episodes and movies showed that creative problem-solving is fun and dramatic.

Because Star Trek Online will be interactive, it needs both of those things even more than the TV shows and movies. Implementing starships that are detailed enough to give players many tools for solving challenging problems can insure that ST:O players enjoy all the fun and drama of Star Trek, and then some.

STAR TREK CRAFTING -- THE DETAILED THEORY

Now let's look a little more closely at the twin crafting concepts of making new devices and writing new programs that change the functionality of devices.

New devices are a Trek staple. One of the side effects of having stories based on advanced technology is that if you need a "McGuffin" for a story, you can simply declare that it exists. Name it with some bit of plausible pseudo-scientific gibberish and you're good to go.

The result of this in Trek is that new devices (new to both the characters and to viewers/players) show up all the time. It's part of Star Trek; there's always some new gizmo that's useful or dangerous (or both) to contend with, or a need to make a new device to solve an urgent problem. So it's only natural that new devices play a meaningful role in a Star Trek MMORPG as well.

There are two ways to accomplish this. One is for ST:O developers to make like Star Trek writers and pre-invent all the new devices that players will ever encounter (perhaps through away missions). That would keep everything canon, but it could chew up a lot of development time. Even worse, no matter how many devices are written by the developers, players will discover virtually all of them in a few months. Once the pregenerated content has been burned through, then what?

The other approach is to let players create their own new devices. This would also require significant development time to do it right, but it has the advantage of being dynamic content that changes for every player and thus never gets stale. It would also do a much better job of letting ST:O players feel like characters in the Star Trek universe because it lets players do what they've seen Star Trek characters frequently doing.

The key to letting players make new devices is for the developers to create basic components, to build the standard set of supplied devices (including starships) out of these components, and to give players a way to take devices apart and put them back together again in new ways and with new components for modified or new functionality.

Suppose you've just finished trading with a representative of the Kylari homeworld, and one of the things you picked up is a subspace phase modulator assembly. Your existing phase modulator is pretty good, but it looks like your subspace scans might be a little more accurate if you could figure out how to integrate this new device into your sensor system. At this point in a TV episode, your ship would get a distress call from somewhere in subspace -- wouldn't it be cool if you could save the day by analyzing the inputs and outputs of the old and new devices and work out how to replace the old one with the new one so that you can find the vessel lost in a subspace inversion?

Or maybe you pick up an improved phase capacitor lattice on an away mission. If devices are built from components, you might be able to field-strip your phaser to use the new capacitor lattice for (say) improved collimation (i.e., more thermal damage but at a significantly higher power drain). By being able to break down devices into components and using different components of the appropriate type to rebuild devices, players could use their ingenuity to solve technological problems just like characters in Star Trek.

But of course all this needs to work within the context of a massively multiplayer game. To keep a device-making ability from getting out of hand so that Federation players don't rapidly wind up with hand-held plasma torpedo launchers, several kinds of constraints could be considered:

• only characters with Engineering or Ops experience have the skills necessary to tinker
• many components have specialized interfaces (reducing the number of other components they can be connected to)
• Federation devices tend to take only Federation components (ditto for Klingon devices, Romulan, etc.)
• standard-issue gear is required for away missions
• new devices must go through a lengthy process to become standard issue gear

These rules could definitely be tweaked; I'm just listing some ideas to acknowledge that there'd need to be reasonable limits on creating new devices. Not so much that this important aspect of Star Trek loses its impact, but just enough so that Federation gear still feels like Federation gear after the game has been going for a few years.

The other concept needed to support crafting in ST:O is programming. At least as often as characters invent new devices -- and probably more so -- they also change how devices behave by modifying the programming that binds devices together into complex systems.

Sometimes you can get what you need by issuing a normal command to a device, such as "EPS manifold R-27, change your output route from EPS junction 34-A to 34-B" or "deflector emitter, apply a frequency modulation of 72.831 megacycles per second to the next tachyon pulse" and so on. That's the kind of thing I call "new processes."

But there are also times when changing a particular device's output isn't enough -- you need to change how an entire system behaves on an ongoing basis. That's when the programs controlling the standard behaviors of systems need to be altered, either with modifications or with completely new programs.

As the examples earlier showed, this kind of system-modification goes on all the time in Star Trek shows and movies. Being able to tweak how a system performs over time is a common task. It's not a "control task" because it's something out of the ordinary, but it's common as a plot feature in Star Trek fiction. It's also an interesting gameplay feature. Consequently, ST:O would benefit from including it as well.

As with devices, the most satisfactory way to let players program systems is for the developers to build systems of devices with default programming, and then allow players to change those system-control programs. In effect, ST:O would have its own standard computer language for controlling and connecting devices. Complex systems (such as warp drives and sensor arrays) would be built by Perpetual out of devices and programs that reside on the local computers that connect those devices. When a player finds that the default system isn't sufficient, he or she could rewrite its programming to improve it, making it more efficient or giving it new capabilities.

STAR TREK CRAFTING -- PRACTICAL QUESTIONS FOR MMORPG GAMEPLAY

Naturally this feature needs to be carefully considered for how it would work in a massively multiplayer online game. One of the most common objections to letting players develop their own programs is that some players will choose to use this power to annoy other players. It's a fair objection, but I think there are also a couple of good responses that can be made to it.

First, a familiar part of shipboard Star Trek is the concept of the "authorization code" (or, in the case of command personnel, their command codes). Although we tend only to see these used in dramatic situations, it's been supposed that entering these codes is actually a standard action. When you start to use a terminal or workstation, the first thing you do is enter your auth code. This serves several purposes: one, it restricts your actions to only those which you are authorized to perform; two, it tags everything you do with your identity (and a timestamp); three, it can be used to lock hostiles out of sensitive systems; and four, it accesses all of the LCARS keypad configurations that you've predefined for performing specific activities. (More on that in a moment.)

The first three of these purposes serve the need for security. By restricting actions to users with appropriate privilege levels, and by logging permitted actions, the use of auth codes would limit griefing. (The third use of auth codes, to lock systems, might be griefed, however.) Still, players serving aboard a starship who use their power to compromise ship systems would likely be caught and shown to the nearest airlock. Even better, restricting systems to authorized (trusted) players only would make it harder for the typical griefer to do real damage. In any event, "programs" to operate ship systems are not at all the same thing as the macro and script commands used to automate player actions in some current MMORPGs -- you might be able to automate a ship, but characters couldn't turn themselves into AFK bots. (And even automating a starship is not without risk -- remember what happened when Dr. Daystrom plugged M5 into the Enterprise? Faulty programming of a starship's systems should have consequences.)

The second response to the "players will abuse the power to write programs" objection is to point out that, in many of the Trek shows, someone does abuse this power! Whether it's Spock faking library tapes (ST:TOS, "The Menagerie") or Ceska hiding a booby trap in Tuvok's mutiny simulation (ST:VOY, "Worst Case Scenario"), it seems like someone is always finding a way to circumvent the security features of starship computers. If ships in ST:O can be boarded by hostiles, or NPCs serving aboard player ships can ever turn out to be saboteurs, then allowing a certain amount of leeway in spoofing a ship's computer might actually prove to be a game feature that players would enjoy because it would let them live out the plot of a typical Star Trek episode.

Perhaps a more powerful objection to letting players write system-control programs is "people want to play a Star Trek game, not program virtual computers." That's absolutely true... for some people. Those who prefer more "physical" or social activities in the game world will no doubt be able to satisfy those interests, but I'm confident that there are other gamers (including people who like Star Trek) who would find equal enjoyment in the technological problem-solving in a Star Trek setting that ST:O could provide. For these gamers, the chance to save the day by reprogramming the transporter system to accept an unscannable material (for example) would be an incredibly satisfying experience.

Taken together, I believe that offering these forms of crafting -- the ability to create new devices and new programs to control a starship's systems -- is such an iconic part of Star Trek that it is crucial to ST:O's success. Allowing players to solve problems through the manipulation of advanced technology is a great way to help them feel like a part of the Star Trek universe.

Crafting as part of exploration is so fundamental to Star Trek that implementing it in ST:O will contribute significantly to getting the most value out of the Star Trek license.

A NOTE ON SENSORS AND STARSHIP OPERATIONS

There's one other point that's related to "crafting" creative solutions to difficult problems, but which isn't directly related to ship's systems. That being the case, I won't go into detail about it here, but it's worth mentioning. And that is the amazing variety of fields and particles and waves and energies that make up the Star Trek universe. (As someone has put it, "Star Trek is one of the greatest sources of technobabble ever." There's a reason why the neologism "treknobabble" was coined....)

From tachyons to polarons to chronotons to vertirons and beyond, Trek is overflowing with things that can be sensed and/or emitted. To truly allow ST:O to feel like Trek, players will need to be able to direct the various systems of their ships to detect these things and (when appropriate) to emit them in multiple modes. Space needs to be full of all these forms of matter and energy in order to give players materials for their ship's systems to operate on -- they are a prime source of challenges to be addressed in creative ways.

[I take up this subject in my customary insane level of detail in my later essay, Sensors and Star Trek Online.]

STARSHIP OPERATIONS AND THE LCARS INTERFACE

To close this subject of working with devices and programs and systems in a Star Trek game, a note about LCARS interfaces. While I expect some differences between how they work in film Trek and in a MMORPG (both for the sake of novelty and because a game will surely require some compromises to canon), I'd be shocked if shipboard interfaces didn't use some form of the LCARS visual interface. Unless ST:O is going to support full voice recognition, we might as well get some additional use out of all those Okudagrams!

So I assume that some version of the LCARS interface will be the means by which players operate ship systems. If so, the details of this interface are worth a few observations as they relate to performing control tasks and creative tasks.

Overall, I would suggest that some thought be given making certain functions part of a common user interface. In particular, I think every display panel should include at least the following components:

• a login/logout control (see the "authorization code" discussion above)
• a Config control to allow screen components to be reconfigured (and the new config to be canceled or saved)
• a Function control that displays a list of saved configs for the current user

These aren't meant to constitute a complete list of common user components. I expect there'll be more; this is just a first crack at a definition -- feel free to suggest others! But these capabilities in particular would serve at least three useful purposes.

First, although every standard ship function should have a default LCARS layout, allowing players to create their own screen layout for any activity will allow them to perform their duties more efficiently. For example, Player A might want to configure a helm control layout in which impulse and warp controls are on the main screen and thruster controls are on a pop-up screen. But Player B might prefer to lay out her helm control screen so that all three modes are on the same page, with thruster controls on the left side because she's left-handed. And Player C might want to have several helm control layouts suited for different tactical situations. Allowing players to configure LCARS screens will go a long way toward personalizing the game for each player, increasing the sense of immersion in the Trek universe.

Another aspect of allowing players to configure screens is to support players with multiple shipboard responsibilities. Once they've configured layouts for each of their tasks, a player will be able to switch between functions by selecting the appropriate control. For example, an Ops officer could be monitoring sensor channels when a telltale lights up indicating that a shuttle launch is in progress. By pressing the Function control, then selecting the config for the Shuttle Ops function, the LCARS display for shuttle operations can be quickly displayed, allowing the Ops officer to inform the captain that yet another unscheduled shuttle launch has occurred. (Those seem to happen pretty regularly in the Star Trek universe, don't they?)

Lastly, allowing displays to be defined for individual users will let players bring up their preferred screens on whatever workstation they happen to be using. This will be especially helpful for those players whose duties take them all over the ship, as opposed to players whose functions have dedicated Bridge or Engineering stations.

In summary, this level of flexibility in control panel configurations would enable players to respond quickly to challenging situations with creative solutions. As the primary interface to modifying or using ship systems (in a game that probably won't include computer voice recognition), it's important to have a control system that players can tailor to their preferred styles of thinking and acting.

SO WHY MAKE STARSHIPS THIS FUNCTIONAL?

There's a final reason I'd like to mention for designing a Star Trek MMORPG so that players can manipulate the advanced technology aboard powerful starships: empowering characters generates interesting stories.

Technology in Star Trek has never been just about the gadgets -- it's always about when to use those gadgets and when not to. In other words, the high tech of Star Trek exists to raise questions (in dramatic form) about the right uses of power. This is the same premise that drives all good science fiction: when advanced technology lets you do nearly anything you like, under what conditions should you refrain from using your power? Should human limits still apply when machines can augment your senses and skills and even intelligence? (Star Trek's Borg ask this question in a startlingly direct way.)

Star Trek has always held that with power comes responsibility. When you have power over life and death, over time and space, and you choose to go exploring, your power over the people you encounter will generate ethical dilemmas. When is it right to use power, and when is restraint the right decision? This conflict drives many of Star Trek's best stories:

• Kirk lets Edith Keeler die (ST:TOS, "The City on the Edge of Forever")
• Is Data a person, who therefore has a right not to be disassembled by Starfleet? (ST:TNG, "The Measure of a Man")
• Barclay ignores Picard's orders and brings the Enterprise to the Cytherians (ST:TNG, "The Nth Degree")
• Picard changes history by sending his predecessor's ship back in time to its destruction (ST:TNG, "Yesterday's Enterprise")
• Picard convinces a young culture that advanced technology does not make one a god (ST:TNG, "Who Watches the Watchers")
• Q gives Picard the chance to be a different man by changing his personal history (ST:TNG, "Tapestry")
• Jake Sisko changes the timeline to restore his father from a closed time-loop (ST:DS9, "The Visitor")
• Sisko provokes the Romulans into declaring war on the Dominion (ST:DS9, "In the Pale Moonlight")
• Bashir chooses to hide his genetic enhancements (ST:DS9, "Doctor Bashir, I Presume")
• Janeway destroys Tuvix by restoring Tuvok and Neelix (ST:VOY, "Tuvix")
• Chakotay and Harry defy Starfleet, changing the timeline to save Voyager (ST:VOY, "Timeless")
• Admiral Janeway sends advanced technology back in time to Voyager (ST:VOY, "Endgame")

But not everyone chooses to use their technological and intellectual capabilities for selfless reasons. Some of the greatest villains in Star Trek have been those who chose to use their power without regard to the consequences to others:

• Khan Noonien Singh lusts first for power, then for revenge (ST:TOS, "Space Seed" & ST:The Wrath of Khan)
• The Terran Empire of the mirror universe rules by force (ST:TOS, "Mirror, Mirror" & several ST:DS9 episodes)
• Although not precisely a "villain," many of the Q episodes explored omnipotence (ST:TNG, ST:DS9, ST:VOY)
• Data's "brother," Lore, is willing to sacrifice anyone to achieve his ends (ST:TNG, "Datalore", "Brothers" and "Descent, Parts 1 & 2")
• The ur-villains of Star Trek -- the Borg -- destroy other cultures by assimilating them into their own (ST:TNG & ST:VOY)
• Dr. Soran destroys star systems to bring the Nexus to him (ST:Generations)
• Gul Dukat comes to hate the Bajorans for rejecting his "compassionate" rule during the Occupation (ST:DS9, "Waltz")
• The Female Shapeshifter leads the Dominion to conquer the "solids" of the Alpha Quadrant (ST:DS9)
• Arronax of the Krenim rips entire civilizations out of time to restore his wife's life (ST:VOY, "Year of Hell, Parts 1 & 2")
• Captain Ransom of the Equinox uses alien lifeforms for fuel (ST:VOY, "Equinox, Parts 1 and 2")

In particular, the Prime Directive has been the source of a vast amount of storytelling in Star Trek precisely because it places self-imposed limits on the use of power. stories testing the boundaries of the Prime Directive have been as valuable to Star Trek as stories testing the Three Laws of Robotics were to Isaac Asimov, and for the same reason: the intersection where hard-and-fast rules governing conduct meet the real world is where there's the most potential for conflict, and conflict makes for good storytelling.

How firmly do you hold to your principles that tell you to refrain from using power? What about when using that power could save you from destruction or relieve the suffering of innocents? When is it OK to bend your principles? How far can you bend them before they break? That's the conflict at the heart of great drama. It's been the source of many of the strongest stories in the Star Trek universe.

It can and should be the source of strong gameplay in Star Trek Online as well.

CONCLUSION

Which brings me at long last to my conclusion: implementing detailed and powerful starships for players to use in Star Trek Online is such an effective mechanism for bringing the spirit of the Star Trek license to life that it should be a key design feature, not dismissed as a "starship simulator."

Detailed and powerful player starships satisfy the two requirements for good storytelling in the Trek universe. The detail enables crafting that would offer Star Trek Online players what legendary game designer Sid Meier has called "interesting decisions." And the power ensures that those interesting decisions carry ethical weight. Without the detail or power, a core aspect of Star Trek is lost -- either it's not possible to generate creative technological solutions to problems, or those solutions are mere grinding without meaning. In either case, it won't feel like Star Trek, and it won't be a fun online computer game.

Yes, a Star Trek MMORPG must do more than just tell a good story -- it needs rules of play to make it a good game. Detailed starships and other devices enable good gameplay by offering a rich environment for crafting and tool-based problem solving. But why settle for merely good gameplay when it's possible to make a great game by ensuring that all of Star Trek Online's features are driven by the humanistic ideals of Star Trek?

A Star Trek MMORPG should be more than "just a game," just as Star Trek was more than "just a TV show." And it can be, if the player operation of detailed and powerful starships is a core design element.

...

To anyone who made it all the way here, my thanks. I appreciate your considering these ideas, and I hope you found something rewarding in the journey.