Matt: It's definitely mostly a puzzle game. We tried to make sure it didn't require fast reflexes or perfect timing, because we wanted it to reach as wide an audience as possible. I think the slight arcade feel is attributable to the way the game is viewed from the side, with lots of platforms and ladders. Even though it's a tile-based logic puzzle game, we tried our best to conceal that with the graphics, to give it a different feel from the more common top-down logic game, and hopefully keep it fresh for people. In classifying this game, we've tended to go with "side-view, platform-based puzzle game," which I think sums it up pretty well. It owes a lot to Sokoban-style logic games, even though it looks different on the surface.

Ryan: The original goal was to make a platform (side-view) puzzle game. Most modern puzzle games are top-view (like Sokoban), and we thought the puzzle genre could use something new. We realized that the Sokoban crate-pushing dynamic would be less flexible in side-view (since the crates simply fall, and you can't really push them "up" again), so we knew it would require some ingenuity to create truly "puzzling" puzzles with the side-view constraint.

It was a fun challenge, and we're happy with the results!

As a bonus, because of the side-view, the game feels somewhat "retro". There are plenty of classic side-view puzzle games like Lemmings and The Incredible Machine, but very few modern counterparts. I think Professor Fizzwizzle fills a bit of a gaming void in this way, and has been well received by gamers as a result.

A level of Professor Fizzwizzle in action.

Ryan: It started with the "platform puzzle game" idea, but it was obvious that we needed a protagonist. I decided that a Professor would be a good fit because he would allow us to have gadget-like powerups that could be used to add complexity to the puzzles. The Rage-Bots were chosen because I figured they fit with the Professor theme, and because they would be fairly easy to come up with sound effects for. I had originally intended to use a vocoder (my uncle created his own, which I could use) to give them robotic-sounding voices, but we didn't end up doing that. After these rough initial ideas, Matt really fleshed out the Professor and the Rage-Bots, giving them the character and spunk you see in-game.

As for the story of the Friend-Bots turning into Rage-Bots, Matt really took off running with it. The in-game story that you see is his creation entirely; When he first showed me the rhyming version of it, I thought it was amazing! Combine the silly plot, the rhyming verses, and the excellent illustrations, and you've got yourself a memorable story!

Matt: While the game has plenty of game elements (crates, magnets, gates, etc), we did make a point of limiting their number. In the concept stage we considered several dozen potential gadgets and gizmos, but we eliminated all but the most versatile. We tried to include only the ones that would open up multiple possibilities. As an example, with the frost gun you could choose either to freeze a crate (enabling it to slide on any surface) or freeze a robot (disabling it, after which it can be used much like a crate). This kind of versatility made it possible to design a large number of interesting levels; because the objects and gadgets can be used in many different ways, each level's strategy is often not immediately obvious. Also, with all the possible interactions between the various game elements, many of our puzzles almost seemed to design themselves!

Ryan: The game was built entirely on my Linux machine using KWrite as my text editor, and GCC on the command line (with Make) to compile the source. Very simple tools, but they work like a charm. I used GDB as my debugger throughout the development, and valgrind at the end to find my leaks!

For the Windows build I used MinGW's GCC and Make to compile the source, and on Mac I used GCC and xCode to build the app bundle.

The libraries I used were SDL (as you said), SDL_image (to load our TGAs and JPEGs), and FMOD for sound. FMOD isn't free, but its ability to run on Win/Mac/Lin, and to play Ogg-compressed XM tracker files, made it a worthwhile purchase.

Ryan: I'm just a fan. I use Linux as my main OS, so it was just easier for me to develop the game on it than on Windows or OS X. Also, Linux systems are often chock-full of developer utilities (or have easy access to them), and this came in handy a few times. Valgrind was easy to get running, and the GIMP was great for viewing the various graphics Matt would send me.

Ryan: Well, I founded the Game Programming Wiki, and we do have a number of SDL tutorials there. I'm also happy to answer any SDL questions that pop up on the Game Programming Wiki message boards.

If anyone reading this is thinking of using SDL to create a game, I would suggest reading up on the docs available from the main SDL website, and finding a message board populated with other SDL developers (the GameDev.net "Alternative Game Libraries" forum is great). The docs will answer 95% of your SDL-related questions, and hopefully the other 5% can be answered by the folks on your favourite message board.

Also, for those who are quite new to game development, you may benefit from the start-to-finish SDL game tutorials available here.

Matt: The bulk of my work was done in LightWave. While I've yet to spend much time with any other 3D package, I began as a LightWave hobbyist and I haven't had reason to switch (at least after NewTek beefed up the character animation tools with version 8). With LightWave I did all the modeling, animation, and basic cel-shading. Another application I use at times is ZBrush, mostly for UV mapping and texture painting. Aside from that, all the post-processing was done in Photoshop; for most of the images this mainly involved cleaning up the ink lines created by LightWave. I think the only other tool worth mentioning is my beloved Cintiq tablet/monitor. It's expensive, but it really speeds up my workflow. I feel spoiled, and I'd hate to go back to an ordinary tablet!

Matt: Unfortunately, not having to worry about the number of polygons can lead to some really sloppy modeling... and since I'm still learning, I'm already a sloppy modeler! In making Professor Fizzwizzle I often made the mistake of using too many polys, which resulted in models that were frustratingly slow to pose. I've been more conscious of this while working on our current game, and it often yields cleaner cel-shading as a bonus. As for modeling something that looks good when rendered as a small sprite, one thing is obvious: it really helps to limit the amount of detail you include. I often had to simplify my models so the sprites would look less cluttered. I think this is particularly important when you're going for a simple cartoony look. One other thing I do, which is pretty standard I'm sure, is render everything much larger than the final version - usually at four times the size, but sometimes even larger if I'm doing significant post-processing. This makes it easy for me to do all my clean-up work on the sprite (mostly cleaning up the ink lines generated by LightWave) before shrinking it down to its final size.

Matt: Some people swear that they prefer the mouse to a tablet, but I think for most people a tablet is just far more natural. Not only does it let you draw and paint with the same hand mechanics you would use with pencil and paper, but tablets are also pressure sensitive which allows you to vary the thickness of your lines with ease. Personally, I don't know how I'd get by without a tablet. Still, although my Wacom Cintiq (a monitor I can draw directly onto) is a nice luxury, a small conventional tablet would do the job just fine.

Matt: Actually, I only own ZBrush because in the past I used it for my own short animations, which were what I did before teaming up with Ryan to form Grubby Games. For those animations I used ZBrush to create highly detailed displacement maps and for 3D painting of my texture maps. For Fizzwizzle, you're right - the models are simple and certainly don't need displacement mapping. But even for those cartoony models I often wanted to paint simple surface details. LightWave's UV mapping tools often seem quite finicky and limited (although my inexperience may be primarily at fault!), but ZBrush allows me to create perfect UV maps without any ugly warping, and better yet, it allows me to paint the surface details directly onto the model, rather than painting a 2D image and later mapping it onto the model. This saves me plenty of time, and spares me plenty of headaches!

Matt: We met in university about eleven years ago when we lived in the same dormitory, and we've been good friends ever since. Both of us have always been interested in developing games, and since our skills are so complementary it seemed natural for us to team up. After a decade of idle talk, last fall we both realized that we were finally in a position to dedicate ourselves to full time game development. I think we're pretty lucky to have stumbled upon one another in this way, since I know many programmers and artists spend years trying to find the right partner!

Ryan: The Game Programming Wiki started a few months before development began on Professor Fizzwizzle. I've always been a hobbyist game programmer, and back in the late 90s I started a website called Lucky's VB Gaming Site. It grew to be quite popular (in the VB game programming community), and it was a very friendly place where newbies could come to learn how to program games.

People often sent me tutorials to add to the website, and it quickly became too much for me to handle on my own. That's why I thought it would be a great idea to use a wiki-format: People can simply add new tutorials to the wiki on their own, and I don't have to deal with the formatting headaches myself. Also, after switching from VB to C++, I found that C++ game development websites were sometimes lacking in the newbie-friendliness department; I hoped that the Game Programming Wiki would be a place where aspiring developers could come and ask questions without fear of being looked down upon. We were all newbies once! Other people helped me get my start, and I'm trying to return the favour.

Ryan: Well, when I switched from using Windows to Linux as my main OS, VB was on the outs. There are VB-like languages that can be used on Linux, but I figured I might as well go back to my roots. I had learned C++ when I was younger, but set it aside in favour of VB because of the ease with which I was able to get VB development jobs. Now I was setting VB aside because of the ease of using C++ on Linux :)

