A little over a month ago we released the Linux port of Osmos, promising statistics on our sales and downloads. We wanted to find out – from a financial perspective, for our studio – “is it worth porting games to Linux?”

The short, simple answer… is “yes.”

Did we get rich off it? No. But the time we invested was repaid, with room for margin of error, and possibly with a little extra at the end. Allow me to break it down:

Costs

It took Dave six weeks to do the port, including time spent testing across multiple flavours of Linux, and running the beta from start to end. Personally, I’m really impressed with what a solid job he did, and how quickly he did it. I doubt an experienced Linux programmer could have done it much faster, especially since Dave was already intimately familiar with the codebase. In fact, it’s hard to imagine porting any game to Linux much more quickly. (Excluding games built in Flash and engines that already support it of course.) The code was engineered to be cross-platform from the start, built on libraries like OpenGL, OpenAL, libogg/libvorbis, freetype, etc. In addition, Aaron had already done a great job on the Mac port, ironing out any remaining gcc/abstraction details. All this to say that Osmos was primed and ready for Linux-porting, and all work done on that front was specific to Linux.

We spent an additional week or two on miscellaneous tasks, including some additions to our e-commerce/delivery system, support, community, PR time, etc.

So… let’s call it an even 2 man-months across the board for our studio. A big question is, what’s a man-month worth? All I can say is, if your answer is the industry consulting standard of $10k/month — you’ve way overbid, and put the Linux port of Osmos into the financial-loss category. However, as independent developers with a passion for what we do, our goals and desires are considerably lower than that (i.e. less than half).

Revenue

Unfortunately, this isn’t so simple for us to measure. We’re selling Osmos under a pay-once-for-all-platforms philosophy — for $10 you get the Windows, Mac and Linux versions. So the numbers are fuzzy. What we can determine though, is how many times each person downloaded each version. We can also look at our sales graph over time, where there is a clear and obvious spike associated with the release on each platform.

Sales per day. (Pardon the ugly graph. Also note that the regions are very roughly drawn,
and do not reflect exactly how numbers were estimated.)

On first glance, one very cool stat emerges: our best sales day ever (by 29%) was right after the Linux release, similar to what 2dboy experienced with World of Goo. That said, the spike is also somewhat narrower than what it was for the Windows or Mac releases. In any case, if we measure the area above the “background noise” for the Linux release (based on the previous month’s sales), this gives us a conservative lower bound on sales. I say lower bound for several reasons. 1) As many Linux folk have pointed out, some purchased Osmos prior to the Linux release in support of our studio and on the promise that we would deliver the port. 2) There may still be some Linux mini-spikes to come, and future “background noise” will of course include Linux customers. That said, based solely on these numbers, Linux accounts for roughly 15% of our sales to date.

We can also determine an upper bound based on client downloads. Here we see that 21% of all our customers have at least clicked on the Linux download link. You may notice that the percentages add up to more than 100; this is because customers can download on multiple platforms. In any case, it’s safe to call this an optimistic upper bound, as I know for a fact that some customers click on every download link just to test it out. Also, it’s impossible to know if some of those people would have made the purchase based solely on the Linux version.

So as a bottom line, Linux accounts for between 15% and 21% of our sales, with the “real” number being somewhere in between.

Profit

When we say “yes, it was worth porting Osmos to Linux”, we’re basing it on the lower bound. If the reality is closer to the upper bound: that’s “gravy”. The tail: more gravy. (Though it does cost us time and money to support and maintain the site).

It’s also important to note that this analysis applies only to sales from the Hemisphere Games website. The majority of Osmos sales come from portals — in particular, Steam. (Steam’s recent addition of Mac support has had a huge effect on our Mac numbers.) If we were to include portals in this analysis, the percentages would look very different. So in the bigger picture, the lack of a strong Linux portal makes it a much less “competitive” OS for commercial development. Of course, if Steam or another successful digital distribution portal decides to support Linux, that’d be major! Like… extra gravy. With stuffing. Mmmmm… stuffing…

A few more stats…

As any Linux user or developer knows, there’s more than one way to skin a distribution on Linux. Dave created four different packages: .deb, .tar.gz, a 32-bit .rpm, and a 64-bit .rpm. Here are download stats by distro. So .deb is more in demand than all other packages combined, while the 32- and 64-bit flavours of .rpm are rather low. A question I have for the Linux community is: could we have skipped the .rpm packages? That is – to be completely materialistic about it – how many sales would we have lost as a result? (Just curious…)

