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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide