But where money's concerned you can't take shortcuts, and in the end a player with a faster connection has a better experience, and (in casino land) those are the players with money anyway. I'm an old casino coder, so the "tricks" were things like, slow the card deal animation keep the roulette wheel animation going longer etc. IMHO this is the only way most games will be written down the line. There's a deterministic state on the server, and the UI doesn't bother to try to sugarcoat it to make it feel any more instantaneous than it is. There's a third way of thinking, best exemplified by Agar.io and things like that which basically asserts that any network latency is the player's problem.
This does allow blatant cheating I'm guessing it was a concession due to the new engine lacking in robustness or portability. 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. 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. 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). It was implemented by Karl Morton, and we also use it for replay files (which is why the game logic is meticulously versioned). The second-generation Worms games (2, Armageddon, WWP) use the same approach (here called "Deterministic action propagation method").
0 kommentar(er)
