Unigine Announces Its OilRush Game For Linux

[kayosiii]

Not every title uses SDL for sound, for example. Some use FMOD (Cortex Command right at the moment...). Some use Miles (NWN...). Some could use IrrKlang (Caster uses it on Windows, but uses other solutions to be better portable on the Linux side since IrrKlang's only X86 Linux...) and so forth.

Unigine for the record uses OpenAL

[Svartalf]

It's just communication difficulties really, much more than any actual technical difficulties, that's what makes the whole situation SO PAINFUL. You should be able to easily query to see if a user has a particular library dependency installed. Universal package management query GO = yes or no. If no, use the one packaged with your installer or have URLs and other mechanisms to help the user download those needed libraries quickly and easily. That's it. It's NOT a hard issue, it just requires some collaboration to come up with the interface. I thought for a while that http://www.packagekit.org/ was meant to answer this issue, a way to query the distro no matter what the distro is in a standardised way, but it doesn't quite look like it. I think this is what I'm talking about here, the successor to the Linux Foundation's Burgdorf API: http://gitorious.org/libpsys/pages/Home, though I don't know if this API allows querying for existing libraries or not but at least is solves the problem with hooking into the user's software management interface as well as properly "installing" (and adding menu links) software.

This, unfortunately presumes a raftload of things, really, that you can't presume or enforce.

Not every title uses SDL for sound, for example. Some use FMOD (Cortex Command right at the moment...). Some use Miles (NWN...). Some could use IrrKlang (Caster uses it on Windows, but uses other solutions to be better portable on the Linux side since IrrKlang's only X86 Linux...) and so forth.

You can't presume that you'll have SDL_mixer along with SDL_sound, etc. as they're not in all distributions. Seriously.

Your scheme makes it VERY complicated for a vendor to keep up with things. And this doesn't even get into issues of libc API version edges, API edges of the varying libraries, bugs you might trip over using within minor sub-versions (i.e Fedora uses 1.2.foo and Ubuntu/Debian use 1.2.bar- and there's a bug you trip over with 1.2.foo...)

Your answer only works for stuff that properly fits within the distributions fully. More to the point, the way I've mentioned works FINE for all distributions- and my installers do put a link in the menus...so, really, except for a bit of extra space I'm ensuring it works and otherwise doing everything else right.

I AM toying with the idea of trying to be a little more intelligent about the installation and seeing if I really need to keep some of the .so's around if they've got "safe" versions of things on the system- but I don't know how complex that'll get and whether it's honestly worth the effort on that one.

[Yfrwlf]

It's not likely to be an issue as the per application libraries are very small compared to the size of the game asset files (models/textures/etc).

If the dev kit is anything to go by it will be something you can just extract to a folder in your home directory and run similar to the way that Blender works if you download the packages from Blender.org. The only way I see that changing is if the publisher requires DRM.

Unigine is the only company that I know with a game dev kit where all the tools run under Linux. Other companies using this engine will find it super easy to make Linux versions of their games - Funding this game will give Unigine the resources to put into developing their engine to make it attractive to other game developers.

Several games on Windows are now requiring you to install Microsoft C++ dev kits and whatnot to get those libraries installed that the game needs. The libraries a program needs should always be available along with the main program for installation if you need them. You need the freedom to run your program even if you have versions of the same libraries installed which are incompatible. Your programs should never expire just because you change distros and/or distro versions, as this would remove your freedom to run your program and you could call it a form of DRM. Sure, this is often not an issue for open source programs, unless they stagnate which is very possible, but regardless this is a freedom you should always have. If a program, say, REQUIRES Ubuntu 6.06 and NOTHING ELSE, even if it were open source, if you can't compile it or you don't know how to compile or whatever reasons, you are so hosed if you are a normal Linux user. If it's close source then you're just totally screwed. Good luck installing Ubuntu 6.06 on a brand new computer. Just an example, don't read too much into it or you're missing the point.

People don't seem to be yelling much at iD, Bioware, Epic (Well, at least over UT99/UT2k3/UT2k4- UT3's a completely different story... ), LGP, Elecorn, and others over it...

It's a common thing within the game industry to do this sort of thing- it provides a pre-rolled set of binaries so you don't have to expect things being fully installed for the game to work and it's easy enough to fix/replace the .so's provided. Now, I use RPATH specifications, which works cleaner than LD_PRELOAD or LD_LIBRARY_PATH does and doesn't require special launcher scripts if that's the only magic you need.

