It has been a little while now that Wonderboy 3 was released for Linux and Mac, thanks to Ethan Lee’s porting efforts, and while you will get to see our review pretty soon, we have some more details to share about how the porting efforts went. This is somewhat of a special project to me, since I met with Omar during the course of the game’s development, well before its release on the multiple platforms it now supports.

But first things first. The original plan by Omar was to release the game at the same time on Windows/Mac and Linux, but things did not turn as he expected, for various reasons:

Omar Cornut: I would probably have aimed to release Linux/Mac simultaneously with the Windows release. That was my intent but then I became surprisingly overwhelmed with preparing the Steam release (adding options which led to new ui, controls remapping, fixing compatibility issues, optimizing for older cards) and didn’t have the bandwidth to even consider talking to someone to make Linux/Mac happen. So next time we’ll tackle that earlier… I now also have more experience with shipping for PC in general so presumably it’ll be easier.

When Ethan took over the porting efforts, he did not start from nothing. There was already some prior work done by Omar on the OpenGL backend and the Mac version. But first you may wonder… why didn’t they just build a single OpenGL version that would run on all platforms, instead of using DirectX on Windows? Actually, that was the original plan.

Omar: The game was initially developed for OpenGL, I used the OpenGL backend for a year. I only switched to DirectX11 because too many drivers have OpenGL issues and I personally kept having the infamous diagonal-tearing-issue on my laptop which made playing the game very depressing, so I ported it to DX11. OpenGL just has too many problems (on every platform).

We may be used (and spoiled) by having reasonably good OpenGL drivers on our platform, but indeed on Windows OpenGL is often a lower priority for hardware vendors focusing most of their resources in efficient DirectX drivers. In any case, Ethan Lee did not start from scratch:

Ethan Lee: Linux/Mac backends existed but they were both really old and totally separate from one another, so I started from scratch to make a generic SDL backend. Some SDL stuff existed in the Linux subsystem but I didn’t use it. The new backend works on Linux/macOS and Windows would probably take an afternoon to get working.

The SDL backend was pretty easy, but hooking it up had a handful of challenges - wiring up a new PC platform without clobbering #if ENGINE_WINDOWS defs isn’t new for me though! Keeping the build together was probably most of the work, with some odd jobs for the filesystem and the graphics subsystem happening every now and then. Their OpenGL support was already in place, it just needed some optimizations for the desktop (a lot of it was either modern GL by accident or GL that worked a whole lot better on mobile than on desktop).

The filesystem oddities mentioned by Ethan Lee made the file listing break in some specific conditions in the Linux port, until he could figure out what was causing this strange behavior:

Ethan: Part of the new backend was a file manager. Basically, all the file I/O calls are done in here. For us, that’s a whole bunch of stuff from unistd/dirent/etc. I had this and I’ve done it like this for a while:

bool isDirectory = dir->d_type == DT_DIR;

Turns out this actually doesn’t work, and we had no real way of telling until I got everything about this person’s setup and we printf’d the everloving crap out of the filetree that the engine was getting back. As it turns out, XFS and ReiserFS don’t support this, but it’s still a part of the struct either way so you just silently get a bad value, leading to the game’s file tree being totally incomplete and leading to lots of missing files and eventually some hard crashes. It took a solid week of trial and error with one other person to figure out what the problem was.

This is what you actually have to do instead:

struct stat info;
stat(fullPath, &info);
bool isDirectory = S_ISDIR(info.st_mode);

The port was well received, and to date there were very few bugs reported to Ethan. In case you have issues with the game please don’t forget to let him know!

Ethan: It did pretty good in reviews, though it was so quiet in the support forums I couldn’t be entirely sure how everyone else felt about it! I think I got 2 [bug reports] in total across both Linux/macOS in the opening week… one was filesystem related and one was Mesa related. If there were any more I’ve already forgotten because they were all so quick to fix.

When it comes to how well the title did in terms of sales on the Linux platform, it’s kind of unclear, while it seems the console versions did much better than the computer ones:

Omar: I have no idea to be honest, I don’t think Steam provide platform information connected to sales? (I don’t have direct access to the sales data). The Steam sales in general have been a little lackluster compared to the consoles, but it’s also because our game was released on consoles earlier, and it’s a very consoley game in general.

On the other hand, Omar is pretty positive about such ports to Mac and Linux. They should all be “worth it” in the long run, while highlighting it’s going to be a case-by-case approach for every game they make:

Omar: I’m happy of the ports. Sales wise, even though we missed the launch window, I suppose having Linux/Mac available is probably worth it for the long tail. Porting future games - pragmatically speaking I think it often comes down to how much resources, energy and bandwidth we have at a certain moment. Ideally I want our  games to be on every platforms and I like the idea of supporting Linux. But some games may be more complex to port, if the porting cost (either the financial or mental cost) gets higher and we’re insecure about the success of a game or short of money it could be tempting to bail out. We’ll definitively consider it for every game, but I can’t promise it’ll happen every time!

As you may all know, the GOG version was late to the party, and not available at the same time as the Steam release. It is now available on their platform, DRM-Free, in case you were waiting for such a release. The reasons involved in such a delay a quite interesting, since most of us are not familiar with the constraints leading to gaps in availability:

Ethan: I did have to spend some time getting Galaxy SDK access but that won’t be an issue going forward… for their older contracts I think they have to amend them to add Linux/macOS as platforms they can distribute for, but I don’t know if their newer deals have that problem. There’s also the process of repackaging which can take some time, but they are starting to develop tools similar to SteamPipe to remove themselves from that process.

Omar: I support GOG and love the idea of GOG but their process are still very manual, sometimes cumbersome. It wasn’t clear on our side what were the steps to move forward with adding Mac/Linux there so it sorts of went lower in the priority list and then it was too late to release on the same day. Likewise, we should have planned that a little ahead.

Many thanks to Omar and Ethan for their availability to talk about the port - and for making the port to Linux happen!Don’t forget you can support them by buying the game on Steam or GOG.

There will be more to come from us in the review of Wonderboy 3 on Linux, and of course we plan to bring you more development stories in the near future as well.