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
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".
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.
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
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.
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
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.
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.
Thoughts from a Girl Making Boys'
Games in a Man's World