Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Now when it comes to Linux builds of games, dependencies can in portable builds be a kind of an issue. Full packages do at least ensure these are all properly installed. Now I've been out of Linux for quite some time, but I believe there's the AppImage project to cover this up... Or is that project not running anymore? Since I'm interested in porting the projects I'm doing now to Linux it will be nice to know what the best method of distribution will be (as that has always been a bit of pain in Linux).

(+1)

As active Linux desktop user I can tell I see the AppImage format quite often. Even some tools here on Itch use it. Tiled for example ports as AppImage. But I have no idea how it handles package dependencies. If you like to play it safe, distribute your game as deb or rpm package as well as a tar.gz archive (for the less popular distros). If possible, include a readme in the tar where you list up all your deps and requirements. I think you basically got it covered well enough that way.

(1 edit)

Thank you for your time. The dependencies I work with now should be rather common (zlib and SDL2, (plus SDL2_Mixer and SDL2_Image)), but since I do not know what the future brings. Linux ports are not even a promise yet, but a friend of mine who is a real geek (and he even takes pride in that, so I can safely say that) did already say he'd help me when the time comes. Yet I do see that AppImage can still be a good way to go to make sure "nothing can go wrong"... well it sounds at least most "fool-proof" to me, at least for the itch app. A deb/rpm may still be an option as separate download for the more "purist Linux user" I guess... ?

(+1)

Yeah, AppImage solves a lot of distro portability issues, and it’s gaining popularity.

However, there are forward/backward compatibility issues with core Linux libraries like glibc. It’s possible to use alternative C libraries etc, but generally it’s easier and more future-proof to run a Windows build in WINE, lol.

For now I’m distributing a ZIP file with both Linux and Windows binaries to cover all the bases, an AppImage more for convenience, and thinking about an Itch installer build.

Thank you. Well, since I only have Linux on a virtual machine right now, things are hard for me to test. All I can do is see if stuff compiles and, that's it.  Running a Windows build in WINE, eh? Yeah, I guess that's always an option, though I'm not sure if this could cause speed issues.

(+1)

No speed issues with WINE; it’s not an emulator, just a (partial) replacement for OS functions. The problems are always about compatibility. It runs demanding games like Witcher 3 just fine, as well as Windows builds of most Unity/Unreal/Godot games.

I find it convenient to develop in Linux and test mostly in WINE - however, it’s more forgiving than real Windows so it is necessary to test on Windows occasionally.

Well the core engines of my most recent work are coded in C++ lately with SDL2 for graphics, audio and stuff like that, and I guess given the popularity of SDL2, I don't expect too much issues in WINE. Or am I thinking too optimistic now?

SDL? If it works in Windows it should work in WINE. It’s more of a problem making portable Linux binaries because SDL has tons of dependencies, especially audio. Disabling SDL’s audio and using Miniaudio instead would probably solve 90% of those… although Linux core libs (glibc etc) cause so many backward/forward compat problems that WINE is (almost) preferable.

Would almost make me think that if I were to create a .deb or .rpm file that I should make it just install the Windows binaries with WINE as a dependency, and using a Shell script as startup file which would automatically start wine with my games.