The gaming industry has seen immense growth in the past decade. According to an analysis by EY, the global market for gaming in 2021 was $193.4b, up from $93.6b in 2016, and the market is only expected to continue growing with an estimated market of $210.7b in 2025.
With billions of people playing video games, gaming companies need to ensure that their data platforms can handle the demands and requirements of this massive amount of data. Online gaming, which makes up a large portion of the gaming market, often has to handle and act on millions of real-time events per second. Consider all the real-time player interactions, chatrooms, leaderboards, and telemetry data that are part of modern online games. For this reason, game developers need a real-time streaming and stream processing platform that can seamlessly scale, process, and govern these data.
This is where DeltaStream comes in – to manage and process all of the streaming data in your organization. In this blog post, we’ll cover how DeltaStream can help game developers for two use cases:
- Keeping leaderboards up to date
- Temporarily ban players for leaving games early
Connecting a Streaming Store
Although DeltaStream can source real-time data from many different data stores such as Kafka, Kinesis, PostgreSQL (as CDC data), and others, for our use cases we’ll be using RedPanda. As mentioned in an article on gaming from RedPanda, RedPanda is a cost-effective, easily scalable, and very performant alternative to using Kafka. These attributes make it a great streaming storage option for real-time gaming data.
Since RedPanda is compatible with Kafka’s APIs, users can add RedPanda as a Store in DeltaStream with the following statement:
Keeping Leaderboards Up to Date with SQL and Materialized Views
Let’s assume we have a topic called “game_results” in our RedPanda Store. We can think of the events in this topic to be the results of playing some game. So, every time a player finishes a game, a new record is logged into the topic which includes the timestamp of the end of the game, the player ID, and whether or not they won the game. This topic contains records that look like the following:
We can define a DeltaStream Stream that is backed by this topic with the following query:
Next, let’s create a Materialized View to keep track for each player how many games they have completed and how many games they have won:
By creating this Materialized View, DeltaStream launches a Flink job behind the scenes which continuously ingests from the “game_results” topic and updates the view with the latest data. In the world of online gaming, thousands of games could be finished every minute, and as these games are completed, the view will stay up to date with the latest high scores.
Next, a leaderboard can be generated by querying the Materialized View. For example, the following query will return the 10 players with the most wins:
If we wanted to find out which 10 players have the highest win/loss ratio, then we can run the following query:
Temporarily Ban Players for Leaving Games Early with Applications
Although most people enjoy online gaming, sometimes our competitive nature can bring out the worst in us. It’s not uncommon for players to leave games early, a phenomenon commonly known as “rage quitting.” For team-based competitive online games however, rage quitters can be detrimental to maintaining a fun and balanced competitive game, as the teammates of the rage quitter have to deal with the consequences of being a man down. To deal with this, gaming developers often add a timeout to players who continuously quit games early to dissuade this behavior.
For this use case, we want to detect when a player has quit 2 of their last 4 games. Let’s assume that there is a topic called “player_game_actions” in our RedPanda Store. Below is an example of a record in this topic:
The action field here describes the interaction between the player and the game lobby. Possible values include JOIN, QUIT, COMPLETE. We can define a Stream backed by this topic:
Now, let’s process this Stream of data to find out which players have left 2 of their last 4 games. While we can solve this problem writing a query with very nested subqueries, we’ll use DeltaStream’s latest Application feature for this example:
Now, let’s process this Stream of data to find out which players have left 2 of their last 4 games. While we can solve this problem writing a query with very nested subqueries, we’ll use DeltaStream’s latest Application feature for this example:
Our Application has 3 statements:
- Filter for only game ending actions including QUIT and COMPLETE
- Count the number of QUIT actions for a particular player over their latest 4 games
- Output results to “rage_quitters” where a player has quit at least 2 of their last 4 games
This query will produce its results into the “rage_quitters” topic. From here, our gaming company’s backend services can ingest and act on events from this topic in real time. Let’s see the results of this application, looking at the game actions for one particular player:
Input in the “player_game_actions” topic:
| event_ts | game_lobby_id | player_id | action |
| 2024-03-30 12:12:00 | 92E7686B | DS_Player1 | JOIN |
| 2024-03-30 12:18:28 | 92E7686B | DS_Player1 | COMPLETE |
| 2024-03-30 12:19:03 | D6860E0C | DS_Player1 | JOIN |
| 2024-03-30 12:21:33 | D6860E0C | DS_Player1 | QUIT |
| 2024-03-30 12:23:12 | CD7B8F87 | DS_Player1 | JOIN |
| 2024-03-30 12:28:54 | CD7B8F87 | DS_Player1 | COMPLETE |
| 2024-03-30 12:29:11 | 4662514B | DS_Player1 | JOIN |
| 2024-03-30 12:30:03 | 4662514B | DS_Player1 | QUIT |
| 2024-03-30 12:45:43 | D8EDB62E | DS_Player1 | JOIN |
| 2024-03-30 12:48:27 | D8EDB62E | DS_Player1 | QUIT |
| 2024-03-30 12:54:01 | 703083A1 | DS_Player1 | JOIN |
| 2024-03-30 12:59:58 | 703083A1 | DS_Player1 | COMPLETE |
| … | … | … | … |
Output in the “rage_quitters” topic:
| player_id | latest_action | event_ts | num_games_quit |
| DS_Player1 | QUIT | 2024-03-30 12:30:03 | 2 |
| DS_Player1 | QUIT | 2024-03-30 12:48:27 | 3 |
| … | … | … | … |
Use DeltaStream to Unlock Real-time Gaming Analytics
Real-time interactions are one of the core components of online gaming, and as the industry continues to grow, it becomes increasingly necessary for these gaming companies to find cost-effective, scalable, and low-latency data solutions. As a fully-managed solution powered by Apache Flink, DeltaStream is an easy-to-use, scalable, and resilient system for all real-time stream processing workloads.
In the examples in this post, we built solutions using DeltaStream to process real-time gaming data, ingesting from storage systems such as RedPanda or Confluent Cloud. In the first use case, we used Materialized Views to build a real-time user-driven solution that keeps track of each player’s wins and losses. In the second use case, we built a real-time event-driven solution to detect when a player is being unsportsmanlike, so that downstream backend services can decide how to act on these players with minimal latency. As a system that can do Streaming Analytics and act as a Streaming Database, DeltaStream is a system built for all stream processing workloads. If you want to learn more about how DeltaStream can help unlock real-time insights for your gaming data, reach out to us or get a trial.
