Complexity

Originally Posted by AaronH:
The main issue though, is in developing a system that is easy enough to use, that anyone can get into it, but complex enough to allow for long term viability and engagement for multiple people.

This is such a great point that it deserves amplification.

In particular, I'd like to offer a suggestion to any developer thinking of going down this design path: it's important to start with a deep system in the design phase and simplify in the implementation phase -- and not the other way around.

Launching with a simple system and then adding depth later seems like a reasonable idea. It increases your chances of getting that feature in the game, for one thing. It also makes sense from a systems design perspective -- build something simple, then add to it. But it's important to note that there are some practical, real-world difficulties in this simple-to-complex path.

The most painful is that every developer always has the best intentions of coming back to some nice, simple (working) system later to significantly improve it... and it never happens. Something always comes up that's more important. If it's working (any software development lead will tell you), the customer will insist that you leave it the heck alone and concentrate on something else. If it ever gets touched again, it'll only be to rip it out and replace it with something else.

But let's say you do get the post-launch approval to enhance a simple system to make it deeper. Now you have the problem that other game systems have had time to expect that your simple system will always look exactly the way it does. When you change your simple system, you discover that it breaks eight other things. Eight other more important things. Your lead is unlikely to be happy about having to explain to her boss that this little change will actually take three times longer to complete than you previously estimated.

And then there are the players. Oh, my. Sure, the folks who always wanted a deeper system will be happy, but what about the other players -- the ones who used that system because it was simple? Even if you go that extra mile and create a deep system with a still-simple interface, there will be players who will insist that you've "nerfed" something they loved like their own firstborn child.

So going from simple in design to complex after the game launches has some problems. What about the alternative?

My suggested approach for building a system that's both deep and focused goes a little something like this:

1. Have an idea for a system with a few interesting capabilities that can interact in multiple ways.
2. Brainstorm lots of design features that explore the core capabilities.
3. Reduce the design down a simple version that highlights the most crucial elements.
4. Build a prototype from the design.
5. Extend the system to expose its gameplay depth -- see what works, what doesn't.
6. Remove the parts that aren't fun, emphasize the parts that remain.
7. Rationalize the system with the other game systems so that it's consistent with them and improves them, too.
8. Abstract an interface to the system that's simple for those who want simple but which doesn't degrade gameplay for those who enjoy depth.

And then, and only then, launch the game.

This approach does a couple of important things. First, it recognizes the systems design principle that complex systems designed from scratch almost never work right -- you have to start with simple pieces that work and put them together carefully. And it has to happen before the game launches. After any system is released to production, it gains constituencies that don't want it to change (as noted above). This makes change nearly impossible.

Second, it follows the observation about elegant design enunciated by Antoine de Saint-Exupéry (author of The Little Prince): "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." Start simple, then bring out the details, then burn off everything that doesn't contribute to making the game more fun overall.

So to come back (finally!) to Star Trek Online: if the goal is to create a system with some depth of gameplay, don't try to launch with it in a simple form; you'll never realize your vision of a deep system. Instead, design it simple but deep to start with. If you want to change it later, that'll be more acceptable to users who already see it as a deep system.