Unreal Engine and continuous integration presents some unique challenges (shared by some other game engines as well) and most CI tools aren’t a great fit for those, so this post enumerates what those challenges are and what is actually required of a CI tool for our use cases.

When I wanted my personal Flutter app to distribute iOS builds from a GitHub workflow using TestFlight, I couldn’t find a good cohesive guide to setting it up. The process was a bit nuanced and time consuming to get right.

In the end I created a GitHub workflow that automatically publishes whenever I push a versioned tag to GitHub – it builds the project, signs it, and publishes that build to TestFlight.

Below I’ve provided the comprehensive set of steps you need to set this up from scratch, which I reproduced using a public sample repository for your reference.

Registering as a potential web browser in modern Windows versions is mostly just about configuring a handful of registry keys, and there’s nothing particularly tricky about doing so in Rust. Exactly what you need to configure (and why) can be hard to divine, and so I’ll walk through the various registry keys that are expected, why, and show sample Rust code for setting them. In addition, there’s a small call to SHChangeNotify that’s required to refresh the OS' notion of available browsers, and that requires a snippet of unsafe Rust code.

I figured out all this while writing an app that pretends to be a browser and forwards URLs to the appropriate browser based on pattern matching. I named it bichrome, and you can find a full example of URL registration in bichrome’s src/windows.rs, or keep reading to learn why these parts are needed and how to adapt it to your program!

I gave a brief presentation followed by a Q&A for a class at the Academy of Interactive Entertainment at their Seattle campus. It was a part of their “Lunchbox Speaker” series where they host various speakers from the game development industry.

It talks about some of the challenges we at Undead Labs encountered developing State of Decay 2, and both practical steps we took to address it as well as some of my opinions on how to avoid or address those things in the future.

Here are the slides from that talk:

Updated 2014-06-03: Added information about STEAM_RUNTIME variable under the new embedded search path subsection.

Updated 2016-01-03: Fixed dead links to Valve’s steam-runtime patches collection.

If you’ve ever had customers report errors like these, then this post might be for you:

  • ./foo: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.16` not found (required by ./foo)
  • ./foo: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory

In my previous post about self-contained distributions, we started looking at how the steam-runtime project works. In this post, we’ll make the steam-runtime work for us in a self-contained distribution that you can ship without depending on Steam.

I will present two possible ways of doing it:

  1. Using a wrapper script.
  2. Using an “embedded search path”.

If you’re wondering why you would prefer the second approach, that section starts with a rundown of the benefits inherent to it!

Distributing a game on Linux can be a little intimidating, and there are definitely pitfalls. The main problem is making sure your game runs on all of your users' machines, and outside of hardware and drivers, the root of the problem is usually one of two things:

  1. You make an assumption about what libraries are present on the system.
  2. You make an assumption about what version of a library is present on the system.

This is very easy to accidentally do, as adding -lSDL2 to the linker’s command line might work perfectly fine on your machine, but you forgot that you installed SDL2 by hand 4 months ago. Another cause could be that while your Linux distribution came with SDL2 preinstalled, another distribution (that your users use) might not. Finally, maybe your distribution came with v2 of some library, but your users only have v1.

The best way to avoid this is to make your game distribution “hermetic,” meaning that it contains all of its own dependencies. There are two main ways to achieve this:

  1. Statically linking with all of your dependencies.
  2. Dynamically linking with all of your dependencies, and pointing the system’s runtime loader at a copy of the libraries you bundle with your game.

Statically linking comes with its own set of problems, so this post talks about solving the problem with dynamic linking.

Introducing the steam-runtime

It turns out that Valve has already solved this problem in Steam with something called the steam-runtime. Contrary to what its name indicates, it has no direct dependency on Steam nor does it even assume that it is installed. It is merely a controlled set of open source libraries (with some patches) and associated tools to use those libraries - to make your game build hermetic.

Mac and Linux have two similarly named concepts that both deal with dynamic loading, that behave quite differently: @rpath (under Mac OS X’s dyld) and DT_RPATH (or just rpath, under Linux' ld.)

Having done development (and more importantly, deployment) on both of these platforms, I’ve experienced first-hand how those concepts can get a little jumbled in your mind, so here’s a brief overview.

I have decided to retire my old tumblr blog in favor of this new octopress blog. The reason for doing so is both that when it comes to a blog, I’d really like to own my own data, and that tumblr’s feature-set has bothered me in the past (with no way of improving it.)

With octopress all my posts are simple markdown documents managed in a git repository, that gets transformed into static content. That way, I both have the raw input for my blog, but also static output, which I can host anywhere else if I decide that I don’t like GitHub any more.

I’m excited by the release of Unreal Engine 4 (by Epic Games), and I figured I’d put a couple of my thoughts down in writing.

First, let me emphasize something that hasn’t been clear about this release: While UE4 uses a subscription model, a continued subscription is only required to get access to updates. Even if you cancel your subscription, you retain license to use & modify the engine. Don’t believe me? Read the second to last paragraph of section 3 in their EULA. You still have to (of course) follow the EULA and pay Epic 5% of your revenue from using UE4, even if you don’t have an active subscription. On the topic of the EULA: It is written in fairly accessible english. Yay!

I’ve seen people compare this release to Unity, and aside from differences in technology, one of the big things to note is that Unity keeps their source very close to their chest. If you’re a Unity developer, and Unity Technologies goes away or the Unity engine has limitations that you care about but they don’t, then you’re hosed unless you go the route of getting a custom source license (which I’d guess isn’t cheap). You have no source access, so you cannot easily remove those limitations, and you cannot add support for new (or old) platforms. The same thing was true for the Unreal Development Kit (UDK), which was the “non-AAA” license option for UE3, but for UE4 it looks like you’ll never be locked down like that.

Lastly, Epic is trying to encourage an open development process - both by them and by their licensees. That’s pretty cool - I cringe when I think about how many different times the same things have likely been implemented / fixed in the Source engine, both by Valve’s licensees, but also Valve developers. Epic realizes that their advantage is not (mainly) their specific implementation, but the sheer amount of engineering effort that has been put into making UE4 what it is. If licensees actually contribute back, then that will further UE4.

Disclaimer: I don’t speak on behalf of Valve Software, and I have no association with Epic Games. I have not looked at the source of Unreal Engine 4 (yet).