Yeah, it wastes disk space- but you can't presume that a user is going to have any of the .so's you're needing installed on their system. Most people want their game to largely work out of box; and since you're not participating in the packaging systems (I looked into that- if you're going to do it right, you're going to have to specify dependencies, etc. which may/may not be available to you for a given distribution (Like linked against libpng 1.2 versus 1.4 (you have to pick one...) and distributions like Arch have moved on to 1.4- and dropped 1.2 completely, which means you're busted if you pick one and DON'T provide a version for the users somehow...)

It's just communication difficulties really, much more than any actual technical difficulties, that's what makes the whole situation SO PAINFUL. You should be able to easily query to see if a user has a particular library dependency installed. Universal package management query GO = yes or no. If no, use the one packaged with your installer or have URLs and other mechanisms to help the user download those needed libraries quickly and easily. That's it. It's NOT a hard issue, it just requires some collaboration to come up with the interface. I thought for a while that http://www.packagekit.org/ was meant to answer this issue, a way to query the distro no matter what the distro is in a standardised way, but it doesn't quite look like it. I think this is what I'm talking about here, the successor to the Linux Foundation's Burgdorf API: http://gitorious.org/libpsys/pages/Home, though I don't know if this API allows querying for existing libraries or not but at least is solves the problem with hooking into the user's software management interface as well as properly "installing" (and adding menu links) software.

Yes, that's technically possible, I know. It just seems to be pretty much against the ideology on GNU/Linux platforms and would likely lead into quite a bit of yelling if someone actually tried shipping per-application libraries. As I said, in OSX that's an every-day thing, Linux people aren't used to that. (and there's a good reason for why it's not done: it wastes hard disk space)

That's why it would be cool if the installer queried the package manager to find out if such and such libraries were already installed and compatible, and if not THEN install them. The point though is to install them IF NEEDED, and to get the program running no matter what because users shouldn't have to ever deal with a broken program that they are wanting to run. But seriously, space issues are really not a big deal any more. When tarabyte drives are the norm, you're pretty safe, but still, it just takes a simple query to solve that issue. The problem is in implementing a standard API for doing such a query and implementing it in the major package managers, something which should be an important project and Linux users should really help to push for if they want easily installable software, like games, to reach the Linux platform. That REQUIRES happy Linux users and attractive, easy-to-use Linux desktops.

Oh year of the Linux desktop, how I long for thee.

[kayosiii]

Yes, that's technically possible, I know. It just seems to be pretty much against the ideology on GNU/Linux platforms and would likely lead into quite a bit of yelling if someone actually tried shipping per-application libraries. As I said, in OSX that's an every-day thing, Linux people aren't used to that. (and there's a good reason for why it's not done: it wastes hard disk space)

It's not likely to be an issue as the per application libraries are very small compared to the size of the game asset files (models/textures/etc).

If the dev kit is anything to go by it will be something you can just extract to a folder in your home directory and run similar to the way that Blender works if you download the packages from Blender.org. The only way I see that changing is if the publisher requires DRM.

Unigine is the only company that I know with a game dev kit where all the tools run under Linux. Other companies using this engine will find it super easy to make Linux versions of their games - Funding this game will give Unigine the resources to put into developing their engine to make it attractive to other game developers.

[snuwoods]

definitely, at that price, I think the support will be there.

[Svartalf]

In case anyone else was interested in the price:

From http://twitter.com/oilrush_game/status/24446011782 (through Google Translate).

Well, then... That just sweetens the pot a bit.

[whizse]

In case anyone else was interested in the price:

so far the matter has not been solved yet, depends on the distribution partners. Approximately no more than $ 20.

From http://twitter.com/oilrush_game/status/24446011782 (through Google Translate).

[Svartalf]

Okay, that's simply you not reading my post at all. Steam doesn't solve these packaging worries, just moves them to Valve/game developer instead of distros. There.

Not even that much... It doesn't solve anything other than deployment, community systems, and DRM (if you're into that sort of idiocy...). Packaging in the sense of what get's sent, etc. is still solidly in the lap of the developer- either you provide all the binaries that might be needed past the stuff for X11, OpenGL, and libc, or you provide packaging with all the main packaging systems (Okay, that'd be RPM, DEB, OPK, and what else??) with dependency hints so that when you install the package it forces the install of what you HOPE might work for your title.

It's neither Valve's or the distribution maintainer's issue with your stuff unless they're the ones doing all the work. (Though I will say, Kano's permanently on my beta testing list as long as he wants to be- he's been very helpful with a few fit-n-finish items and it's nice having a distribution contributor to work with for a change...)

[Svartalf]

Thats why were in need of a distribution system like steam. Packaging worries are less, more patches(sometimes so much that it annoys the user). If there should be one request to Unigine then it should be abandoning DRM.

If you believe that Steam will fix your packaging woes, I've got some nice sea-side property on the Florida coast to sell you- or better yet, a bridge to sell you.

Even if they provide packaging, that's just deployment- you're still going to need to know which binaries to require within the local system's loadout or provide your own answers in a directory as part of the packaging, much like they do now with most Linux games that're not part of the distribution's repo.

[Svartalf]

Yes, that's technically possible, I know. It just seems to be pretty much against the ideology on GNU/Linux platforms and would likely lead into quite a bit of yelling if someone actually tried shipping per-application libraries. As I said, in OSX that's an every-day thing, Linux people aren't used to that. (and there's a good reason for why it's not done: it wastes hard disk space)

People don't seem to be yelling much at iD, Bioware, Epic (Well, at least over UT99/UT2k3/UT2k4- UT3's a completely different story... ), LGP, Elecorn, and others over it...

It's a common thing within the game industry to do this sort of thing- it provides a pre-rolled set of binaries so you don't have to expect things being fully installed for the game to work and it's easy enough to fix/replace the .so's provided. Now, I use RPATH specifications, which works cleaner than LD_PRELOAD or LD_LIBRARY_PATH does and doesn't require special launcher scripts if that's the only magic you need.

Yeah, it wastes disk space- but you can't presume that a user is going to have any of the .so's you're needing installed on their system. Most people want their game to largely work out of box; and since you're not participating in the packaging systems (I looked into that- if you're going to do it right, you're going to have to specify dependencies, etc. which may/may not be available to you for a given distribution (Like linked against libpng 1.2 versus 1.4 (you have to pick one...) and distributions like Arch have moved on to 1.4- and dropped 1.2 completely, which means you're busted if you pick one and DON'T provide a version for the users somehow...)