Matt: We're very excited to secure a finalist spot again this year; the competition was even stronger this time around! Our 2007 entry is FizzBall, which is our attempt at a breakout game with a twist. Most gamers who check it out will immediately see its influences. We were huge fans of the Katamari games, and FizzBall is like a breakout game with a little Katamari thrown in. The character from our first game, Professor Fizzwizzle, is the star of this one as well. On each level you help the professor bounce a bubble off his paddle, smashing objects and collecting animals. As the bubble gets bigger, it can collect larger and larger animals. Your goal on each level is to rescue all the animals, and there's a wide variety of bonus levels as well.

Matt: After the release of our first game it became clear that the professor was very popular with many of our users. When we entered development on FizzBall, the professor character seemed a good fit in terms of allowing for some kind of background story, especially since we needed some crazy contraption-on-rails, and wanted the rescue of animals to be central to the game. Also, it seemed a good idea to capitalize on the popularity of the character, and to try to establish our games as a recognizable brand. That being said, we'll definitely be introducing other characters in future games. Don't worry - we have no plans for Professor Fizzwizzle breakfast cereal, or any other attempts at world domination! :)

The ability to reuse art assets didn't affect our decision, but it was a nice bonus - we probably saved a good week's worth of character modeling and rigging.

Ryan: Well, I think there are a number of reasons. First, fans of Professor Fizzwizzle (the game) really seemed to grow attached to Professor Fizzwizzle (the character), so we thought that they would enjoy seeing him in a different kind of adventure. Also, the concept for FizzBall (rescuing animals in a magic bubble) seemed to be well suited to a professor-type character; we needed some way to explain the magic bubble, and the contraption used to bounce it around! Professor Fizzwizzle seemed to fit the bill.

Matt: There have been no changes on the graphics side. I split my time about equally between LightWave and Photoshop, with a little Z-Brush for UV texturing. I still haven't learned how to use LightWave's UV tools well enough, but Z-Brush is a nice crutch! And my trusty Cintiq has really been earning its keep.

The professor's ship (aka the paddle) modeled in LightWave (click for full size)

Ryan: I changed operating systems between Professor Fizzwizzle and FizzBall; I now use Mac OS X as my main OS, instead of Linux. However, I still use the same tools on Win/Mac/Lin to make the various cross-platform builds, so not much has really changed.

We did add one new library: libcurl. We use it to submit high scores to our online server so people can compete globally for daily scores and all-time scores.

Since things went so well for us with the development of Professor Fizzwizzle (for the most part), we didn't really have incentive to change our habits!

FizzBall development in Xcode

Ryan: Hehe, "and I'm a penguin!" should be added to those commercials to balance things out, Linux-wise :)

I actually made the switch because I bought a new MacBook Pro as a dev/testing machine; we needed an Intel Mac to properly test the Universal Binary builds of our games. I planned to triple-boot Windows, Mac OS X, and Linux on it (as I had seen a few websites with instructions on how to do so), but shortly after I started using the MacBook I found out about Parallels. (It was in beta, at the time.)

For those who do not know, Parallels allows you to run virtual versions of Windows and various Linux distros on Mac OS X. You can also use Parallels on a Windows or Linux machine, however Mac OS X itself cannot be run via Parallels as a virtual machine. So essentially, if you have an Intel Mac and use Parallels, you can easily develop for Windows, Mac, and Linux all on a single machine! You can't do that on a Windows or Linux machine.

Parallels also helps us ensure that our games run on a variety of Linux distros, as it's very simple to install and boot up virtualized copies of the most popular distros of the day. It sure beats quintuple-booting! And I can create copies of "fresh" Win/Lin installs so I can revert to them at any time.

So, to make a long story short: I'm now a Mac user because it makes cross-platform game development easiest for me. And I do like Mac OS X itself, quite a lot. The fact that it's essentially UNIX underneath makes me happy; I spend a lot of time messing about on the command line, as most developers do!

Ryan: I think the "ball growing" mechanic sort of balanced itself, actually! The main reason we were excited about the FizzBall concept was that we felt it addressed a major flaw in many breakout-style games: The "last brick" problem. It's often a pain to destroy the final brick in a breakout level, as you need fairly good aim to hit it. As a result, levels start out fun and frantic, and eventually become slow and frustrating.

FizzBall addresses this issue by increasing the ball size as the level progresses. So, at the start of the level, the ball is small but there's lots of fun stuff on screen to interact with. By the end of the level, it becomes quite easy to rescue any remaining animals because the ball is large and easy to aim. Also, the fact that you don't have to break everything on a level is another advantage: All you have to do is rescue the animals. Destruction of the environment is just a fun bonus!

Matt: It'll definitely be a thrill to see Miyamoto's keynote address. Will Wright's keynote was one of the highlights of last year's GDC for me - he's such an engaging personality, and it was fascinating to get a little peek inside his thought processes.

But actually, even though I missed Keita Takahashi's presentation the previous year, last year I had the good fortune of spotting him as he wandered alone through the conference center. Poor guy! I couldn't resist introducing myself and shaking his hand, even though he must be sick of fanboy stalkers like me! :)

