Guild of Writers

Two and a half years ago, I suggested on these forums that it would be useful to create a peer to peer client (like many home games, such as Age of Mythology, do now).

I wrote:Has any thought been given to integrating a server and netcode module into CC or TPOTS to support peer to peer multiuser play? I don't mean to ask that it work for hundreds of people. I'm aware enough of the load and communication issues to know better. I just mean for small groups of people, say two to ten, to visit the Cavern and other ages together without needing to rely on a single server. And if you were feeling adventurous with your programming, allow node servers for people who have high bandwidth availablity and who can link to another node server with another small group of people.

Reference:
viewtopic.php?f=10&t=1556

The reason I bring this up now is because of PlasmaClient. Perhaps now is an appropriate time to resurrect the idea of spontaneous or virtual P2P "shards." One of the reasons the idea could not be easily implemented, as Paradox explained, was "the actual code of the .exe cannot be modified." With open source software, that is solved.

Further, and importantly, combined with Marten and Lontahv's idea of a PRP previewer, you're getting into collaborative, ad hoc development tools. That is, an instant shard comprised of clients viewing and testing new ages.

Collaborative tools are the evolution of most things and would be especially beneficial to a widely distributed community pipeline.

The issue is that there needs to be some central coordination unit managing accounts, vault, and so on. There are some IDs that need to be unique and consistent. So, there always has to be someone being the server, and all the data (age states and so on) are taken from that peer. If he quits, everyone else is kicked. This would in the end mean that the full server is integrated into the client.
The, in my eyes better, alternative would be to make the server so easy to set up that people can go ahead and "just do" it.

The, in my eyes better, alternative would be to make the server so easy to set up that people can go ahead and "just do" it.

Most keep waiting on the simple age creation thingy too...We can always hope and be blinded by the amazing things that happen just when we think it can't be done..

diafero wrote:The issue is that there needs to be some central coordination unit managing accounts, vault, and so on. There are some IDs that need to be unique and consistent. So, there always has to be someone being the server, and all the data (age states and so on) are taken from that peer. If he quits, everyone else is kicked. This would in the end mean that the full server is integrated into the client.
The, in my eyes better, alternative would be to make the server so easy to set up that people can go ahead and "just do" it.

I agree with this - and I'd throw in that a good simple local server is better for testing than an "offline mode" as well, since the latter also requires integrating some goodly chunks of server-ish code into the client.

Isn't it a basic requirement of all peer-to-peer protocols that server logic be integrated into the clients?

Sure it is. But peer-to-per just does not work in all scenarios. The Uru server architecture is quite the opposite of P2P, and seeing that an online game has to provide a consistent view to all players, I don't see any way to change that.

The client already does most of the work, doesn't it? With the server acting as go-between and age/state storage? Uru Prime has its own vault. Broadcasting (remember, this is for smallish, informal shard sessions, not a "shard" in the traditional sense) - either UDP or simulated TCP connection loop) and temporary nodes and states (volatile) could suffice. I say volatile, with temp IDs and such, because someone's shared test age probably should not be given a place in the vault or permanent file system to avoid conflicts.

You can not merge two vaults due to conflicting IDs. The client running in offline mode does all the work a server usually does, but it can only do so because it knows that it alone assigns IDs and edits the vault. Even a temporarily shared age instance has to be consistent, so there is no technical difference to a complete Shard.
Sure one client could get a "Host" button and someone else could then log in - if the client contains a full-featured server. When the host leaves, all other clients are kicked.

diafero wrote:You can not merge two vaults due to conflicting IDs.

Merge, no. But what's to merge when you have a host? Maybe you're thinking something I'm not, or maybe I'm not considering something.

diafero wrote:When the host leaves, all other clients are kicked.

Not sure because it's been a while, but in my example game, Age of Mythology, the others remain in their map to play in single player mode when a host leaves - not kicked. Of course, when you're the author, you can make the rules. You might even code automatic host elections (e.g. Windows browser elections) to let them continue. You might even code a virtual vault which is initially copied and synchronized off the host during the multiplayer session but which disappears when the last player quits.

It is perfectly good for the client to do some local Vault caching, but to ask them to cache the entire Vault is worse than having a single dedicated Vault server. The Vault is not simply player progress, but also which Ages belong to each player, invitations, and Age states. If the Vault "host" went offline in a P2P set-up, nobody would be able to continue playing because no other client would know all of the Age GUIDs for all the other players.

Yesterday in IRC we were discussing some possible ways to have an online mode and an offline mode synchronise Vault data. But due to the aforementioned id and GUID problems brought up by diafero, such a model would require that the player already exist on the server and offline mode would not be able to make progress to new Ages.

I don't think that cutting out the Vault as a central authority is the best plan. However, that doesn't mean we should rely entirely on it either. I'm envisioning a system where the server is the canonical Vault, but each client runs its own Vault copy as well. The client Vault should act as a cache for the player's user data and Ages. At runtime, the client pulls up the cached Vault and asks the server to send any updated nodes. Throughout gameplay, as the player meets others and visits their Ages, the client keeps a temporary cache of the incoming Vault nodes. Then rather than sending a node change to the server and having the server propagate it to all the other players, each client would make changes to their local Vault and propagate those changes to all the other clients and to the server. In the cse of an invalid change, the server can easily propagate a reverted node back to all clients. When the client exits, the data from other players is cleared from the cache to leave only the local player data.

One of the concepts enforced by this model is that a user cannot change the vault nodes of other player (in general, there are some valid exceptions that be handled appropriately). It is also important that the server is not synced the local Vault upon connection, only that the local Vault is synced to the server. That would prevent a user from editing their local Vault and then connecting in the hope of propagating their changes to the server. Proper checksums on both ends should ensure that data is only written during actual gameplay, where it can be validated by both the client and the server.