Open Development

Open Development is a practice where, in game design, many builds are presented to the end-user throughout the design stage (well before beta or even alpha stages), and typically a forum or blog feedback system is in place for discussion and inclusion of the public. The idea is to get feedback very early — well before things get sent down the production river, and to ensure you’re making a product that resonates with your audience.

Studios like Data Realms (Cortex Command) and Wolfire (Overgrowth) are famous for this development style. I also used this method for the development of Space Squid.

The major advantages of Open Development are Marketing (you can build a following early), User Testing, and early direct-feedback to guide your design. For me, open development helped gave me confidence that what I was making was indeed worthy of this Earth.

The biggest disadvantage (for me anyway) was simply time. Blogging every day about changes to Space Squid was a chore that took up more effort than I’d like to spend. There’s also the danger that your development gets sent down the wrong path; after all, the public isn’t very good at Game Design. Larger studios say that secrecy is a necessity, though I’m not sure why. Something to do with marketing and advertising budgets? Legal concerns with who gets credit maybe?

Open Development also puts a bit of pressure on you to keep the project in a playable state. For Space Squid, I was trying to have a playable build every day — which means no half-finished code, no “I’ll finish this up tomorrow.” This lead me to cut some corners I probably shouldn’t have.

Closed Development

Closed Development is what people probably think of as the status-quo. The public is rarely aware the product even exists until marketing begins, and public input is not sought. Developers are free to design the game as they see fit, and will sometimes do closed-testing (paid user feedback testing, closed alphas/betas, etc.) if the are smart.

Every single big-name studio I can think of utilizes this method of development, and some independent developers will end up making their projects this way just because they don’t want to spend their time blogging. I used this development method for Steambirds.

The disadvantages to closed development is the lack of constant, unbiased, public input. A lot of time the user testing is done internally (giving biased results), and a paid Game Designer is simply trusted to know what he’s doing (and if he doesn’t do well, it is assumed he doesn’t get as much work in the future). You also miss out on the long-term marketing strategy (building up a fan base, making people feel included in the game development cycle, etc).

A huge advantage, though, is being able to keep your head down and just getting it done. No worrying about every-day release schedules, being able to have code checked out for weeks on end, no having to itemize and publicize every single thing you do. And if you (and your game-design friends) are absolutely convinced the gameplay is perfect as-is; why bother bringing the public in on it?

Except, of course, the danger that you’re wrong? :)

What’s Better?

Neither! As usual, things aren’t black-and-white. I don’t have marketing budgets or legal issues to worry about, but I’m also too damned lazy to blog every single day. I value the input and feedback of the public, but the public often doesn’t understand what I’m trying to do, and can’t see past a few visual glitches to the gameplay underneath.

While developing Protonaut I posted once a week instead of once a day. I often pooled major new ideas into a big release that I could then do the equivalent of alpha-tests on. I spent a long time with the game in a not-working state, but I also kept it to myself and let the fans play with the last stable build. It wasn’t quite perfect, but it was a better shade of grey.

Designing to your Strengths

Everyone has their own preferences and their own styles. I know I’m a people-person; I like to post blogs and I like hearing feedback (and can take criticism) from the public. I also know I have a particular weakness for trying to incorporate everything the public suggests; every idea is an excellent one, and the scope or original vision is quickly lost if I don’t keep myself in check.

I’m still working on finding a balance. Protonaut was still too open for my tastes and SteamBirds was way too quiet. At least I know where I’ve been, and the direction I want to go. All I can ask of the other developers out there is to actually try both extremes before making a decision on where you should go next!