One of the things that I've run into when designing games is a tendency to start things too soon. I started work on the skill system for Horizon Station before I did just about anything else - that was too soon. I developed a detailed economy model - but I did it too soon.
What I should have done when I first landed this gig was recite the Boy Scout motto to myself a few hundred times so that I wouldn't make these kind of foolish errors. Be prepared. As a game designer, always, always be prepared.
Which is not at all the same as believing that you are prepared. I was almost positive that I was ready to start real hardcore design on Horizon Station, but I was wrong. There were large elements of the game that I didn't understand, and so, I was decidedly unprepared.
How do you avoid the mistakes that I made? I can't give you a cut-and-dry answer, but I can tell you what I would have done differently.
First off, you need to have a really clear idea of what you want your game to look like when it goes out the door. Don't revel in your grand plan, or wax poetic about the intricacies of your skill system - pick the core activities that you want in your game on its go-live date.
When you have a firm grasp on the types of things that you want your players to do, then take a look at your development tools and decide what it is that you can reasonably accomplish with what you have at hand. A mistake that I made was sketching out systems that were far too ambitious for the tools that were available to me, a mistake I compounded by forging ahead with design documents for those same systems. It cost me time, and a lot of aggravation, when I realized that what I had written just wasn't possible at this stage.
Once you know what you want to do, and what tools you'll be using to do it, then, and only then, should you start in on your design. And at this stage, design is a very broad thing, involving a lot of brainstorming and note taking. Once you've built up a massive store of ideas, start going through them and plucking out the ones that you are definitely going to use. Ideas that are iffy, either conceptually or technically, leave it on the pile. You'll probably be able to come back for it later, but obsessing about it now will only delay the implementation of things you know you can do.
With a strong list of the kinds of activities that will make up the meat of your game, and a good idea of how you will bring those activities to life, it's time to start looking at the real heart of the game: the environment.
I made another critical error in my work on Horizon Station, in that I did not start really getting down to the brass tacks of the environmental design until late in the process. Which meant that the environment was being shoe-horned to fit a skill system, and the wheels fell off in a big hurry. Had I started with the environmental design, I would have seen right away where I was going wrong with my skill system. Let this be a lesson to future developers out there - do it right the first time, or you'll spend a lot of time doing it right the second time.
With your environmental concepts firmly in place along with your activity ideas, take some time off and step back. Move away from your development area, and start putting things down on paper. If you don't, you're going to find yourself drifting further and further away from your goals. Design plans are critical to keeping your development on track and moving forward - be prepared.
When the real nuts-and-bolts design work begins, you want to be able to point to your design document to answer any questions. "What was I thinking when I added this property to this widget?" Look in the design document. "Why did I include a forced regurgitation skill?" Look in the design document. In other words, before you start hacking out code and writing room descriptions - be prepared.
Speaking of which, it looks like it's time for me to head back to my Great Database of All Things Horizonish. Catch you all in 7.
