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

[Szimitar]

If you are interested in joining us, go to http://skynet.hipolipolopig.us/

We need both Programmers and Brainstormers, so if you are passionate about this topic, then help us make it come true.

[Caille]

I think I will join you guys over there.

 

Can it be done? Yes. Will it be tough. Hell yes! Will it be worth it? Fook yes!

 

I would be content if we could get two players in one Skyrim, more than that would be gorgeous.

 

 

 

Alexis

*smiles*

[Szimitar]

I would be content if we could get two players in one Skyrim, more than that would be gorgeous.

 

Actually, if we get two players to play with each other it's not that hard to make it 64.

Nonetheless it will be a lot of work and it will take us a few month after the CK is released to get a prototype running, so if you want to help please do.

[nandchan]

The way I've always imagined it is that one client acts as a host and will function as a completely normal game, and all the other clients act as “slaves” and can therefore not interact with NPCs or loot whatsoever. All game and save data would be taken from the hosting client's save game - what the loader would do, when starting the slave (after the host is running), would be to generate a new save file that is based on all object data from the server, in order to “synch” the two together, then adding in your own “exported” character from a different save file - that is, its appearance, inventory and attributes. In essence, the slave client acts as a more or less total ghost, with all of its internal processing disabled and actors simply synched via the network (and interpolated locally, eg. only node updates, speeds, animation events and so on are synched).

 

That's just what I'd imagine such a system like. It's a massive project, and I'd be neither willing to nor do I have the time to help with such an ambitious undertaking. But one bit of advice I can give you: Don't even begin thinking about the implementation until you have the entire concept and planning stage mapped out completely.

[Szimitar]

We're still in a concept phase, but the plan as of now is to create a Server / Client system. If someone has a gaming rig powerful enough he could of course run both Server and Client on his PC, though in most cases a dedicated machine would be best.

[Lucubration]

Szimitar, that's not quite correct. According to what we've discussed so far, the Server is still playing the game, it's just their instance of the game that is making many of the decisions about actions that take place in the world. Clients connect their own game to the Server and accept the Server's decisions about what's taking place in its world.

[nandchan]

We're still in a concept phase, but the plan as of now is to create a Server / Client system. If someone has a gaming rig powerful enough he could of course run both Server and Client on his PC, though in most cases a dedicated machine would be best.

 

See

 

Szimitar, that's not quite correct. According to what we've discussed so far, the Server is still playing the game, it's just their instance of the game that is making many of the decisions about actions that take place in the world. Clients connect their own game to the Server and accept the Server's decisions about what's taking place in its world.

 

This sums it up pretty well. The point here is not to implement the entire game mechanics inside a separate Server client - that is simply bound to fail, but rather using an existing game client as a sort of make-shift server, then synching only stuff that's necessary for co-operative gameplay, and not every single action. The challenge is now not ensuring that the world behaves properly, but ensuring that each copy of the world exhibits the same behavior, overall a much easier challenge to tackle than what Szimitar described.

 

Note: It may be yet possible to simply convert an input-less, window-less game client instance into a makeshift server, by just having the only “real” player be repositioned to accommodate for cell loading and so on, with every participating person running the same limited slave client. But then you still need some sort of host machine which will receive decision making priority.

 

One way I could imagine this whole thing working: All conversation, quest interaction and so on can only be performed by the hosting player. To facilitate multi-playerism, we will thus introduce special “vendor” NPCs which, when clicked, will simply open their inventory, with dynamic locks in place to prevent two players trading the same actor/object at the same time (makes sense from a realism perspective as well). Similarly, NPCs that only provide non-dialogue lines in proximity or when clicked will also work for all players, it's just the stuff that removes player control and locks you into the conversation menu that's only available to the hosting player. Obviously, all voice lines will still by synched so the other players can hear what the NPC is saying in real time.

 

Edit: Instead of introducing special NPCs, existing NPCs that are also vendors would simply only expose their vending to slaved clients, nothing else. The restriction about no two players being able to access the inventory would hold, eg. if the host starts talking to an NPC, and another player opens this NPC's inventory in the meantime, if the player upon finishing his dialogue selected the “Let's trade” option, he would get the “This person is currently busy” error message, at least until the other person is finished.

 

Edit: Furthermore, player <-> player trading could also be done via special “inventory” dialogues, where both players can “commit” their portion of a trade to an empty inventory, and view the other's items; then if both players confirm the trade the items would be swapped by a script.

 

It would function very well that way since, if you think about it, converting a purely single-player RPG with quest dynamics, decision making and NPC interaction into a multi-player game simply does not work, you can only port aspects of it, eg. the combat, which falls well within the intentions specified in the original post - for example grouping up to clear a hard dungeon or kill a dragon, or simply numerous companions assisting the host player during some quest of his own.

 

