Got a linux native game that needs testing?

Posted by
September 2nd, 2012 6:23 pm

Well, i’ve basicly given up on ludumdare’s search feature, it’s utterly useless since it finds every single game that so much as mentions linux in any way (it finds games that say “sorry won’t work on linux” and “let me know in comments if it works on linux”) and half the people that “do” have linux version requires a 6 hour install procedure to get all the interpreters installed.  If anyone has a linux native game that needs testing, go ahead and leave it in the comments here and if i havent already I’ll check it out!  Now that’s NATIVE games though, i don’t want a bunch of java7 and love2d games linked here, I can’t run those! So binary only.


11 Responses to “Got a linux native game that needs testing?”

  1. quasist says:

    Please, let code monkeys have some fun ^_^

  2. Dietrich Epp says:

    Since I saw your post, and in response to some comments on my game, I’ve released native Linux binaries. I know they work on Debian, but there’s a good chance they work on other distributions as well.

    No, it doesn’t work on WINE, due to problems with image decoding.

    http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=7606

    Requirements: GtkGLExt, LibPNG, ALSA (Note: if you have sound problems, try shutting off Pulse Audio before launching the game. I’ll probably want to support Pulse Audio at some point in the future.)

  3. rxi says:

    I get the feeling no linux users have been able to run my linux version since I’ve had a few comments about it. To be honest it put me off even making a linux version in the future, as if providing a version which doesn’t work for most people who try it is just wasting their time. That being said, feel free to give it a blast:

    http://www.ludumdare.com/compo/ludum-dare-24/?action=preview&uid=16007

    It’s 32bit and requires libsdl and libsoil to run. I have a post-jam version with music (that can be turned off) linked in the description, this version only requires libsdl. It’d be nice to know if it works, thanks!

    • Raptor85 says:

      the problem with your game is you’re compiled against glibc 2.15 which isn’t even stable yet much less common, it was just released this june and is FAR from tested (the windows equivilant would be linking to the visual studio 2012 RC runtime, it’s too new, nobody is going to have it yet and the system update where it becomes stable and common is probably at least a year out), so next to nobody will be able to run it. You really do NOT want to be linking against cutting edge, just released library versions, especially if you’re not going to provide libraries yourself for download, this isn’t just a linux thing this is true on mac and windows also. Use the common release version, compile for 2.11(current stable) and nobody will have issues running.

      Your other issue is you’re using a bunch of libraries but not packaging them with your executable, you want to do that for a binary release ALWAYS. You did this in the windows release, you included SDL.dll, but for the linux release you neglected to copy libsdl.so into the zip

      • rxi says:

        Thanks for the reply! As you can tell I’m not really a linux user. In fact, I only installed it so that I could try and compile a linux version of the game for the jam.

        I didn’t realise it was that simple to include the libraries along with the distribution. I was under the impression that if you provided one library you’d then have to provide all the dependencies, until you end up at a point where you’re including literally hundreds of libraries just because you wanted to include SDL. I can see from your competition entry that that doesn’t appear to be the case, though.

        Regarding linking to the new C library, It’s what was included in the latest version of ubuntu. I also didn’t even consider that it could be an issue.

        I’ll be sure to keep your points in mind for next compo, and I appreciate the help. I don’t know if I’ll manage to get round to fixing the current entry.

        • Raptor85 says:

          interesting ubuntu pushed it out so quickly, even on gentoo we just got 2.15 available in the repos a week or so ago according to the changelog, this weeks rsync to the repo quite literally unmasked it for me right after i posted that, avialable on 64 bit only (32 bit compat libs are still 2.14 on 64 bit systems, so compat libs are still masked) 😛 (changing glibc is essentially a full OS upgrade though, so it’s not something you do lightly)

          Looks like you just happened to grab an install that was brand brand new and kinda got the packages a little before most people will be receiving them normally, still though i’d consider 2.15 an “unsafe” target as it will still be quite some time before everyones upgraded to that, especially if you consider the users who install from dvd and don’t auto update will essentially be running 2.13 or 2.11 until they fully re-install their system. There’s basicly two rules of thumb for using libraries, and this again is NOT linux specific, it’s generally a good idea on windows/mac/etc too

          1. NEVER use the newest cutting edge version without a really, really good reason, use whatever the COMMON version is
          2. Either staticly link or include everything you can legally include that the user might not have

          For linux to determine the type of packages the user “might not” have, for the most part if it’s in /lib they PROBABLY have it, if it’s in /usr/lib it’s PROBABLY an optional package and they might not have it installed, though it really comes down to if you actually had to choose to include a specific library in your code, it’s probably optional and you should probably package it (notable exceptions, stuff like opengl and directx, while they are optional and user controlled they’re also VERY hardware specific and they need to be user installed)

          There’s a lot of stigma on linux about including shared objects with the game, as it’s technically “bad” and the “wrong” way to do it, but frankly….who cares, it’s the ONLY way that reliably works without requiring the user to install a bunch of stuff himself or have a per-distribution package to make the user install a bunch of stuff to their system, packing shared objects allows the game to be fully downloadable and playable without ever requiring root access to install packages or mucking around with updating potentially fragile libraries in the OS itself.

          Or put another way, this is how ryan gordon (icculus) does it as well when the release is binary only, and I think he knows a thing or two about binary releases on linux 😛
          http://en.wikipedia.org/wiki/Ryan_C._Gordon

  4. What did you mean by : Should definitely make a post-compo version?

    • Raptor85 says:

      Your game has a good base but as released has a lot of problems that make it too broken to be really fun, just saying that you should follow up with what you have and make an “improved” version (known around here as a “post compo” release) using the feedback you’ve gotten, especially since you say it’s a first game could be worth learning and improving it. Can’t be rated for hte competition of course but a lot of people around here will still give you more feedback on it.

  5. heuermh says:

    Just to clarify, is that a hate on JDK 7 specifically or java games in general? I ask because I use linux primarily (64-bit linuxmint cinnamon) and did throughout LD24, except for a Mac to run the Pickle sprite editor.

    There was a post with links on how to package a java game appropriately, but I’m afraid I’ve ran into a lot of entries that missed that advice

    http://www.ludumdare.com/compo/2012/08/24/how-to-package-your-java-game-this-ld/

    Is packaging the problem, or are you just not running a JDK or JRE at all?

    • Raptor85 says:

      java7 isn’t stable everywhere yet, it’s actually blocked on some distributions because of java6 packages it actually breaks that don’t have a java7 equivilant yet. On windows also most people don’t impulsively update java at every chance, so about the only people anywhere you can expect to be on the latest java is java developers. Especially on linux though, since a lot of tools run on java, it’s a fairly major upgrade since you don’t only need to upgrade java but any system packages that rely on it as well to link to the new java7 (library layout changed, it’s more modular now), the kind of thing you generally don’t change on a stable system. (like python)

      99% of the entries compiled for java7 arent even using java7 anyways, they’re using the java6 compatability api’s instead of the new java7 versions of them so there’s no reason it shouldn’t be compiled for a java6 target.

      That said, yes, I AM skipping any java7 entries, it’s not worth risking my system stability and a working development toolchains to play a single game, but I am playing java6 ones that packaged their libraries properly. Only reason i dont want those listed here though is that they are already easy to find, just search for java and there’s not many false positives, whereas if you search for “linux” 90% of them do not have a linux version of the game, it’s a “linux” link that points to the windows executable saying that “it might work in WINE”, a .love file, a source package with no makefile or lirbrary deps, or my personal favorite a short note apologizing for no linux support…basicly it’s the incredibly broken search engine’s fault i even need to ask, if there was just a OS filter on the game entrys it wouldn’t be an issue.

      • heuermh says:

        Right, I agree that requiring JDK 7 is a Bad Idea, as there are simply none available for some platforms, such as OSX versions prior to Lion. And there aren’t really any interesting new APIs in JDK 7 compared to JDK 6.

        JDK 8 on the other hand . . .

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]