Today’s sexy topic: database access. Woot!

Okay. It gets better, I promise!

By way of groundwork, I’m going to sketch out a massively- multiplayer persistent world game:

Freelancers of Orion: World of Starcraft

• It’s a RTSMMO
• Each player owns a home planet that cannot be captured or destroyed
• Players build fleets of specialized craft to fight for contested planets, asteroids and space stations
• There is a commerce and trading element
• The game is played in 3D space. There is an enforced truce in the Galactic Plane (2D-slice), to allow a safe corridor for commerce.
• The player’s planet (and ability to mobilize fleets) grows more powerful, levels up, as do the player’s “civilization skills,” shipbuilding, mining, trading, combat, etc.
• Planetary fleets can be organized into interplanetary confederations (clans/guilds).
• Heads of federations can play a meta-game of strategy on an abstracted map. Similar in purpose to the Battlefield 2 Commander interface, for the command of multiple fleets

That’s swell! Sounds like a fun game. So what’s the twist?

So, one way to think of an MMO is as a database with a very obfuscated and clumsy interface.

Really, you just want to access the database, and change level=1 to level=60, but the interface for making that simpl change is so complex that it takes most users many months to make that simple change.

(I would also argue that Guitar Hero is a CD player with the world’s worst interface, but that’s for another day.)

The “game” people play when they play an MMO is the client, a database front-end. So why not have several different clients, or let the players write their own?

So here’s the proposal. Give the community an SDK to create their own custom client interfaces.

I know. Flashing Red Lights! Alarm Bells! Danger! Danger!

Sure. Look, I just write these little articles. Odds are, I’ll never have to make this game. Let’s just look at some of the upsides, and then see what can be done to mitigate some of the real dangers.

The Standard Shipping Client (PC): A god’s-eye view of the planet and fleets, a Homeworld-esque selection and movement model.

The PDA Trade Client: Allows players to log on and play the trade-only aspects of the game in the safe Galactic Plane. The game is represented as a 2D “Star Control” style-game.

The POP3 Client: For managing the homeworld, build queues and trade contracts as play-by-mail.

The Flash Web Client: Merchant storefronts for managing in-game stores, with EBay integration.

The Cell-Phone Client: For beefy cellphones, the cell client is a Confederation Leader interface for managing Confederation (guild) communication, and as a portable version of the strategic command interface.

How could this possibly work?

Maybe it won’t, in which case the developer makes some of these clients, and wouldn’t that be a shame?

But if you want to harness the mod community, turn them loose to develop a hundred cool interfaces you never considered, I propose the following approach.

You set up a sandbox server. On the sandbox server, anything goes, and the players can write clients and gizmos to their heart’s content. It’s the wild west, but adventurous players can test and lobby for new clients before the are available to the regular servers.

GMs and QA folks test out and monitor the various clients, and sound out the community for approaches that strike a chord. Promising looking clients are vetted for abuse-potential. When a client seems ready for wide release, it is provided a unique cryptographic key that allows it to interoperate and be monitored on the regular servers. The key can be revoked if the client turns out to be problematic.

All updates to the client happen in th sandbox, and are again vetted prior to wide release.

The the mod community loose, and see what happens. There is certainly prior art at more restricted levels of access, see user scriptability in Second Life.

-game over-

Thanks for reading another action-packed installment of Design a Day. For background on the Design A Day challenge, take a peek here and here.