Technology
Is a Decentralized Video Game Round Possible?
The Problem Facing This Question
Every time I think of decentralization; I think of huge supercomputers, spread around the world, all preforming calculations to mine the next block. The Blockchain format is not a viable video game environment because of the large latency that comes with it. However, the only reason that blocks are necessary in a cryptocurrency is to that malicious users do not try to exploit the inherent latency that comes with the Internet, by spending more than they have. This is not the case for video game servers, because packets are an unlimited recourse. However, there is a possibility that a malicious client could send different data to each client, but more on that later.
An Explanation
From now on, I will refer to a collection of players playing together as a round, or as a video game round. I will also reserve the term “server” as a application that computes, stores, sends, and interprets all the data necessary to run a normal video game server. There can be multiple servers per round.
A component is a single server that is running a round.
Centralized Game
Currently, all video game rounds and servers are centralized; there is only one server, and all of the players are clients. There is also no way for any of the clients to communicate to one another, except through the server.
Standards
In order for there to be efficient decentralization in any system, there must be standards for each component of a round to follow; or else, the components will not be able to adequately communicate, or understand what the other components are trying to do.
Encryption
First, each client will have their own private and public key pair. Depending on what the format of the whole video game is, these keys might or might not be linked to a specific user. Every time a connection is made, the components will send each other their public keys, which will then be used to communicate a symmetric key, to encrypt the data. Having a private-public key is necessary for each server to compare their connection requests, to make sure that the connections are coming from the same person.
Client-Server pair
The first option is the simplest; for each client, or player, there is also a server kept and maintained. Every time a client connects to a round, the server paired with their client will connect to, and send a request to, all of the other clients currently in the round in which they are trying to connect to. The servers would then share the join request with all of the other clients, and then receive information back concerning weather or not the other servers got the request or not.
The servers will then vote on weather or not to admit the pending player. If the player is admitted. The vote is used for reasons that can be changed; for example, if the connecting player has been reported for cheating, servers may not allow the new player to join.
If the new server does get authorized, it will contact all servers for a list of other servers in the same round. The server the will connect to any other server that they have not connected to yet, and appears in a majority of the ledgers that the other servers gave it; and will exchange keys, and connect.
All of the servers will exchange data with all of the other servers; and will also exchange what data they received from the other servers with each other, and what data they received from each other from each other (more on this later.)
Application
This style of server is best used on games that do not have a large player to round ratio (first person shooters, who usually have 12–24 players per round are best for this option) and rounds that do not have a large world size. If an open world game, like No Man’s Sky, that has a very large world size would not work on this type of server, because there would be too many connections, and too much data for each server to process.
Downside
There are two big downsides to this option. The first option is the fact that this option would require port forwarding, which most people do not know how to do, or even what it is. The second downside is that each and every client would also have to keep a server; some computers that people use are very slow, and do not have the capability to run a whole server.
Many servers, even more clients.
For technology like the Bitcoin Blockchain, the ledger is not stored on the computer of everyone who has a wallet, it is instead, stored on multiple large servers. Every time a wallet holder would want to do a transaction, the wallet holder just has to contact a few of of the ledger holders, and send them the transaction. Option two is based off of this concept; a few big servers will run a round, and connect to multiple clients each; and then the servers will share the data with each other, and then in turn share the data that they received with the clients it is connected to.
The servers that run a round this way must also have a way to defend against desynchronizing. Each server must share all the data they receive, and then share the data they receive from the data that is received from the server which sent it.
Application
This type of round is best on large, or processing intensive rounds, that are too difficult be processed on each individual client. Most games that are not co-op, or first person shooters, will need this type of server, because it is much more efficient, and allows players with old or cheaper computers to play on the server.
Downside
The downside to this is the fact that ping will be worse because there are more places for the data to go, and even more than a centralized server. There is also one point of failure if a client does not send its data to multiple servers; which sounds easy, but the servers might be uncommon, and far apart, which may force a player to accept high ping, or use a malicious server, or both.
Anti-Cheat
Every game will have cheaters; cheaters, in a centralized server, can be dealt with by the server, or by a vote by the clients if the anti-cheat fails. However, on a decentralized system, a single anti-cheat will not work because no single person runs it. For anti-cheat, each server will keep a Boolean for each client (or a vote) and then distribute this data to the other servers. Servers that do not vote will be assumed that they vote “no” for every client. The servers then will then kick anyone who is suspected of cheating by more than 50% of the servers in the round.
Synchronization
Much like any other decentralized technology, there must be protection against the system becoming desynchronized from one another. If the system becomes synchronized, it will no longer be a system, but instead separate systems, based of of what vague data they receive. In most decentralized system, a block chain is used; however, a high latency method like a block chain will not work for a live video game round; there needs to be a majority-proofed way to prevent desynchronization.
If all of the individual servers are following protocol, and not purposely manipulating data; the servers will never desynchronize from one another. However, data manipulation is inevitable, and there needs to be a universal, but still decentralized way of defending against this. The simplest way of doing this is by having each of the servers send each other the data that they receive from the others. This will allow each of the servers to compare the data, and figure out if it is manipulated. Only one check is needed because it is majority prof this way; as long as the majority of the servers are reporting the correct data, the individual servers can judge vote whether to kick a player or not.
