Arcado Network Brings Decentralized Reward Systems to Video Games

The Arcado Network focuses on bringing a decentralized 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. reward system 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 errors = []; genesis = store.account.get( ); asset = { : [], ...genesis.asset } asset.games.push({ : .asset.address, : .asset.name, : .asset.roomId, : .asset.gameId, : .asset.entryFee, participants: [ .asset.address], : .asset.distribution, : .asset.maxPlayers, : }) updatedGenesis = { ...genesis, asset }; store.account.set(genesis.address, updatedGenesis); const const "16313739661670634666L" let games createdBy this name this roomId this gameId this entryFee this // string this distribution this maxPlayers this status 0 // 0 open to join, 1 started, 2 ended const 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 which has been defined by the room creator. entryFee player = store.account.get( .asset.address); playerBalance = utils.BigNum(player.balance); entryFeeBalance = utils.BigNum( .asset.entryFee) updatedPlayerBalance = playerBalance.sub(entryFeeBalance); updatedPlayer = { ...player, : updatedPlayerBalance.toString() } store.account.set(player.address, updatedPlayer); const this const new const new this const const balance #2. Join Room The join room custom transaction will also be locked as well the and, in addition, the following further checks are then initiated: entryFee Does the game exist? Did we reach the maximum number of participants? Does the user have sufficient balance? game = genesis.asset.games.find( game.roomId === .asset.roomId) (!game) { errors.push( TransactionError( , .id, , .asset.roomId ) ); errors; } (game.participants.length >= game.maxPlayers) { errors.push( TransactionError( , .id, , game.maxPlayers ) ); errors; } playerBalance = utils.BigNum(player.balance); (playerBalance.lt(game.entryFee)) { errors.push( TransactionError( , .id, , player.balance ) ); errors; } const => game this if new '"asset.roomId" does not exist' this '.asset.roomId' this return if new 'Game is already full' this '.asset.maxPlayers' return const new if new 'Insufficient balance for player' this '.asset.entryFee' return #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. genesis = store.account.get( ); game = genesis.asset.games.find( game.roomId === .asset.roomId) (game.createdBy !== .asset.address) { errors.push( TransactionError( , .id, , .asset.address, game.createdBy ) ); errors; } const "16313739661670634666L" // Check if sender is the owner of the room otherwise reject const => game this if this new '"asset.address" does not match createdBy field for room - you are not the owner of the room' this '.asset.address' this return #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. distribution = asset.games[gameIndex].distribution numOfParticipants = asset.games[gameIndex].participants.length entryFeeBalance = utils.BigNum(asset.games[gameIndex].entryFee) total = entryFeeBalance.mul(numOfParticipants) firstWinnings = total.div( ).mul(distribution.first) secondWinnings = total.div( ).mul(distribution.second) thirdWinnings = total.div( ).mul(distribution.third) firstPlayer = store.account.get( .asset.first); firstBalance = utils.BigNum(firstPlayer.balance); updatedFirstBalance = firstBalance.plus(firstWinnings) updatedFirstPlayer = { ...firstPlayer, : updatedFirstBalance.toString() } store.account.set(firstPlayer.address, updatedFirstPlayer); // Pay out the winnings const const const new const const 100 const 100 const 100 // First player const this const new const const balance 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.