We strove for smoothness in our visual design; the slow pulsing glow in the motes, the hypnotic drifting particles inside your player that slowly tumble out into the Blobiverse, the growing and decaying starfield in the background, and gentle visual transitions between scenes. We were careful too with audio. There’s no game event that can cause the music to suddenly stop with a crash like a drunkard stumbling into the record player at a party. We chose an ambient soundtrack without a dominant beat, so that the player doesn’t unintentionally speed up the Mote in response to the music. And to keep the music a part of the background noise of the Blobiverse, rather than just a soundtrack playing along with the game, we had to change the speed of the music when the player changes the simulation speed of the Blobiverse.

Bringing this artistic vision to the iPhone was a tough technical challenge. The phone is powered by a tiny lithium-ion battery about half the size of my thumb, and to make good use of this minuscule power source, the computing and graphics power of the phone are kept low. If either the CPU (computing power for physics simulations, gameplay, sound, and user input) or the GPU (graphics power for drawing the scene) hit their limit, the animation starts to get choppy, like a pot-holed highway in New Jersey. And so began a long two-pronged process of code optimization.

Seeing other iPhone games that have complex worlds full of people, buildings, cars, and guns you may wonder why it would be difficult to animate our 2D retro-style arcade game. The performance secret for a 3D game is walls. The player can’t see through walls, so once a portion of the screen is taken up by a barrier, the computer can just ignore everything that exists behind it. In contrast, everything in Osmos is translucent, giving the soft, glowing, jellyfish atmosphere to the game, and so the computer has to draw everything within the player’s field of view every frame.

After a few months of work, we were starting to be satisfied with the game’s performance on the iPhone, when Apple announced the iPad. We knew this large touch-screen computer would be the perfect device for Osmos. Being lowly Canadians, we couldn’t get our hands on an actual iPad till many months after the U.S. release. In the meantime, we developed Osmos using Apple’s excellent simulator software, but we didn’t know how the performance of the iPad would compare to the iPhone until we could actually run the game on the device. The 2nd generation iPhone had been GPU limited, the 3rd generation had been CPU limited, but we hoped that the iPad wouldn’t be limited at all. But we knew we wouldn’t get a free ride once several developers noted that the GPU on the iPad was somewhat underpowered.

The area of the iPad screen is 8 times larger than that of the iPhone, while the number of pixels on the screen is just 5 times larger. I now need to take a brief aside to laugh at the marketing term HD. HD stands for high-definition, which most people would interpret to mean high-detail, fineness, or in computer terms, pixels per square inch. The iPad has only 5/8ths as many pixels per square inch as the 3G iPhone, which means that all those iPad games that distinguish themselves from the iPhone version with the name HD, are actually lower definition than the iPhone. The iPad has even lower definition when compared to the high resolution 4G iPhone, with the iPad having 1/5 the pixel density. Of course, pixel density isn’t everything, and the iPad is a joy simply because the screen is larger. And I will now guiltily confess that when you install Osmos for iPad, Hemisphere Games also shows the name of the game as Osmos HD. But mom, Billy was playing with the chainsaws first.

Marketing silliness aside, the fact remains that the iPad has to process 5x as many pixels as the iPhone. Our tests indicated that the iPad graphics card was only 3x as fast as the iPhone. So once again, we had to put on our thinking hats, and see what last corners of Osmos we could optimize. The Apple documentation let us know that overlapping transparency is hard on the graphics chip and encouraged us to create opaque, easy to draw worlds, but we really wanted to keep the soft glow of Osmos. Still, it was time to make some concessions for the mobile platform, so we turned on our debugging tools to see what graphical element in Osmos was causing the most overlap. In the following debugging screenshot, black areas of the screen contain nothing at all (easiest on the GPU) dark green areas have lots of overlap (tough on the GPU), and the light green areas have 1 or 2 overlapping elements, perfect for creating that soft glow.

Debug view of overlapping stars.

All that empty space was weighing down the GPU.

It was quickly apparent that our background star field was using up all the graphics power. In the PC version, the stars are created randomly at varying sizes to try and cover the background space of the Blobiverse. For the mobile versions we generated a grid and tried to distribute the stars evenly, while being careful that the visual effect didn’t look like a grid. The resulting stars look a bit flatter than the PC version, which had us disappointed for a while, until we regained some perspective and remembered that we were trying to run Osmos on a phone. The new stars made Osmos run twice as fast, which was a very exciting optimization.

