Design Ideas for a Space MMO

Introduction

Every time I watch a movie or TV series with space fighter combat (Star Wars, Battlestar Galactica, Firefly/Serenity, Star Trek, etc.), this idea recurs to me. It's based on time spent playing X-Wing, Wing Commander, and other space sim games in high school. The idea: how to take space fighter sims to the next level, to make one as an open-source Massive Multiplayer Online game. I'm sure other people have had this idea (in various forms). But here's how I would go about it. (But I don't have time for another project, especially one this big. So I'm posting ideas here to add to every time I watch a space movie. In the meantime, maybe someone else will get interested in the project...)

Project Stages

A project this big needs to be built from the ground up, but with some kernel that's useful and fun as soon as possible. So I'd build in the following order.

Flight Sim

The basics of the game is a star fighter space simulation, so we should start here.

Underlying Rule System

Every modeled/in-game system should be based on only a handful of universal attributes. (Think of these as character attributes in an RPG.) These attributes and interactions should be based on real-world physics as much as possible, but with an eye for game balance. And we're talking sci-fi here, so not everything needs to be fully specified. And it's a game, so keep it simple and remember we're not going for full sim here.

Attributes include:

Attributes are revisited in the next section, after we have some systems in mind we'll need to support.

Ship Components (Sub-systems)

Each sub-system type will have certain constraints/rules attached to it. For instance, all propulsion systems may have volume constraints, so that they can't be incredibly long or flat. But within these general constraints, and based on the underlying game attributes, subsytems are user specified--each having different properties and design trade-offs.

Sub-systems include:

Propulsion
Exact details of operation can be unspecified (as the glowing pale blue or red lights on the back of most movie spacecraft are), but has energy requirements of at least enough to move the inertial mass of the whole starcraft. Pretty easy to calculate how much energy is required. Probably has different volume and mass based on how much acceleration it can provide. A ship might have a main propulsion system, and then a handful of small thrusters to rotate the ship. Or a ship could have six equal systems that allow it to move in any direction without turning.
Flight control (steering)
Coordinates the many small propulsion system used to provide rotation, etc. Might be scripted to provide different sorts of behavior--such as banking, etc.
Energy
Provides energy for the ship as a whole. Might have auxiliary or backup systems. Possible user-provided designs: battery, solar powered, nuclear, fusion reactor, anti-matter, etc. Systems that provide more power are larger and heavier (due to necessary cooling and containment systems). (Still unresolved: includes a "fuel" component, meaning you can run out, thereby limiting flight time?)
Weapons
Lasers, or various projectiles. [Special attribute?: damage done. Special attribute?: range] Perhaps disabling ion-cannons, meaning different types of damage? Tractor beams?
Shields
May be energy or field-based, or may simply be armor plating. [Special attribute?: damage protection. All systems have a default of 1, but shields provide additional covering]
Life-support (cockpit)
Might include cockpit protection, ejection system, etc. Pilot death occurs after a certain amount of time with no life support.
Sensors
Includes presence of space objects (radar-like overview), targeting computer (determining friendly ship from foe; based on some broadcast code?), reports on enemy subsystems (whether they have shields up, for instance), etc. Maybe need to be broken down into further subsystems. Also, systems for jamming or fooling enemy sensors. [Special attribute?: range]
Communications
Ability to communicate with team members. (May be need to be dropped, or at least integrated, depending on the real-life chat/communication system used.)
Faster-than-light system
Some sort of "jump" system, whether hyperdrive, warp, or something else.
Navigation
Usually necessary for any sort of faster-than-light travel, but often can be taken out independent of the actual jump system
Cargo capacity
Not a system per-se, but certainly takes up a lot of volume and a bit of mass.
Other systems
On-board maintenance system (such as an R2 unit that can fix systems in-flight); atmospheric flight system (perhaps reduces energy needs through use of wings, etc); cloaking system (2 versions: blind to sensors, and blind or disguised to eyesight); remote flight control (to avoid pilot loss as well as the need for a life support system); stasis system (to preserve pilot or whole ship).

As mentioned, each subsystem would be user-generated and specified, within the bounds of the underlying attribute system. (So this needs to be right to maintain game balance!) From a library of such subsystems, users can then build different ships. These can be as simple as a communications or sensor relays with no propulsion or shields, to a starfighter, to a major fleet carrier. Ships should also be customizable in external appearance, though general shape constrained by component sub-system volumes. Also, placement of subsystems determine which are hit in blasts--so placement and shielding can determine whether you're more likely to loose communications or hyperdrive or life-support.

Game should also support "power rerouting". By cutting power to some systems, more can be routed to weapons, shield, propulsion, etc. (So it might become standard to reroute power from hyperdrive to weapons and shields when in combat.) But should rerouting have any further drawbacks, such as time to preform the reroute, or the possibility of burning out a system running at higher power levels?

Attributes again. Greater mass means more energy requirements to move it. Greater volume means being an easier target to hit. Higher energy requirements means you need a larger energy-generating subsystem, making a heavier, larger ship. To make such a ship more maneuverable, a larger, heavier propulsion system is needed. Ship design becomes a strategic endeavor of trade-offs: shielding, maneuverability/speed, weapon selection, range, FTL capability, etc. (There might be some good ideas for game/system design from table-top space RPGs?)

Cost is a tricky one. May simply be dependent on other attributes. But cost might allow reduction in other attributes (lower mass/volume/power needs through more expensive design). This should be limited somewhat, so someone with a lot of coin can't completely dominate the game world. However, ships with higher cost also hurt more then they're destroyed.

