Spot the Fraudster: A multiplayer game built using Condense

Creating a multiplayer game requires infrastructure that ensures low latency, nigh flawless synchronization, and simultaneous data processing. Spot the Fraudster is a multiplayer transaction-based game built using Condense. 

Introduction

What exactly is Spot the Fraudster? 

Spot the Fraudster is a multi-player game, where players can make transactions as a celebrity of their choosing. Each player can make independent transactions of whatever amount from an overall balance. The game’s main responsibility is to detect the original owner and block any “fraudulent” transactions.  

How is this game played?

• The game works on a room-based structure where players can create and join game rooms. They can provide names to these rooms and share the room code with other players. 

• Once the host, the player who created the room, starts the game, all the players will be given the choice to choose the celebrity they want to play as. Once any of the players choose a celebrity, the same is set for the entire room. 

• All the players in the room can now start making transactions as that celebrity. The first transaction will be established as the baseline transaction, and all other transactions will be tested for fraud. 

• The game ends if a fraud transaction is performed or if more than 10 continuous suspicious transactions are detected within 5 minutes. 

• An example of a fraud transaction is another transaction done from a location more than 50 km away from the baseline within 1 minute. 

How does it work exactly?

Here's the entire flow of the app that I've made using Condense. There are multiple entry points to land into the lobby in the game, the most popular way is by navigating to the "Interactive Games section" on the website.

Based on this, with the help of our design team, we arrived on exactly how the low feds of the game should look like. I have attached the entire low feds designed in Figjam at the top of this article.

How did I build it in Condense? 

There were several options I had in terms of technologies that I could use for this project. However, I wanted to keep the architecture streamlined, for easier debugging if needed. For the UI of the game, I went ahead with ReactJS, and to achieve synchronization across all players, one of the best ways would be to use Apache Kafka. To do this, building a pipeline was necessary.  

The Pipeline

Building this pipeline in Condense was straightforward. I created three custom applications using the Custom Transform Framework (CTF) and deployed them as connectors inside Condense. I then configured three PostgreSQL store connectors to persist the processed data. To branch the flows, I used the Split Utility in Condense to split the incoming stream into separate output streams based on routing rules. Finally, I worked with our Kafka administrator to provision seven Kafka topics that the pipeline uses for ingest, processing, and distribution.

Here's a structured breakdown of exactly how I built it on Condense:

Custom Application 1

I have built a custom application that has all the logic related to room creation, joining, persona selection, etc. It publishes the rooms data to topicnew1 and the players data to topicnew2. 

Point to note: I've named kafka topics as topicnew1, topicnew2, topicnew3, etc

PostgreSQL Database

A PostgreSQL Database is also being used to build the game. It has 3 tables, for maintaining data with respect to rooms, players, and transactions.

PostgreSQL Store Connector 1

A store type PostgreSQL connector is deployed. What this does is, it consumes data from topicnew1 and inserts rooms data into the rooms table.  

PostgreSQL Store Connector 2

Another store type PostgreSQL connector is also deployed. What this does is, it consumes from topicnew2 and inserts players' data into the player's table. 

Custom Application 2

This custom application receives the transaction data from the players and publishes it to topicnew3. 

PostgreSQL Store Connector 3

Another store type PostgreSQL connector is also deployed. What this does is, it consumes from topicnew3 and inserts transactions data into the transactions table using the query. 

Split Utility

It consumes from topicnew3 and checks the validity of the amount entered. If the amount is greater than the balance, it publishes the transaction data with the message “invalid amount entered” to topicnew4. If the amount entered is valid with respect to the balance, the transaction data is published to topicnew5. 

Learn More about the Split Utility here

Custom Application 3

Here, the data is consumed from topicnew5 and checked for fraud. The transaction data with appropriate success, suspicious, or fraud messages is then published to topicnew6. 

Custom Application 2 then consumes from topicnew4 and topicnew6, broadcasts the transaction results to all the players in the room with the available balance using web socket. 

Conclusion

By building this pipeline in Condense, the infrastructure cost was reduced to zero, took away the hassle of hosting the backend services, made data flow and data synchronization very smooth and easy to understand. 

Learn more and explore the final version of the game here.

Here's a list of all the screens that were designed