0
\$\begingroup\$

Most professional video games use either a peer-to-peer architecture or a client-server architecture. In the former, clients often trust each other, and instead employ anti-cheat techniques to ensure that all clients are using the same version of the game. In a client-server architecture, the company-owned server manages the game, and each client only needs to trust the server without trusting any other client.

My question is: how might I write a game network architecture such that the server is not necessarily trusted either (e.g. it is another client, or is buggy, or has been compromised), and do so in a way that does not take too much processing power away from the game?

I know that the blockchain algorithm (as infamously used by Bitcoin and other cryptocurrencies) does provide this as long as at least half of the computing power is owned by trusted machines. While this may work for long-term actions (such as match verdicts), it doesn't work as well for the frame-by-frame actions of action games and can also be too slow for turn-based games, to say nothing of the computing power it requires of the clients or of any dedicated servers.

\$\endgroup\$
  • \$\begingroup\$ It seems like we can reduce your "untrusted server" case to an existing peer-to-peer case: just re-designate the server as a peer, and treat it with the same scrutiny/cross-checking you would another player's client. \$\endgroup\$ – DMGregory Jun 19 '18 at 3:42
1
\$\begingroup\$

The client is in the hands of the enemy

I forgot where i read this, but it's really useful while coding client-server architectures. Basically it means you can't trust the input from the clients and have to check if it's possible. In your case you also have to check the input you get from the server.

For Example:

  • Strategy: keep also track of enemys resources and units. Is it possible to build them? How fast are they?
  • Shooter: How much ammunation does the enemy have? How much did he use? Is his movement valid?

These checks should not take too much time in your gameloop and can at least verify if the actions are allowed.

The Problem with this solution is, that your client has to know everything. So it's easier for hackers to see where the enemy is, how much resurces he has, and so on.

In an standard client-server architecture the server decides which input is valid and which one is not. In your architecture each client decides this for himself. So maybe display a warning that the recieved data is inconsistent. The Players then can decide if they want to keep playing, or end the game. (Only show this once a match!)

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.