Handle errors, expect the unexpected!

 

Avoid encountering uncaught handle errors in your game

Quite frighteningly, developers who are new to distributed applications are generally more susceptible to making false and costly assumptions such as: infinite bandwidth, homogeneous networks and zero latency… spine-tinglingly terrifying, right?

So what can you do as a game developer to avoid these common pitfalls and avoid encountering uncaught handle errors in your game?

I’ve seen many examples of this over the years and so I want to share some wisdom to help you stay out of the woods when tackling error-handling in your game.

 

Considerations

Let’s take the ChilliConnect LoginUsingMobileDeviceID call as an example.

Sure an error is “Invalid Game Token”, but it’s safe to assume that you’ve carried out testing to have gotten that far! So how about a “Temporary Service Error”? This type of error isn’t strongly defined and could be a result of a multitude of causes, none of which really matters. However, your game received them so how will it respond?

If you rhetorically answered “…ummm, not well” then you wouldn’t be alone!

Now let’s say that you’ve logged in and you’re syncing your game Catalog, and updating a piece of Player Data: why not create a Match to start playing? Remind yourself that you need to code a dependency between those calls and ask yourself what will happen is the Match call runs into some issues. Will the Player Data update still be valid at that point?

 

Key Learning

• If an error is defined, your game will receive it at some point.
• If you have a low traffic game, your game might not receive an error for some time.
• If you have a successful game making millions of API calls your game will receive an error more often than you realise.

There isn’t anything wrong with ChilliConnect, honest!*, any network service you use will have similarities. Robust games that your players can rely on require you to think through these use cases and ensure you don’t leave issues for them to encounter.

If at this point you’re thinking “these errors don’t apply to me” or “I’ve thought everything through” then you should check out the list of fallacies of distributed computing.

• Did the network just drop out?
• Did the network speed suddenly go from fast to slow, vice versa or is it displaying signs of inconsistency?
• Is there a packet loss, massive latency, or no network at all?

 

• Read the documentation
• Read the errors
• Don’t just code to the happy path
• Expect the unexpected
• Test

…and most importantly, keep creating amazing games.
 

*In fact, in the unlikely event of encountering a problem the ChilliConnect Unity SDK will automatically retry a call behind the scenes.

 

If you’re developing on our SDKs here’s a bonus Halloween treat…
 

Handling errors in the Unity SDK

Action<SetPlayerDataRequest, SetPlayerDataResponse> successCallback = 
    (SetPlayerDataRequest request, SetPlayerDataResponse response) =>
{
    //success no errors here
};

Action<SetPlayerDataRequest, SetPlayerDataError> errorCallback = 
    (SetPlayerDataRequest request, SetPlayerDataError error) =>
{
    //Available attributes
    // - error.ErrorCode - e.g. 7001 PlayerDataWriteConflict
    // - error.Errordescription - e.g. Player Cloud Data Write Conflict
    // - error.ErrorData - e.g. {"Existing": {"Key":"K1"...}, "Attempted": {"Key":"K1"...}, }
};

var requestDesc = new SetPlayerDataRequestDesc("CharacterData", "NewValue");
requestDesc.WriteLock = "1";
storage.SetPlayerData(requestDesc, successCallback, errorCallback);

 

Handling errors in the Scripting SDK

var sdk = ChilliConnect.getSdk("2.14.0");

var = newItem = { "Name": "Rope", "Strength": 7 };
var rucksackContents = [];
rucksackContents.push(newItem);
var initialWriteLock = "1";

try {
    var saveRucksackResponse = ChilliConnect.CloudData.setPlayerData(
        "Rucksack", rucksackContents, initialWriteLock
    );
}
catch(e)
{
    //Available attributes
    // - e.code - e.g. 7001 PlayerDataWriteConflict
    // - e.message - e.g. Player Cloud Data Write Conflict
    // - e.data - e.g. {"Existing": {"Key":"K1"...}, "Attempted": {"Key":"K1"...}, }
}

 

Sources

Fallacies of Distributed Computing
Happy Path

 
New Features
Admin API
Leaderboard Partitions and Resets