Another point of interest for us was referring web traffic, and we were surprised to see where much of it came from. Here are the sites that generated the most traffic for the Linux port:

1. linux.org.ru
2. linuxgames.com
3. habrahabr.ru
4. hup.hu
5. planet.ubuntuusers.de
6. linuxtoday.com
7. happypenguin.org
8. root.cz
9. linuxlock.blogspot.com
10. planet.ubuntu.com
11. linuxfr.org
12. linux-gamers.net
13. linuxjuegos.com
14. and a special mention goes out to Liam Dawe of gamingonlinux.info, who helped spread the word to a number of those sites!

While we expected/hoped to see traffic from sites like linuxgames and happypenguin, we were very surprised to see the amount of interest from Russia and Eastern Europe. Apparently Linux gaming is alive and strong in that part of the world!

“I am not a number — I’m a free (as in speech) man!”

People are interested in numbers, and we’ve provided them, but that’s just one dimension of the story. As independent developers, there are other more altruistic factors that are important to us.

Before I go on, I must admit that I’m spoiled. Dave did all the hard work on this port, and all I did was some website work: extending our digital delivery system, etc. So I’ve experienced nothing but the happy glow of the release, and from my perspective the Linux community has been awesome and generous. We’ve received a heap of positive and encouraging feedback, which is always nice to hear. Support emails for Linux are night-and-day-different from Windows or Mac — they include the log, version numbers, stack info, troubleshooting schemes already attempted, etc. Sometimes they even include the solution to the problem — just letting us know. And Linux users are vocal — there have been some amazing people in the community that have helped spread the word. We simply could not have done this ourselves; we wouldn’t have known half the places to approach, and even if we had we would have come across as fish-out-of-water. So once again, thank you.

That’s it for now on sales. We’ll probably follow up with some additional stats on the Linux tail in a month or two; but in the meantime, if you have any questions or comments, fire away!

For the lucky folks out there with an iPad, we’ll skip the foreplay and jump straight to the gist: the beta is starting and we’re looking for players (both new and old) to test it out! If you’re interested, send us an email at webmaster@[this domain].com.

Some of you may be thinking “What, no iPhone version?” Not to worry, it’s coming. Here’s the scoop:

About six months ago, Aaron – who had just finished a great job on the Mac port – began work on the iPhone version of Osmos. To be honest, we weren’t sure it would “fit”. Would the iPhone be powerful enough to simulate and render everything? How would Osmos feel and play with multitouch controls? Would it be fun and playable on “such a small screen”? Aaron decided to jump in and find out.

Over the next couple of months, he confronted and solved all the technical problems: new Objective-C core and wrappers, check; conversion to OpenGL ES, check; sound (streaming, pitch shifting, etc.), check; multitouch controls, check! We knew there was still redesign work ahead, but our initial impressions were really positive: yes, Osmos would work very nicely on the iPhone.

And then a funny thing happened. Apple’s rumoured new tablet became a reality — and it was hot. We decided to get one, but unfortunately they were so hot we couldn’t get our hands on one for months! So we continued with the iPhone redesign: new game structure, new menus, more levels, difficulty curve smoothed out, everything tweaked for the screen size and processing power of the device. It was a lot of work, but everything was falling beautifully into place. A few weeks ago, we were 95% done — and very happy with the results.

That’s when we got our iPad. (Finally, on the international release. Oh, Canada.) Aaron had been preparing for it on the simulator, and it only took him a few hours to get Osmos up and running on the device. There were issues at first (more on that in another post), but overall: wow! We were really excited and impressed. At that moment we knew we had to release the iPad version first — kind of like when Butch Coolidge (the character played by Bruce Willis in Pulp Fiction), chainsaw in hand, sees the katana. An obvious choice.

So, while we promise to release the iPhone version of Osmos (which still rocks!) soon — up next: iPad! Get’cher beta!

Welcome to the second installment of our three-part Linux post-mortem. Part 1 lay the foundations for the article and where we’re coming from. Today’s post directly addresses the question “What worked and what didn’t?” with a set of ‘pros and cons’ that cropped up during the port. The final post will offer a more nuanced set of reflections on these experiences, their implications for game development, and my advice for moving Linux forward as a gaming platform.

Porting Osmos to Linux: What I Loved

Let’s start with an account of the stuff that stands out as having worked really well — things that were well designed, pleasant to use, and easy to learn.

Love: Live discs and bootable USBs

