[size="3"]I'm here with Ryan Clark and Matt Parry from Grubby Games. For the benefit of our audience, tell us a little bit about the game itself. It seems to mostly be a puzzle game, but it certainly has a couple of arcade elements here and there. How would you describe Professor Fizzwizzle and where would you classify its genre?
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.
The Professor Fizzwizzle main menu (click on any picture for a larger version).
[size="3"]When you look at a Sokoban-style game, though, it's obviously a puzzle game. There's just a certain "look" that people expect from puzzle games, and Professor Fizzwizzle doesn't really follow that mold. When I first saw the screenshots of the game, my impression was that it's a Donkey Kong or Super Mario Brothers knockoff, but your game really owes more to Sokoban than Donkey Kong. Was this your intention from the start, or did the design evolve during prototyping?
[size="2"]
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.
[font="arial, verdana, tahoma, sans-serif"][size="2"]
A level of Professor Fizzwizzle in action.
[size="3"]Was the whole thing with the professor and the robots planned from the start, or was it more of "let's do a platform-based puzzle game" thing with the professor and the runaway robots added later? Or, more succinctly, when did the "plot" arrive in your game design?
[size="2"]
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!
[size="3"]One thing that separates Fizzwizzle from the aforementioned Sokoban is the amount of stuff you have to play with. With Sokoban, there are basically four things (the box-pusher, the box, the box-target, and the wall). Fizzwizzle introduces a couple-dozen problem solving gizmos as the game goes on, from elevators to inflatable barrels, and probably some stuff I haven't gotten to yet. While this does give the game more flavor than Sokoban, it does make things more complex, what with all the ways things can interact. How did the breadth of items affect the design and development process?
[size="2"]
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!
[size="3"]Ryan, tell me something about the development tools and process you used. I recall reading that you used C++ and SDL, but did you have a particular compiler or development environment of choice?
[size="2"]
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.
[font="arial, verdana, tahoma, sans-serif"][size="2"]
Fizzwizzle code in KWrite, Ryan's code editor of choice.
[size="2"]
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.
[size="3"]Any good SDL-related websites or discussion groups or other resources that you can recommend?
[size="2"]
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.
[size="3"]And Matt, same question as earlier but for art tools. You've got plenty of cartoonish animation in the game. What tools did you use for modeling and animation (and post-processing if any was necessary)?
[size="2"]
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!
[font="arial, verdana, tahoma, sans-serif"][size="2"]
The good Professor modeled in LightWave.
[size="2"]
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.
[size="3"]Is a graphics tablet a must-have for graphics work?
[size="2"]
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.
[size="3"]You mentioned Zbrush as a finishing tool, but when I think of ZBrush, I think of people using it for hyper-realistic skin/hair effects. The Fizzwizzle models, though, are very smooth and cartoonish. Did ZBrush fit into the equation, and if so how?
[size="2"]
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!
[size="3"]You guys seem to fit the classic programmer/artist duo. How did you guys find each other?
[size="2"]
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!
[size="3"]Tell me more about the Game Programming Wiki. Did that start before or after Fizzwizzle? What kind of need is it filling in the game development community?
[size="2"]
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.
[size="3"]So you came over from the VB side of things, but you wrote Fizzwizzle in C++. What advantages and disadvantages you've found between the two? Is it just a matter of being able to port to non-Windows platforms, or is there something else?
[size="2"]
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.
[size="3"]What are the advantages and disadvantages of having a very small team?
[size="2"]
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!
[size="3"]I'd ask for a sneak-preview of your next big game, but I don't know the legal status of NDA's between the US and Canada. Instead, tell me what (if anything) you'd change about your development process and/or the tools you used.
[size="2"]
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!
[size="3"]For last year's IGF, I interviewed Metanet software, another two-person Canadian company. Does the secret to being an IGF finalist lie in being a two-person company or in being Canadian? Is there any truth to the rumor that the secret to quality game design lies in watching hockey while eating french fries with mayonnaise?
[size="2"]
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?
[size="3"]Is this your first GDC? What are your GDC plans and expectations (beyond taking home a pile of clear Lucite prize-bricks)?
[size="2"]
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)!
[size="3"]Aren't you worried that Keita Takahashi will try to roll you into a large ball?
[size="2"]
Matt: Have you been talking to my psychiatrist behind my back?
[size="3"]There are loads of ways to sell software online nowadays -- lots of shareware money-processors, systems to put magic "unlock the rest of the levels" codes into the game, and the like. What kinds of commerce stuff are you using, and why did you decide to use the ones you did?
[size="2"]
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.
[size="3"]Any advice you'd like to give our readers who want to get out of the "I need a development team" rut and want to produce a completed game?
[size="2"]
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...
[size="3"]Thanks for the interview, guys. Any parting thoughts besides "be sure to vote for us for the audience-choice award"?
[size="2"]
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!
