This is really great to see, and we need more of it. Amos from the game store Itch.io has written up a guide for people pushing out Linux builds of games.
Wrote a guide to distributing self-contained Linux builds — what did I miss? #gamedev https://t.co/fBgi9auLni pic.twitter.com/KdHinPVBkX
— Amos ♦ (@fasterthanlime) March 24, 2016
Here's an excerpt from the guide:
QuoteThe Linux ecosystem is composed of many different distributions, and each have their own package format. For independent developers with limited resources, it's often not practical to distribute and maintain repositories with packages for each of these distributions.
Thankfully, distributing self-contained Linux builds is possible, and this page tries to explain how.
Be sure to give the writer feedback on it on twitter, and in our comments here too. We need more great guides like this to help developers when publishing on Linux.
I've seen a number of developers confused recently on best practices, so hopefully this little bump from me will help somewhat. It surprises me the amount of developers that follow us, so this one's for you!
One of the most annoying things is developers who don't have everything the game needs with it, I hate hunting down libs (sometimes really outdated ones too!). Don't make us do that please.
Find the guide here.
QuoteFor the launder script, there are some side cases where:
SCRIPT_DIR=$(readlink -f $0 | xargs dirname)
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${SCRIPT_DIR}/lib"
cd "${SCRIPT_DIR}/bin"
$() is bash specific I think and there is absolutely nothing wrong with ``
btw. do you use
#!/bin/bash
or
#!/usr/bin/env bash
Quoting: Guest[...]SCRIPT_DIR=$(readlink -f $0 | xargs dirname)"
[...]
My favourite has been the following, for a number of years:DIR="$(dirname "$(readlink -f "$0")")"
Same thing really, I just like the non-piped approach.
Quoting: sobkas[...]
$() is bash specific I think and there is absolutely nothing wrong with ``
btw. do you use
#!/bin/bash
or
#!/usr/bin/env bash
Very true. I prefer to just require bash instead of targeting sh in general - less surprises down the line in case I forget some incompatibility issue.
I generally use /bin/bash. No real reason other than I've never had issues with it.
QuoteAt the time of this writing, 32-bit processors are becoming rarer, but 32-bit operating systems are still a reality. Distributing both 32-bit and 64-bit binaries is a small effort that prevents a lot of headaches.
I'd say no. If developers are constrained they should drop 32-bit builds and only release 64-bit. Otherwise they'll have to deal with a lot of hidden issues, like the infamous large XFS partition bug. Those focused on gaming today don't use 32 bit OSes anyway, and non capable of 64-bit PC hardware doesn't exist for years already.
Last edited by Shmerl on 25 March 2016 at 3:07 pm UTC
Quoting: GuestDon't forget that something like a Raspberry Pi may not be 64bit, but could be a target audience for some games, and is a flavour (of sorts) of Linux.
But the Pi has an ARM CPU, so it's a completely different architecture anyway.
Last edited by DrMcCoy on 25 March 2016 at 7:14 pm UTC
It sometimes confuses engines if not set. And I second the XDG_* suggestion. I hate apps that create their own .hidden_directory right in my home directory.
Quoting: MyeulCDon't forget to also export LC_ALL=CI'd argue that this should only be done when necessary. Game developers should learn to make use of the locale settings instead of ignoring and stumbling on them.
See more from me