Thursday, December 8, 2011

How to beat Pixelated

Here's a game I thought was neat. It's called Pixelated, for blackberry.
src: http://www.blackberryinsight.com/wp-content/uploads/2010/05/pixel.png

The concept is simple: Given a randomly generated grid of 6 colours, you are assigned ownership of the top left square and can claim adjacent colour-uniform regions by changing the colour of your region to match.

I thought I'd try thinking of some algorithms to beat it. This is a free form AI design challenge for myself, I don't intend to implement these algorithms any time soon.

#1: Naive strategy: Select next colour to be the colour which my region is adjacent to the greatest number of pixels of, counting the # of pixels in each neighbouring region

#2: (relatively) Intelligent strategy: Select next colour which maximizes E, where:
E(c) == sum(g(x,y)) for all pixels "(x,y)" which are members of the new region which would result from selecting colour "c"

Wonders how/why I came up with these particular strategies? I played a few rounds of the game and the strategies are the ones I noticed myself doing. As usual, engineers imitate nature because nature has a lot going for it.

Terminology:
Region: A group of pixels which touch each other and share a colour
My Region: The region which includes the top left pixel. I can change the colour of My Region once each turn.

To test these algorithms I would implement the game, an interface to it, and then I would run both AIs through a batch of randomly generated boards to see which one did better. If one of them achieved a satisfactory result (the free version of Pixelated requires you to beat the game in 23 moves or less, on a 9x16 pixel game board) then I would be complete. If I wasn't satisfied with the performance of either, I would tweak the rules of the existing strategies or come up with new ones.

This is the same approach used to solve computer vision problems, and engineering design problems in general.

  1. Identify problem parameters
  2. Dream up a few solution algorithms, with help from existing literature and my imagination as appropriate
  3. Run my algorithms through a simulation and measure their results in a clear numerical way
  4. Decide that one algorithm is acceptable, or come up with new algorithms. 
Isn't that neat?