Ryan: I've had an Xbox 360 since last Christmas, and got a Wii this Christmas, and a PS3 for my birthday. So, thanks to very generous and resourceful relatives, I have all 3!

But honestly, I still play the 360 the most. It has been out the longest, and therefore has the best single-player games available. However, the Wii is definitely a blast when we have a group of friends over. The PS3 only gets trotted out when someone wants to see what the PS3 is like. "Resistance: Fall of Man" looks very nice, but the gameplay doesn't really offer anything overly fresh. I prefer playing Gears of War or Battlefield 2 on my 360.

I'm hopeful that the PS3 will see more use once we get past the "launch title" era.

Ryan: With Professor Fizzwizzle, we definitely had to knock on some virtual doors to get the attention of the major online gaming portals, but with FizzBall things were somewhat easier. We had already established relationships with many of the notable portals and, perhaps because of FizzBall's more "casual" nature, we were able to get the attention of the remaining portals we were unable to reach with Professor Fizzwizzle.

I'm not sure if it was persistence, a more suitable game, or perhaps that more people have heard of us now, but things were definitely easier for us, this time around!

Matt: With our first game (Professor Fizzwizzle), we've seen significantly more revenue through our own site than through the portals - almost twice as much at this point. But then again, that game was not accepted by some of the largest portals, like RealArcade and Yahoo. Also, it wasn't really "portal-friendly"; it was felt to be too complicated for most true casual gamers.

With FizzBall, we anticipate that a larger chunk of our revenue will come from the portals (as seems to be true for casual games in general), but it's really impossible to say just yet, as we've received very few sales figures thus far. One factor to consider is that the vast majority of portal sales come in the first month or two after the game's release. After this, games tend to be much less visible to potential customers, because the portals are always releasing so many new titles. In contrast, we believe that over time we should see a much longer life for our games on our own site.

As for your other question, when a customer downloads our demo through a portal, any eventual purchase is handled entirely through the portal itself. Because they spend a great deal of money to promote themselves and to attract customers, portals are understandably very careful about preventing any of their traffic from leaking away to developers' websites; they won't even allow any external URLs to be displayed within the game or in the help files.

When we first began dealing with the portals, we were worried about losing out on potential revenue, since the portals retain the bulk of the revenue from the units they sell. But we've come to the conclusion that, for the most part, the people who our games from a portal would never have bought it from our site anyway - we just don't think there's very much overlap between the traffic on our site, and the traffic on the portals.

Matt: On the positive side, Plimus support is incredibly quick to respond. And as far as payment goes, we're extremely happy with them; we've always received our cheques on time. In fact, a year ago, we were so thrilled with everything about Plimus that we never would have considered any other provider.

However, in the past six months or so there have been some hiccups, mainly involving purchase confirmation emails not being sent to our customers. When this has happened it has been extremely frustrating, both for us and for our customers. We've had some unbelievably irate emails from customers as a result (some almost comically angry)! This really bothers us when it happens, because one of the great things about being a small company is that we can pride ourselves on great customer service and support. So we've got mixed feelings, at present.

Ryan: We don't use any tricks, really. The majority of our traffic and sales come from web sites that review our games. These sites find out about us either via our press releases, or as a result of direct emails from us to them, asking if they'd be interested in reviewing one of our games.

One big advantage we have, in terms of direct sales, is that our games run on Mac and Linux. These communities are certainly much smaller than the Windows community, but they are easier to reach. There are a handful of major Mac websites (Apple.com, Version Tracker, Mac Update, etc) that can drive a ton of traffic to your site. Linux gaming websites are similarly helpful, although it seems that word of mouth plays an even larger role in our Linux sales. Commercial Linux games are so few and far between that people seem happy to spread the word when they find a game they like! And we certainly appreciate that support :)

Ryan: The Game Programming Wiki is doing well! It is a fairly close-knit community of programmers, each with their own specialties. I rarely have to answer programming questions myself, these days -- they're usually solved before I even see them!

As for wiki-management: I think the key is to find some intelligent sysops/moderators, and empower them to keep things in line. As I said, the "core community" of GPWiki is quite diverse, so there's usually someone around who can verify that a recent edit is valid or not!

The wiki does see a fair amount of spam, but we have a spam blacklist that I continually update to prevent repeat attacks from the same sources. And, of course, our diligent sysops make sure that any spam that arises is very short lived.

On the downside, we still don't seem to have found a great way of structuring the wiki to make it easy and intuitive for newcomers to find the information they need. The majority of people find the site via Google searches, so they've probably already found the content they want (if they search for "sdl tutorials", they'll get the appropriate page on the wiki, for example), but I still hope that we can eventually find some paradigm that ties all of the content together in a more meaningful way.

Matt: This is nothing new or earth-shattering, but it's certainly worth repeating: start small! It's truly amazing how much work goes into developing a game, even a simple one, and if you've never seen a project through to completion it's very easy to get overly ambitious. Each time we develop a game it seems to take nearly twice as long as we predict; had we not concentrated on fairly simple game designs, I bet we'd still be working on our first title. If you're looking to get into indie development, the best advice I could give is to spend some time prototyping several simple gameplay concepts, until you find one that's truly fun and that's small enough that you think you can finish it in six months. But then don't be surprised when you're still polishing it up a year down the road :)