Game Code Integration Overview

As a general rule, we consider you to be the expert on game code. Scorbit does write code designed to pull data out of machines and reconstruct game state with our hardware, but this is different than actual game mechanics.

As a result, we have tried to design a system that is easy to integrate into different styles of game development on different sizes of processors and memory. We have tested our SDK on extremely low cost systems, such as a Raspberry Pi, or even first generation Beaglebone devices without a problem. Our network libraries are designed to be installed on OS distros of various flavors and cause as little overhead as possible.

Our game code integration is managed though a series of SDK calls that are common to all games. Not all are required, as some features, such as achievements or display integration, are optional and may require more or less changes to the original game code.

The Game Process

Adding the Scorbit SDK calls to the game loop process is generally the first order of business once pairing and provisioning tests properly. The sequence generally works like this:

1. Initiate a new game session
2. Update scores, modes, or other game state information into a structure
3. Commit the structure on a set frequency, so you can update multiple values at once
4. Process any responses, such as player identity (claiming) or achievements
5. End the session, trigger the end of the logging and session analytics
6. Repeat

If all you do is update player number, ball number, scores for each position, and the game being active or inactive, that is the minimum case and the integration will work. However, if you provide more data, at the end of a session Scorbit can present an interactive timeline to the player, that includes all modes, target, progress and achievements involved during the session.

The GameState Object

Games typically operate in a loop, continuously updating the game state, rendering frames, and handling user input. The Scorbit SDK is built to function within this loop, allowing real-time updates to the Scorbit cloud, including scores, player information, and game state changes. All SDK methods are non-blocking, ensuring updates are processed in the background without delaying the game loop.

There is a main class GameState, which object is created once during the initialization of the game app. Theoretically, once created it will never be destroyed, as the game app is usually a never ending loop.

The GameState object is used to store all the information about the game state, such as scores, player information, and game state.

There are two kinds of methods in the GameState class:

1. Game State Update Methods
2. Network Methods

Game State Update Methods

Methods: setGameStarted, setGameFinished, setCurrentBall, setActivePlayer, setScore, addMode, removeMode, clearModes, commit.

These methods are called from the game loop to update the current game state. Calling update methods with the same values are harmless, as the SDK will consider the updates only if the values has changed.

It's important to call commit method at the end of the cycle. No matter if anything has changed or not, at the end of each cycle call commit method. This will make sure that changes are considered.

Network Methods

Methods: getStatus, getMachineUuid, getPairDeeplink, getClaimDeeplink, requestTopScores, requestPairCode, requestUnpair.

These methods facilitate interaction with the Scorbit cloud, enabling the retrieval of connection status, machine UUID, and other relevant information.

• Methods prefixed with get* return information immediately.

• Methods prefixed with request* operate asynchronously and return results via a callback function. The callback must be provided as a parameter when calling a request* method.