frvctl
commented
11 years ago Since time is decentralized as is can't you just retroactively assign a standardized time, which would remain the same for the duration of the room, based off of the first person to start the omg (offline multiplayer game). Also as far as the options available number one seems best, however, instead of picking just one person to be the god client. Something that would probably lead to complications based on the latency of that persons internet, have a dynamic god index that changes as the game progresses based on certain factors.
antimatter15
One cool thing about the design is that every client is fully capable of behaving as a fully functional server. We're using this for offline, but it could be much more than that and do offline multiplayer.
In the near future we'll have WebRTC and serverless peer to peer connectivity, for low-latency Protobowl lan-parties. We can have a twenty-line p2p simulator running on any platform, Google App Engine, Azure, AWS, JVM, etc and use those as seamless fallbacks whenever the server does go down.
This doesn't actually have much in terms of practical application, but it's certainly technically interesting, and might help with our technical-audience pitch.
The main problem is with no trust mediator. If each client is by definition the same, which one will run the server code and which ones will self-subordinate to their natural state (cf. " Is not this simpler? Is this not your natural state? It's the unspoken truth of humanity, that you crave subjugation.").
So serverless multiplayer implies one of two approaches (there may be more, but I haven't thought of them yet)
The first is to retain the client-server architecture, but to have one client elevated to godhood, and all the other clients defer to his almighty reign. The problem is of course in picking which player to give such a status, and in handling an untimely death (however, this may be a non-issue since serverless multiplayer is designed itself as a fallback system, and should automatically be able to transition in advent of a coup d'etat).
The second option is to have each server activated, acting essentially in a synchronized offline mode. The problem here that arises is what exactly the synchronization/communication does, what do you broadcast, how do you verify it, and fix conflicts when they occur.
The simplest implementation of the second option is for every action to be sent two places, to the local server, and externally broadcast to all other clients. Servers receive external events and apply it to the local state.
The problem is of course loss of synchronization. Race conditions will not get resolved in the same way for everyone, and players would end up on different questions.
One way to resolve this is to check for consensus first, before applying anything to the server's internal state. That is, you contact all peers with your current (normalized) timestamp, and once everyone's acknowledged that you have the right to speak, you send along your actual message.
Then there's the problem of computing a "normalized" timestamp. Well, if you're just dealing with the fallback case, fine, you can retain whatever sync_offset the central authority had decided on when you were connected, but how do you create a normalized timestamp in an entirely decentralized environment?