Objective
This is a governance motion proposal describing a solution for efficiently running a real-time game server using canisters. The team of PLETHORA proposes that the NNS should create a subnet specifically designated for real-time multiplayer game canisters. This subnet would consist of 3 nodes rather than the usual 13 node application subnets.
This is a motion proposal and does not directly result in changes to the IC. Rather, voting to support the proposal is an indication that work should begin on creating this gaming subnet. If it passes, then we will work with DFINITY and other parties to create a 3-node subnet.
Background
In order to have a multiplayer game with real-time player movement, it is necessary to have a server that records the positioning of each player. This data needs to be updated frequently in order to prevent lagging of players. In most online games, this requires a ping of <100ms.
PLETHORA is focused on building 100% on-chain games, meaning we’ve built a real-time multiplayer server in a canister. We leverage the Unity game engine and the ICP.NET agent (thanks @Gekctek !) to communicate directly with canisters.
And we made a video to show it to you!
In this video:
- Every 300ms each player updates their position in the world to the canister
- Every 25ms each player queries the canister for positions of other players in the world
- We then estimate the animation states and use smoothing techniques to render the characters running/jumping around the 3D world
Here’s the link to the video demo:
However, we’ve ran into two main issues:
- Canisters have >2000ms ping because canister state changes must go through consensus. The more nodes in a subnet, the longer it takes to reach consensus. This is awful lag for real-time multiplayer.
- Three canister update calls are sent per second per player to record player positions. This huge volume of calls cost an exorbitant amount of cycles. The more nodes in a subnet, the more expensive the update calls become.
By lowering the amount of nodes in a subnet to three nodes, we can reduce both latency and cost for running a real-time multiplayer game canister.
Another consideration we want to propose is creating 2 subnets of 3 nodes each. The first subnet would be populated with 3 nodes based in North America. The second subnet would be populated with 3 nodes based in Asia. Therefore, we could route our Western players to the North America subnet and our Eastern players to the Asia subnet. This will result in much lower latency from the game client to subnet, but also lower latency between the nodes communicating for consensus. We would love to hear your feedback on this.
But what about the security of these subnets?
In its first iteration, the movement in PLETHORA’s games will be client-authoritative, meaning it is purely for visual purposes. For this reason, it’s not a major concern that a subnet could be subverted by two colluding nodes. There’s no incentive to do so because the multiplayer movement does not have important game logic associated with it.
In the future, we can take small steps to enforce server-authoritative movement in a canister to prevent clients from cheating their movement. At that point in time, the security of the subnet may become a bigger concern. But we firmly believe the tradeoff with latency and cost is worth the reduction of nodes for client-authoritative movement.
Why This Is Important
Gaming will be the next major use case of crypto, and gaming economies will eventually overtake economies of entire countries. We have conviction that in order to build games that will rise to that scale, everything needs to be fully on-chain. When a game is fully enforced by smart contracts, it presents the greatest opportunity for humanity to improve how we interact and create value for each other.
And when we say 100% on-chain, we mean it. This includes real-time multiplayer game servers. Adhering closely to this strict standard will enable composability like never before, and will empower games to be DAO-governed through the SNS.
No other blockchain can run a complex game with tremendous amounts of logic and data 100% executed and stored on-chain. We need to show the world what the Internet Computer is capable of accomplishing.
What We Are Asking The Community:
Provide feedback on this proposal within this thread.
Vote accept or reject on NNS Motion
Participate in technical discussions as the motion moves forward
Additional Cycle Costs Calculations:
Let’s calculate the cost savings of switching to a 3-node subnet. These are just estimates, the actual amounts will vary depending on how many bytes are sent in the ingress messages.
If we send 2 update calls per second per player, that’s roughly 7.2K update calls per hour.
On a 13-node subnet, 7.2K update calls with position/rotation/scale/animation data uses roughly 14B cycles.
Let’s assume we have 10,000 concurrent players for 24 hours on a 13-node subnet.
On a 13-node subnet, it would cost around 3400T cycles.
That’s roughly $4,530 per day or $136,000 per month
If we do the same math for a 3-node subnet, it would cost around 785T cycles.
That’s roughly $1,070 per day or $32,000 per month
As you can see, the cost of cycles is significantly reduced with less nodes. This will become increasingly important as games scale to millions of users.
It’s harder to calculate latency when reducing the node count of a subnet, but we expect it will significantly decrease as well.