I do prefer C++ to VB, but I know it's not for everyone. If you don't have a good understanding of the language, programming in C++ can be a nightmare.

But if you do have a good understanding of the language, C++ allows you to do a great many things that aren't otherwise possible. Also, the cross-platform capabilities of C++ (specifically, the G++ compiler) have allowed us to make games for a wider audience, which has really helped our bottom line.

Matt: For starters, with such a small team it's great that you're heavily involved in everything: initial concept, game design, level design, character design, testing, marketing, support. Ryan does the coding and I do the graphics, but other than that anything goes. This is very satisfying, and keeps things fresh; plus, the game really is your baby, since you're not just working on one tiny part of it.

Being a team of two means that we never have to compromise our creative vision for the game. If we don't want to add a certain feature, we don't have to add it; it's as simple as that! And it's pretty rare for us to disagree strongly about any significant issue, so it's easy for the two of us always to be fully committed to the game that's taking shape. That also holds true for the choice of which project we should work on. In the initial stages all sorts of ideas are flying around, but with only two of us it's easy to settle on one that we're both very excited about. Without that excitement, it's pretty tough to imagine slogging through the later, less sexy stages of development, and those stages inevitably come with any project!.

Another big thing is that, as an indie developer, you truly have to be self-motivated just in order to finish a game, especially while you're working on the duller aspects of development (like the GUI, or player profiles, or designing the 215th level, etc). You don't have a boss breathing down your neck, setting deadlines and milestones. With only two team members, there's much less chance of someone lacking that self-motivation and self-discipline (or even of having real life intrude too much on their working hours) and falling behind, letting the whole team down. There's never any time wasted waiting for other team members to catch up, or chasing them for something that was needed last week; if there's a problem, Ryan and I talk about it right away and start solving it immediately, which is great.