Being able to boot into an OS from USB without having to first install to the HD is fab, and the various Linux distros have for the most part done a good job of supporting this behaviour. During development, live discs were helpful in two main ways. Firstly, when I was starting out, they made it easy for me to poke around and find a distro to use as my ‘core’ Linux install (i.e. the install on which to do the bulk of my Linux development; I settled for Ubuntu 9.04). Secondly, live discs made it easier to do quick first-blush tests of cross-distro/DE/WM compatibility for my executables and packages without having to first fully install and configure every OS.

One wish for the live discs would be for the OS versions they contain to have more robust HW drivers, particularly for video. I realize drivers are a tricky issue in Linux and hard to support generically out-of-the-box, especially on a live OS (where, for example, rebooting to install a better driver isn’t in the cards), but for game development it would be great to have decent video performance when booting from a live disc.

Love: Code::Blocks

I was looking for a simple, light-weight, easy-to-use C++ IDE that was easy to find in binary form for several distributions (I didn’t want to have to compile an IDE myself) and that had some kind of interface sitting on top of gdb. Code::Blocks was the answer. It wasn’t bug free, mind you, and crashed on me once or twice per day (at times to great frustration because of state loss… but nothing reliably reproducable, I’m afraid, hence no bug reports filed). But, critically, it provided a simple project system, a simple-yet-powerful set of compiler/linker options, the essential find/error/debug/bookmark interactions, and a basic gdb front-end. Essentially everything I needed was there, it was simple to use, and it was available and (relatively) stable cross-distro.

Love: The Linux Package Manager

Linux’s package system may not have been easy-breezy to support (more on this below), but it sure was easy-breezy to use. It was straightforward to find the developer libs/headers I needed and get them automatically installed into the right places. It was fantastic that dependencies are automatically tracked and installed, and that headers/libs install to central and standard places for trivial inclusion/linkage into the project.

Two footnotes: firstly, this smoothness of experience was conditioned in part by the legwork that went into ensuring Osmos relied only on the most core of libs (libs/packages that ought to play nice and be easily found on any distro; GL/GLX, X11, FreeType, OpenAL, libogg/libvorbis, etc). Secondly, a couple of the enterprise-oriented distros seemed to require a prohibitive amount of leg-work to configure for engineering purposes; this makes sense if the distro is targeted towards the consumer/office end of the market spectrum rather than the engineer, but for someone new to development on Linux, it’s painful if you don’t do your homework ahead of time.

Love: Support from the Linux Community and our Beta-Testers

It’s great to see how keen Linux users are to help support software on Linux. The average Linux user is on-the-ball and really encouraging in terms of their enthusiasm for Linux and their appreciation of our efforts to get Osmos on Linux. Post-launch, we’ve been getting great feedback and PR support from a few key folks in particular.

When the Linux port went into beta I issued a public call for testers and recruited about 50 people. Each one was top-notch in terms of being observant while playing the game. They were all helpful with their detective work, and the average level of technical savy-ness was very high when it came to sniffing out audio and WM/X issues for repro. Folks were keen to try the game on as many machine specs as they could, and were keen to volunteer information and “run with” the testing on their own. All this resulted in a very short beta period (less than two weeks) in which a lot of solid testing occurred very quickly, and with only a single patch being required to hammer out all known issues.

Love: Cross-Platform Compatibility is Good for your Code

While not a Linux-specific observation, there’s no doubt that developing multiplatform software is always beneficial for the code. Each platform has different analysis tools, compilers that issue different warnings and generate different code, and video drivers with different behaviour; all of these serve to highlight any underlying issues in your project, and so the work invested on one platform has benefits for the other platforms too. For the sake quality and stability, cross-platform compatibility has been a good thing for Osmos.

What I Didn’t Love

Let’s move on to the stuff that was less easy to love; things that stood out as being frustrating, difficult to use, and in some cases broken.

Didn’t Love: Supporting multiple Distros/DEs/WMs/drivers/etc.

The #1 obstacle to getting more games on Linux is that it’s very difficult to get your game working correctly and acceptably on all machines. It’s really hard to guarantee a smooth experience for all players when there’s a combinatorial explosion of possible distributions, desktop environments, window managers, driver/hardware versions — each with their own unique foibles, bugs, and undocumented behaviours. It’s the classic PC gaming problem, but magnified. Linux loves freedom and choice, which I applaud — but some amount of standardization, collaboration and “Let’s work together”-ness is required for the platform to be friendly to application developers.

Didn’t Love: Audio

