Porting games to GNU/Linux (or "Linux" for short)

Scroll or press Space to continue...
There's also a video of this presentation.

Who am I?

I've worked on some games you might have heard of

And others you might not have heard of

I also help other devs support Linux

• Advance
• Airscape: The Fall of Gravity
• Another World
• Armello
• Assault Android Cactus
• BANG BANG BANG!
• Basingstoke
• Bastion
• Broken Age
• CrossCode
• Day of the Tentacle Remastered
• Duet
• The Dwarves
• Expand
• The Fall
• The Fall 2: Unbound
• Fatal Theory
• Firewatch
• The Girl and the Robot
• Grim Fandango Remastered
• Guns of Icarus Online
• Hand of Fate
• Hero-U
• Hue
• The Journey Down
• Killing Time At Light Speed
• The Magic Circle
• The Maker's Eden
• Massive Chalice
• Moirai
• Overgrowth
• Overload
• Oxenfree
• Psychonauts
• RIVE
• SkyScrappers
• Slow Down, Bull
• Snakebird
• Spacebase DF9
• The Stanley Parable
• Stasis
• That Dragon, Cancer

And more!

My current project is a fantasy first person/
text adventure hybrid game (and engine)

So, Linux game porting...

Why bring games to Linux?

• Expanded markets and opportunities
• Linux users are often willing to pay more^{[1] [2]}
• Linux users are often vocal^{[1] [2]}
• Linux users are often passionate^{[1] [2] [3]}
• Added value for existing customers who may wish to change OS
• More environments/compilers means more opportunities to discover bugs and improvements for all platforms! (more relevant when Linux support is done in-house)^[1]

Wolfire's 2008 blog post on this stuff is still relevant!

What is porting?

Changing software to run in an environment that it wasn't originally designed for.

Primarily, porting consists of:

• Replacing incompatible dependencies
• Rewriting existing incompatible code
• Writing new environment specific code

How can F/OSS help?

• F/OSS libraries are typically cross platform
• Access to source code for dependencies can make debugging easier
• F/OSS libraries can be modified to fix bugs or add functionality without waiting for upstream
• Active F/OSS projects can have helpful, knowledgeable communities surrounding them^[1]
• F/OSS projects can be valuable implementation reference^[1]

There are lots of useful F/OSS projects

Here are some examples:

• Dev tools/environments
  • GCC
  • LLVM
  • Steam Runtime
  • Eclipse
  • KDevelop
• Middleware
  • SDL (and friends)
  • OpenAL
  • Theora
  • Vorbis
  • Libjpeg
• Compat layers/drop-in replacements
  • MojoShader
  • MojoDDS
  • ToGL
  • FNA

How does the F/OSS ecosystem benefit from games supporting Linux?

• Sometimes leads to new F/OSS projects having existing Linux support out of the box (libraries^[1], engines^[2], whole games^[3])
• Upstream bug reports
• Upstream patch commits
• Exposure for F/OSS projects
• Easier migration paths for users looking to switch to Linux
• More mature tools for F/OSS game developers to make use of^[1]

So, how do you port a game then?

Different porters have different approaches, but here's a general guide:

• Get it compiling
• Fix it up
• Package it

Simple!

Not that simple!

So, how do you port a game then?

A bit more detail:

• Get it compiling
  • Set up a build environment
  • Replace problematic deps
  • Stub out problematic code

So, how do you port a game then?

A bit more detail:

• Fix it up
  • Write/rewrite platform specific implementation for stubbed code
  • Address platform specific bugs
  • Implement platform specific best practices

So, how do you port a game then?

A bit more detail:

• Package it
  • Bundle deps (if needed)
  • Build package manager packages (if needed)
  • Make setup application (if needed)
  • Write a launch script (if needed)
  • Tar it all up (easiest!)

My porting workflow for DotT

• Set up build environment ahead of time
• Get the codebase to compile
  • Copy Mac build system (tweak as needed)
  • Stub out anything that isn't fixable in under a minute
• Address any remaining platform specific #if directives
• Look through all build scripts for any remaining platform specific stuff
• Rewrite any remaining stubbed code
• Focus on fixing crashes/behavioural differences

My porting workflow for DotT

What kind of hurdles can you face?

• Learning (not just the project, but also deps and platform APIs)!^[1]
• Licencing (open and closed)
• Incompatible dependencies
• Dependency idiosyncrasies^[1]
• Case sensitivity
• Compiler idiosyncrasies^[1]
• Not breaking other platforms
• ...
• Distro compatibility

Some advice

• Take breaks, exercise and eat well (healthy people do better work!)^[1]
• Don't be afraid to ask questions (if a 2 minute question will save 2 days of work, that's a no brainer)^[1]
• Embrace others' coding styles/decisions (without hating them)
• Respect platform best practices (XDG, locale handling, etc.)
• Avoid getting isolated
• Porting is not for everybody and that's OK

Day of the Tentacle Remastered is available now for GNU/Linux (and some other less exciting platforms). Visit dott.doublefine.com for more information.

For more details on my Day of the Tentacle Remastered port, along with insights from a range of other porters, visit CheeseTalks.net

This presentation was created using Stack