Think by Building / Build to Answer Questions

Jun 30, 2011

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.



Subscribe by e-mail to receive an update every month of all new HobbyGameDev articles, videos, and game development resources.



7 Comments

  1. tartley says:

    This really strikes chords with me, reminding me of classic essays about software development in general – such as Martin Fowler’s ‘The New Methodology’ (um… http://martinfowler.com/articles/newMethodology.html) which lays out the motivation for Agile by pointing out that the more heavy-weight and beaurocratic methodologies, which tend to try and plan every last detail up-front, are not notable for their success. Instead, Agile encourages us to plan the bare minimum we absolutely need to get started, and then continue to extend and refine that plan as we learn from the parts of the project that are completed. It transforms planning into a ‘just in time’ process. We delay each decision until the latest possible moment, because that is the point at which we will have the most information available.

  2. [...] read an interesting article a little over a week ago, called “”Think by Building / Build to Answer Questions” on hobbygamedev.com.  I believe I understood the crux of the author’s point and agreed [...]

  3. donniemarges says:

    This is honestly something I really struggle with. I’m not very good at prototyping. For example, with this one game I’m working on, I’ll prototype something, but then get hung up on the graphics because they’re just boxes or some free sprite that I’m using as a placeholder. So I refine the graphics but then lose sight of what I was prototyping to begin with.

    I also feel like because I’m spending time on a prototype, that it’s something that I should release for the public to download or to buy or whatever.

    I would be happy to get any feedback on how to remedy this or maybe some tips or something.

    • Chris DeLeon says:

      One option is to separate visual thinking from prototype programming. A method that has worked well for me for many years (at least well enough to finish most things I start) is to draw up a mock-up screenshot first, then program to bring that screenshot to life piece by piece. The placeholder art can be pulled directly from that made up screenshot. This way the placeholder art (a.) matches, unlike free found sprites (b.) has contextual visual meaning according to your intention, unlike boxes (c.) makes all the decisions at once about relative dimensions, which is one of the most intermixed art/programming issues. Until that screenshot is drawn up, trust that the programmer side of you will figure out some way to make it happen. Then switch, and until that screenshot ‘works’ interactively, keep the programmer hat on. This discrete role switching minimizes deadlock that comes up from changing gears too rapidly. (Art, of course, can always be revisited after things work.)

      An alternative strategy, common among programming-centric hobby developers, is to design away the issue by sticking to styles or game types where the artwork is abstract or simple enough to handle programmatically and/or with very minimal art time. This sounds like a cop out, and it kind of is, but done cleverly it can help a game stand apart by showing off a unique and memorable look – or simply by having more refined game mechanics than a content-rich game has the design agility to pull off. In this case, the fidelity of the art is less of a distraction, because you’ll be able to produce final-ish visuals as you go.

      Be sure too that you’re only prototyping something that warrants prototyping, and not just thinking of incomplete thoughts and learning projects as prototypes. The purpose of prototyping is to test something that you aren’t sure about, or to learn something you can’t figure out without playing it, or to communicate a non-verbal idea to others (usually developers). If what you’re trying to do with the gameplay is fairly straightforward and generally understood because it’s part of an established genre or similar to an existing game, just get to work building it.

      More practice and experience with the game development process end-to-end is the real answer, though I realize this answer isn’t particularly helpful in the short term. The best prototyping depends upon your ability to see your prototype in terms of where it’s going, instead of where it’s at. That requires having a clear notion of what issues can safely be dealt with later in the process, and since that answer partly hinges on the types of videogames you make and your own strengths as a developer, only finishing more projects can lead to the ways of thinking that are successful for you.

      > I also feel like because I’m spending time on a prototype, that it’s something that I should release for the public to download or to buy or whatever.

      This is a risky line of thinking for prototyping, and is probably getting in the way of the potential benefits. The carefree freedom to be wrong, to screw up, to make a mess, and to change your mind are the value of working with a prototype. Precisely because no one has to see it, it’s an opportunity to take chances and attempt things that you’re not sure enough about to plan a full project around.

      9/10 of everyone’s innovative ideas are bad. Finding the 1 in 10 that’s worth doing something with means getting the other junk safely out of your system. That safety comes from treating prototypes as disposable and tentative.

      A third hat to remember is the producer’s, to remind your programming and visual sides to at some point just pick a direction that currently seems good enough, then make concrete progress toward a coherent end goal until it’s realized. Any creative work – book, painting, song, film, videogame, whatever – could have been iterated on forever at the earliest stage, but then the world would be without any books, paintings, songs, films, or videogames.

      • donniemarges says:

        Hey Chris!

        Thank you so much for the advice, I really appreciate it!

        I will definitely do the mock up screenshot, that’s a great idea. I come from a corporate programming background and I’m just making the switch to indie game development. Basically, we came up with specs and then got to work building the software, and it was done when it passed testing. Even now, I make my money by developing mobile apps for businesses. I guess my biggest obstacle is being able to think in terms of prototyping and when it comes to game development, get away from the “this has to be a product” frame of mind.

        It’s interesting that you bring up the fidelity of art. I took a graphic design course on my own time to learn the Adobe suite and get a discount on the software. But I find that I get very self-conscious when it comes to art and I don’t know why.

        Anyways, you’ve made some great points and have given some awesome adivce that I will definitely take to heart.

        Thanks again Chris!

  4. […] still thinking by building. It’s just not starting from as established a foundation, accepting a higher chance of […]

  5. […] I’m a huge fan of the idea that you can (and should!) think by building, and build to answer questions. […]

Leave a comment

Comments Form
  • Your email will not be used for any purpose other than to update you in replies to your comments. Your website address will be shown as a link from your name with your comment. Your profile photo is auto-magically provided by Gravatar.

All contents Copyright ©2014 Chris DeLeon, solely to prevent others from copyrighting it.
Permission to reproduce, modify, and distribute this content granted without special request.

Site production by Ryan Burrell.