Factorio and the viability of Couch Co-Op on Linux

Several years ago I would often play multiplayer with my brother and a friend the old-fashioned way: We grabbed a few copycat Xbox 360 controllers (genuine ones had cost way too much pocket money!) and played in splitscreen mode. We’d often buy games with our pocket money with local co-op in mind. However, couch Co-Op support in PC games has been terrible since forever, so even back then, we’d often rely on a piece of open source software called Nucleus Co-Op to play games like Borderlands 2 or Don’t Starve Together.

This was a long time ago, but lately I’ve gained an interest in game ownership, and more importantly LAN multiplayer, since I have been through more than a few Terraria and Factorio playthroughs with friends. I’ve also learned about multiseat, a rather obscure feature of desktop Linux, and these reignited my memories of my old gaming sessions. I wanted to see how feasible something like that would be on a modern desktop Linux system under Wayland, the shiny new display protocol.

Unfortunately no Nucleus Co-Op equivalent exists for Linux. There is this shell script which seems to launch multiple Weston sessions and uses Firejail blacklists to assign gamepads to each compositor. However I have yet to try this script, even though its blacklisting looks better than what I ended up doing with Factorio:

Running an instance in gamescope (embedded in sway) and running an other regularly (only game specific hacks applied):

# `a` player using gamepad in gamescope
gamescope -- ./game/bin/x64/factorio --config foo/config/config.ini
# `b` player using keyboard and mouse without gamescope
./game/bin/x64/factorio --config bar/config/config.ini

And the result: 2 players, ‘a’ and ‘b’ in the same LAN game, one playing with a gamepad in a gamescope session, the other playing with keyboard and mouse

This method has worked for the 5 minutes I’ve spent playing like this, but it has a few quirks:

Factorio, like many other games, won’t allow running multiple instances without hacks
It was finicky to set up (this is on me for not trying the aforementioned script)
Both instances can get input from any input device, there is no separation
Possibly inconsistent tiling

Two of these are game-specific issues.

This is a GOG copy of Factorio and a global lock file is built into the Linux edition (The Windows version probably has something similar but I haven’t checked) so you don’t mess up your save files. To work around this, you need to create two config files (copying the default config.ini is good enough) and set two separate write-data directories. You then need to launch the game with your new config, the top of which would look like this if you were using a foo directory in the game’s root directory:

; version=10
; This is INI file : https://en.wikipedia.org/wiki/INI_file#Format 
; Semicolons (;) at the beginning of the line indicate a comment. Comment lines are ignored.
[path]
read-data=__PATH__executable__/../../data
write-data=__PATH__executable__/../../../foo

The second point is just a matter of automating the workarounds (using Goldberg Emulator for Steam titles, creating separate game profiles, etc.) which is something Nucleus Co-Op has already done for a lot of titles.

The third is partially solvable, using the same trick as Co-Op On Linux uses: blacklisting every input device besides the keyboard+mouse combo or gamepad that is “assigned” to the game window. This of course cannot stop the root compositor from receiving input events, but I don’t remember it being any more polished with Nucleus Co-Op either.

The last is actually a feature of desktop Linux, this is a matter of how your compositor handles window management.

I think if someone puts in the work, we could have a decent couch co-op experience on Linux. The bits are certainly there to make this work, it’s just severely under-documented. Note that this is just for Linux-native games, but I don’t think it’d be too difficult to incorporate WINE in such a system either.