Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Tastes richer, less filling.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.



No Arbitration Server For Synchronized Simultaneous Turn Based Game

  [vote for,

In games such as frozen synapses (A tactical simultaneous turn based game), two players or more submit their turn to an arbitration server that then sends a list of moves to everyone else at the end of a round. This prevents one player from peeking at the other player's move before the next round is executed.

But why have a central server do the turn calculation? Why not have at least these steps instead, so you don't need a central server at all?

1. Wait for everyone to decide on an action

2. Everyone encrypts their next command, and send it to all other players.

3. When everyone receives everyone else encrypted commands, then everyone sends each other the decryption keys to start simulating the current round.

4. After everyone simulates the next scene, a hash is sent to everyone else and compaired. The game will stop if one of the hash is mismatched.

Pro: No server required. Game can exist even when the main company that host the common server dies.

Con: The game engine must be fully determanistic, (make sure your floating point calc remains the same for all archechture. Maybe a virtual machine may help.)

mofosyne, Dec 23 2013

Synchronous RTS Engines and a Tale of Desyncs http://www.altdevbl...-a-tale-of-desyncs/
Creating a syncronous game engine is not easy [mofosyne, Dec 23 2013]

Badumna fully distributed network model http://www.scalify.com/
[theircompetitor, Dec 23 2013]

Commitment scheme http://en.wikipedia...i/Commitment_scheme
What this kind of crypto is called. [Wrongfellow, Dec 24 2013]


       In the system that you have described, there is no authoritative node, such as a central server. Therefore, you must already be trusting your opponents and no encryption would be necessary.
Cuit_au_Four, Dec 23 2013

       Servers in such systems are primarily there to prevent cheating. There are lots of systems that use a rotating authoritative node, or even a fully distributed system   

       The fully deterministic bit is truly a bitch, because, given sufficient testing, the universe itself is not :)   

       In our experience using Unity, for instance, we had to write our own deterministic engine for billiards because using Physics one could not guarantee shot accuracy on a network, particularly during breaks. Ditto for bowling, which we are still testing.
theircompetitor, Dec 23 2013

       For a turn based game you can probably get away with using integers for everything. They should be deterministic enough for most purposes.
Loris, Dec 23 2013

       That's very traffic wasteful in every imaginable way.   

       Once the calculations security issue has been dealt with by moving it clientside, the role of comms-server can be taken by any one machine (lowest lag time is a good place to start). When that Player decides on a move it is sent out encrypted to everybody's machine which tells them they can start sending their moves to the server, unencrypted. Then traffic can continue as normal: once a move is received by the server the server-player's decryption key is sent, as is every succeeding move received by the server from other players.   

       Since nobody can start thinking of their next move until the server's Player has made up their mind concerning the current turn, it makes sense to move serveritude, as the game progresses, to the Player with the lowest _mental_ lag time. This would make it indistinguishable from an honour-system star network.   

       © you'll be getting my bill.
FlyingToaster, Dec 23 2013

       The automated stuff being described in the main text probably doesn't need to be quite so complicated. That's because it is AUTOMATED. So, let us assume that the same game installed on all the players' machines has the same encryption algorithm AND the same "seeds" used for doing encryption.   

       (Assume the seeds are generated by the players when the Group is formally defined --every player in the Group contributes at least one seed. The automatic system will obviously be able to know how many players there are in the Group.)   

       So now each player can create a game-move, and the automated system can use the seeds to generate the data needed for encrypting it -- which is also the data needed for decrypting the game-moves from the other players.   

       One of the simplest encryption-decryption systems involves coding data as a bunch of numbers, and adding a RANDOM number to it to encrypt, and subtracting that same random number to decrypt it. Computers actually only do pseudo-random numbers, normally, but the more different seeds are involved in generating them, the more the results can look like truly random numbers.   

       You want the random number to be larger than the data, of course. Suppose the data ranges from 1000 bits to 10,000 bits, depending on the complexity of a player's move. If you know the maximum possible data-to-encrypt, you can always choose to generate an appropriately larger random number (say 50,000 bits).   

       Here every player-computer generates the same random number at the same time, because all are using the same algorithm and the same seeds. And for the next move, a different 50,000-bit random number would be generated --still the same number on each of the player-computers, because all are still using the same pseudo-random number-generating algorithm.   

       The automatic system sends the encrypted move to all the other players in the Group, and the automatic system refuses to decrypt any player's move until all the moves have been received.   

       Net effect: At the cost of some initial handshaking to acquire all the encryption seeds, every Game Turn can involve sending modest amounts of data between the players. Perhaps twice or even thrice, if you want to verify data integrity.
