“Random Enough” - Hacking Past Your Problems When Prototyping

Posted on November 21, 2013 - category: tech-art

In this blog post I’ll talk a bit about prototyping games or apps and moving quickly when stuck in a tricky programming problem.

I’m currently prototyping a circular puzzle game. Part of the game is about matching colors to their neighbors. I wanted a way to start the level by randomizing the blocks while having no neighboring tiles that were the same color.

However, I didn’t want to spend the time to figure out if there was an existing algorithm to do this. I wanted to keep coding and figuring out more important mechanics to the game, so I just made a quick while loop that would keep randomly shuffling until it found something.

The loop took a long time to run… Sometimes several seconds or more.

I realized that the while loop was sometimes going through hundreds or thousands of iterations. Now, I didn’t know how to visualize how complex of a problem I was trying to solve. It could have been simple or it could have been vastly complex. My goal wasn’t to visualize this problem. Instead of getting distracted on a problem whose complexity I didn’t know how to guage, I decided to cobble together a quick hack.

So instead, I wrote a Lua script that ran iterations of the while loop until it found some. Then, whenever it found a true result, I simply stored those combinations in a table. I ended up only finding 13 combinations. Then when I run the game, it just chooses one out of the table randomly. (Each number represents a color.)

shuffleTiles = {
{4, 1, 4, 1, 3, 2, 1, 3, 2, 3, 4, 2},
{2, 1, 4, 1, 4, 2, 3, 2, 3, 1, 4, 3}, 
{4, 3, 4, 3, 2, 1, 3, 2, 4, 1, 2, 1}, 
{4, 1, 3, 2, 3, 1, 2, 4, 3, 4, 1, 2},
{3, 2, 1, 4, 1, 2, 3, 4, 2, 3, 4, 1},
{2, 4, 3, 4, 2, 1, 4, 1, 3, 2, 3, 1},
{4, 2, 3, 4, 2, 1, 3, 4, 2, 1, 3, 1},
{3, 4, 1, 3, 1, 4, 2, 3, 2, 1, 4, 2},
{3, 1, 4, 3, 2, 4, 3, 4, 1, 2, 3, 2},
{4, 1, 2, 3, 1, 2, 3, 4, 1, 2, 4, 3},
{4, 1, 2, 4, 3, 1, 2, 3, 4, 3, 2, 1},
{4, 3, 1, 2, 3, 1, 3, 2, 4, 2, 4, 1},
{1, 2, 4, 3, 1, 2, 3, 4, 1, 2, 3, 4}
}

Since I can also rotate the board, this results in 12 x 13 = 156 starting configurations. This is much faster than running a slow algorithm at run-time (which would last for an unpredictable amount of time) and gets me back to coding the important bits. 156 combinations is enough for me to test the game on.

I call this “random enough”.

Later on, as development continues, I can come back to solving a fast algorithm or researching if there is an existing sorting algorithm that would suit me. But if it is good enough, then I might not even need to. At this stage, my most important goal is to find a fun set of rules that results in a fun game.

This is one of the principles in “How to Prototype a Game in Under 7 Days”. “Nobody knows how you made it, and nobody cares.”

The board-sorting is an important detail, but how it is sorted is a trivial one and it could potentially have cost me days of tinkering and research. It is fun to solve problems, and easy to get distracted in ways like this. When prototyping something new, my goal is to continue moving as fast as possible. You don’t want to get stuck on one little problem when you have a whole bunch more work to do.

There are two lessons here:

1. If you have heavy calculations to make that result in a relatively small output, it may be better to front-load the calculations and store it as data.
2. Don’t get stuck on side problems. Focus on the core problems. (Which for me is finding a fun game mechanic and designing the interactions.)

Comments (closed)

Abhijit: We are all guilty of falling into such traps while designing products. I agree, Random Enough is Sufficient Enough in the initial design phase.