Disclaimer: I am not an investment advisor. When I describe my own trading activities, it is not intended as advice or solicitation of any kind.

26 October 2010

Arms Race, Part 2

In Part 1, I explained my motives for writing software to play Bejeweled Blitz.  In Part 2, I define some terminology and lay some groundwork for the first step of actual programming.  I assume that readers of this blog have played Bejeweled Blitz before; if not, go to Facebook and waste some time.  When you're done "researching", come on back and read the rest of this post.  Since it's a visual game, I'll need to define some terminology so when I describe a gem type we'll all know what I'm talking about.

The board of Bejeweled Blitz is the entire Flash application, including the non-game screens and the artwork behind and around the actual playing area, which I call the grid.  The grid holds all the gems and other playing pieces in an 8x8 array of cells.  The top-left corner cell's top-left corner is the grid origin.  The X values of cells and pixels increase as we travel to the right, and the Y values of cells and pixels increase as we travel down.  The top-left cell is (0,0), and the bottom-right is (7,7).

Gems can be any of the following colors: Blue, Green, Orange, Purple, Red, White, or Yellow.  The majority of gems are in a normal state, but they can also be explosive (aka flaming), crosshairs, or multipliers.  There is also a non-gem piece called a hypercube (PopCap's term).  These are nearly impossible for my software to identify in a moving board, so I gave up on them and let them be.  Yellow gems can also be in coin form; they still work as yellow gems, but add 100 coins that can be used for boosts between games.  Coins collected during the game count the same as coins left on the board at the end, so in practice yellow gems and yellow coins are equivalent.

Normal
Flaming
Coin
Crosshair
Multiplier
Hypercube

Points are generated by removing the gems from the board, which is done by forming paths of matching gems by swapping two adjacent gems.  Paths can be 3, 4, or 5 gems long.  Depending on the shape and length of the path, flames, crosshairs, or hypercubes can be created from the path.  Since gems fall into the empty spaces left by paths after gem removal, it is possible to get a combo bonus when falling gems fill the holes of a new path.  Multipliers are generated when enough gems are removed in a single move; I think that number is 10-12, but I'm not sure.  There is also a no-multiplier time limit after one is generated, which my software doesn't account for.

Normal gems, coins, and multipliers remove only themselves when matched in a path.  Flames remove a 3x3 square with themselves in the center.  Crosshairs remove the entire row and column upon which they reside.  Hypercubes do not get used in a path: instead, they remove all gems of the same color as whatever gem they are swapped with.

The user must continually look for opportunities to create paths by swapping adjacent gems.  I refer to gems that form a path as path members.  Since only two gems can be swapped per move, we can define the trigger gem as the one which is out of place.  We can likewise define the target gem as the non-matching gem in the trigger's way.  Swapping trigger and target forms the path, removing the gems and activating any special properties in that path.

Speed is of the essence, as mentioned before.  If paths are formed fast enough, a speed bonus is built up; if this is maintained long enough, the game switches into Blazing Speed mode for a few seconds (10, maybe?).  In this mode, all normal trigger gems and coins are treated like explosive flames.  Note that not all members of the path explode - just the one involved directly in the swapping operation.  Thus combos do not get more explosive than normal, either.

A general outline of a working program to play Bejeweled, then, might look like this:
  1. Locate the origin of the grid on the screen
  2. Detect all the gem colors and properties
  3. Build potential paths with triggers and targets
  4. Choose the optimum path and swap its trigger and target gems
  5. Loop back to 2 until the game is over
I felt that the hardest part of the program was detecting the gem colors and properties, so I tackled that first.

Stay tuned for Part 3: Gem Color Detection

No comments:

Post a Comment