HobbyGameDev - Formerly GameDevLessons.com

A musician is more likely to dream up new songs by strumming on the guitar than by writing notes on the page. A chef is more likely to invent a new recipe by trying a bold variation on an otherwise known formula – while actively preparing the invented dish, not while sitting in the park with a pen and a notepad. A painter, no doubt, benefits by investing some mental energy in deciding on subject or approach, but I think that the genius of Mona Lisa happened while standing at the canvas with paint.

I’m guessing at the above, since I’m not a musician, chef, or painter. However I can say for certain that as a videogame developer, I think by strumming on my guitar, trying different spices in the kitchen, and mixing on the canvas.

When we’re halfway into developing a game, we think differently about it than we do when we’re just getting started or nearly done. The same is true at 25% through, or 75% through (which often turns out to actually be only 25% through). While building something, we’re always at an intersection of “How do I address this immediate challenge?” and “How can I keep this on track to hone in on a coherent, complete result?” Yet before initiating building, the tendency is to think in vague, incoherent, daydreaming ways about the project without either of those helpful grounding questions in mind, because there’s nothing tangible yet to pivot on.

Of course, it’s valuable to foresee and steer away from potential dead-ends, to have some clear initial direction in mind, and to have a sense for how long a given project might take. I’m not anti-planning. I only mean to suggest treating any such plan as highly tentative – as little more than evidence to yourself and others on the team that there is at least one path that can lead to coherent completion.

The natural objection to building too soon is a fear that doing so sets too much in stone. That objection assumes the historical approach required of massive physical projects like ships and skyscrapers: extensive planning, followed by huge costs of building. Since the cost of building (and more so, the cost of undoing) is significantly lower in software than in battleships or buildings, I’m suggesting that development is part of the planning process, and seamlessly carries into the production process. Build to clear up uncertainty in the planning, to narrow down frayed possibilities, to work out a plan based in the reality of gameplay with situated proof that A works well and B doesn’t hold together.

If a feature isn’t working out, ditch it. If a level is bad no matter how it’s reworked, lose it. If something was originally planned but what’s currently working seems to work just great without that something, consider forgetting that something and the extra complication it would invite – though if you have the time, build it, and rip it back out if it’s not an improvement.

When the built gameplay gets pulled back out, it isn’t a loss. It was exchanged for new information that could not be obtained any other way. It was a sacrifice made in exchange for conviction that the better course is to go without that surrendered part.

When, while actively developing, it becomes clear that there’s a much better destination en route or accessible by a short detour, remember that the goal isn’t to reach the originally planned destination, but to make something worth making. If the original goal’s role turned out to be getting you close enough to spot that alternative outcome and achieve it, go for it.

It’s ok to make a few not-as-great games, especially if it means that you feel comfortable taking a few chances, trying out a range of new ideas, and working with a variety of different people or influences. However you can give each project its best chances of succeeding by being bold about cutting out the not-as-great features and the not-as-great content, but the flexibility to do that kind of cutting only comes from building to test ideas along the way, beginning with making plans.

Building isn’t just for final decisions, it’s also for arriving at better decisions. Don’t just build to keep what’s built; build to think, and build to answer questions.

Permalink: http://www.hobbygamedev.com/int/think-by-building-build-to-answer-questions/

Posted in:

Intermediate, Vol. 27

Tagged with:

Programming