Arcado Network Brings Decentralized Reward Systems to Video Games

The Arcado Network focuses on bringing a decentralized reward system to any multiplayer game by providing game developers with a generic API. The API is capable of performing many operations on the Lisk network through the Lisk SDK, such as game profile creation identified by a Lisk address, or a signal at the start of a game. 

The goal of this generic API is to abstract the underlying Lisk logic. This means a game developer can solely focus on building their game. Hence, there is no need for the developer to have a deep understanding of the Lisk project. 

To summarize, we offer game developers an easy-to-use gateway to implement decentralized gamification.

Example

For example, I’m playing the multiplayer game “Call of Duty” with friends. I can create a “room” where all friends with a Lisk account can log in. The room creator sets an entry fee which has to be paid by every participant. The entry fee is locked and will be distributed at the end of the game to the winners.

Furthermore, the room creator can set distribution for the payout of the winnings. For example, first place receives 50% of the prize money, while the second and third place get 30% and 20% respectively.

Rules 

The following rules apply to game creation with the Arcado Network API:

• Any user can create a room, (and becomes the owner of a room).
• A room must have the following four properties:
  ○ Room Title
  ○ Entry Fee
  ○ Max Number of Players
  ○ Prize Distribution
• The room creator can signal the start and stop of a game.
• The room creator is responsible for entering match results.

Implemented Custom Transactions

The Arcado Network proof of concept consists of the following four custom transactions:

• Create Room
• Join Room
• Start Room
• end Room

#1. Create Room

const errors = [];
const genesis = store.account.get("16313739661670634666L");
let asset = {
    games: [],
    ...genesis.asset
}

asset.games.push({
    createdBy: this.asset.address,
    name: this.asset.name,
    roomId: this.asset.roomId,
    gameId: this.asset.gameId,
    entryFee: this.asset.entryFee, // string
    participants: [this.asset.address],
    distribution: this.asset.distribution,
    maxPlayers: this.asset.maxPlayers,
    status: 0 // 0 open to join, 1 started, 2 ended
})

const updatedGenesis = {
    ...genesis,
    asset
};
store.account.set(genesis.address, updatedGenesis);

The first Gist snippet shows how we load the genesis account, (16313739661670634666L) as we use this account for storing all the games. A games array keeps track of all the created game rooms.

Furthermore, we lock the

entryFee

const player = store.account.get(this.asset.address);
const playerBalance = new utils.BigNum(player.balance);
const entryFeeBalance = new utils.BigNum(this.asset.entryFee)
const updatedPlayerBalance = playerBalance.sub(entryFeeBalance);
const updatedPlayer = {
    ...player,
    balance: updatedPlayerBalance.toString()
}

store.account.set(player.address, updatedPlayer);

#2. Join Room

The join room custom transaction will also be locked as well the

entryFee

• Does the game exist?
• Did we reach the maximum number of participants?
• Does the user have sufficient balance?

const game = genesis.asset.games.find(game => game.roomId === this.asset.roomId)
if (!game) {
    errors.push(
        new TransactionError(
            '"asset.roomId" does not exist',
            this.id,
            '.asset.roomId',
            this.asset.roomId
        )
    );
    return errors;
}

if (game.participants.length >= game.maxPlayers) {
    errors.push(
        new TransactionError(
            'Game is already full',
            this.id,
            '.asset.maxPlayers',
            game.maxPlayers
        )
    );
    return errors;
}

const playerBalance = new utils.BigNum(player.balance);
if (playerBalance.lt(game.entryFee)) {
    errors.push(
        new TransactionError(
            'Insufficient balance for player',
            this.id,
            '.asset.entryFee',
            player.balance
        )
    );
    return errors;
}

#3. Start Room

The start room transaction will change the status of the room to “started” (represented by ‘1’). However, more importantly, it contains a check to see if the transaction sender is actually the owner of the room. See the snippet below to see how we check for this.

const genesis = store.account.get("16313739661670634666L");

