Photographer’s Algorithm

Dec 5, 2012

This is just a new term I’m applying to a basic design strategy that I’ve mentioned and explained on HobbyGameDev several times before. I usually refer to this idea as overproduction.

Lately I’ve taken to instead thinking of it as the “Photographer’s Algorithm,” which I think gets the idea across more effectively.

Professional photographers, even with the best training, the best equipment, and ample experience, still take many, many more photographs than they wind up keeping. There are too many factors, variables, considerations, and subtleties to simply go someplace, take the “right” photo, then call it a day. They instead take a ton of potentially right photos, then compare them against one another to pick the best to keep.

Likewise, no matter how experienced you are, no matter how good your tools are, and no matter how clear of an idea you have for what you’re doing, in matters of design there are usually countless factors involved, and counting on getting something done the best possible way on the first attempt is unrealistic. It’s not good design to rely on luck as the mechanism for identifying a solid initial effort to iterate further upon. Try minor and major variations, but also try some designs that are completely different, built from wildly different strategies or initial assumptions from the ground up – whether we’re talking about levels, weapon tuning, game economy, AI scripting, or otherwise.

People with traditional design backgrounds probably take for granted that this process happens in all design. Designers doing product design, package design, t-shirt design, and so on are used to quickly trying out dozens of different ideas and tossing most of them out.

However most gameplay designers don’t have a traditional design background. Because much our work, even at a prototyping level, often involves a sizable time investment, people get lazy about it and start to act like there’s only time to do one, instead of making several to keep one. If less time is wasted being overly careful about which direction is tried, and that time is invested instead in just creating multiple different options that are far enough along to be meaningfully assessed, there’s a lot less guesswork involved. It takes some of the luck out of it.

Make several variations. Keep then clean up the best. Throw away the rest.

That was my process for Boom Blox levels, Shotgun Debugger levels, Vision by Proxy: Second Edition levels, Vectorverse levels, and more.

Don’t make just enough and then find yourself stuck with the worst of it. A good tool isn’t only suited to rapid iteration, but also to rapid exploration, to figure out through experimentation what’s worth further iteration.

No matter how good you are at what you’re doing, the best 40% of your work is better than the other 60%. Working with that plan in mind to edit aggressively can free you up considerably to take chances that you might not take if you always create with a sense that you’ll be stuck with whatever idea or direction is first attempted.

As Fried and Hansson say in Rework, “Be a curator… What makes a museum great is the stuff that isn’t on the walls; what makes a museum great is there’s someone saying ‘No’ to things.”

Curate like a photographer.

Several of my iOS apps were designed as highly polished versions of carefully selected projects out of my 219 daily experimental gameplay projects. Think about that for a minute: I spent seven months having virtually no social life in order to make that happen, then I filtered out 98.6% of it. But of those three small apps, one led to my series winding up on JayIsGames, one was a finalist showcased at IndieCade 2010, and the other paid my rent for a year and a half.

There are actually similar stories for other developers that led to the more commercially well-known games Crayon Physics (from a series of 1-month game prototypes) and World of Goo (from a series of 1-week game prototypes).

If you’re having trouble deciding what to throw away: come up with some simple weighted criteria (these can be subjective values – “understandability,” “aesthetic appeal,” “fairness,” “spectacle” – weighted to give some criteria more emphasis than the others), score each attempt you’ve made from 0.0-1.0 in each column, find the weighted sum to rank those scores, then throw away the bottom X% of your attempts, where the greater you can make X and still get away with it, the better. It’s a handy way to make a rational decision when your gut is telling you that you want to keep all of them for different reasons.

But use the Photographer’s Algorithm, and you’ll consistently wind up with something much better than you could have accomplished nearly any other way. It allows direct comparison, in-engine, in-play, between potential results in a way that’s otherwise simply impossible to do, since The Brain is Not an Emulator.

* Note of clarification: though it sounds similar, the Photographer’s Algorithm has nothing to do with the Painter’s Algorithm. (The Painter’s Algorithm is a basic concept used in 3D computer graphics to draw things beginning in back of the scene then moving to the front, to properly handle overlap.)

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2018 Chris DeLeon.

Site production by Ryan Burrell.