AutoHotkey Community

[Dewi Morgan]

First script, because hello world is passé.

The company "Pop cap games" have a popular Flash game called "Bejewelled".

It's simple: a grid of coloured pieces. Each move, you swap two adjacent pieces to form a line of three or more of the same colour. The line disappears, tetris style, the pieces shift downwards, and the empty grid spaces are filled from the top.

I wanted to try out different strategies in a controlled environment, to see which was best. I decided to make something that would play Pop Cap's Bejewelled or any of the mass of similar clones that have come out, and record scores for different strategies.

The graphics in the latest version, Bejewelled 2 Deluxe 1.0 are significantly "improved" from the earlier version, in ways that I suspected would prevent ImageSearch (animated pieces, with flashy sparkles on) or PixelSearch (pieces are different shapes, have arbitrary photographic backgrounds which could contain any colour). But that version of the game has a really handy-for-testing-strategies "play forever" mode.

So I pick a pixel within each piece, and use the r/g/b proportions to try to guess what colour it's meant to be.

So far, I think I'm successful. It plays on three different versions of the game, though obviously once they use colours it can't differentiate (cream and white), it fails.

The version below is configured for, and the colour guessing function is optimised for, the locally-installed demo version of Bejewelled 2 Deluxe 1.0, though it will with tweaking work with others too.

Now I have to get some RL work done, but if I can be bothered, next I'll: 1) Make it prompt for grid size,
2) Ask for mouseclicks on the top left and bottom right of the grid
3) Ask for mouseclick on a piece in the centre of the board to get the sample pixel position within the gridsquares.
4) Grab the window title from the active window after those clicks
5) Grab the score after a fixed time (probably as an image).

For the moment, I've run it through a large number of moves using two algorithms: bottommost valid move, and topmost valid move. It doesn't rank moves by potential gain at all, and does no planning ahead (for that, I'll throw the board layout at a language that I'm more comfortable in). But already, a pattern is emerging.

Going for the lowest move on the board gives the highest average per-move score, so would be good for timed games.

Going for the highest move on the board gives lower per-move scores, but gives longer games, and hence higher overall scores, since you're less likely to run out of valid moves. Good for versions of the game where running out of moves ends the game.

This strategy difference seems to be the case on every version of the game, though the smaller the board, the less the difference is.

I'd really be interested in whether people can think of a better way of differentiating between different pieces. At the moment, it sometimes has a hard time differentiating between cyan/blue (so I removed cyan, since there were no cyan pieces), and red/orange/yellow.

Mostly, though, it's the white sparkles that cause problems: it thinks they are white pieces. I guess one option there would be to retest "white" pieces at a couple of other points, just in case.

I'd also be interested in any other feedback whatsoever, from code style to optimisation suggestions to telling me to STFU. I'm new to this language, and anything you can say will be muchly appreciated.

[Chris]

Even if someone doesn't use it for this particular game, your script is sophisticated enough to be a great example of screen-searching in its own right. Thanks for posting it.

[eef]

Nice idea, Autoplay!

I really like bejeweled and play it quite often.
As I see this has been posted some time ago.
Nonetheless heres my proposal for a solution of
your "color guessing problem":

The idea is to take average color of a given gem.
In the following pseudocode x=0,y=0 is the upper left
coordinate of the gem. dx/dy its size.

[Guest]

Very good point.

Have to average the r, g, and b separately, though. Otherwise, the "average" of 0x030000 ("black, negligible red") and 0x0000ff ("100% blue") is 0x01807f ("50% cyan") - clearly not a sensible average colour: the green value isn't in either of the initial two colours.

Averaging the bytes individually, it's 0x01007f (50% blue, negligible red), which is a more sensible average.

Another thing to take into account is that sparkles and other graphical wossnames will generally be greater than one pixel in size, so you can save processing time (or use the same processing time to scan a larger area) by skipping pixels.

Since stuff tends to be in straight lines, my guess at the best pixel-pattern would be the tightest one in which no pixels are in a straight line for eachother.

For example in an 8x8 array, you could scan only 8 pixels and get a pretty good guess, if you selected them carefully: http://en.wikipedia.org/wiki/Eight_queens_puzzle

o o o X o o o o
o o o o o o X o
o o X o o o o o
o o o o o o o X
o X o o o o o o
o o o o X o o o
X o o o o o o o
o o o o o X o o

This might be moot, though: my gut feeling is that pixel-checking is "expensive", and needs to be minimised, but perhaps it's really fast.

For an 8x8 board, the number of checks at:
1 pixel/boardsquare = 8x8 = 64
8 pixels/boardsquare = 8x8x8 = 512
8*8(=64) pixels/square = 8x8x64 = 4096

Could then use a fn like (untested):

[Vixay Xavier]

I've adapted the above script for use with Puzzle Quest!
Great Script Btw!!

Now I am just hunting for a good algorithm to match 4 of a kind
set priorities and some basic GUI

Try it out, and let me know!

[vixay]

I can't attach the bitmaps here, but basically they are the copped screen cap of the word Victory/Defeat after you play the game.

Wrote this primarily to beat the easy opponents/boring puzzles.