// Check if sender is the owner of the room otherwise reject
const game = genesis.asset.games.find(game => game.roomId === this.asset.roomId)
if (game.createdBy !== this.asset.address) {
    errors.push(
        new TransactionError(
            '"asset.address" does not match createdBy field for room - you are not the owner of the room',
            this.id,
            '.asset.address',
            this.asset.address,
            game.createdBy
        )
    );
    return errors;
}

#4. End Room

Lastly, the end room transaction will change the status of the room to “ended” (represented by ‘2’). In addition, it is also important to note that the custom transaction will pay out the fees according to the defined distribution.

// Pay out the winnings
const distribution = asset.games[gameIndex].distribution
const numOfParticipants = asset.games[gameIndex].participants.length
const entryFeeBalance = new utils.BigNum(asset.games[gameIndex].entryFee)
const total = entryFeeBalance.mul(numOfParticipants)
const firstWinnings = total.div(100).mul(distribution.first)
const secondWinnings = total.div(100).mul(distribution.second)
const thirdWinnings = total.div(100).mul(distribution.third)

// First player
const firstPlayer = store.account.get(this.asset.first);
const firstBalance = new utils.BigNum(firstPlayer.balance);
const updatedFirstBalance = firstBalance.plus(firstWinnings)
const updatedFirstPlayer = {
    ...firstPlayer,
    balance: updatedFirstBalance.toString()
}
store.account.set(firstPlayer.address, updatedFirstPlayer);

For example, four players participated with an entry fee of 10 LSK. This means the total prize pool contains 40 LSK. If we set the distribution to 50%, 30%, and 20% respectively, we receive the following payouts:

• First: 20 LSK
• Second: 12 LSK
• Third: 8 LSK
• No payout

The User Interface

The frontend consists of React, Typescript, Rematch, (state management), and Ant Design. The different screens that are involved in the frontend application for the Arcado network can be seen below:

Login screen

Register

Users can register for an account using their email address.

Account created 

We wanted to make sure that a user can log in multiple times. Therefore, the user needs to confirm that the passphrase is saved to ensure they won’t lose access to the account.

Browse games

A user is presented with a predefined set of games. We selected a few popular games to illustrate how a gaming overview would look like. 

Game details

A user is able to see a game description, the different rooms that belong to a game, and have the functionality for them to create a room on their own.

Create room

Creating a room is the most important part of our application. A user is currently responsible for setting up the criteria for other users to join. The necessary requirements are a name, entry fee, the maximum amount of players, and a price distribution in percentage terms.

Game room

A game room is our interactive page for accounts to view the status of the room, join games, and also for admins to manage game room start and endings.

Future Extensions

We would like to develop this concept further to serve as a real API for decentralized gaming, aligning with relevant stakeholders from the gaming industry.

Overall, the API needs to incorporate more flexibility. For example, only the room creator can signal the start or end of a game. Besides, the room creator has to submit the final state to calculate the distribution of the winnings. However, that’s still some aspect of human error that should be automated via API calls in a decentralized way.

SDK

One future development would be to wrap all functionality in a SDK. Developers would be able to use mechanisms such as “create game”, “create room”, “start/stop game” and others. The SDK would give game developers the ability to incorporate the cryptocurrency paywall in any multiplayer game, and monetize multiplayer matches in seconds.

Games

Our games are currently hardcoded in a centralized repository. A mandatory feature would be to include a “create game transaction”. It would remove our centralized control on which games are allowed on the platform, and furthermore open up our platform for IOS, VR, AR, Android or any other game platform.

Indie developers can add games with ease due to the fact that they do not have an audience. We believe that big game studios that would like to use the platform will likely experience more ‘scammy’ look-a-like game creations. Mechanisms to prevent thousands of look-a-like games are one of the many topics that we would like to tackle as soon as possible.

If you would like to visit the Arcado project, check out the following repositories:

• Backend repository
• Frontend repository
• Arcado Chain repository

If you feel inspired and want to build your own proof of concept blockchain application, check out the Lisk Builders program. More information about the program and the application procedure can be found on the Lisk web page for the Lisk Builders program.

Disclaimer: This blog post was written by our community members, Endro (Lisk.chat username: Endro Labs) and Michiel (Lisk.chat username: michielmulders ) as part of their participation in the Lisk Builders program.