I am releasing a video game this week and I am going to attempt to include a Linux appimage. My current plan is to include only 64-bit binaries. This post is your chance to convince me that I should include 32-bit builds (in addition or exclusively, depending on how persuasive you are).

UPDATE: Wait. Hold on. Why *did* I believe it would be possible to compile a video game for Linux? Obviously this is impossible. I should have realized it was impossible

EDIT: Obviously, the problem is I had named the shared object .so and I should have named it .so.0

SoooOOOO
Now I'm getting an even better error
I asked Linux to compile my video game and it just called me a dummy and stormed off
@mcc I was gonna be annoying, and make the always funny sudo joke. But holy shit you have enough to deal with.
@mcc As someone who wants to release their game on Linux I'd love to know... what format are you compiling to? How best to distribute it? Etc?? I have no idea how Linux gamers game
@soundasleep @mcc With a hodgepodge of Steam, GOG, WINE, bash scripts, and frustrated cursing.
@bdod @soundasleep @mcc Funny, but Wine is actually a much better idea than compiling for Linux. Windows APIs are more stable than linux will ever be.
@soundasleep I don't know. I haven't released a game for Linux yet.

@soundasleep @mcc afaik, x86 is x86. The main distinction is that you want your linux binary to make linux syscalls and not windows ones. Most game engines should have an export option that does this for you.

If you don't want to go through the trouble, I'd encourage you to at least test your windows executable against proton to see if everything's doing well. I usually use bottles for this.

@fireye @soundasleep I think this post is mostly nonsense and does not contain good advice.
@mcc @soundasleep hey fair enough I'm still in undergrad; would love to hear what I'm mixed up on.
@fireye @soundasleep In this conversation's context, x86 is usually a term reserved for 32 bit; 64 bit is usually called x86_64 or x64 (although the latter is *usually* a Microsoft term). System calls on Windows are, unlike Linux, not made directly by end user programs. Windows and Linux executables differ in many ways (try search keywords like "ABI", "ELF", "PE"). A 64bit Linux system requires additional 32 bit system libraries (this is common but not automatic) or it can't run 32 bit binaries.
@fireye @soundasleep "shipping" for Linux by simply verifying Proton capability, as you suggest, is however good advice.
@mcc @soundasleep oh this is quite helpful, thanks! I was looking at the ELF spec for nix packaging recently but pretty clearly did not understand it. Will revisit it with more context now lol.
@mcc @fireye @soundasleep This sounds insane to a novice, but turns out to be the most sane option. ๐Ÿซ 
@mcc @fireye @soundasleep Huh, I could swear I've often heard "x86" used colloquially to describe the entire family of architectures that trace their lineage to the 8086, including x86-64. (In practice, this usually evaluates to "not ARM") Is this not a thing? ๐Ÿคท
@diazona @fireye @soundasleep colloquially, yes, but this is a conversation explicitly about the distinction between 32 bit and 64 bit x86-family architectures, and even in a colloquial sense the phrase "x86 is x86" is wrong in this context due to the many different ISAs the x86 family comprises, one of which (AMD64) explicitly breaking compatibility in both directions (an x86_64 processor loses support for some x86 instructions and addressing modes unless explicitly switched into legacy mode).
@mcc @fireye @soundasleep doing an x64 release but it refers to ia64 ๐Ÿฅด
@fireye @mcc I do have an export option for this... but I don't know if it should go to a .deb, a .rpm, or some plain ol' binary, I have no idea ๐Ÿ˜… I'm using https://docs.oracle.com/en/java/javase/17/docs/specs/man/jpackage.html
The jpackage Command

@fireye @mcc It _sounds_ like I just have to create an `app-image` and it'll make the plain ol' binary for me
@soundasleep I feel like the most compatiblest option is to give us the bare .jar file.
@clayote @soundasleep appimage is highly compatible. However as clayote says if you are Java you have significant compatibility options a regular Linux binary would not have.

@soundasleep i usually do raw binaries or zip archives, but my games arenโ€™t too big (lot of game jam entries).

i typically also release the .love or .tic files, which are equivalent to the JAR.

@soundasleep i feel like i should ward off pedants and clarify that they are equivalent from a user standpoint but are different technically (e.g., no bytecode in .tic or .love). although both JAR and .love files are zip archives.
@soundasleep @mcc Frankly, I think windows games on Proton is probably the most common way to play on Linux. Or at least that is how most Steam games seem to work on my Steam Deck.
@antopatriarca @soundasleep @mcc same for me. Doing things Linux-native is cool, but if itโ€™s at least Proton-compatible and youโ€™re okay with putting it on Steam I think youโ€™re good
@standev I have also played games from GoG or Epic Games using Proton without too many issues. Particularly outside of the Steam Deck as some games may require some more tinkering on that platform outside of Steam. So you are not forced to use Steam.
@mcc i think that means she likes you but needs to work through some stuff