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...)
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.
The basics of the game is a star fighter space simulation, so we should start here.
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.
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:
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?]
So we need the following design phases and game software systems:
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...
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.
The next level is to add objectives and strategy.
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.
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.)
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.
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.
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.)
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.
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.
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 |