Hemisphere Games Reveals Osmos Linux Sales Numbers 131
An anonymous reader writes "Hemisphere Games analyzes the sales numbers for their Linux port of Osmos and ask themselves, 'Is it worth porting games to Linux?' The short, simple answer is 'yes.' Breakdown and details in the post."
A few other interesting details: the port took them about two man-months of work, the day they released for Linux was their single best sales day ever, and they got a surprising amount of interest from Russia and Eastern Europe. Their data only reflects sales through their website, and they make the point that "the lack of a strong Linux portal makes it a much less 'competitive' OS for commercial development." Hopefully someday the rumored Steam Linux client will help to solve that.
rather impressive (Score:4, Informative)
I don't think linux will become a more profitable platform to target than windows for major game houses in any sort of foreseeable future, but I think that graph [hemispheregames.com] from the article makes a pretty strong case for indie developers to target linux.
Good news for indy developers (who now have a larger potential audience), and of course good news for linux users.
Re:Valve hasn't said a word. (Score:3, Informative)
Yep, here's the article [phoronix.com].
Re:One game? (Score:5, Informative)
> If it took two months to port a puzzle game, imagine how much time and expenses it would take to port a big-name...
One suspects most of that time was learning a new platform. If Linux was a target from the start and the game house had done it before the porting time would be less. To begin a cross platform library like SDL would probably be selected at the start of the project. Porting would then be a minor problem. Even better would be to divide the development team's workstations and develop all targeted platforms in parallel to catch cross platform issues during development. Done that way a wide targeted product should not add more than a couple percent to the development costs.
Another idea. If a game house or group of them developed a common repository the distribution costs could be minimal. This doesn't require their wares be free either. Activation keys/etc could still be used while using repos to eliminate installation problems, distributing updates, etc. Who needs Steam? Better, who needs to cut Steam in for a cut for something Linux has native?
Re:Duh? (Score:4, Informative)
To reinforce the point:
Re:Really good news (Score:3, Informative)
That's not what GP is suggesting (not a machine nor a distro): he's talking about a standard like the LSB [linuxfoundation.org], but for games.
Re:One game? (Score:4, Informative)
One suspects most of that time was learning a new platform. If Linux was a target from the start and the game house had done it before the porting time would be less. To begin a cross platform library like SDL would probably be selected at the start of the project.
Quote TFA:
The code was engineered to be cross-platform from the start, built on libraries like OpenGL, OpenAL, libogg/libvorbis, freetype, etc.
Re:Valve hasn't said a word. (Score:4, Informative)
And something to consider (Score:5, Informative)
What happens if you need something that is NOT cross platform to Linux? You then have to develop an in house version of it. Ok, but that is increasing the cost of development over all, not just for the Linux version.
An example for commercial titles would be Speedtree, Scaleform, or any number of other middleware apps that do not have Linux ports. None of them do anything you couldn't write yourself, however they simplify development thus reducing time thus reducing cost. Scaleform is used to make resolution independent UIs easily and quickly. It gives artists robust tools so that they can design UIs right away. The programmers then can make use of them. This is cheaper than having to have the programmers write not only the UI code for the engine, but then tools for the artists to make the UIs and so on.
So in a complex title you might well find costs of the Windows version going up because the tools you use aren't available for Linux. Saying "Just use something else," or "Just write your own," isn't an answer. The question isn't if it is technically possible to do it, the question is it economical to do it. The amount of expected sales has to exceed the costs by a non-trivial amount.
Re:One game? (Score:3, Informative)
> Quote TFA:
> The code was engineered to be cross-platform from the start, built on libraries like OpenGL, OpenAL, libogg/libvorbis, freetype, etc.
That basic level of avoiding Microsoft only tech makes a port plausible, it doesn't make your code cross platform. I noted the distinct lack of a mention of an explicit cross platform layer such as SDL. The article doesn't say what the original development environment was but I'd put more money on Microsoft Visual Studio than emacs/autoconf/gnu make, etc. Weeks getting a SDL app that builds on Windows to one running on Linux would imply they hit some sort of obscure glitch, the sort they probably would have mentioned.
Valve confirmation on the Telegraph website (Score:4, Informative)
"Valve has also confirmed that it will make Steam available to Linux users in the coming months." - telegraph.co.uk [telegraph.co.uk] (this is on the website of national UK newspaper).
It's not the quote you explicitly sought but I would argue it makes it seem like Valve have said something about a Linux port. Regardless, your overall point that the source of information should be scrutinized definitely holds...
Re:And something to consider (Score:3, Informative)
I Quote ...
"An example for commercial titles would be Speedtree, Scaleform, or any number of other middleware apps that do not have Linux ports. "
http://webcache.googleusercontent.com/search?q=cache:7iB72hLjMmwJ:www.xoreax.com/case_study_scaleform.htm+scaleform+linux&cd=1&hl=en&ct=clnk&gl=uk [googleusercontent.com]
"Because we support all major gaming console systems as well as Windows, Mac OS, and Linux, Scaleform GFx is built across over 80 different configurations. Once built, the configurations must be compressed into zip files or installer executables."
N...