[HN Gopher] Networking of a turn-based game
___________________________________________________________________
Networking of a turn-based game
Author : blue1
Score : 51 points
Date : 2022-02-15 21:05 UTC (1 hours ago)
(HTM) web link (longwelwind.net)
(TXT) w3m dump (longwelwind.net)
| bob1029 wrote:
| In my experience, most of the pain boils down to synchronization
| of state between participants. This is also your principal vector
| for cheating.
|
| If you are willing and able to make a very extreme sacrifice
| regarding client-server architecture, it is feasible to
| consolidate all state to 1 synchronous domain while serving an
| arbitrary number of participants.
|
| The sacrifice is basically to build your game as a native take on
| the Google Stadia model. I.e. inputs are raw player events,
| output is a low latency A/V stream back to player.
|
| Keep in mind you don't have to always serve an x264 stream to all
| clients. Depending on your objectives and type of game, you can
| serve an intermediate view model that instructs the client on how
| to draw its view using local assets and resources (textures,
| models, gpus, etc). This would be more like how Blazor server-
| side model operates.
| d0m3 wrote:
| Nice article. I built my own online version of a turn based board
| game because none exists at the moment. I just want to play with
| my family so I didn't bother coding a server at all, instead all
| clients communicate their actions to all others so I naturally
| implemented the deterministic approach. I haven't thought about
| secret state so it's interesting to see a possible solution for
| that. Fun!
| wanderer_ wrote:
| I have poked and prodded at making my own turn-based game, and
| one thing I have learned is validation. Don't trust input, and
| you will make robust serverside code. Assume every bit sent by
| the client was maliciously sent in order to bring down your
| service in flames. Keep this mentality, and security becomes that
| much easier.
|
| AJAX long polling is a good way to send data while avoiding
| spurious requests and/or delays, albeit with a bit more load on
| the server.
| MrLeap wrote:
| Seconded. The way I look at this is to always build the
| allowable action space from nothing, and default to nothing.
| Most of the time it involves a state machine where each node
| comes with a white list of currently allowable verbs a client
| can send.
|
| The alternative is an infinite action soup, which opens
| opportunities for inspiration by lateral thinking. I'm doing it
| this way for a single player Lovecraftian text editor I'm
| working on. It's a terrible idea for multiplayer things.
| CyberShadow wrote:
| The second-generation Worms games (2, Armageddon, WWP) use the
| same approach (here called "Deterministic action propagation
| method"). It was implemented by Karl Morton, and we also used for
| replay files (which is why the game logic is meticulously
| versioned).
|
| The solution we used for managing secret state, when the state is
| from a random source, is to delay generating the secret
| information for as long as possible (so, e.g., if a card is
| drawn, the drawn card is decided at that moment, as opposed to
| pre-shuffling the deck at the start of the game). We experimented
| with some designs in which the secret is revealed only to the
| player who owns it, and the rest only see a verifiable hash of
| the secret until the player performs an action which reveals the
| secret; however, it doesn't solve the general problem that any
| time the game must immediately (without network latency) make a
| random choice, the design must compromise between either allowing
| a hacked client to predict the result (when the RNG output is
| stable) or manipulate it (when the RNG output changes very often,
| e.g. every frame).
|
| Sadly, the newer games went for a simpler synchronization
| algorithm, in which if a discrepancy is detected, the entire
| state is simply copied over from one player's game to another.
| This does allows blatant cheating; I'm guessing it was a
| concession due to the new engine lacking in robustness or
| portability.
| Spivakov wrote:
| About deterministic propagation model: "It relies on the
| assumption that processing the actions of a player is
| deterministic."
|
| I am curious in what scenario of online gaming does this
| assumption fail.
|
| I remember that about a decade ago there was a mobile game called
| Chaos and Order (like dota/League of Legends but was played on
| apple device). In one game, I heavily outplayed my opponent.
| After winning the match we added friends and realized that we
| actually experienced two totally different games - he lost it in
| my game but won it on his side, and my in-game actions made
| nonsense in his one. We called it a "ghost".
|
| It is just funny to see how crappy the outcome would be if the
| deterministic propagation fails. Also in context such as system
| theory where error inevitably happens, the design shall make sure
| the extent of failure will not go unbounded.
| baggy_trough wrote:
| Usually bugs, for example if the rng doesn't get handled in
| precisely the same way.
| meheleventyone wrote:
| The very worst kind of determinism errors are butterfly effect
| like in that you don't notice the desync until long after the
| cause has occurred. It's pretty imperative if you're building a
| deterministic system to add a layer of error checking right
| from the start so you can ensure each party ends up in the same
| state and identify desync very early. On the other hand you
| also want to identify where desync doesn't matter (for example
| most FX) so you limit the scope of what has to be deterministic
| to keep things simple.
| ermir wrote:
| This is called a "desync" and is a bug in a particular
| implementation of multiplayer networking. In this model instead
| of the server sending the state to each player, it sends their
| inputs, and allows the local device to completely determine the
| state of the game. If there are any differences at all in how
| the game's calculations are made, the game will have different
| states in different devices. Even different models of the
| iPhone may have tiny differences in how they calculate the
| square root for example, and over time these minor differences
| cascade into totally different games.
| Thaxll wrote:
| Imagine the same game being played on different platform (
| different CPU... ) with different compiler etc ... it's
| possible that the physics does not behave exacly the same
| everywhere.
|
| It used to be the case not so long ago.
___________________________________________________________________
(page generated 2022-02-15 23:00 UTC)