How Facepunch Studios uses Sentry

Culturally, the common thread at Sentry is gaming. More often than not we’ll close out a day by hopping on voice chat and firing up a game. Lately, that game has been Rust.

Rust is a multiplayer sandbox survival game for the PC, Mac, and Linux. It’s inspired by titles like DayZ and Minecraft in the sense that you must collect resources and craft items in order to progress. There’s no objectives, no storyline — just you and a world full of other players trying not to die.

We got word that the people behind Rust were using Sentry to prioritize their bug fixes. After recovering from hyperventilation and several high-five related injuries, we talked to Garry Newman, creator of Rust (and yes, Garry’s Mod) about his experience.

Why did Facepunch Studios decide to use Sentry over traditional crash reporting?

I actually programmed a system similar to Sentry for Garry’s Mod years ago. In Garry’s Mod we have a scripting system and people make and release mods and add-ons. I wanted a way to alert the creators of those scripts that they were failing, and show them the errors so they could fix them. I also wanted a way to remove add-ons that were causing a ton of errors. So I made a website for it.

One thing I learned from that is that it isn’t easy to keep and process that amount of data. It’s a full-time job. That’s why when we started making Rust I started looking for alternatives. That’s when I found Sentry - which ticked enough boxes for us to commit to.

How does your team monitor Sentry? Do you integrate Sentry reporting into any other services?

We pop on every now and then to check on things. We did have it posting to Slack for a while, but found that we were getting too much information - it wasn’t useful until it was visible in its grouped, ordered form on the website.

Rust is written in C# which isn’t a native Sentry platform. How did you go about integrating with the service?

We’re written in C# under Unity. There are a bunch of libraries that already exist for Sentry on C#, but what we want to do is very simple, I wrote my own.

This was probably less than a hour of work. It’s just sending a bunch of JSON to a URL. That’s not hard to do.

Are some features more utilized than others?

When we have an error report it’s very useful to be able to break that down into categories and see who’s affected. For example we might get an error reported and see that it’s only affecting people on OSX, or people with less than 2Gb memory, or people with Intel graphics cards, or people that have been playing for over 3 hours, or on a specific map. That seems like a really obvious thing, and it is, but it’s really helpful information. It’s something that takes days or weeks to verify if you’re relying on debugging via email or support tickets.

Has your team’s culture changed since adopting Sentry?

If someone screwed up we can just link someone to the bug without explaining it. There’s no confusion about whose fault is it. Bug gets fixed.

How does the team feel about Sentry?

It’s not something we even think about, it’s that integrated into what we do. I can’t even imagine doing this stuff any other way.

Sentry completely removed the reliance on customers to report errors.

Check out the Rust Devblog for more about Rust, Garry, and Facepunch studios.