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… (continued in ebook)

7 Comments

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.

[…] 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 […]

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.

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.

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.

Leave a comment

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.

Name (required)

Email (will not be published) (required)

Website (optional)

Comment

Sign me up for one email each month with links to new HobbyGameDev entries

“Being a complete beginner in the coding world I’ve been looking for a good course for a long time. I can definitely say this one by Chris DeLeon is the best one I found, since it gave me some strong basics by building a retro game. He is a great communicator and a skilled developer, he is able to explain basic concepts in a very simple way including all the details that a beginner could need.”

I've learned more in the past few months working with Chris DeLeon's book and training than I have in the last five years of trying to do it myself. His years of experience with game development and training make him invaluable.