Brace yourselves, folks, because I’m going to put it bluntly: audio in Linux is a mess. The audio situation is another major obstacle to game development on Linux. It’s 2010; audio is a solved problem. And yet on Linux, it’s shocking that you cannot count on something as simple as non-streaming playback, never mind any kind of processing (which most games are wont to do!) There are a variety of standards (ALSA, OSS, PulseAudio, Phonon, …) — which one to choose? Each standard has different problems on different machines. For a given standard, some drivers are buggy and poorly configured by default, while others do horrible thinks like block on open when another process opened the device. This is all another way of saying that there are no audio standards. What is a developer to do?

“But doesn’t OpenAL hide all the mess behind a single stable API? Ideally you’d write the audio code once in OpenAL and then walk away.” This isn’t how it happens in practice, because the fact of the matter is that the mess is still there. Simply wrapping another software layer around the underlying problem doesn’t make it go away. Using OpenAL for audio doesn’t all-of-a-sudden mean I can count on anything runtime-behavior-wise. I write my code in OpenAL (rather than having to write directly in ALSA, PulseAudio, etc), but at runtime I still need to make choices — for example, by saying which underlying audio layer I want to use — and different people’s machine/lib/driver combos will do different things. Simply using the local machine’s default audio device doesn’t guarantee anything about what’s going to work and what doesn’t, and a game needs guarantees in order to work correctly. The audio situation is quite horrible I’m afraid.

Didn’t Love: Lack of Documentation and Consensus

In the Linux world there is so much choice and non-standardization, and it’s really hard to find out about things. Documentation is sorely lacking, and it’s hard to find solutions because when a question is asked, people don’t agree on the answer. Forum threads aren’t a good substitute for proper documentation, because forum threads can quickly become historical and fall out of date, meaning folks looking for answers spend a lot of time chasing down false-leads and asking themselves “Is this forum thread relevant to me? Is it really what I’m looking for?” In the Linux world, it seems to take a great deal of detective work and reverse engineering to get things done; the plethora of choice means that the newcomer is never certain about their choices — and there will always be someone who disagrees with you (often vocally).

Didn’t Love: Drivers and Hardware Support

My main development machines are two off-the-shelf laptops with mainstream components, and neither of them had WiFi or video that worked out-of-the-box on any distribution I installed. It took many hours to get decent hardware performance. Proprietary drivers, open source drivers… which do I chose? Do I really have to compile a driver for myself? What’s more, when a new Linux user inquires about driver problems on a forum, the standard line of defense is to blame the problems on hardware manufacturers. Whether or not the manufacturers deserve blame, the Linux platform folks need to step up, acknowledge the reality of the situation, and try to work to improve the platform. The chipsets that didn’t work for me (without great effort) were nowhere close to bleeding edge (ATI and Intel graphics, Broadcom Wifi; some models dating back to 2007) and all are widely available on a large segment of the consumer-level market. Linux needs better support for its HW; if I can’t walk into BestBuy, pick up a run-of-the-mill laptop and have my video and networking hardware work, then the platform is troubled.

Didn’t Love: Packaging the Game

It took days of effort to create the binary packages for Osmos (I’m happy to say that it’s looking like we don’t have to patch!) How should an app be packaged in Linux? Should I build my own libs and package them with my game, or rely on package dependency info and hope the distros have the right versions in their package repositories? Which package formats do I choose (.deb, .rpm, .tar.gz, others)? Do any of the package formats have naming conventions I need to follow? What do you need to do to support both 32bit and 64bit? What are the standard practices for where/how my game is layed out on the filesystem? What goes where and where do you commonly put softlinks? How do I represent softlinks in the various package systems? Do architecture-specific files belong in special places? Are there any standards for what’s in the environment path? How do I integrate my app into the desktop environment? What DEs are worth supporting? Do I need to do separate things to support separate DEs?

There are no standards or clear answers to any of these questions. There’s no documentation for this stuff! Asking on the forums will typically net you a spectrum of answers with no consensus answer and lots of little side arguments. I basically reverse engineered what I saw other apps doing (which sadly was of little comfort because everyone does it differently). I settled on supporting .deb/.rpm/.tar.gz with explicit 32bit and 64bit executables for both the demo and retail versions of Osmos, with no redistributed libs and instead relying on package dependency info. So far, this has worked out for nearly all distros except CentOS which has an archaic version of libvorbis and nothing new in the standard repositories.

Side-note for those interested: I didn’t venture anywhere near cross-compilation and instead simply built the 32bit and 64bit executables on separate 32bit and 64bit Ubuntu installs (which, interestingly enough, both displayed unique and undocumented WM/Xserver interactions, despite being the same version of Ubuntu!)