Vernon, Dec 23 2013

       Actually, as a solution to the specific problem of cheating by player(s), during a turn, knowing other players' moves before making their own, there's no need for a designated server, nor to send all sorts of encrypted info and decryption keys from and to everybody.   

       The player that moves first: his machine assumes the role of comms-server for that turn and is the only one that sends out an encrypted move, to everybody. For that turn, everybody treats him as server and sends him their moves unencrypted. Since his move has been declared it's okay for anybody who receives his move to send him theirs. And it's okay for him to send everybody who has already sent in a move everybody else's moves.   

       Obviously, due to lag, for some turns more than one machine sets itself up as server. But that's okay: each client chooses the first encrypted packet as server, ignoring any others, and each server that receives an encrypted packet knows there's another server(s) in the group for the turn. The servers share their own lists of player moves that have been made between them for dissemination.
FlyingToaster, Dec 24 2013

       This kind of crypto is called a "commitment scheme" (link).
Wrongfellow, Dec 24 2013

       it sounds like a massive bandwidth waster. why not simply use a circular mother/daughter setup where for each window a different computer is the pair arbiter for another player. A has B B has L L has D D has A then you shuffle, and so on. In this way a player who is trying to pervert the system can only do it for the window then they are mother for the data that they want to pervert, which is only fractional. The chance that you will window the data that you need to pervert gets smaller the more players you have in the network.
WcW, Dec 24 2013

       If you're just sending the moves you made, bandwidth won't even matter unless you're accessing the Internet via morse code, homing pigeon, smoke signals, or dial-up. I can't imagine that the encoded moves could possibly take up more than a kilobyte or two, in which case it'll take only about a couple seconds or less to download or upload them on most internet connections. (And in fact, it'll most likely be far less - specifying a move in chess takes a few bytes, for instance.) So for most users, mental lag time will exceed data lag time.
Hive_Mind, Dec 24 2013

       I was thinking about something more along the lines of a fps.
WcW, Dec 25 2013

       >In games such as frozen synapses (A tactical simultaneous turn based game), two players or more submit their turn to an arbitration server that then sends a list of moves to everyone else at the end of a round.   

       I don't think it's possible to have a turn-based FPS. Is it?
Hive_Mind, Dec 25 2013

       A "duel" could be called a first-person-shooter for 2 people. And it could be turn-based, sort-of (both take their turns at the same time, much like those other game scenarios already discussed herein).   

       In a duel, of course, it is possible that neither player will be able to take a "next" turn.....
Vernon, Dec 25 2013

       actually, if you see each window as a "turn" then they are. Admittedly it's far more complicated than that but on some basic level it comes down to the same basic concept, the game progresses in a stepwise fashion with the illusion of smoothness. Most of the time people making calls in the same window isn't important and is only used to verify that players aren't doing things that violate the movement and inventory rules of the game. However the question of if you have hit someone means that a second computer has to arbitrate the question, looking at the window in question and making a call. It is possible in arrangement that you are the mother for a window when you arbitrate a call on your own player and then "drop the call". For games with very few players each window might need to be arbitrated by two sisters, and the results compared to keep everyone honest.
WcW, Dec 25 2013


back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle