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:
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:
- You make an assumption about what libraries are present on the system.
- 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
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:
- Statically linking with all of your dependencies.
- 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).
On Friday I spoke at Droidcon UK 2012, and it was my very first conference talk, titled The Butler Did It: Continuously building & enforcing app quality using Jenkins.
I did the talk together with Christopher Orr, and the topic was using Jenkins CI and Gerrit to improve app quality when building Android software. It also included a short rant about the Android NDK. I thought it went surprisingly well, especially considering I was fueled by only 5 hours of sleep!
The turn-out was great - every seat was occupied, and we got a lot of interest in the form of questions afterwards. Here you can find the source material for our talk - our slides are pretty light on text, so we also have a version with a more fleshed out version of our speaker notes.
I’ve been told by the Droidcon organizers that they’ll publish the video from the talk. I’ll post an update once that’s available.
In addition, the demo doesn’t have any audio or captioning so far, but hopefully we’ll update soon with a narrated or captioned video.
If you’d like to contact me or Chris, the contact information is on the last slide.
EDIT April 2014: I finally found the video of the talk, it requires a (free) sign-up, and is available on SkillsMatter.com
Here’s the first “dev diary” video for Arcane Deathmatch.
So far the game has:
- Working networking
- Simple network lobby
- Basic UI - leaderboard, spell shop
- Three initial spells (magic missile, infernal nova, teleport)
- A very boring level
- A reward system for kills
- A round system with a “last man standing” victory condition
Yesterday I asked two coworkers to play Arcane Deathmatch with me, to get an initial feel for what direction I’m going in. It was a great experience, and a great motivator: I finished up a large amount of basic implementations of features in the last week, so that it’d be ready for the playtest.
I highly recommend doing this early for people working on hobby projects - it helps you focus on shipping and creating a real product, and motivate you. During the time leading up to the play-testing, I started thinking of every issue I’ve filed in the bugtracker in terms of “how important is this to testing gameplay”.
Some very useful things I learned include:
- Controls need to be thought about very carefully, and tested on real people. What seems fine when you’re just testing around the environment is experienced completely differently when you’re in an action-packed fight.
- While art is not important to the “fun” in this concept, UX is very important - even early on. People need to find the information and actions they care about!
- Pacing is very important, and hard to get right - there are a lot of factors that influence it, many of which I haven’t gotten around to implementing yet.
There were a lot of other subtle bugs and improvements I found through this little hour of gameplay. As an example, camera movement is currently not animated, which makes Teleport very jarring.
For now, I’m back to implementing some new content (especially a more interesting level and more spells) - and then I can get a better feel for how pacing and balancing needs to be done.