While off-the-shelf game engines like Unity, Godot and Unreal often make it easy to bring games to Linux - what about developers who roll their own? Utopixel have blogged about bringing their new game Outer Wonders to Linux.
Outer Wonders is an in-development pixel-art adventure with plenty of puzzles to solve. You play as Bibi, a sweet little round monkey. Exploration is going to be a key part in solving puzzles, as you may need to have a good look around for how to overcome each one as they're hoping it will be "more elaborate than traditional maze games".
The developers mentioned that "supporting Linux specifically was no easy task" but why? Well, mainly it seems because "documentation about building and deploying games for Linux is scarce and often intricate" so they wanted to do their part on helping others achieve excellent Linux support and how they did it for Outer Wonders.
The developer goes through details like ensuring the widest compatibility possible by dealing with glibc, SDL 2, dependencies and more. It's actually a pretty interesting piece for developers who are not using a traditional game engine. I do love the games industry when it comes to indie developers like this. There's such a great feeling of cooperation and coming together, when you see developers publishing what they've learned for others like this to then learn from and use.
Want to give it a go? Good news, there's a demo available right now on itch.io featuring 7 puzzles, requiring 15-30 minutes overall.
Check out their blog post and try Outer Wonders from itch.io.
"We don't have a Linux-powered computer available for testing yet so Outer Wonders has been tested only in virtual Ubuntu machines so far."
I see so many developers say this. Do developers seriously not know how to dual boot an OS ? Failing that do they not have a spare HDD they can toss Linux onto and boot onto that ?
I see so many developers say this. Do developers seriously not know how to dual boot an OS ? Failing that do they not have a spare HDD they can toss Linux onto and boot onto that ?A big part of it is a lot of developers only have their one machine. Even if they have more than one drive, screwing up your only machine is a pretty big risk. Installing Linux might be easy nowadays but that doesn't mean if fits in with the hardware developers currently have. It's why I honestly think WSL2 with the proper GUI support coming up could really help developers with the testing part.
I see so many developers say this. Do developers seriously not know how to dual boot an OS ? Failing that do they not have a spare HDD they can toss Linux onto and boot onto that ?A big part of it is a lot of developers only have their one machine. Even if they have more than one drive, screwing up your only machine is a pretty big risk. Installing Linux might be easy nowadays but that doesn't mean if fits in with the hardware developers currently have. It's why I honestly think WSL2 with the proper GUI support coming up could really help developers with the testing part.
I get what you're saying and agree with you for the most part. That said, though... A hard drive swap or even a USB bootable drive is pretty damn trivial and should be as close to zero risk as you get when it comes to hardware (and the USB option *is* zero risk, for all intents and purposes). If they can spin up a VM, they should have all the know how to roll a spare drive with a linux install.
glibc compatibility though, yeah that can be a pain
I would say that the main problem that devs do here is that they link with a too new version of glibc, the thing with glibc is that it's extremely forwards compatible but not backwards compatible (aka build on an old version of glibc and you program works on a new glibc but not the other way around).
edit: However that is not really needed either if you are willing to put in a real effort. E.g in this case according to the blog they had to install Ubuntu 20.04 because they didn't know that you can still access the full 14.04LTS universe by changing the URI from where APT fetches updates so they ended up with a "too new glibc" but you can still downgrade the version since glibc contains every single old version back to 2.1
As an example when I compile a program here on my Ubuntu 20.04 I get a link to the 2.14 version of memcpy() due to glibc implementing an optimized version of memcpy in 2.14:
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy
I can however in my source code force glibc to use the old version of memcpy:
__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
int main (int argc, char **argv)
And after compile I now link with the old version of memcpy():
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 memcpy
Last edited by F.Ultra on 27 May 2021 at 6:08 pm UTC
I am really happy they went through the effort to add Linux support but at the same time I can't help but notice this:
"We don't have a Linux-powered computer available for testing yet so Outer Wonders has been tested only in virtual Ubuntu machines so far."
I see so many developers say this. Do developers seriously not know how to dual boot an OS ? Failing that do they not have a spare HDD they can toss Linux onto and boot onto that ?
It does seem extremely unprofessional. If you were making a Windows game, you wouldn't release it without testing it on a Windows machine; if you were making a Mac game, you wouldn't release it without testing it on a Mac; the same with PlayStation, Xbox, or Switch. And Linux is free: you don't need a whole new machine, you just boot your test machine into a different environment.
"Here's a thing. We didn't check to see if it works. Give us some money." isn't really adequate. You get better service than that at the flea market.
Last edited by CatKiller on 28 May 2021 at 1:33 am UTC
I am really happy they went through the effort to add Linux support but at the same time I can't help but notice this:
"We don't have a Linux-powered computer available for testing yet so Outer Wonders has been tested only in virtual Ubuntu machines so far."
I see so many developers say this. Do developers seriously not know how to dual boot an OS ? Failing that do they not have a spare HDD they can toss Linux onto and boot onto that ?
It does seem extremely unprofessional. If you were making a Windows game, you wouldn't release it without testing it on a Windows machine; if you were making a Mac game, you wouldn't release it without testing it on a Mac; the same with PlayStation, Xbox, or Switch. And Linux is free: you don't need a whole new machine, you just boot your test machine into a different environment.
"Here's a thing. We didn't check to see if it works. Give us some money." isn't really adequate. You get better service than that at the flea market.
While I agree with you, they did perform tests just on a virtual machine, yes you won't catch amd/nvidia/intel specific GPU driver oddities (but then they don't seem to use advanced 3d capabilities anyway), but everything else should be similar to testing on real hw.
While I agree with you, they did perform tests just on a virtual machine, yes you won't catch amd/nvidia/intel specific GPU driver oddities (but then they don't seem to use advanced 3d capabilities anyway), but everything else should be similar to testing on real hw.Yeah, I wasn't trying to single these guys out. Releasing for Linux and trying to help others release for Linux are both good things. Just that attitude expressed (obliquely) by some devs that it doesn't matter how shabbily they treat their Linux customers because it's only 1% of the market, right?
Game devs should use their whole arse.
Last edited by CatKiller on 29 May 2021 at 9:48 am UTC
See more from me