The hardest aspects to synch, from my point of view (with very limited experience concerning any bethesda game's core mechanics), would probably be object physics and actor dynamics (eg. random-controlled movement). Another hurdle to tackle would be zone changes - should all players be instantly forced into the new zone, or should an isolated client (zone-wise) simply introduce its own hosting functionality for this zone? If so, the server could be decentralized, with clients all accounting for unique zones they're currently in, according to a given priority list (where the theoretical “host” would have the highest priority, and would thus act as the server if all players are in the same zone). That way, you can end up situations in which different players farm for different items in completely different parts of the world in order to have one player brew potions for the whole group. In short, the open world aspect is retained.

 

Edit: To facilitate clock synching, waiting could be disabled and fast travel could be made to not affect the ingame time. Alternatively, the wait dialogue could be only available to the host, and when he presses wait, the time value of the slaves simply get updated instantly, without pausing the game. That way you can still have the host player wait, say, 8 hours for a shop to open up.

Edited December 2, 2011 by nandchan

[Szimitar]

I'm sorry, I don't really see the advantage of your proposal. Why is a dedicated server bound to fail? It would be a modified version of the client, stripped of character and rendering cycles, and instead receiving/sending the change in players' states.

 

Lucubration is right though, I misunderstood and appearently the plan is to have a hosting player to which the others connect, as nandchan described it as well. I'm not a programmer so I may well be wrong, but I still think a dedicated server is the key to making this work, so please tell me where I'm wrong.

[hipolipolopigus]

Right, I'm back from my nap! :D Responses time!

[hipolipolopigus]

I think I will join you guys over there.

 

Can it be done? Yes. Will it be tough. Hell yes! Will it be worth it? Fook yes!

 

I would be content if we could get two players in one Skyrim, more than that would be gorgeous.

 

 

 

Alexis

*smiles*

Welcome to the development process! :happy:

 

The way I've always imagined it is that one client acts as a host and will function as a completely normal game, and all the other clients act as “slaves” and can therefore not interact with NPCs or loot whatsoever. All game and save data would be taken from the hosting client's save game - what the loader would do, when starting the slave (after the host is running), would be to generate a new save file that is based on all object data from the server, in order to “synch” the two together, then adding in your own “exported” character from a different save file - that is, its appearance, inventory and attributes. In essence, the slave client acts as a more or less total ghost, with all of its internal processing disabled and actors simply synched via the network (and interpolated locally, eg. only node updates, speeds, animation events and so on are synched).

 

That's just what I'd imagine such a system like. It's a massive project, and I'd be neither willing to nor do I have the time to help with such an ambitious undertaking. But one bit of advice I can give you: Don't even begin thinking about the implementation until you have the entire concept and planning stage mapped out completely.

We're still in a concept phase, but the plan as of now is to create a Server / Client system. If someone has a gaming rig powerful enough he could of course run both Server and Client on his PC, though in most cases a dedicated machine would be best.

Szimitar, that's not quite correct. According to what we've discussed so far, the Server is still playing the game, it's just their instance of the game that is making many of the decisions about actions that take place in the world. Clients connect their own game to the Server and accept the Server's decisions about what's taking place in its world.

Silly Szimitar :3

This sums it up pretty well. The point here is not to implement the entire game mechanics inside a separate Server client - that is simply bound to fail, but rather using an existing game client as a sort of make-shift server, then synching only stuff that's necessary for co-operative gameplay, and not every single action. The challenge is now not ensuring that the world behaves properly, but ensuring that each copy of the world exhibits the same behavior, overall a much easier challenge to tackle than what Szimitar described.

 

Note: It may be yet possible to simply convert an input-less, window-less game client instance into a makeshift server, by just having the only “real” player be repositioned to accommodate for cell loading and so on, with every participating person running the same limited slave client. But then you still need some sort of host machine which will receive decision making priority.

 

One way I could imagine this whole thing working: All conversation, quest interaction and so on can only be performed by the hosting player. To facilitate multi-playerism, we will thus introduce special “vendor” NPCs which, when clicked, will simply open their inventory, with dynamic locks in place to prevent two players trading the same actor/object at the same time (makes sense from a realism perspective as well). Similarly, NPCs that only provide non-dialogue lines in proximity or when clicked will also work for all players, it's just the stuff that removes player control and locks you into the conversation menu that's only available to the hosting player. Obviously, all voice lines will still by synched so the other players can hear what the NPC is saying in real time.

 

Edit: Instead of introducing special NPCs, existing NPCs that are also vendors would simply only expose their vending to slaved clients, nothing else. The restriction about no two players being able to access the inventory would hold, eg. if the host starts talking to an NPC, and another player opens this NPC's inventory in the meantime, if the player upon finishing his dialogue selected the “Let's trade” option, he would get the “This person is currently busy” error message, at least until the other person is finished.

 

Edit: Furthermore, player <-> player trading could also be done via special “inventory” dialogues, where both players can “commit” their portion of a trade to an empty inventory, and view the other's items; then if both players confirm the trade the items would be swapped by a script.

 

It would function very well that way since, if you think about it, converting a purely single-player RPG with quest dynamics, decision making and NPC interaction into a multi-player game simply does not work, you can only port aspects of it, eg. the combat, which falls well within the intentions specified in the original post - for example grouping up to clear a hard dungeon or kill a dragon, or simply numerous companions assisting the host player during some quest of his own.

 

The hardest aspects to synch, from my point of view (with very limited experience concerning any bethesda game's core mechanics), would probably be object physics and actor dynamics (eg. random-controlled movement). Another hurdle to tackle would be zone changes - should all players be instantly forced into the new zone, or should an isolated client (zone-wise) simply introduce its own hosting functionality for this zone? If so, the server could be decentralized, with clients all accounting for unique zones they're currently in, according to a given priority list (where the theoretical “host” would have the highest priority, and would thus act as the server if all players are in the same zone). That way, you can end up situations in which different players farm for different items in completely different parts of the world in order to have one player brew potions for the whole group. In short, the open world aspect is retained.

 

Edit: To facilitate clock synching, waiting could be disabled and fast travel could be made to not affect the ingame time. Alternatively, the wait dialogue could be only available to the host, and when he presses wait, the time value of the slaves simply get updated instantly, without pausing the game. That way you can still have the host player wait, say, 8 hours for a shop to open up.

I... Wow :happy:

 

Having a server that isn't a client/server isn't likely. We need a game running with our server because that's where everything happens. We're not doing everything from scratch, just hooking and intercepting what we can to make the client work correctly. We've discussed a few of the things you've mentioned over on our forums and I'd like to keep theory talk there where possible, head on over :happy: I think you'd do well as an Assistant Director like Szimitar :teehee: You've certainly got the mind for it!