SkyNet - Co-Op Gameplay (Theory and potential structure)

[nandchan]

The key to understanding how distributed systems work lies in forgetting about the whole “server/client” model. Instead of having each player be a slave to some master server, each player simply notifies the other players of what he's doing, as an individual.

 

It's a many to many association graph where each node is connected to all the others, a situation which is perfectly modeled by UDP broadcast.

 

A server/client model works like this:

 

1. Player moves

2. Player's client sends his move message to the server

3. The server sends it to all other clients

 

A distributed model works like this:

 

1. Player moves

2. Player's client sends his move message to all other clients directly

[Emmarae]

The key to understanding how distributed systems work lies in forgetting about the whole “server/client” model. Instead of having each player be a slave to some master server, each player simply notifies the other players of what he's doing, as an individual.

 

It's a many to many association graph where each node is connected to all the others, a situation which is perfectly modeled by UDP broadcast.

 

A server/client model works like this:

 

1. Player moves

2. Player's client sends his move message to the server

3. The server sends it to all other clients

 

A distributed model works like this:

 

1. Player moves

2. Player's client sends his move message to all other clients directly

 

and if you only have a max connection of say 5 connections (4 other players and the server), the latency wouldn't be observable. Now also you have to remember that the game doesn't load the whole world at once. Cities are seperate from each zone. The server will have to have a running world view (having every zone open and loaded with things going on) so that if a player in one zone, say Whiterun, is killing a dragon, while some other player and his partner in crime are attacking Shor's Stone, all of it will be stored and maintained on the server so that when the dragon-killing player enters shor's stone, the devastation is still there. Now, the engine currently repopulates areas in 30 in-game days. That amount of time will have to be dependent upon the number of players ingame. if there are 5 players, then the timescale for repopulation would have to be 30/5=6 days. This will keep things interesting, because if you don't do this 5 players could easily wipe out all of skyrim. Also, all NPC's need to have to be affected by repopulation. Killing the Jarl of Whiterun will ruin some players game. This will eliminate the effects of trolls.

 

I'm done talking now. I'm more of an ideas person than a coder. I haven't coded since college, and I don't really plan on doing it again, though I do want to play around with the CK and make some races :P If you want more ideas, let me know. I can always pull some more out of my backside. ^-^

[hipolipolopigus]

Just to be sure, we're talking more of a P2P structure than a rigid foundation, correct? That's what it sounds like to me xD How would a client connect to the distributed network if there's no set server? Connecting to one peer and then having that peer tell all the other peers that are connected to that peer that the new peer connected to the network is... Well, not only cumbersome to type ( :happy:) but I'd imagine insecure and unstable :confused:

 

That aside, how would quests work? The scripts for the quests would need to be heavily modified, possibly more so than with the solo-server model.

 

Don't get me wrong, I like the idea of taking load off by distributing it across the entire mesh, but it's a little bit messy considering I've been programming in my "TCP mode" for... Well, several years :P

 

We need some form of communal Ventrillo system >< Typing is becoming as cumbersome as ever! :sweat:

Edited December 3, 2011 by hipolipolopigus

[Emmarae]

...

That aside, how would quests work? The scripts for the quests would need to be heavily modified, possibly more so than with the solo-server model.

...

We need some form of communal Ventrillo system >< Typing is becoming as cumbersome as ever! :sweat:

 

Well, I have an idea on how to make quests work. If someone can form up a vent server, I'll gladly share. :D

 

I lied. I'll share now. Each player has a quest log that keeps track of quests completed. Just make it so that quests are maintained individually. We'd have to add a party system for players working together. Then the party system would designate someone as the leader, and if the leader completes parts of the quest, then those in the same area as the leader who are in the party will receive completion of the quest/quest part.

Edited December 3, 2011 by Emmarae

[nandchan]

Just to be sure, we're talking more of a P2P structure than a rigid foundation, correct?

 

That's how I envisioned it.

 

That's what it sounds like to me xD How would a client connect to the distributed network if there's no set server? Connecting to one peer and then having that peer tell all the other peers that are connected to that peer that the new peer connected to the network is... Well, not only cumbersome to type ( :happy:) but I'd imagine insecure and unstable :confused:

 

UDP Broadcast does not require knowledge of other peers, you get the messages whether you want to or not - to start playing, you simply have to start listening to them. It's distributed on the router/switch level. Alternatively, for multicast packets, you'd simply have to register to a multicast port. Of course, we could use some more sophisticated message passing systems (with a message passing server) to allow broadcasting messages over TCP - but in this instance, the server would be completely mechanics-agnostic, it would know nothing about the game itself, and simply reproduce messages.

 

