Announcement

Collapse
No announcement yet.

Lessons For Developers In Porting Games To Linux

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by Ancurio View Post
    Because it's pretty massive? (~150MB). The reason it exists in the first place is so Valve can say "heey, remember all those libraries you'd usually have to bundle with your game to make sure it runs? Well here's this gigantic catalog of general purpose libraries that we guarantee you to be installed with steam, so you don't have to ship them".
    Of course, shipping the libs yourself is the default option and what game devs have been doing mostly before Steam. Of course, what they still could do is make sure they develop against the specific library versions defined in the Steam runtime, and then they could check at install time if the runtime is present and not extract their own libraries. (Of course, then you'd still have to deal with the problem of some non-steam games suddenly not running anymore when uninstalling Steam).
    I don't think that's massive at all, as long as you have only one installed copy (which you can, when you know a vast set of games use the exact same version, thus, this runtime that works as a de facto standard version of libraries). Consider the weight of a single mainstream game nowadays, and then compare it to 150MB. And if the problem would be with installing Steam, there's always the option of taking that repo and building packages, so the runtime can be installed by itself. No shipping, and no Steam (if you don't want to install it).

    Comment


    • #47
      mrugiero: I agree, I don't think 150 MB is too massive for a desktop Distro (for a runtime). But in general, I'd be uncomfortable, if any given game will expect the full runtime to be installed to be runnable. It should adapt to the existing system libraries, and install only what's necessary to run. Or preferably to give an option to bundle what's needed with the game itself, without requiring to install the whole runtime.

      Originally posted by kacperpl1 View Post
      Forum behaves quite funny - it has hidden Leszek's message and now it got posted on second page - so i quote it if u didn't notice
      Hope that will clear out some stuff.
      Thanks for pointing this out - I totally missed that reply as well.

      Originally posted by IneQuation View Post
      Hi guys, Leszek here. I didn't expect Phoronix to pick my little talk up, especially after 2 months, but it's nice to be featured.

      Indeed I'm a Debian guy, and all my port development takes place on Debian. I only have an Ubuntu chroot+debootstrap environment for building.

      I don't mean to stir up a flamewar here, but you guys are - quite naturally and I don't blame you for it - looking at things from a consumer's perspective. And judging by some of your posts in this thread, you're quite emotionally engaged in your stance.

      But from a developer's standpoint, you need to deliver a quality product that works reliably on a wide range of systems. Valve allows us to cut some corners in that regard with the Steam Linux Runtime. How can I possibly consider basing my game off of Debian libs if their SDL2 is binary-incompatible with Ubuntu's (sic!)?

      The numbers don't lie - Ubuntu remains the most popular Linux distro. There is no well-established proprietary software distribution mechanism for Linux. That's why aligning with Valve and Steam is a no-brainer to professional gamedevs: we're simply trying to cover the largest market area possible so that we can pay our bills.
      So why would suddenly Ubuntu SDL given some special treatment then if there are already other incompatible versions? Using distro independent SDL would make more sense in such case. While Ubuntu is often positioned as most popular distro - it's quite questionable, and even if it is, it's not the only big distro out there, i.e. it's not a massive majority to completely ignore the needs of others. If by Valve's solution you mean using such portable runtime (open source and DRM free), which other distros can easily provide as well - then it's good (it's also a question how to make using that runtime comfortable for users who don't use Steam). But if you mean simply to aim to develop for Steam, then I don't consider this a good thing to promote for developers.
      Last edited by shmerl; 06-22-2013, 10:38 PM.

      Comment


      • #48
        Originally posted by shmerl View Post
        mrugiero: I agree, I don't think 150 MB is too massive for a desktop Distro (for a runtime). But in general, I'd be uncomfortable, if any given game will expect the full runtime to be installed to be runnable. It should adapt to the existing system libraries, and install only what's necessary to run. Or preferably to give an option to bundle what's needed with the game itself, without requiring to install the whole runtime.
        Well, that's up to the particular game dev. Choosing which to ship (and install if missing) should be fairly easy, since you (I say this by experience) already know what libs your game needs be linked to to run, and you have your install script (or the preferred deployment method) at hand, you could easily comment out everything but what you really need. Installing pieces of the runtime by itself sounds harder, though. Not too hard for someone experienced in the subject, probably, but I have no real knowledge in that area.
        Someone said Steam already checks if system's libraries are already the version needed and skips installation, so it should be doable. A really reliable solution might need further changes in package managers (make them expose the ABI version in the package version in a standardized way, which I have no idea if is currently happening).

        Originally posted by shmerl View Post
        If by Valve's solution you mean using such portable runtime (open source and DRM free), which other distros can easily provide as well - then it's good (it's also a question how to make using that runtime comfortable for users who don't use Steam). But if you mean simply to aim to develop for Steam, then I don't consider this a good thing to promote for developers.
        As I already pointed out, the article is about porting games. This means the choice of using or not DRM was already taken, because the game was already implemented. This makes the whole promotion or detraction of DRM in the talk irrelevant to the subject.
        Also, the incompatibility pointed out is the binary one. This means that as long as you use the runtime provided, your game will run. It won't if you use system's libraries.

        EDIT: About the special treatment, from a dev POV you could take into account that an easier install means an easier setup of a VM to test your software, if it's not your main OS.
        Last edited by mrugiero; 06-22-2013, 10:55 PM.

        Comment


        • #49
          I think writing new games is not less important case than porting existing ones. So both need to be addressed really. And DRM aspect is more critical in the case when developers don't specifically need it, but aim Steam out of whatever perception like "all gamers use it" or what not.

          Comment


          • #50
            Originally posted by shmerl View Post
            I think writing new games is not less important case than porting existing ones. So both need to be addressed really. And DRM aspect is more critical in the case when developers don't specifically need it, but aim Steam out of whatever perception like "all gamers use it" or what not.
            Certainly, but considering Windows is still the main platform for mainstream computer games, what you should address is writing portable games, which I'm sure is already addressed in most cases because of Mac, and then giving this portable games the specific support for Linux, which is covered by the article.
            Also, for writing new games most of this guidelines are quite valid, too, just more lax. And you can follow the advices given by squirri instead. But the article and the talk is targeted to mainstream publishers wanting to port their current titles, and I think the discussion about writing them from scratch would better fit a new thread on the subject.

            Comment


            • #51
              Originally posted by GreatEmerald View Post
              Actually, The Witcher is *made* by GOG Or, more accurately, GOG is a subsidiary of CD Projekt RED.
              Formally, GOG is a subsidiary of CD Projekt, so it's a sister company of CD Projekt Red, but essentially they are all closely related. Situation with CD Projekt Red and their games is interesting. When they produced the Mac OSX version of the Witcher 2 they added OpenGL support to their RED engine. And considering that they plan to release Witcher 3 for PlayStation 4 (which ships with OpenGL), most probably their current RED engine also works with OpenGL. I asked them on several occasions what their plans are regarding Linux and Mac OSX with the Witcher 3, but they didn't say anything, since they probably have a policy not to talk about supported platforms at all before the release. Techincally however it seems that they don't have major blocks preventing them from making the Linux port, expect for having a will to do it Their firm DRM free stance which they even expressed in DRM free distribution service (GOG) would combine well with Linux ports, but that didn't happen so far.
              Last edited by shmerl; 06-23-2013, 12:37 AM.

              Comment


              • #52
                Originally posted by shmerl View Post
                So why would suddenly Ubuntu SDL given some special treatment then if there are already other incompatible versions? Using distro independent SDL would make more sense in such case. While Ubuntu is often positioned as most popular distro - it's quite questionable, and even if it is, it's not the only big distro out there, i.e. it's not a massive majority to completely ignore the needs of others. If by Valve's solution you mean using such portable runtime (open source and DRM free), which other distros can easily provide as well - then it's good (it's also a question how to make using that runtime comfortable for users who don't use Steam). But if you mean simply to aim to develop for Steam, then I don't consider this a good thing to promote for developers.
                I think its that ubuntu SDL got special treatment to support steam and if other distros want to run steam they need to get compatibile. It works on ubuntu and steam - it no brainer for us, developers, here. I can only assume that going some distro independent SDL would take more time at this moment.

                Leszek won't waste time on ideology talk, so if you want to ask something it'll better be a tech question - then I'll try to persuade him to answer.

                Comment


                • #53
                  Originally posted by kacperpl1 View Post
                  I think its that ubuntu SDL got special treatment to support steam and if other distros want to run steam they need to get compatibile. It works on ubuntu and steam - it no brainer for us, developers, here. I can only assume that going some distro independent SDL would take more time at this moment.

                  Leszek won't waste time on ideology talk, so if you want to ask something it'll better be a tech question - then I'll try to persuade him to answer.
                  Singling out one distro as a preferred target where SDL is known to have distro specific tweaks incompatible with others sounds like a very bad idea by default. Either one should target something that is known to be easily available and compatible across most distros, or one should take care of bundling that in distro independent way. It's not a matter of ideology - it's simply a fair approach for your potential users. I.e. not treating Ubuntu like first class citizen, and others like an afterthought. Especially if Ubutnu explicitly ships an incompatible SDL.
                  Last edited by shmerl; 06-23-2013, 03:55 AM.

                  Comment


                  • #54
                    Originally posted by shmerl View Post
                    Singling out one distro as a preferred target where SDL is known to have distro specific tweaks incompatible with others sounds like a very bad idea by default. Either one should target something that is known to be easily available and compatible across most distros, or one should take care of bundling that in distro independent way. It's not a matter of ideology - it's simply a fair approach for your potential users. I.e. not treating Ubuntu like first class citizen, and others like an afterthought. Especially if Ubutnu explicitly ships an incompatible SDL.
                    SDL is just another library, and ABI incompatibility is something usual across distros. That's why there is a common runtime. As long as it's not API incompatible, it's not a problem. The only difference it makes is that Steam (and a correctly made install system) will not install another version of it for Ubuntu users, because they have the used one by default.

                    Comment


                    • #55
                      Originally posted by mrugiero View Post
                      SDL is just another library, and ABI incompatibility is something usual across distros. That's why there is a common runtime. As long as it's not API incompatible, it's not a problem. The only difference it makes is that Steam (and a correctly made install system) will not install another version of it for Ubuntu users, because they have the used one by default.
                      From kacperpl1's comment I understood that using distro independent way (i.e. common runtime / bundles and etc.) is not preferable since it's "harder" than targeting distro's package. So I was arguing that this will give special treatment to such singled distros which is not fair. If the game relies on common runtime and that runtime is easily available everywhere - then it's fine.

                      Comment


                      • #56
                        Originally posted by IneQuation View Post
                        Hi guys, Leszek here. I didn't expect Phoronix to pick my little talk up, especially after 2 months, but it's nice to be featured.

                        Indeed I'm a Debian guy, and all my port development takes place on Debian. I only have an Ubuntu chroot+debootstrap environment for building.

                        I don't mean to stir up a flamewar here, but you guys are - quite naturally and I don't blame you for it - looking at things from a consumer's perspective. And judging by some of your posts in this thread, you're quite emotionally engaged in your stance.

                        But from a developer's standpoint, you need to deliver a quality product that works reliably on a wide range of systems. Valve allows us to cut some corners in that regard with the Steam Linux Runtime. How can I possibly consider basing my game off of Debian libs if their SDL2 is binary-incompatible with Ubuntu's (sic!)?

                        The numbers don't lie - Ubuntu remains the most popular Linux distro. There is no well-established proprietary software distribution mechanism for Linux. That's why aligning with Valve and Steam is a no-brainer to professional gamedevs: we're simply trying to cover the largest market area possible so that we can pay our bills.
                        So what SDL2 versions do Debian and Ubuntu offer atm, given the fact that it hasn't been released yet(I don't count rc as release)... and the ABI has been declared frozen only like two months ago?

                        Comment


                        • #57
                          Originally posted by log0 View Post
                          So what SDL2 versions do Debian and Ubuntu offer atm, given the fact that it hasn't been released yet(I don't count rc as release)... and the ABI has been declared frozen only like two months ago?
                          TBH I didn't bother to check that thoroughly - I know I tried running a binary linked against Debian's SDL2 and it crashed when running with Steam Runtime's; the converse (linked against SR, run with Debian's) crashed as well.

                          But SDL2 is pretty sweet and I made a mistake by saying you can't do multithreaded rendering in the slides. The thing is, I looked at the SDL2 docs early in development of the port and I couldn't find any information about context sharing. It's only been a couple of weeks ago that I actually happened to look at the headers in the source and found out I was wrong - it was simply undocumented. I traced the feature to a commit that Sam Lantinga made back in May 2012 I think, but the documentation wiki is still way behind the code.

                          I'm preparing another talk which will be exclusively about SDL2 where I will address and correct this, as well as present all of SDL2's cool features to other professional developers.

                          EDIT: Oh, unless you wanted to know about features? Well, for PKHD I'm using window/GL context management, game controller/joysticks and haptic feedback, and all of it seems to work nicely with the version that's shipping with the Steam Runtime.
                          Last edited by IneQuation; 06-23-2013, 04:40 AM.

                          Comment


                          • #58
                            Originally posted by IneQuation View Post
                            I don't mean to stir up a flamewar here, but you guys are - quite naturally and I don't blame you for it - looking at things from a consumer's perspective. And judging by some of your posts in this thread, you're quite emotionally engaged in your stance.

                            But from a developer's standpoint, you need to deliver a quality product that works reliably on a wide range of systems. Valve allows us to cut some corners in that regard with the Steam Linux Runtime. How can I possibly consider basing my game off of Debian libs if their SDL2 is binary-incompatible with Ubuntu's (sic!)?

                            The numbers don't lie - Ubuntu remains the most popular Linux distro. There is no well-established proprietary software distribution mechanism for Linux. That's why aligning with Valve and Steam is a no-brainer to professional gamedevs: we're simply trying to cover the largest market area possible so that we can pay our bills.
                            For the developer, it also makes sense to look from the consumer's stand point, as that's the revenue source. For example, if the consumers hate DRM, and you include DRM, you're hurting your sales. So if you are porting a game, you want to have it distributed by both Steam and Desura, on as many distributions as possible, to allow most people access to the game.

                            The Steam Runtime is an OK thing to have, but I'm not convinced that it's any better than just distributing your game libraries with the game. If the user already has Steam, good for them, everything will work. If the user doesn't have Steam, suddenly an installation of the whole Runtime is needed, which is far more bloat than just including the libraries with the game (since it won't be using the entirely of the runtime). And, genuine inquiry, what happens when Valve decides to update the runtime? Your game suddenly stops working? The new runtime is installed in a new slot, and if so, how do you tell which runtime is which version? Or would Valve never update the runtime and thus force everyone to use ancient libraries?

                            Which is another point I want to address if you bundle your libraries, you get full control over what your game uses. So while Steam Runtime may have GTK2, you could very well want to use GTK3. If you bundle the libraries, everything works out fine, and you're not limited to the selection or the versions in the Steam Runtime. That's just a lot more flexible. In addition, if there is some update in the system that causes the libraries to not work correctly any more with your particular game, with bundled libraries you could just swap out the old library with a new one that doesn't affect any other games, which could have got broken if you updated the library in the Steam Runtime as a whole.

                            Another point I don't really agree with is that if in doubt, do what Valve does. In my opinion, if in doubt, check your options and go with the one that makes the most sense. If it coincides with what Valve does, that's great. If not, no big loss, because not everything Valve does is the best choice for every game.

                            Comment


                            • #59
                              Originally posted by GreatEmerald View Post
                              For the developer, it also makes sense to look from the consumer's stand point, as that's the revenue source. For example, if the consumers hate DRM, and you include DRM, you're hurting your sales. So if you are porting a game, you want to have it distributed by both Steam and Desura, on as many distributions as possible, to allow most people access to the game.

                              The Steam Runtime is an OK thing to have, but I'm not convinced that it's any better than just distributing your game libraries with the game. If the user already has Steam, good for them, everything will work. If the user doesn't have Steam, suddenly an installation of the whole Runtime is needed, which is far more bloat than just including the libraries with the game (since it won't be using the entirely of the runtime). And, genuine inquiry, what happens when Valve decides to update the runtime? Your game suddenly stops working? The new runtime is installed in a new slot, and if so, how do you tell which runtime is which version? Or would Valve never update the runtime and thus force everyone to use ancient libraries?

                              Which is another point I want to address if you bundle your libraries, you get full control over what your game uses. So while Steam Runtime may have GTK2, you could very well want to use GTK3. If you bundle the libraries, everything works out fine, and you're not limited to the selection or the versions in the Steam Runtime. That's just a lot more flexible. In addition, if there is some update in the system that causes the libraries to not work correctly any more with your particular game, with bundled libraries you could just swap out the old library with a new one that doesn't affect any other games, which could have got broken if you updated the library in the Steam Runtime as a whole.

                              Another point I don't really agree with is that if in doubt, do what Valve does. In my opinion, if in doubt, check your options and go with the one that makes the most sense. If it coincides with what Valve does, that's great. If not, no big loss, because not everything Valve does is the best choice for every game.
                              Just a thought. If you will bundle the library, maybe static linking is a better option, if possible. It's probably better performance wise, and enables you to run an extra optimizer pass and stripping unused library functions, which both helps size and performance.

                              Comment


                              • #60
                                I made some mental shortcuts there which I had hoped would be understood. Apparently they weren't, so I'm going to explain a little bit.
                                Originally posted by GreatEmerald View Post
                                For the developer, it also makes sense to look from the consumer's stand point, as that's the revenue source. For example, if the consumers hate DRM, and you include DRM, you're hurting your sales. So if you are porting a game, you want to have it distributed by both Steam and Desura, on as many distributions as possible, to allow most people access to the game.
                                Of course you are right. However, if you're a mid-to-large gamedev studio/publisher, not an indie operation, your PC game is probably already fitted with Steam. Desura's userbase is marginal compared to Steam's, so in order to get the game out ASAP (Steamworks API is identical on all platforms), and have feature parity with the Windows version, going with Steam on Linux is a no-brainer. Again.

                                Also, why does the mainstream user not mind Steam's DRM? Because it's almost perfectly non-invasive. I also usually object to DRM, especially if it's poorly implemented, like in Apple's ecosystem, but Steam sets an example that I wish other DRM companies would follow. I respect your position, but you guys opposing DRM are a minority. A vocal one, but still - a minority.

                                On a side note, coding Desura integration for UE3 is a project I have on my TODO list. If I manage to convince the management, you might see PKHD available there as well.
                                Originally posted by GreatEmerald View Post
                                Another point I don't really agree with is that if in doubt, do what Valve does. In my opinion, if in doubt, check your options and go with the one that makes the most sense. If it coincides with what Valve does, that's great. If not, no big loss, because not everything Valve does is the best choice for every game.
                                Just as I wrote above - it's a mental shortcut. I evaluated the situation from a mid-to-large game developer such as my company, and aligning with Valve made most sense of all the options. I expect it to be the same for all non-indie game studios.

                                Good questions regarding the library versions - Valve's documentation actually doesn't address that. The only option that makes sense from my point of view is to maintain backwards binary compatibility (i.e. keep the old version alongside a new one if ABI changes). They can't risk breaking already working games. I'll ask Valve support.

                                Comment

                                Working...
                                X