I've been meaning to write this for a while now. Better late than never :D
General Linux Thoughts
Unity Specific Stuff
- Thanks for considering providing a Linux build. You're awesome.
* Engage with your Linux players and listen to their feedback
* Consider pushing the notion that all desktop PC platforms should be equal (if you're already doing Linux support, supporting the big three (Win, Mac, Lin) isn't a big stretch). This encourages your user communities to come together rather than be divided by platform.
- Linux file systems are case sensitive
* Pick a case and stick with it
* Write a function that checks for upper and lower case versions of stuff (if you're doing lots of file IO, this is going to be expensive)
- Be aware of file permissions
* Windows file systems can't set Linux executable permissions.
* Ask a Linux user to do it for you (they can untar, +x and then tar it back up), or mention it in a readme
* Linux users can set this in most fime lanagers by right clicking and chosing properties and ticking an "allow execution" checkbox, or by running "chmod +x filename" (without quotes) from a command prompt in the same folder as the binary.
- Get some testing feedback before releasing a build
* The earlier you test, the more informed you'll be about any issues you might have, and the less time they'll have to dig themselves deep into your codebase
* Consider dual booting/live booting a distro that you can quickly get decent graphics drivers on (it's not that hard nothing compares to first hand experience)
* Befriend some Linux users and ask for their thoughts (accept that if you don't have much Linux experience, others will know more than you - there's nothing wrong with being a noob, but you can shoot yourself in the foot if you can't acknowlege when you are one)
- If you're not using a pre-made engine, use mature F/OSS tools/libraries when you can, as they tend to be cross platform friendly (and you can open them up and check out how they work)
* Pay attention to licencing and the implications of "static linking"
* Ryan "icculus" Gordon's 2012 talk titled Open Source Tools for Game Development is a good watch: http://icculus.org/flourish/
- If you need to distribute libs, be aware of LD_LIBRARY_PATH
- Be aware of 64 bit vs 32 bit
* If you're going 64 bit only, make note so that 32 bit users don't waste bandwidth downloading
* It's not that hard to make a single "shell script" (like a batch file if you're coming from Windows) that can automatically launch 32 or 64 bit depending on the user's architecture: https://gist.github.com/Cheeseness/6338585
* Almost all 64 bit distros provide 32 bit compatability libraries (though not all 64 bit users are willing to install them).
- Executables don't need file extensions.
* There's no need to add something to them (especially not .deb or .rpm, since that indicates an installable package format rather than an executable binary).
- There are standard locations for keeping user files, etc.
* Not all Linux users care, but there's value in taking advantage of XDG http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
- Mouse grab behaves differently in standalone Unity builds compared to the web player, apparently.
* Screen.lockCursor() seems to be the most appropriate way to grab the mouse: http://docs.unity3d.com/Documentation/ScriptReference/Screen-lockCursor.html
- Default mouse sensitivity in Unity is much higher under Linux.
* Add sensitivity configuration options if you can.
- Unity 4.2 seems to have Rift issues which result in headtracking not working and eye viewports being misaligned.
- Don't use default values for company name and project name.
* Configuration files are stored in ~/.config/unity3d/CompanyName/ProjectName, and if you use the default values for these, your game's configuration and save files will conflict with/be overwritten by other games' ones.