A new client which wishes to join the network would send a “request” packet, requesting a copy of each player's actor information (eg. appearance, position and so on) via broadcast, those players would all send a “full synch” packet in response (to everybody). The new player then sends his own “full synch” packet.

 

One hurdle that would remain to be solved is how to determine which save file to load, it's possible that a separate player would have to be contacted to receive a copy of his save file in private. If we do end up setting up a “priority list”, this could simply be reworked to be the player with highest priority.

 

That aside, how would quests work? The scripts for the quests would need to be heavily modified, possibly more so than with the solo-server model.

 

Whenever an individual client updates a quest's status, it sends a broadcast message to all other clients notifying them of the change, thus causing those local clients to update their quest stages. Quests which involve dialogues or freeze the player would only freeze the player that actually triggered the script/update, and dialogues would set the usual dialogue locks (also notified via broadcasts) so that no other player can use the NPC in the meantime.

 

Don't get me wrong, I like the idea of taking load off by distributing it across the entire mesh, but it's a little bit messy considering I've been programming in my "TCP mode" for... Well, several years :P

 

It's certainly possible to broadcast manually in TCP mode, or use a combined form of TCP and UDP where UDP broadcast would be used for unreliable, lightweight motion synching, and TCP could be used to negotiate connection parameters and establish secure presence lists or locks, eg. knowing which client should synch NPC motion and which shouldn't for an individual zone.

 

If so, we could simply have existing clients open a new TCP connection to a given player in response to a “join” broadcast, thus still causing us to need no server. This has the advantage of being able to detect when a connection is dropped uncleanly (eg. game or power crash) and remove the associated player's actor from the world.

 

We need some form of communal Ventrillo system >< Typing is becoming as cumbersome as ever! :sweat:

 

I think typing is fine, may I suggest a new keyboard? :)

 

Edit 1:

 

Each player has a quest log that keeps track of quests completed. Just make it so that quests are maintained individually. We'd have to add a party system for players working together. Then the party system would designate someone as the leader, and if the leader completes parts of the quest, then those in the same area as the leader who are in the party will receive completion of the quest/quest part.

 

What advantage would this hold over allowing each player to complete quests or parts of quests?

 

For example, think about a quest where you need to complete two objectives: 1. Release some captives, and 2. Open a door so that additional reinforcements can join. (If you're role playing, the opening door can be done by a sneaky character who eludes sight, with the orc berserker and paladin tank standing outside the drawbridge)

 

This way, you can have different characters complete different objectives, only to regroup later in order to, say, kill some boss character. Or think about quests such as the Mehrune's Razor shards, you could split up and have each player collect a single shard, in order to let the group's main DPS obtain the razor.

 

I don't think the game world lends itself well enough for multiplayer situations large enough to warrant multiple parties, especially since it has no mechanisms for providing multiple copies of quests. It's not a MMO and will simply not work like that, so the largest scale I can see this working with is in the scale of a single party.

 

Edit 2:

 

More positive implications of this setup: It would be possible to, say, have each player go do the quests in a certain region of Skyrim and become thanes in their respective cities, each player purchasing their own homes. Basically, it would work exactly like the single player RPG, except with the main player being present in multiple locations simultaneously. As far as the NPCs are concerned, every player is the same person - the main character.

 

So, if it's possible for a single player to be the master of several guilds, it would be possible for several players to be the master of several guilds. The only negative aspect is that if player A becomes archmage, and player C becomes the listener, the mages at the Winterhold College would recognize player C as archmage still. But I think that's a flaw we can live with.

 

Similarly, if a polygamy mod is created, it would be possible for multiple players to marry different NPCs (although technically they would all recognize every player as “my love”).

Edited December 3, 2011 by nandchan

[hipolipolopigus]

...

That aside, how would quests work? The scripts for the quests would need to be heavily modified, possibly more so than with the solo-server model.

...

We need some form of communal Ventrillo system >< Typing is becoming as cumbersome as ever! :sweat:

 

Well, I have an idea on how to make quests work. If someone can form up a vent server, I'll gladly share. :D

 

I lied. I'll share now. Each player has a quest log that keeps track of quests completed. Just make it so that quests are maintained individually. We'd have to add a party system for players working together. Then the party system would designate someone as the leader, and if the leader completes parts of the quest, then those in the same area as the leader who are in the party will receive completion of the quest/quest part.

Aww, I totally almost set one up right now :laugh:

 

Not exactly what I meant, but a good idea nonetheless! -Jots down idea on Post-It, looks around for space on desk, walls... Monitor side!- Anywho... I'm trying to minimize the stress that's going to be placed on our (currently non-existent...) core-editing staff. This may be a mistake, but they have the most laborious job (Next to me trying to work out a stable UDP implementation ;)). Admittedly, the more core-editing staff we could get our hands on the better!

 

