This post is going to sound like one of those late-night infomercials.

Forget everything you know about debugging a mobile game!

Though a little cheesy, the sentiment behind it holds true. Embrace is nothing less than a brand new way to monitor and debug mobile games. Our approach is built from the ground up to answer this one question: What information would you need to go from any user complaint to understanding what went wrong?

In other words, how could you debug any issue with certainty?

In this post, we’ll cover the following:

  • Why are mobile games uniquely difficult to debug?
  • How is Embrace different from traditional mobile game monitoring solutions?
  • What are the benefits of Embrace’s approach?
  • How can you know if Embrace is right for you?
  • What can Embrace do for your team today?

Why Are Mobile Games Uniquely Difficult to Debug?

While mobile games vary in their complexity, we can think holistically about the problem space of tracking down any given bug. We can think about it broadly containing six categories.

  • Your code
  • Your backend
  • Other people’s code
  • Other people’s backend
  • The user’s device
  • The user’s environment

We’ll go into these categories in a second, but before we do that, think about how you would track a failure in an individual event from each of these areas.

For example, if a third-party vendor’s backend goes down, how long will it take you to discover this? Or if an issue only occurs when a user’s device is in low power mode, how would you make that connection?

What about trying to debug errors that span multiple categories?

If a user complained that the game froze at a certain point, how would you go about determining what the root cause is? It could be heavy data processing, a blocking network call, the device being low on memory, or some combination of all three.

In other words, how can you discover the root cause with certainty?

We'll let that question sink in a bit as we dive into each of the above categories. Let's explore why it is difficult to debug the types of issues that can occur in each of them.

Your Code

You’re probably logging every transition in and out of state machines in your game. When a user complaint comes in, you can search the logs to reconstruct the path the user took through your game.

If the problem was a crash, you know to start at the end of the session and work backwards. You know that at a certain point, something in your code broke.

This approach to debugging has gaps whenever an issue can’t be easily revealed through logs.

Here are a few such examples:

  • If a failure only happens when the phone is in low power mode
  • If a failure is the result of a device-side networking error (e.g. timeout or connection error)
  • If a failure is due to a third-party SDK
  • If a failure occurs when the user force quits the game after a frozen ad load

As new issues arise, you can add more and more logging to cover each new case, but this results in you always being on the back foot. You’re burning time manually building visibility.

You’ll never “finish” adding logs because the truth is they cannot provide a complete picture.

Your Backend

You have backend monitoring in place. When users complain that the game freezes or stutters, you check your dashboards and scratch your head. When every network call returns a speedy 200, how do you find the problem?

After all, the server-side truth is not the same as the device-side truth.

Here are a few examples of what could happen device-side after “successful” network calls:

  • The device fires too many calls, which leads to timeouts when processing the responses.
  • The user walks into a dead zone and loses connectivity, resulting in a connection error.
  • The main thread has a blocking third-party call, which prevents your first-party calls from firing until it completes.
  • The game is frozen because of how long it takes to process heavy assets.

In other words, if you don’t know how your game technically executes on the device, you will lack crucial visibility.  

Other People’s Code

You’re going to have other people’s code in your game. Whether it’s for attribution, running ads, product analytics, error monitoring, etc., the important thing is to know how this other code affects your game. Otherwise, you are risking your business on blind trust.

Here are some examples where third parties can hurt your mobile game:

  • They send blocking network calls on the main thread, forcing your users to stare at frozen screens.
  • They fire too many network calls, which leads to slowdowns.
  • They have bad code that causes crashes.
  • They run too many cleanup tasks, resulting in expired task crashes, cold starts, and corrupted data.

The introduction of third-party code means your game is ultimately left holding the bag for any performance and stability issues it causes. If your monitoring solution cannot surface these bad actors, your team will waste time chasing down user complaints that are outside of their control.

The User’s Device

Mobile games do not run on a PC, console, or in a web browser. They run on a variety of devices with different resource constraints.

Here are some areas where the device itself can reveal bugs:

  • The device doesn’t have enough memory, which results in system kills after low memory warnings.
  • The device’s CPU is pegging because it cannot handle the amount of processing your game requires.
  • The device enters low power mode because your game drains the battery quickly.
  • The device stutters because the hardware cannot handle the workload to support high frame rates.

If your tooling doesn’t let you identify performance and stability differences across devices, then you are risking churn. You should know which devices your users are on, which are most valuable to your business, and which ones have bugs with the largest effect on your bottom line.

The User’s Environment

Your mobile game is not being played in one controlled environment. Your users play it around the world, in many places with vastly different and changing network connectivities.

Here are some examples of how the environment can cause bugs:

  • The user walks through a dead zone, which leads to freezes and connection errors.
  • The user lives in an area with bad WiFi that struggles to handle the amount of data your game is sending from the backend.
  • The user loses connectivity during a key user flow, which leads to a crash and a loss of their progress.

If you don’t know the different environments in which your users are playing your game, you won’t test under real-world conditions. Your code won’t stand on its own in everyday scenarios that your users will go through.

How Is Embrace Different from Traditional Mobile Game Monitoring Solutions?

