A couple of weeks ago, we announced the release of Osmos on Linux. Even before I had finished the port, we had been invited by a few members of the Linux community to do a post-mortem on our experiences. We were asked, “What would have made the port easier?” It was pointed out to us that while some indie developer forays into Linux had resulted in drama (viz. John Blow’s inquiries into Linux back in August 2008 as he was considering porting Braid to Linux), it was hoped that more indies would “take the plunge” and share their experiences with the Linux community, to work together towards developing Linux into a platform for gaming.
Our response was, “Great idea!” Last week, when I finally had time to sit down and begin writing, I discovered there was quite a lot to say about my experiences — more, I think, than fits comfortably into a single blog post. So, nearly three weeks after Osmos’ launch on Linux, allow me to present the first of three daily installments of the Osmos Linux post-mortem!
In this post, I’d like to lay a bit of groundwork by describing where we’re coming from. First then, three main points:
1) As a studio, we are (and continue to be!) open-minded and hopeful about Linux as viable platform for games.
AAA shops have essentially stopped porting games to Linux (viz. the latest positions of long-time Linux proponents id and Epic). Conventional wisdom in the games industry is that you can’t pay the bills making games for Linux because the market isn’t big enough relative to the cost of development. Hemisphere Games, however, is an indie studio, and our development costs are much lower; we don’t have as many mouths to feed, and our aim is for smaller-budget titles. So, it isn’t as obvious that this wisdom holds in our case.
Porting Osmos to Linux has been an experiment for us as a studio. Is it worth porting games to Linux? We sure hope so, but we’ll have to see! We had a nice sales spike our first week, but it’s trailing off fast; we’re waiting to see what the tail is like, as news about the availability of Osmos on Linux gets around. In a few weeks, we’re going to publish some sales stats and share our analysis on the prospects for the various platforms from the perspective of game development. This post-mortem can therefore be viewed as a sort of prequel to the sales and market analysis still to come.
2) Our goal in these articles is to help the Linux platform, not to condemn it.
The word criticism literally means “to discern the value of a thing”; criticism a good and essential part of growing. In continuity with my first point, our objective with these articles is to help the Linux folks learn about their platform, to offer perspective about where its strengths and weaknesses lie. We want to be open and honest in our description of our experiences as game developers working with Linux for the first time. The intent of my feedback is to share what Linux is like for first-time users and developers, where the barriers to entry lie — essentially, what works, what’s broken, what’s attractive and what’s a turn-off!
Please let this be abundantly clear: we want to provide helpful insight into what Linux looks like for game developers — to constructively critique Linux as a gaming platform, for the purposes of improving it, not tearing it down.
3) Our hope is that the experiences and opinions we share will be carefully considered, given our position as seasoned game and engine developers.
Leading up to this post-mortem, I’ve already shared a bit of my perspective with members of the Linux community in a couple of contexts. I’ve found there are three common ways my perspective gets dismissed without engagement:
- “These comments are coming from a terrible game designer… If you’re a good developer you get things done”;
- “id and Epic port their games successfully to Linux, why can’t you?”
- “You should have hired a Linux-pro to do the port rather than attempting it yourself”
Let me respond with two comments. Firstly, observe that the final Osmos Linux port is very polished and successful from a technical standpoint, as evidenced e.g. by the favourable reviews, warm comments on our forums, the wide number of configs supported, the smooth package installation process, the excellent performance even on low-end machines, etc. Secondly, I invite our critics to examine our credentials. For the sake of this post-mortem article, note that I was at Epic as one of the handful of people on the Unreal Engine, and therefore 1) I have a bit of perspective into how things are done and what attitudes are like at shops like these; and 2) I’ve written a bit of code on one or two platforms in my day.
So, I hope it’s clear where we’re coming from; we’re friends of Linux, not enemies!
Let me also say a few words about the Osmos codebase itself.
A Brief Overview of the Cross-Platform Life of Osmos
From very early on in the project, it was decided to build Osmos from-the-ground-up with cross-platform compatibility in mind. Before I joined the project in September 2008, Eddy had (very rightly) decided that OpenGL, OpenAL, libvorbis/libogg and FreeType would be the core libraries on which the game was based (SDL was not an option for us for a variety of reasons; while useful in some contexts, SDL is fairly high-level and not a friendly solution 1) for the kinds of low-level processing that many games need to do, particularly with sound and input; and 2) when considering portability to consoles). The game was initially released on the PC in August 2009. Shortly to follow, we simultaneously launched two ports in December 2009: a version of Osmos for Mac/OSX (ported by our resident Mac/iPhone specialist Aaron Barsky) and a multitouch-and-D3D version of the game for Win7 launch and the new ‘Games For Windows — LIVE’ platform. There have also been iPhone and iPad versions of Osmos in production since January 2010, as well as other dark and mysterious initiatives afoot (more details on these soon!)
So, by the time we came ’round to the Linux port in March 2010, Osmos had already been ported a couple of times and therefore the codebase was mature, stable, and proven from a portability standpoint. We considered hiring out the Linux port, but were wary about it. We were unsure about how much revenue the port would bring in. All ports to date had been done in-house, and so our processes were ironed out and we knew what to do. And anyway, since we’d need to have a heavy involvement in the port for the sake of assuring quality even if it was contracted out, we decided in the end to simply do it ourselves. I was the only person on the port, and the entire process, including the closed beta took six weeks. I have no serious experience with Linux beyond being an end-user in the labs back in grad-school.
So, with all this as preamble, we’ll get on to the meat of my experiences with Linux in tomorrow’s post! Stay tuned…