State events duality

When talking about data sources in esports, not all of them are created equal. Each source can differ across a number of aspects.

Data accuracy, speed and granularity determine which use cases it can be used for, whereas aspects like data structure and the delivery method can heavily impact the time needed to integrate with a data source.

Figure 1: High-quality, detailed live widgets like the above are only possible when the data source is accurate, fast and offers a high level of detail.

Whilst all of these aspects are important and interesting topics on their own, we’ll be diving into a more fundamental distinction today, namely whether a data source is state-based or event-based.

The former only gives you a look into the current state of the game, while the latter gives you an idea of how it got to that state, tracing out the entire course of the game. In this post we’ll introduce each separately by looking at some real-life examples and delve deeper into how both interact with one another.

State

The dictionary ¹ defines state as:

A condition; a set of circumstances applying at any given time.

In esports, the game engine keeps track of the most up-to-date in-game state. Examples of this would be:

• The total kills of a player throughout the game
• Whether or not a team has won the game already
• A player’s current money and inventory

The in-game state updates continually over time. The most common strategy is to take samples at a predetermined time interval (e.g. once per second).

Figure 2: Sampling game state at a fixed time interval.

A real-life example of such a state-based data source is Valve’s Game State Integration (GSI) format, in which the state looks like below.

{
  "player": {
    "team2": {
      "player0": {
        "name": "OG.N0tail",
        "kills": 6,
        "deaths": 2,
        ...
      }
    },
    "team3": {
      "player1": {
        "name": "EG.Fly",
        "kills": 4,
        "deaths": 3,
        ...
      }
    }
  },
  ...
}

Events

The dictionary ² defines an event as:

An occurrence; something that happens.

In esports, an in-game event can be activated by a number of triggers, ranging from a player or team action to in-game logic. Examples of this would be:

• A player killing another player
• A team winning a game
• A player purchasing an item

In-game events occur throughout the game. The most common strategy is to push out information about the event as it occurs.

Interaction

If you have been following along closely, you might have noticed the interaction between state and events, which is illustrated below. In-game events happen at arbitrary times and change the in-game state over time.

Figure 3: In-game events changing state over time.

For the example of a player killing another player, the event causes both the involved players’ in-game states to change, incrementing the attacker’s total kill count and the victim’s death count.

While in a perfect world, events and state are perfectly interchangeable and one should be able to be derived from the other and vice versa, there’s practicalities that make it hard to work with just one or the other.

If only state samples were available, one would need to try and derive the events that happened in between said samples by looking at what changed. The higher the sampling frequency, the more reliably events can be derived. However, the sampling frequency would need to be infinitely high to make sure only state changes caused by one event at a time would be picked up. One problematic example would be multiple kill events happening in rapid succession, between two state samples. When looking at the difference between these samples, one cannot possibly derive which player killed which other player.

If on the other hand only events were available, the situation would be less dire. Now at least we have a full picture of what exactly happened throughout the game, but at the cost of not having the in-game state readily available from the data source.

Conclusion

Understanding how fundamental concepts like state and events interact with each other forms the key to solving the drawbacks of data sources that serve each respectively. In a next blog post of this series we will dive into how this very interaction has inspired GRID’s in-house developed data format, which solves the outlined problems with each data source respectively by tying state and events closer together.