Also, while it may seem obvious, communication is a snap with such a small team. We don't have to waste time re-explaining things to make sure everyone is up to speed. There's no need for a detailed design document, because both of us are intimately involved with every decision that's made, from start to finish, and we have a pretty unified vision right from the start.

Lastly, from a graphics standpoint, having a tiny team can help in the establishment of a cohesive style to the game. Whether people like the particular style or not, at least it's cohesive and doesn't look pieced together, which is really a danger when multiple people are working on the graphics. Even if each artist is highly skilled and produces great looking stuff, if it doesn't have the same style it can detract hugely from the game experience. Some indie games have incredibly simple visuals which are nonetheless pretty effective, just because they're consistent (and often unique).

The disadvantages are harder to come up with! I suppose having a limited number of man-hours each week leads to a relatively long development cycle, but we're still able to make our type of game in around six to nine months, which isn't bad. We're definitely limited in the scale of the projects we can tackle, but this isn't necessarily a bad thing. We're never going to create the next Half-Life, or some immersive 3D MMORPG, but to be honest that stuff doesn't really interest us anyway; we're pretty old-school and don't necessarily think that 3D is always better, so the fact that we're limited to fairly simple sprite-based graphics is actually a positive thing for us.

With only one person in the graphics department and one in the coding department, there's slightly less chance that we'll have the necessary skills or experience to tackle any given task (coding or graphics), so I know on the graphics side of things I often have to devote a couple of days to research and experimentation until I can produce the effect I want. With a larger team, there's a greater chance that someone else would be able to tackle that, and that I could learn from them... but that being said, I don't see it as a burden really, and it provides great opportunities for us to learn in a self-directed manner, which is often the best sort of learning for me anyway.