The number of attributes should be kept to a minimum. For instance, missiles could be treated as tiny ships, following the same rules of mass and propulsion energy requirements. Sensor range could be based on some tiny mass (particle, rather than wave, physics) and the initial propulsion given. But this could be become computationally complex (especially when sensor beams need to return with their info). So this would be a good special case attribute, that simply returns the appropriate info within range. But sensor systems would still have a baseline of mass/volume/power consumption. Probably different kinds of sensor systems too, detecting different things. [How much of this needs to be specified in core rules?]

Software Design/Construction

So we need the following design phases and game software systems:

[Paper design]
Get the underlying rule system worked out, with sample ships sketched out to see how they'd play out. Coincides with setting up a project site, with forum for designer discussion of game rule trade-offs and design.
Game core
Whatever can be made core, that is. Common libraries, etc.
Sim software
Probably some existing open-source projects to pull in/build on? Given XML ship files, can fly those ships around and test game balance. This phase can also generate some default subsystems and ships. Lots of client/server network issues, etc. Bulk of system is here!
Component and Ship Building interface
So users can start building/customizing the ships they want. Needs to include servers to archive components and ships, and a search system. Components would have a stat brief of attributes, name, author attribution, user comments, rating.
Interface and customization
Cockpits could be skinned (in-game: assume standardized connectors, and pilots can bring their own customized control decks and plug in). So users can share cool cockpit skins (though ship designer may also specify a default cockpit layout). May also control propulsion systems through scripts--to allow banking and automatic aerobatic moves ("Crazy Ivan", barrel roll, etc), through hotkeys. Other system configuration scripts.

At this point, we have a very customizable space flight sim system. Users can set up their own servers, and possibly specify certain game rule options (collisions, allowed systems, etc.) for their universe. But this is just the beginning...

Social Support

People tend to form clans/guilds in online settings. The space MMO should support this. Starting with mercenary teams, people might create armies (with standardized ships and decals) and alien races.

Users should have a pilot record, including campaign history and stats (kills, hit accuracy, deaths, etc). Might have a graphic and generated webpage ("pilot MySpace" sort of thing). Pilot death needs to be handled. Might assume cloning: pilot body is recloned and implanted with memories up to last mission (when died), so gets no stats for that mission. This process should be costly in some way--probably in coin. [So what happens when characters are broke? Permanent death? So always sock some away for pilot death? The motivation should be that pilots are much more demanding of proper shields, and lifesupport and ejection systems (which could be scripted to automatically eject on certain conditions).]

Most important, team play needs to be supported. At most basic, need a VoIP system (though may have chat backup). This might simply be an external system, such as Team Speak. This alone would add a great dimension to the game!

There should also be support for ships with more than one pilot--ie, co-pilots. Co-pilots might just handle sensors and watch for fighters through different views, or they may even man rear turret guns, reconfigure onboard systems, etc. But this means at least two views and partial control from the same ship by two clients.

Strategy

The next level is to add objectives and strategy.

Universe Objects

Though some of this might appear in the initial system, the game should include planets, stars, asteroids, other odd or interesting interstellar phenomenon (black holes [following similar rules as tractor beams?], ion storms that mess with sensors, etc.). These make combat more interesting. But by this phase of game development, we can begin to add resource management. Mining and settling can add further resources for teams to dominate and defend and to provide their funding.

Command Overview

It should be possible to have an "god's eye view" (ala Ender's Game) of the battlefield (though this should be constructed from ship sensors and deployed sensor relays--meaning taking out or jamming sensors would be of prime strategic importance). This would allow a commander to coordinate a team's attacks. Much of this would be socially determined, external to the game--team structure, special attack groups, any wingman relationships. But the game would support such coordination. (Just having the team talk goes a long way, but might want different channels, as well as ability to mark different objects on the sensor screens as objectives or friends, etc.)

AI

The ship control API needs to be made public, with support for plugins in any other programming language. Users can then contribute AIs--whether for roving mines, probes, missiles, "copilots", independent fighters, collaborative starfighter teams, etc. There's a lot of work out there for interesting game AIs, such as RoboCup. If they could work in their favorite language through a well-documented API, could garner a lot of interest for this sort of thing. May also include a basic in-game programming user interface to build simple scripts.

With a selection of AI systems (archived and searched in much the same way as any other components), would be possible to command whole droid armies from command view. Could have a mix of droid and human fighters. Could setup a game AI in control of an army and humans can team up to fight them in combat.

Roleplay

By this point, we'd have a very cool star fighter sim! We could call it done at this point. But here are some interesting ideas of ways to include players with other interests in the system.

First Person Shooter

It may be interesting to co-opt existing FPS software to stage land assault battles and board enemy aircraft. However, this would largely be interesting only if there is a strong objective-based scenario behind it. (Could also use pre-played FPS games--time taken, etc--in space sim portion of game.)

Increase Roleplay Option

Pilots could be expanded to include other kinds of characters--pirates, miners, politicians, etc. A game of Diplomacy could be staged at higher levels, providing planetary objectives for existing mercenary teams. Those players interested in higher levels--races and planetary system creation--would create realms in which space sim could take place. This higher level strategy could direct the need and objectives for particular skirmishes.

Vendors

Commercial interests are listed here, but they should be involved as soon as possible. Much like Red Hat and other OSS vendors, they could provide:

Vendors could bring in a lot of casual players, building critical mass and polish for the system. These users, once in the system, would be able to add content through the user-interfaces for ship and component design. Eventually, they might want to hack around on the underlying game system.

Conclusion

Similar Existing Projects

Allegiance

Overview from Wikipedia. Originally a Microsoft research project, the source has now been released and taken up by the gaming community. Contains about 80% of what I've described above, and it's already up and running. It doesn't have the same core that allows user-designed ships, but it's an existing system we can play today. Steep learning curve though.


SD Emporium : Space MMO
www.snarkdreams.com/personal/
Last Edited: 04 Apr 2007
©2007 by Z. Tomaszewski