Didn’t Love: No OS-level GUI layer for simple dialogs

This is something of a minor point compared to the above, but I want to mention it because it comes up often enough in cross-platform development. Because Linux has no OS-level GUI layer, games that need any kind of UI must link against heavy-weight UI libraries (GTK, QT, etc) which typically impose some kind of application framework. Common examples of the usage of UI in the gaming world would be a dialog that prompts the user for input the first time a game is run (e.g. “Launch in fullscreen?”) or that displays a message when an app terminates unexpectedly. For Osmos, I had to cut such user-friendly elements because I didn’t want the game to have any but the most basic of dependencies.


Whew! Alright: in part 3, I’m going present a more general discussion of the implications of some of these issues for game developers, and reflect on ways to improve matters. Stay tuned…

Dave

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:

1. “These comments are coming from a terrible game designer… If you’re a good developer you get things done”;
2. “id and Epic port their games successfully to Linux, why can’t you?”
3. “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…

Dave

We’re excited to announce that Osmos has been successfully absorbed by Linux, and is now available! Our newly initiated, one-man Linux warrior, Mr David Burke, has done an amazingly quick and solid job on the port, and it’s been running smoothly on a wide variety of Linux distributions and machines. (Big thanks to all our beta testers!)

Check out our FAQ for a list of Linux distributions that Osmos has been confirmed to run on. Or, if you’re unsure, download the free demo (in .deb, .rpm, or .tar.gz form) here. As always, Osmos is DRM-free. In terms of hardware specifications, the game has been tested on all sorts of machines. Dave’s primary laptop is actually a four year-old Core 2 Duo with on-board Intel graphics, and he made sure the game would perform well on low-end machines. For the record, though, here are our “official” minimum Linux requirements: Processor: 1.0 GHz Memory: 512 MB RAM Video card: any hardware supporting OpenGL Sound card: no special hardware required; any driver supporting OpenAL

As for input, the best Osmos experience is to play with a 3-button mouse; but we’ve made sure it plays well with just a trackpad and keyboard for all the laptop folk out there. (Check the in-game control menu for details.)

For those of you who have already purchased Osmos from Hemisphere, the Linux version is already yours — just follow the link in your original purchase email. (We’ll send you all a new one in the next day or two in case you’ve lost it.) And for new players, we’re still offering our $10-deal for all three (PC + Mac + Linux) versions together.

Still to come…

1) Dave plans to write a post-mortem on his experience with doing the Linux port. Expect to hear his thoughts and feelings (and possibly gripes) on the subject in the next week or so.

2) This port is also an experiment for us as a studio. Specifically, is it worth porting games to Linux? We hope the answer is yes, but we’ll find out soon enough. And you will too. We plan to publish statistics on our sales and downloads on all three platforms in about a month’s time.

Thanks, and happy Osmoting!
-The Hemisphere Team

If you had asked us two months ago – or even one month ago – if the Linux port of Osmos would come out before the iPhone or iPad versions (more info on that soon, promise!), we would have said “Not a chance!”

We would have been wrong.

Thanks to the hard work and mad skills of Dave Burke, our newly converted Ubuntu warrior, the Osmos Linux beta has been going really well. All systems look go for launch in two days (i.e. Wednesday, April 28), right here! (Is there a Linux portal out there? There should be!)

As promised, everyone who already purchased the PC or Mac versions from Hemisphere will automatically have access to the Linux version upon release. Moreover, we know that Linux is very much a word-of-mouth community, so we’d really appreciate your help in getting the word out about the game. We’ll be giving out a free copy of the Linux version to everyone that reviews or posts about Osmos on their blog. (Just send us an email with a link to your post.)

Thanks and more soon…

As some of you know, we had been looking for someone to port Osmos to Linux. But in the end, after mulling it over for a while (and a couple nice offers from experienced Linux folk), our very own Dave Burke has decided to tackle the port himself! Who knew he was such a masochist?

Anyways, Dave has reported back that after some initial head-banging on installation and configuration (he’s started with Ubuntu), things are progressing really well. Hooray for cross-platform libraries like OpenGL, OpenAL, libogg/vorbis, etc. and well abstracted code!

He even promised a screen shot a few days ago and — lo and behold! — just delivered:

What’s more, he says he’ll be ready for some external testing by next week! So it looks like the wait is nearly over for all you Linux users.

In the meantime, let us know (by email or on the forum) if you’re interested in early “alpha” testing or participating in the closed beta.