But yes, good ideas :happy:

[hipolipolopigus]

[... Brilliant ideas everywhere! ...]

See, this is why you'd be an amazing asset to the team! I've next-to-no idea when it comes to UDP, so my implementation of it would be poor at best :/ Until either 1) I can make UDP work how I want without high packet-loss and noise or 2) you join, the network infrastructure is doomed to remain as TCP-only :/

 

I'm not overly concerned with network load, I doubt there will be more than 10 people on one server/mesh (If there was a UDP mesh thingy involved :P). The issue comes in with the amount of logic the server will need to process (Under the TCP model). Since we can't benchmark until after the CK is released, we can't say (Though I dare speculate it will be medium/medium high)

 

I think typing is fine, may I suggest a new keyboard? :)

It's not my keyboard, I just do better when I visualize (Which comes a lot easier through listening, for me :P) Edited December 3, 2011 by hipolipolopigus

[Emmarae]

...

That aside, how would quests work? The scripts for the quests would need to be heavily modified, possibly more so than with the solo-server model.

...

We need some form of communal Ventrillo system >< Typing is becoming as cumbersome as ever! :sweat:

 

Well, I have an idea on how to make quests work. If someone can form up a vent server, I'll gladly share. :D

 

I lied. I'll share now. Each player has a quest log that keeps track of quests completed. Just make it so that quests are maintained individually. We'd have to add a party system for players working together. Then the party system would designate someone as the leader, and if the leader completes parts of the quest, then those in the same area as the leader who are in the party will receive completion of the quest/quest part.

Aww, I totally almost set one up right now :laugh:

 

Not exactly what I meant, but a good idea nonetheless! -Jots down idea on Post-It, looks around for space on desk, walls... Monitor side!- Anywho... I'm trying to minimize the stress that's going to be placed on our (currently non-existent...) core-editing staff. This may be a mistake, but they have the most laborious job (Next to me trying to work out a stable UDP implementation ;)). Admittedly, the more core-editing staff we could get our hands on the better!

 

But yes, good ideas :happy:

 

You know that when the CK comes out and you have enough proof to show a Co-op Skyrim is possible, more coders will be willing to help out. Sadly I'm not a coder. I am always design. :P

[hipolipolopigus]

You know that when the CK comes out and you have enough proof to show a Co-op Skyrim is possible, more coders will be willing to help out. Sadly I'm not a coder. I am always design. :P

Mhm, but the CK is a mixed blessing. We don't know its' limitations, so I'm trying to refrain from speculating on end-functionality of SkyNet :confused: Eventually we'll be able to do everything, sure, but it'll be very limited at the start due to a lack of familiarity with the CK and a lack of hooks for SKSE.

 

"Sadly" you're not a coder? You don't need to be a coder to contribute fascinating ideas and concepts (Like you've already done) :happy:

 

Oh and then there's Bethesda probably not being terribly happy about the idea. I don't even want to try the argument "But it makes it better", look at the LAA fix. :sweat:

Edited December 3, 2011 by hipolipolopigus

[nandchan]

[... Brilliant ideas everywhere! ...]

See, this is why you'd be an amazing asset to the team! I've next-to-no idea when it comes to UDP, so my implementation of it would be poor at best :/ Until either 1) I can make UDP work how I want without high packet-loss and noise or 2) you join, the network infrastructure is doomed to remain as TCP-only :/

 

I'm not overly concerned with network load, I doubt there will be more than 10 people on one server/mesh (If there was a UDP mesh thingy involved :P). The issue comes in with the amount of logic the server will need to process (Under the TCP model). Since we can't benchmark until after the CK is released, we can't say (Though I dare speculate it will be medium/medium high)

 

Keep in mind UDP Broadcast is in practice largely confined to LAN setups, which is what I imagine this being used for. I don't know if it's possible to broadcast over services such as Hamachi.

 

Either way, it's of course possible to forget all about UDP Broadcast and use a distributed setup using a small server which would only handle connections.

 

Also, instead of using UDP broadcast locally, one could use a connectionless, multicasted but reliably delivered socket type such as RDM (System.Net.SocketType.Rdm), which retains message borders and order and ensures that no messages get lost or duplicated. This may actually be the best course of action even for LAN usage.

 

It's not my keyboard, I just do better when I visualize (Which comes a lot easier through listening, for me :P)

 

I see, that makes sense. I'm also a visual person, though I can visualize better when reading than when hearing.