TAG's crown jewel and a bag of technical tricks - Bejeweled 2 is TAG's #1 game and pushes the platform to its limit.

After TAG scored the Bejeweled license from PopCap, it was left to producer/designer Larry Cadelina, artist Aaron Berger, and me to make the game a reality. We agreed from the start that, despite platform limitations, we had to make the translation as faithful to the original as possible. The game had to be bursting with great graphics, sounds, and special effects. Bejeweled's basic gameplay is compelling for most people, but the great visual and aural payoff it gives you what really sets it apart from other match-three games. Most other TAG games were relatively static, so implementing these effects would be a challenge.

As if the bar wasn't high enough, Bejeweled 2 was going to be the first game on the upcoming version 2.0 of the Thunder platform, and it had to be completed in 4 months. This meant that I also had to work closely with the platform team to address bugs and add new features.

So, we had a very short timeframe, a new, unfamiliar, still-in-development platform, and the most complex game yet built for TAG. To make a long story short - we did it! And, we even added an all-new multiplayer mode. The game shot to #1 as soon it as it was released, and has stayed there ever since.

Fig. 1 - Gems Falling (5% of original)

Pre-composited Graphics

One of the most surprising parts of implementation is that, other than the score and level fonts, there is no real-time image compositing. Everything else is composited with its background offline - all of the jewels, explosions, animations - everything. You might think this would lead to a combinatorial explosion, and you'd be right! Fig. 1 shows a particularly hairy animation - gems falling off the board, which you see when you lose the game. There are 7 types of gems composited on top of 10 different backgrounds. The full-size image is a 3840x3456 pixel .PNG, and weighs in at 8.13MB.

At first blush, this seems like a really dumb idea! However, the TAG platform is all about scalability, and CPU is the most valuable resource. Real-time compositing is computationally expensive, and a game that uses it heavily scales poorly. Conversely, using pre-composited images is computationally cheap, but takes up much more memory. However, the TAG platform places game assets such as art and audio into shared memory, and only one copy exists irrespective of the number of sessions. So, by pre-compositing everything, you take a one-time hit in memory, and no per-session hit in CPU. That makes pre-compositing a no-brainer. And, generating the combinations is not difficult - the TAG toolchain has a number of tools designed to do just that.

Fig. 2 - Gems, low quality

Bitrate Conservation

All TAG games are designed to stream as MPEG2 at 1.25Mb/s. Audio takes up 256kb/s, and there's about 100kb/s of overhead, leaving around 900kb/s for video. That's not a lot of bits for a 640x480 display at 30fps! For all of our games, we wanted to keep the video quality high and minimize the number of compression artifacts. This meant that we could not have many things changing on the screen at once. Typically, you could change 50-60 tiles in a single frame before you started to run out of bits, which caused the video stream to drop frames.

Now, Bejeweled's game board contains 64 gems, each of which is 9 tiles. That meant I could only animate a paltry 6 gems per frame! That wasn't going to work, since there are times when most of the gems are moving all at once, like when they drop in at the start of the round.

I got around this problem with a two-fold approach. First, I compressed the gems at both high and low quality levels. I used the high-quality images when the gems were static, and the low-quality ones when they were animating (see fig. 2). At low quality, each gem used many fewer bits, meaning I could move more at once. In addition, I took advantage of MPEG motion vectors to further reduce the bits spent. Using these two techniques, I got a six-fold increase in the number of tiles I could move per frame. And best of all, since the animations were quick, the compression artifacts were not noticeable.

Fig. 3 - Multiple explosions

Special Effects

When it came to special effects, there were cases where pre-encoding every possible combination simply wasn't possible. The power gem explosion was one example of this. When adjacent power gems explode, the resulting fireball effects intersect. Given all the possible gem positions and colors, it was simply impossible to pre-generate all of the combinations. So, we changed the effect!

As Fig. 3 shows, when two adjacent power gems explode, you get one full explosion and several smaller ones on the perimeter. This greatly reduced the number of combinations, and we still had a really cool effect. We employed similar techniques to other effects, such as the hypercube lighting, which used several one-tile bolts and a pathfinding algorithim to produce a satisfying electric effect.