Pirates

"Pirates" is planned to be a massively multiplayer online (MMO) game that blends blockchain technology with decentralised gameplay. Players navigate ships, collect gold, and engage in naval combat in a vast oceanic world. Using zknoid, ship movements, collisions, and transactions are securely validated on-chain, while an off-chain server manages real-time game state and spawns new collectibles. This hybrid system ensures both security and efficient gameplay. Checkout concept game : https://github.com/rudrakpatra/pirate_game https://pirategame.vercel.app/

Tokenomics and Resources: The game use a single token - PirateCoin (PC's). Player stake some PC for ensuring fair play.

The game has two in-game resources:

gold - used to buy cannon balls. cannonballs - used to attack other ships. Main Challenges: To make the game truly decentralised, we are storing all the important data on-chain. As the number of players is massive. We cannot simulate all the players and game objects every frame/block. Also, reading the game state from the chain is unoptimised.

Game Mechanics: Each player starts with a ship spawning from a port. The player either sail in the vast ocean looking for gold, or try shooting down other players to get their loot.

Ship movement In this game players will control their ship via blockchain transactions. The ship always move forward at constant speed. The player can turn their ship sideways by changing the turn rate (increments of 5) and submit a transaction. The change is reflected from the next block. Whenever a ship changes its turn rate. The on-chain state of the ships location gets updated. We only store shipLocation, currentDirection & turn rate of the ship. This is enough to compute the future location of the ship at some time t.

Ship Combat: Ships can fire cannonballs at other ships. When a player wants to fire. He commits a shoot order. After the order gets filed, he must wait for some W blocks (W is the wait time). After W blocks he must reveal the location where had shot. This way some cannon shots are revealed every block. If some ship is hit by a cannon at time t, to prove it we can show that the ship position lies inside the cannon ball's damage circle.(ZKP) Ships will have a health. The ship is destroyed if health reaches 0. It is possible that a collision may remain unreported. We get around this by making the reporting beneficial for at least some actor, incentivising him/her to report it.

Collectibles: Ships can collect gold from the ocean. Each gold collectible has a random value. The value is determined randomly upon collection and stays hidden to the player who collects it.(ZKP) Say player A's ship is destroyed by player B. A must reveal the gold he collected (A has staked some PC) and collected by B.(ZKP) New gold can be spawned by a transaction. New gold should spawn at a random location.(ZKP)

Staying in the ocean is dangerous. Other players can destroy your ship and take your gold.

Ports: Simply speaking, ports are marked circular areas in the game world. If your ship moves inside such an area, you can visit that port.(ZKP) On visiting, you will be taken to the port menu to do the following:

Buy cannonballs with gold. Leave the port and start sailing (collected gold -> PC). Leave the game (collected gold -> PC). When you play the game for the first time you will be asked to buy a ship (using PC). You can buy a ship from any port you like but the price of a ship is different at each port. Advantages of ZKP: Security: zknoid ensures that all transactions and actions are securely validated and recorded on-chain, preventing tampering and ensuring fair play.

Efficiency: To reduce the no. of reads from the chain. We will maintain an indexer server which will look for changes in the game state. This server will simulate the game off-chain (report the collisions). For each correct report you will get a small commission in form of PC. You can burn 1 PC to spawn R gold collectibles at random locations in the game world.

The hybrid approach of using an off-chain server for real-time game state management reduces blockchain load and improves performance, making gameplay smoother and more responsive.

Conclusion: "Pirates" offers an immersive MMO experience with secure, self-balancing and efficient blockchain integration, providing a thrilling naval adventure in a decentralised world.

This project is powered by zknoid ,built on the protokit framework. Architechture: 1.Protokit Framework 2.Indexer Server for query of game related information. Features of zknoid used in this project:

1. The coin bridge feature. We have used the zknoid token as our Pirate Coin. We created protokit's runtime methods to convert zknoid tokens to game gold and vice versa.
2. Game Session Keys Session Keys eliminate the need for signing in every in-game transactions. An easily integrate-able feature.
3. The multiplayer module. Multiplayer was the main challenge, as zknoid is specialised to handle 1v1 PVP matches. We have designed the game to be self balancing. All players are making transactions to control their ship.
4. Random number generator. We used it to create a random spawn point of the ship and randomly spawn a new loot.

Challenges & Solution:

1. As the players need to know about the game information stored on chain, we need an efficient way to do so. solution1: we can create a indexer server that polls and stores the chain state is a more optimised data structure ( for example a player only need to know about its neighbouring ships giving use scope for optmization). However, this solution requires too much work and time to implement. solution2: the client directly poll the protokit chain server for state. For enabling this we are storing a double linked list kind of structure in the StateMap. Link to code where is it is implement (https://github.com/rudrakpatra/zknoid/blob/develop/packages/chain/src/pirates/PiratesLogic.ts).This way, #queries required for a new player to sync with the state is equal to the #active players in the game.

2.Collison and State Updation We cannot update the position of all players in the chain every block. We issue a transaction only when a player tries to change its ship turning rate. For all players we store (x,y,direction,time) at some time in the past. Game is designed such that the player position can be computed easily on chain by some function Position (last_ship_state)=>{newX,newY}. We use this to prove object collisions in the game. Conclusion: using the features of protokit & zknoid, we are able to create :

1. Smooth Continuous Realtime Gameplay.
2. Scalable and Provable Multiplayer.
3. Decentralised Control over Game Elements.
4. Security and ZK aspect provided by o1js.