So as you can tell, we're pretty happy to keep our team small for as long as possible!

Ryan: I don't think we've changed a single thing, actually! I'm developing our next game on Linux using KWrite, just like last time, and Matt's still using LightWave and Photoshop, as far as I know. Our tools worked well enough for Fizzwizzle, so we've had no reason to change.

Actually, that's not true. For Fizzwizzle we used TGA image files, with alpha. Now we've moved to PNGs instead. We're using a PNG compression tool to get the file sizes down; hopefully this will mean that we can include more content in the game, without allowing the download's file size to balloon!

Ryan: What, Americans don't eat fries with mayonnaise?! Matt, we'd better pack a couple crates of fries + mayo for our trip down the IGF! Maybe we can get tickets to see the San Jose Sharks play hockey, too... do you think they'll let us bring our own mayo into the HP Pavilion arena, John?

Matt: Yes, this is the first GDC for both of us. It's actually our first game-related conference of any kind, so we're pretty excited about it!

One of the coolest things about becoming a finalist was that it gave us an excuse to make sure we attend the GDC. I know we're both looking forward to meeting many of the other talented folks in the indie developer community, not only to share our ideas and experiences, but also just to get to know them a little bit. Many of them seem very cool and have been incredibly helpful and supportive, which has been a huge boon for a fledgling company like ours! Other than that, I'm just really looking forward to soaking up the whole experience, seeing how it's my first time attending. Hopefully we'll be able to catch many of the presentations - Ryan and I will have to juggle our booth duty as best we can. Although I have to say I'm a bit disappointed that I missed last year's session with my current gaming hero, Keita Takahashi (the genius behind Katamari Damacy)!

Matt: Have you been talking to my psychiatrist behind my back? :)

Ryan: We're using both Plimus and RegNow as our payment processors. When a purchase is made through either system, the user is emailed a link which allows them to download the full version of the game. This method has been working really well for us, and it's quite simple.

You may be wondering why we're using two payment processors; it's because they each have their own strengths. Plimus has is a really flexible interface, and very reasonable rates. Also, their customer support is prompt and effective, and we've been really happy with them. RegNow, on the other hand, has a huge number of active affiliates. By supporting RegNow, we make it easy for hundreds of affiliate sites around the web to sell our games. Also, RegNow accepts payment via PayPal, which Plimus (currently) does not.

Ryan: Think smaller. Design a game with your own constraints in mind. For example, if you have good coding skills but poor graphics skills, design a game that will require fewer distinct graphics assets (a simple puzzle game, perhaps) and contract out the work if you must.

Also, creating a smaller game (something that you can actually complete!) will help you to assemble a team for your future games. Once you have proven that you can finish a game, people will be much more likely to trust you and invest their time on one of your projects.

Plus, a small finished shareware game will make you more money than a large unfinished shareware game :)

Matt: Ryan makes a very good point about attracting other team members by proving yourself with a small game first. Our situation was different - even though Ryan had never seen a game through to completion (at least to my knowledge), just by knowing him so well I was certain I could count on him to have the tenacity to finish any project we started. But without that kind of certainty, I would have been very hesitant to commit so many months of my time. Without the two of us being fully dedicated to finishing Fizzwizzle, who knows what would have happened...

Ryan: Yes! If you're new to the indie game scene, but like what you're seeing over at the IGF website, you should check out some of the staples of the indie game world: GameTunnel and TIGSource. (Unfortunately, TIGSource is currently having technical difficulties... I'm sure it'll be online again soon.) TIGSource will keep you up-to-date on the latest indie goings-on, and GameTunnel has in-depth reviews for a ton of indie games. Enjoy!

Matt: Thanks very much for your time, John. All the best!