0
$\begingroup$

TLDR, this will be a discussion rather than my private problem.

Nowadays, most game developers or publishers have central servers to manage player transactions such as movement, mouse position, and so on. We can say the events in general.

But what if the developer just needs to publish a client app for end users without needing to deploy the game server? So, there is only a codebase for the client.

For example, in a fighting game with three players, they are X, Y, and Z. Where they have property named Health Point (HP) and position (coordinate). Here is the game loop step:

  1. Updating States: X, Y, and Z modify their own HP value to 100 on the client side. Also, their initial position follows game rules. (client app rules).
  2. Publishing States (Hash+Salted): They published their HP; if there is a player that doesn't follow the game rule, for example, X set his HP to 999, it is simply not considered a player or a cheater by another fair player. Note that the states published are hashed.
  3. Getting New Events: Suppose there is an event where X hits position (2,3) with damage 69 (69 is based on the game rule). X was choosing that position simply because of the because of the last known location of Z.
  4. Reveal States (Plain): They reveal their states in plain text, which are based on previous hashes. It turns out the (2,3) is the Z position.
  5. Verify States: The player compares the hashed states that were sent earlier before getting new events with the plain states; if the result is not the same, it simply means there is a cheater or unfair player, and the other player has the right to vote against the unfair player.
  6. Back to the Loop (Step 1): Suppose there is no cheater, then player Z must update his own state (specifically HP) from 100 to '100-69', which is 31. If Z tried to cheat by not updating HP, it would be detected later in the Verify phase.

So, from that example game, we can conclude the main components of this serverless game in general are:

  1. States: These can be properties of the player.
  2. Events: These can be actions executed by the player.
  3. Rules: This is defined in the app as the limitation of states and events that can be verified by another player.

So, as you see, I am mostly talking theoristically, not really practically.

I expect there is a counter to my proposed concept about this interesting decentralised app, like another vulnerability by a cheater. So, if there is a vulnerability, I expect you to answer with the proposed prevention for such a vulnerability, optionally. Yeah, I realised that even though I'm using the word cryptography in the title, currently I just mentioned hash.

But if you want a counter practically, like, currently we don't have such a fast hash method that might lag the entire game, I still accept the answer.

Practically, the network topology used will be mesh, but it can be ringed with adding next hop and previous hop metadata to the game events public ledger. Open ports for inbound connections and outbound connections. Also, UDP might be matched with this.

So, any there components I missed to implement this? Or my proposed concept is ready and fine to implement practically?

$\endgroup$

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.