Embrace is a revolutionary solution for debugging mobile games. It offers the ability to debug at the level of the user experience.

  • You no longer have to collect different categories of data across tools.
  • You no longer have to manually stitch data together to reproduce a user session.
  • You no longer have to waste time trying to figure out what happened.

Embrace collects 100% of user sessions, and within those, it collects the technical events and user actions that recreate the user’s journey within your game.

In other words, at every stage during your mobile game, Embrace will show you the following:

Behavioral Truth:

  • What did the user do (e.g. swipes, scrolls, button presses, rage taps, force quits)?

Technical Truth:

  • What events fired and what were the results (e.g. network calls, logs, handled exceptions)?

Device Truth:

  • What was the current state of the device (e.g. memory, CPU, battery, frozen screen)?

Environmental Truth:

  • What was the network connectivity (e.g. WiFI, cellular, no service)?

Game Truth:

  • What happened in the game (e.g. state machine transitions, screens, webviews)?

For any user’s experience, you can track exactly what happened. Embrace is the fastest way to go from a user complaint or bug report to understanding what happened and putting out a fix.

What Are the Benefits of Embrace’s Approach?

It’s one thing to provide a lot of data, and another thing completely to provide actionable data. After all, you could log everything in your game and still not effectively troubleshoot issues. Where Embrace shines is the combination of comprehensive data and its immediate digestibility.

Let’s go through a hypothetical example to shed some light on just what Embrace can provide you. You’ve got a mobile game, which means you’ve got users complaining about it in many ways — on social media, bad app store reviews, blogs, forums, etc.

Let’s say a new complaint has surfaced, claiming that your game freezes. Different users say it freezes at different places. Worse, there isn’t really much in common in these various bug reports. With traditional tooling, you could take the information your users provided and start trying to manually reproduce the issue. That could take hours, days, or just simply not be feasible. Perhaps it’s an edge case where very precise conditions need to align to trigger the freeze.

Bottom line: You don’t want your game developers to burn time chasing bugs without much to go on. The result is that bugs that could be fixed remain in your game because of inadequate tooling.

How could Embrace help in this situation?

You identify the user in your database from their bug report. After searching for them in the Embrace dashboard and pulling up their game sessions, you pinpoint the bad session and start investigating.

Scenario #1

You scroll through the Session Replay looking for something that could cause a freeze. And there it is — a broken webview. It’s a failed ad load. The user was stuck looking at a blank white screen, and there are many rage taps indicating their frustration. You can now investigate whether this is a recurring problem, in which case you can approach your ad vendor — proof in hand — to find a resolution.

Scenario #2

The Session Replay reveals a really slow network call to your backend service that calculates matchmaking. Other sessions also have these slow response times. You let the backend team know the problem — proof in hand — and they investigate the latency issue.

Scenario #3

The Session Replay shows that the user lost their network connection right before the freeze. After recreating the session locally, you discover the game isn’t notifying the user with a helpful dialog in this situation. By adding code to address this, your users will now know when the network is causing issues. This reduces the number of bug reports that are outside of your control.

Scenario #4

The Session Replay indicates that the device entered low power mode right before the freeze. You hadn’t coded this section of the game to account for resource reductions during low power mode, so you start working on a fix immediately.

Scenario #5

The Session Replay shows that the device emitted a low memory warning right before the freeze. You investigate and discover in this specific game state that your game is inadvertently loading too many heavy assets at the same time. After reworking the loading logic, you eliminate the large memory footprint.

These scenarios are just a few examples of the many ways that Embrace empowers your team to save time by immediately showing them what led up to the issue. And since Embrace does not sample sessions, you get data from every single session. Thus, even if a user experience did not end in a log or other traditional event you would account for, you would still be able to diagnose with complete information.

How Can You Know if Embrace Is Right for You?

Think about how your team currently debugs:

  • How much of the process is manual?
  • How much of the process is guessing?
  • How much of the process is time-consuming?
  • How much of the process is flying blind?
  • How much of the process ends with, “We can add more logs and rerelease”?

Mobile gaming is growing fast, and the competition has never been tougher. You cannot rest on your 99.99% crash-free rate and assume that is sufficient to retain users. Increasingly, mobile games are competing on performance.

How would your current tooling show you that your 99.99% crash-free game had 20% of your users force quit in frustration at slow load times?

You need to spot every aspect of your game that doesn’t deliver a great user experience. And then you need to fix it.

You need an efficient, comprehensive solution for debugging in production.

Without Embrace, you can pretend that you know about every issue.

With Embrace, you can actually know about them.

What Can Embrace Do for Your Team Today?

Embrace is an observability and debugging platform built for mobile teams. We are a comprehensive solution that fully reproduces every user experience from every single session. Your team gets the data it needs to proactively identify, prioritize, and solve any issue that’s costing you users or revenue.

Need help improving the performance and stability of your Unity games? Take our SDK for a spin!

Want to learn best practices for scaling your mobile applications? Check out these helpful eBooks!

Want to see how Embrace can help your team grow your non-game app with best-in-class tooling and world-class support? Request a customized demo and see how we help teams set and exceed the KPIs that matter for their business!