Decision Making – Don’t Be the Donkey

Sep 24, 2009

Meet the Donkey

“If you aren’t sure which way to do something, do it both ways and see which works better.”

John Carmack

Buridan’s Donkey (traditionally known as “Buridan’s ass“) is a parable from philosophy in which a donkey, standing before two equally appetizing bales of hay, is unable to decide on a reason to eat from one pile rather than the other. Paralyzed by indecision, the donkey then starves to death, next to more than twice as much food as it needs.

Too Many Ideas, Not Enough Action

Lots more people have the skills related to game making – programming, digital artwork, storytelling – than are involved in making games. The problem in many cases isn’t that they lack ideas for videogames, it’s that they have too many ideas for videogames, and aren’t sure how to prune bad ideas from good ones.

Without being able to tell bad ones from good ones, how can someone know which concepts they should start on? Which will be the most effective use of their time?

Like trying to cram too much through a funnel, the path from brain to hands jams up from uncertainty about how to narrow down the possibilities.

How to Tell Bad Ones From Good Ones

I can give you my answer to this question, but doing so wouldn’t be very helpful.

What’s a good idea for me to make is based on what videogames I know best, what ideas I’m passionate about, what types of work my own personal experiences have led me to see the most clearly.

What we want to know is what’s a good idea for you, and there’s only one way to get to that…

How to Tell How to Tell Bad Ones From Good Ones

Making games that turn out poorly is how you learn which ideas are bad ideas for you.

Making games that turn out well is how you learn which ideas were good ideas for you.

There’s really no better way to know. No one else can know for you.

You can’t know in advance until you’ve made some games to get a sense of how you work, what drives you, the way things look to you while you work on them, and how the people that you respect respond to different aspects of your work.

Pick one of your videogame ideas that you can create the fastest and easiest. If you can’t quite tell which among the fastest/easiest ideas is smallest and simplest, just pick one randomly. Why the one that you can create the fastest and easiest? See the old Atari rule of thumb for beginning difficulty.

Then make that game.

Fastest And Easiest – Because First Ideas Come Out Poorly

Almost without exception, whichever idea a person decides to make first will come out poorly anyhow. This is particularly true if someone is making a videogame on their own, as opposed to pairing up with someone that has more experience.

More clearly: almost any first project is extremely likely to be a bad one.

That’s even true if the project had potential to be a good one if taken on after accumulating more experience. Beginning developers just need to get it out of the system. The sooner they can do so, the sooner they can apply the lessons learned in that process to a second game project. Then it’s possible to bury the crummy original work under a pile of newer, better work, like the rest of us have that have been at this for a long enough time.

Seeing people start their dream game as their first game is heartbreaking. It’s a surefire plan to crash and burn. It will never be high enough quality to be satisfied with releasing it, but the inability to finish the first project (and the effect associating game making with ruining a dream project) can be distracting from getting back into videogame making. I’ve seen it happen, to dozens and dozens of college students that were once excited about making videogames.

(That a developer’s first game will be bad, and should just be got out of the way, was point 1 of 3 in an old slide presentation I put together in 2006 for beginning game developers. Check it out for points 2 and 3 and how to deal with these challenges.)


Although Carmack’s background as a legendary programmer means his quote is typically applied to videogame programming, it’s every bit as relevant to art, design, and audio creation. My best work has come from when I created 50% or more levels or features than I intended to keep, then pruned out the weakest 1/3 of what I made. Some exciting ideas just don’t turn out as well in-game, and it’s hard to know in advance. This overproduction model promotes taking chances and risks, trying out ideas that may not work, because there are fallback options available.

Anyone’s best 60% of their work is, obviously, better than the other 40% of their work.

The idea of overproduction is a bit like prototyping, except instead of focusing all your energy on one thing as a proof of concept, you split your energy into trying out a few different directions at once. If you’ll spend your time making 9 levels to their halfway point when you only need 6, sketching 4 variations of an icon when you only need one, or trying out a few variations on core gameplay speed/pacing before settling on one, you’ll take a lot of luck out of the equation. There are things we can’t tell until we try them working on-screen with a controller in real-time, and those are the things that make all the difference in a videogame.

Besides going beyond code into content creation, it also goes beyond content creation into game creation. My best downloadable freeware games could not have been the only six projects that I worked on – they were only possible in the context of the many other downloadable freeware games I’ve developed. My favorite 42 experimental gameplay projects could not have been the only 42 made, to exist I had to spend 7 months making all 219 of them.

One of the patterns from which one-hit wonders emerge in the music industry is when their first major release is packed with 18 of the best songs they’ve ever played, out of dozens, even hundreds. When their next CD comes out, they’re competing against the best material they had accumulated in the years before becoming famous.

Even the best batters don’t hit a grand slam every time, every play Shakespeare wrote wasn’t groundbreaking (some of them are considered downright terrible), and every game a developer makes won’t be his or her best work. But having created it increases the body of ideas, concepts, and code that might go into future projects. Having created it adds to the pile of variety, breadth, and tangible byproduct of experience that a developer can mine looking back to identify best works.


If it’s hard to tell which idea seems better, go for the quicker one. If you can’t tell which is quicker, pick one at random, flipping a coin if you have to. If you have the time, money, passion, and tummy room for it, eat both bales of hay, starting with either one.

Just eat the hay. Don’t starve.

If you’ve been sitting around thinking about making videogames and haven’t done so yet, whether you’ve been keeping up with my free articles or not, whether you think you’ve got time or not, go make the easiest and fastest videogame you can make. Need more help to get started? Check out the other articles for more information and links to more resources. Whatever excuse you might have in mind, another thousand readers are thinking the same thing – if you’ll find a way to get past it and build momentum, you’ll have an immediate upperhand on thousands of other would-be developers.

(Originally posted as Vol. 6 Sec. 4)

Este artículo está disponible en español. Traducción por cortesía de Andrés de Pedro.

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 ©2017 Chris DeLeon.

Site production by Ryan Burrell.