Intelligent distribution causes far less overlap than random placement.

The new starfield looks remarkably similar to the old one and runs at twice the speed.

Why did Apple, with the physical space and much larger battery reserves of the iPad, use an underpowered graphics chip? Well, the cynic in me suspects that they want you to buy another iPad when they release the next generation and describe the graphics card as being x-times faster. But given how important a successful launch of a tablet computer needed to be in an unproven market, I suspect the true answer reason is heat. A powerful graphics processor uses a lot power, generating a lot of heat, creating much discomfort in your lap.

In the end, we were very pleased with the buttery smoothness we could drag out of miniaturized low power devices. There’s still a few tiny hiccups and jerks that our OCD personalities would love to see disappear, but perhaps we’ll have to wait for the next generation of high technology to emerge from Apple.

If you’re interested in all the juicy details about Osmos on the iPhone, visit this page. Or, if you trust us implicitly, (as you should ,) click the App Store image below and buy this glorious piece of iPhone gaming goodness for just $2.99 (in the US); and then, write a review on the App Store (or “promote” others’ reviews), and tell your iPhone gaming friends.

Once again, we’d like to thank and congratulate the man behind the port, Aaron Barsky. He’s done an amazing job, as we think you’ll agree. We’d also like to thank our friends, family and awesome beta testers who helped us get here.

Well, now that all iOS devices are covered, (updates aside of course,) we plan on writing a few “post-mortem” posts about our experiences in iOS-land and the App Store. Hopefully they’ll both amuse and be useful/interesting for other devs and curious fans. Here are some of our planned topics:

• iPad vs. iPhone development and optimization.
• “The Russian!”
• Why Osmos is not a Universal app. (It’s not just because we’re greedy.)
• Adventures in iTunes Connect.

So check back in this space soon for more…

Thanks, and happy Osmoting!

The #1 question we get asked is “how will Osmos look and play on the iPhone’s small screen, especially with my fat fingers?” The answer: very nicely! Check out this video to see it in action.

We’ve put a lot of work into this version (in fact the iPad “inherited” a lot of that work), and we hope you’ll enjoy it! For more information on features, the trailer, and awesome reviews of the iPad version, check out the Osmos for iPad page.

What? A “walk through?” Yes. We see Osmos as an arcade game — not a puzzle game, where giving away “the answer” can rob players of the satisfaction of discovering the solution for themselves. Here, it’s more about your understanding and skills; and as you improve, we believe your enjoyment of the game will also increase. We really want people to be able to finish the Odyssey (which we see as an introduction to the various level types) and spend their time enjoying and building skills at their own speed in Arcade mode.

So, without further ado, here it is.

Pardon the “2001, A Space Odyssey” inspired, over-the-topness; the shape of the iPad, Osmos Attractors, the new Odyssey game mode… we’re just feeling a little epic. Can’t you just hear Thus Spake Zarathustra playing in the background?	If you’re interested in all the juicy details about this unique version of Osmos, just visit this page. Or, if you have an iPad and trust us implicitly, (as you should ,) click the App Store image below and buy this glorious piece of iPad gaming goodness for just $4.99; and then, write a review on the App Store and tell all your friends.

We’d also like to thank and congratulate the man behind the port, Aaron Barsky. You may remember him from such blog posts as Mac Osmos and the sordid Confessions of an Indie Game Developer. He’s done an amazing job, as we think you’ll agree.

Finally, a big thank you to our friends, family and awesome beta testers who helped us get here.

Happy Osmoting!

As I mentioned in a previous post, we learned a lot from the development - and feedback! - from the PC/Mac/Linux versions of Osmos, and have reworked the “i” Versions from the ground up: new game structure, sweet multitouch controls, more levels, difficulty curve smoothed out, new menus, everything tweaked for the screen size and processing power of the device, etc. We’re very happy with the results, and friends who are familiar with the game are saying this may be the “definitive version” of Osmos!

Here’s the original Osmos trailer, which is still totally relevant to the new version (it contains all the levels seen in the video)

And here’s a little hands-on sneak-peak of Osmos HD on the iPad

The iPhone version will come roughly a month after the iPad version, but the latter was so strong we decided to focus on it first. So for those of you with an iPad, mark July 8th on your gaming calender. We think you’ll be pleased!

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!

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!

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

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