Grubby Gems
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.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Home, My Backup Data Center
- A Topic for Discussion - Open Source Feature-Richness?
- What's the tweeting protocol?
- Dart: a New Web Programming Experience
- Developer Poll
- Trying to Tame the Tablet
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




2 hours 13 min ago
4 hours 46 min ago
6 hours 3 min ago
6 hours 38 min ago
7 hours 49 sec ago
11 hours 49 min ago
12 hours 36 min ago
14 hours 9 min ago
15 hours 46 min ago
17 hours 44 min ago