Wanting to know more about the company and what makes it tick, I sat down (in a virtual sense) with Grubby Games' cofounder and programmer Ryan Clark.
DB: Thanks for agreeing to this interview. First off, how long has Grubby Games been around, and perhaps more to the point, how long have you been making Linux games?
RC: Grubby Games was founded in 2004, and we've been making Linux games the entire time.
DB: What about the games available for sale on your site that run only on Windows and/or the Mac platform?
RC: The games on our site that do not run on Linux were created by other developers; we sell those games as affiliates. All of the games we have developed (and will develop) run on Linux.
DB: That's good to hear! What led to your decision to support Linux with all of your offerings?
RC: We chose to make Linux games because I personally always have wished that there were more games for Linux. It seems that others share my sentiment, as we have received a number of e-mails from Linux users, thanking us profusely for making our games available for Linux. (We also get our share of comments from Linux users who are angry because our games are not free/open source!)
DB: Do you think you might ever release your games or any of your animation/rendering or other libraries under an open-source license? I'm thinking of something along the lines of what id did with Doom and Quake when after the commercial benefit of the games had passed, they released the source code to the engine (but not the levels themselves) under an open-source license.
RC: I hope we'll be able to do that at some point, yes. However, we already do it in a manner of speaking, through another Web site we run: The Game Programming Wiki (gpwiki.org).
I've written a number of articles for the wiki, many of which describe the exact same methods I use in our games. And on the GPWiki forums, I do my best to answer any questions people may have.
DB: I'll have to check that out. What percentage of your sales come from Linux versions of your games?
RC: About 2%, although I do know that a number of people have purchased Windows or Mac versions of our games because they want to (indirectly) support our Linux efforts.
DB: Good for them! Do you think the market is ready for more commercial Linux game studios?
RC: It's hard to say. We certainly wouldn't be able to afford to do what we do if we were Linux-only. However, I do think that more studios should consider making Linux versions of their games. Many already support Windows and Mac; it's not much harder to support Linux too. Not supporting Linux is just like throwing away money.
DB: So, at least for now, is the cross-platform approach the best way to go?
RC: As I said, we certainly couldn't survive on the money we currently make from the Linux versions of our games. However, we're definitely not reaching all of the potential Linux customers that we could be.
If we're currently reaching only 2% of potential Linux customers, then yes, we could survive by making Linux-only games, if we could somehow reach 100% of them. And I'm confident that we're probably reaching less than 2%, at present. But how do you reach the rest of them? We haven't found any cost-effective way to do it. Expensive advertising campaigns surely would help expand our reach, but likely would not benefit our bottom line.
DB: How much of your code is fully cross-platform?
RC: More than 99%. We have platform-specific code only for a few things, like locating a good place to store user profile data, or opening a Web browser.
DB: How hard is it to support all three OS platforms simultaneously?
RC: Really not that hard. The tricky bit is not the coding, it's the deployment on each platform. But even the deployment is easy once you find a system that works well for you. With each release, it becomes easier and more automatic for us.
DB: Do you have any games currently in development that you can tell us about?
RC: We have three games in development, but they are all in their very early stages, so we're not quite ready to divulge any secrets. But, I can tell you that they'll all run on Linux, of course. We're branching out in a few new directions, so expect to see some cool new stuff.
DB: I'm excited to see them! Are you the head programmer/only programmer on these new games?
RC: I was the only programmer when we started in 2004, but we now have three programmers on staff. Programmers work on their own games; we feel that it's more efficient to run three projects with one programmer each than one project with three programmers.
DB: All three of your current games ship with a ton of levels. How do you decide when you have created enough levels and are ready to ship?
RC: We usually aim for a certain minimum amount of play time. (We want to make sure our customers feel like they got good value for their money.) As a result, our games tend to have a minimum of about six hours of game play. If you are superhuman, and you play through all the levels without any sort of hiccup, you can finish our games in around that amount of time.
In reality, our games will last much longer than that, of course. I seriously doubt anyone could solve all of the Professor Fizzwizzle or Professor Fizzwizzle and the Molten Mystery levels in less than a full-time week. The games also provide replay value through high-score systems, trophies or level editors with downloadable levels made by other users.
DB: Speaking of the level editors, was their inclusion a planned feature from the get-go, or was it a “well, it's built, so we might as well include it” kind of thing?
RC: A level editor just felt like a natural addition. If people enjoy solving puzzles, some percentage of them also will enjoy creating puzzles. It was an easy way to add replayability to the games, and a way to build community.
Also, we just really wanted to see what people would come up with. I was very pleased the first time someone stumped me at my own game.
DB: Are any of you still creating levels for the games and posting them on-line, or are you all too busy creating the next great Grubby Games game?
RC: I check out levels created by the community, but I rarely post new ones myself. As you say, we are very busy working on the next batch of games.
DB: Seeing as your games run on the big three OS platforms, which one do you do your primary development on?
RC: Our first game, Professor Fizzwizzle, was developed entirely on Linux. Since then, we've moved over to Mac OS X. The reason for the move is Parallels Desktop. Parallels allows us to run Windows and Linux as virtual machines, from Mac OS X. As a result, we can develop and test for all three platforms on one machine, without needing to reboot—very handy.
DB: Very handy indeed—I'm a big fan of virtualization myself. On a slightly related note, I do have to say that my favorite game of the three is FizzBall. When you were in the planning stages, how did you come up with the idea for this game? It's a wonderfully crazy cross between Katamari Damacy and Breakout.
RC: Matt and I are both huge fans of Katamari Damacy, so I think it influences our thinking somewhat. We're also fans of Breakout/Arkanoid, but felt that there were a few major shortcomings of the genre: the “last brick problem”, and the “lack of control” problem.
The “last brick problem” is likely familiar to you: you've got one brick left in Breakout, but you can't quite seem to hit it—so frustrating! We feel we solved this problem in a number of ways. First, the Katamari-ness of FizzBall means that the ball grows over time. The large end-game ball makes it easier to hit any target you might be aiming at. Second, since you're supposed to be rescuing animals rather than breaking things, you don't actually have to destroy everything on the level.
The “lack of control” problem lies in the pinball-like nature of Breakout: after you hit the ball, you have nothing to do until it comes back down. We addressed this problem by introducing “fans” that allow you to alter the ball's trajectory while it is in flight. This allows skilled players to achieve large combos, collect hard-to-get trophies, and it makes FizzBall less of a “waiting game” than traditional Breakout titles.
DB: Yes, you did solve both of those issues quite well, and I'm working my way through the last few trophies. Finally, I wanted to ask you about who created the levels on Professor Fizzwizzle and Professor Fizzwizzle and the Molten Mystery? Some of them (especially the ones in the advanced level sets) are insanely hard! I'm almost convinced that you have a secret team of psychotic chess geniuses on your staff.
RC: Matt and I created almost all of the levels for Professor Fizzwizzle, even the advanced ones. It was a challenge to make so many levels, but a lot of fun too. For Professor Fizzwizzle and the Molten Mystery, we hired level designers to help us. In fact, to find the best level designers, we simply chose from the players who already were submitting Professor Fizzwizzle levels to our Web site! Jarod and Lior did an amazing job for us.
DB: Yes they did. Thanks for taking the time to talk with us today.
RC: Thanks Daniel! It's been fun.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Non-Linux FOSS: .NET?
- Designing Foils with XFLR5
- Consent That Goes Both Ways