h a l f b a k e r yLoading tagline ....
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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.)
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]
[link]
|
| |
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. |
|
| |
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. |
|
| |
For a turn based game you can probably get away
with using integers for everything. They should be
deterministic enough for most purposes. |
|
| |
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. |
|
| |
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. |
|
| |
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. |
|
| |
This kind of crypto is called a "commitment scheme" (link). |
|
| |
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. |
|
| |
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. |
|
| |
I was thinking about something more along the lines of a fps. |
|
| |
>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? |
|
| |
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..... |
|
| |
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. |
|
| |