1/16/2002 -- The Making of Candy Cruncher

Puzzle games are an interesting genre. Unlike most hardcore games, they really, really have to focus on fun. There is no technical competition between puzzle games. No one is looking for the next GF3 vertex shader enabled Tetris -- puzzle games are all about the game play, and the graphics just have to be "good enough".

THE PUZZLE GAME MARKET

We were intrigued by the puzzle game market, because if you look at the number of players on-line playing the free Web games at The Zone, Yahoo Games or even The Station @ Sony, it's pretty obvious it's not a small market. And given the huge success of games like Tetris and Lemmings -- and the success of www.realarcade.com where some games get 30K downloads in a week -- it was apparent that the market wasn't exactly small. The problem was that we didn't want to make another Tetris or Mah-jongg clone -- if we were going to do something, we'd like to do something new and original.

THE PLAN

Luckily for us, my wife had an epiphany for a game design that (we'd hoped) hadn't been milked to death. Line up rows and columns by sliding a single empty space around. It matched what we considered the "recipe" for successful puzzle games:

- obvious game mechanics
- emphasize pattern finding and matching
- players enjoy "bringing order out of chaos"
- avoid gimmicks, stick to good core gameplay

If you look at the successful and popular puzzle games today such as Bejeweled, Bounce Out, Collapse, Tetris or even Shanghai/Mahjongg, they all share the above aspects in common. In addition, because we were aiming at the casual gaming audience, we had to set our download size and minimum specs REAL low. Ultimately I decided that the point of diminishing returns was going to be Win95, Pentium/166, 32MB RAM and DirectX 3. The goal for download size was 1.5MB, but we overshot that by about a megabyte. Not earth shattering, but many of our customers are connecting on 28K modems, so the difference between a 1.5MB and a 2.5MB download is significant to them. About 25% of our downloads are aborted, so it would be nice if we could get the download size even smaller.

Once we hashed out the basic details of the game design, the theme needed to be established. My partner, Rosie, came up with the name and "look and feel", and from that point on we were ready to roll. It was my expectation that the game would only take about 2 weeks to write. As it turned out, that was pretty close to the mark -- it took about two weeks for us to get the first set of art assets and code in place, but another two weeks were necessary to finish tweaking, testing and launching.

I don't like games with a limited time component -- it stresses me out so much I can't enjoy myself. So the first working build of Candy Cruncher gave you unlimited time but limted moves. This felt "okay" -- it was relatively sedate, but still engaging. Unfortunately, after playtesting we found some issues with limited moves.

The big problem was that it often made the player feel like a dork. If you start moving the space around, then decide to backtrack, you end up feeling foolish and stupid. That's just not the type of emotion you want to bring out in your players. Another problem was that the "end game" was completely anti-climactic. With only a few moves to go, it was pre-ordained that the player was screwed, so the last few moves evoked feelings of dread mixed with hopelessness. Once again, not what you want to give your players.

The final problem, which was solvable through some hackery, was that it was possible to lock yourself into a corner. In that situation the space is surrounded by "black jellybeans"; without a timer, the game simply can't end, because the player can't move. There were game design hacks that could have fixed it, such as shuffling the board, allowing you to "punch" through the jellybean at a cost of moves, etc. But none of those "felt" right, and they wouldn't have been intuitive to the player.

So we made the decision to go with a time limited game. In retrospect, that was a smart move -- Candy Cruncher became significantly more fun once you could just start moving the space around wherever you wanted. The end game was more hectic and exciting because you felt like you could get "just one more row" if you clicked fast enough. And if you got blocked in, the timer would run out and you'd know not to do that again.

During this tweaking phase we relied heavily on the input from friends and family, both experienced gamers and neophytes. Based on their feedback we made a lot of changes to the game's features and feel. This greatly improved Candy Cruncher's polish, and definitely shows the value of getting input from "fresh eyes".

THE IMPLEMENTATION

Once the design and look-and-feel were hashed out, I had to deal with the real world problems involved with supporting a wide range of hardware. For graphics, the two choices were GDI/DIBSections and DirectDraw. I went with DirectDraw, on the assumption that the Microsoft engineers have spent a lot more time optimizing their blitters than I would be able to justify. Also, since Candy Cruncher is such a simple game, I expected there to be few problems with the blitter support in DX3. As it turns out, this was the case (however, newer versions will use GDI "just in case").

For sound, we just used DirectSound. I could have opted for the safer route of using waveOut and writing my own audio mixer, but that was more work than I wanted to deal with and I believed that DX3 was robust enough for production work. In addition, I'd heard that quite a few users of similar type games that used waveOut would complain about audio latency. Unfortunately, going with DirectSound support has turned out to be the primary source of support and driver problems.

The first thing I found out was that hardware accelerated sound mixing was useless. I ran into skipping buffers and garbled output on a good chunk of DirectSound compatible audio cards, including ones from companies you'd hope would have their drivers stable. Oddly enough, the most reliable sound systems were inevitably the cheap integrated AC97 codecs like the Crystal Audio stuff. The cards we had the most problems with were Creative boards, including a PCI128 and an AWE32.

So to simplify my life I switched to doing everything in software (LOC_SOFTWARE) with DirectSound -- no hardware acceleration enabled at all. We lose some performance, in theory, but the reliability gained is worth it -- almost all of the audio problems disappeared. The only other big compatibility problem we've run into is that some very old drivers and soundcards (think "SND4 WinModem on Packard Bell Pentium/166") don't support DirectSound notifications, which we used for streaming audio. This caused Candy Cruncher to crash on some very old systems. To solve this problem subsequent versions use a separate thread that periodically wakes up to refresh the streaming audio buffer.

For audio compression we use the Ogg Vorbis (www.vorbis.org) codec library, a very high quality, dependable cross-platform audio compression system. It's also free. We've made less money off Candy Cruncher than we would have had to pay in licensing to use the MP3 format. No thanks.

SOUND AND MUSIC

Any good puzzle game needs puzzle game music and sound effects. A friend of ours (another puzzle game developer), Luc van den Borre (www.nuclide.com), recommended Ian Livingstone of MediaThemes (www.mediathemes.co.uk). We heard a track for a game that Luc was doing, and we were blown away by how cool it was. We contracted Ian to make the music for Candy Cruncher, and we've been delighted with it. The sound effects were taken from a stock cartoon sound effects library we purchased from Sound Ideas.

COPY PROTECTION

I don't believe in aggravating paying customers with lots of annoying copy protection, but by the same token, I do recognize that it's human nature to defer spending money as long as you can. As a result, we wrote a simple copy protection system that basically requires registration of the full version, with a completely separate demo version that can't be cracked (because there's nothing to crack). The demo version has a limited subset of features and nags at you, but you can still play the core game relatively unobtrusively. We think we've hit a good middle-ground between demo and full version.

It's entirely possible (and expected) that some more unscrupulous buyers out there will freely redistribute the full version and associated registration code and name, however we're not willing to devote more engineering effort or create customer aggravation to thwart the minority of pirates that are out there. We have to face that if someone is going to try to get Candy Cruncher for free and that they're that determined to do it, they're going to find a way. Then again, we're talking fifteen bucks here -- hopefully it's inexpensive enough that the hassle of finding a warezed copy isn't worth it for most people.

Thankfully, casual games is one of the few domains where minimal copy protection can make a difference. Our users are generally honest, and they don't have the "ins" with the cracking/warez scenes, so we don't anticipate piracy being too much of a problem. The downside, of course, is that piracy directly affects us a lot more than if we'd had a big advance from a publisher.

LAUNCH AND SUPPORT

After two weeks of iterative changes and testing, we launched Candy Cruncher through Longbow Digital Arts (www.longbowdigitalarts.com), friends of ours that have a very successful business making games such as DXBall, RivalBall and TreadMarks. We used InstallMaker (www.clickteam.com) for the installation program, and we've also used PatchMaker by Click Team with success.

Of course, we immediately ran into customer support problems, of a type that I expected in an abstract, theoretical way, but which was still startling when confronted for the first time. We found that many of our users have no idea what operating system, computer type, CPU, RAM, soundcard or drivers they had installed. In fact, installing an icon on the desktop seems required because many of our users can't find the game if they have to navigate the Start Menu. It's not that they're dumb, it's simply that computers are too complex for many casual computer users.

The bugs have been esoteric and, in many cases, are difficult to reproduce without the exact machine available. The biggest problems have been shoddy audio drivers -- in fact, we haven't run into graphics related glitches. All in all, we've only had about a half-dozen reported problems out of many thousands of downloads. The next version we put out will have an even more stripped down audio and graphics core and will hopefully run on ANYTHING made since 1996.

LATER RELEASES

The first version of Candy Cruncher was 1.05.3. Since that launch, we've spent several more weeks making modifications to it and getting it portable. The first version of Candy Cruncher was pure hack and slash -- I didn't want to think too much about the code, because I knew a lot of what I was doing was going to change anyway. After launching Candy Cruncher (and getting customer feedback), I went back and started cleaning up and fixing myriad little parts of the code that were ugly.

Candy Cruncher 1.10, released four weeks after 1.05.3, had a lot of changes in its technology, almost none of which were visible to the user:

* removed DirectSound notification support
* removed DirectInput support and switched to 100% Windows message
* placed resources in external file instead of embedding them in the app
* made the core Candy Cruncher code portable with no Windows dependencies
* made registry entries look in HKCU instead of HKLM
* added support for GDI graphics


After the next (and final) release of Candy Cruncher I expect us to have a portable framework of code that supports multiple operating systems. From there we can rapidly implement cross-platform puzzle games, probably on a four week development schedule. The hard part will be coming up with ideas!

THE FUTURE OF CANDY CRUNCHER

For a small developer, one of the hardest things to do is to know when a project is "done". Since the game is constantly selling and can be updated easily, you're always tempted to tweak and improve the product, which is a dangerous trap. You have to know when it's "good enough". Because of this, we're consciously trying to finish development on Candy Cruncher "real soon now". We have at least one or two releases left to get in some final changes. For starters, we want to port to MacOS, OS X, and some PDAs. Once that's done, and any final patches are released, we plan on moving on to some of our other projects.

SUMMARY

Candy Cruncher has been a moderate success for us. With very little publicity we've managed to sell a few hundred copies -- nothing earth shattering, but much better than we expected, and we expect word of mouth to carry it forward for quite some time. It allowed us to establish a relationship with our e-commerce partner (BMTMicro) and with a distribution partner (Longbow Digital Arts) in a fairly low risk environment. Most important, however, is that Candy Cruncher let us launch a product quickly -- something that's important when trying to keep morale up with a struggling startup. It also gave us a feeling of satisfaction and a job well done.

Next Installment: Thoughts from a Girl Making Boys' Games in a Man's World