[icecoldduke]

Trooper Dan, on 20 July 2016 - 12:00 PM, said:

I think what Spiker is trying to say is that what you are doing is great but he hopes that you will resume working on the renderer soon and specifically for EDuke32 so that those of us waiting for our shiny new toy will have something to play with.

Shadow Warrior multiplayer won't take me very long to do, and I want it in for the next test. Once the multiplayer code is done, the next test will be ready for release. After that I will get back into rendering.

EDIT:
I'm making notes on various parts of the Shadow Warrior code base. Were is a good place to upload those notes to?

[Moggimus]

I'm looking forward to trying this out. From what I think I see in the screens you've posted, you seem to be running without any texture filtering/hires textures/models and just the advanced lighting, which is just the kind of thing I'm interested in. So this will be able to run both Duke3D and SW? It's looking really great.

[icecoldduke]

I'll upload a new video soon, but now both players can move, kill each other, and respawn.

[Micky C]

I'm curious, if the multiplayer shouldn't take too long, why is it taking the eduke team years and years to do?

[Mblackwell]

Because EDuke32 has to send more data than SW.

Because there's a difference between flooding the network with data packets and doing a proper robust networking pass.

[Hendricks266]

Because "proof of concept" is not the same as "ready for action".

[TerminX]

Micky C, on 20 July 2016 - 02:17 PM, said:

I'm curious, if the multiplayer shouldn't take too long, why is it taking the eduke team years and years to do?

Shadow Warrior doesn't have a scripting system and has no game behavior outside of what is defined in the executable. The multiplayer ICD describes is about at the level ours was at in 2009 when I first had a working proof of concept of client/server multiplayer. Doing it properly is a lot harder and a lot more involved than just replicating the game world from the server to the clients--that part is very easy. The hard part is getting it to work with low latency and low bandwidth requirements when there are potentially hundreds (or thousands in some mods) of sprites that need to be updated constantly. If we wanted shit multiplayer that just had the server sending the client updates by brute force then it would have been done years ago.

[icecoldduke]

Mblackwell, on 20 July 2016 - 02:34 PM, said:

Because EDuke32 has to send more data than SW.

There shouldn't be. You should be able to send the same amount of data in SW and EDuke32, because the server should always be authoritative.

Mblackwell, on 20 July 2016 - 02:34 PM, said:

Because there's a difference between flooding the network with data packets and doing a proper robust networking pass.

The only aspect of the game the client should have control over is movement, and the server would need to do some dead reckoning to ensure the clients haven't warped across the level. So the way I have it is the server sends down a initial snapshot which contains all of the sprite/wall/sector info for the map. Then afterwards the snapshot only contains deltas. I also need to get in interpolation, rather then position snapping. It works pretty well though. I was able to play to with my friend in LA no problems. Granted the latency between my house and my friends isn't very high, but its pretty good for a few days worth of work.

TerminX, on 20 July 2016 - 02:47 PM, said:

Shadow Warrior doesn't have a scripting system and has no game behavior outside of what is defined in the executable. The multiplayer ICD describes is about at the level ours was at in 2009 when I first had a working proof of concept of client/server multiplayer. Doing it properly is a lot harder and a lot more involved than just replicating the game world from the server to the clients--that part is very easy. The hard part is getting it to work with low latency and low bandwidth requirements when there are potentially hundreds (or thousands in some mods) of sprites that need to be updated constantly. If we wanted shit multiplayer that just had the server sending the client updates by brute force then it would have been done years ago.

Sure, but if you add interpolation on top of what I have now, high latency issues shouldn't be as bad. I would argue the clients shouldn't be executing the scripting logic; but you could do dead reckoning on that if you wanted too. Either way I'm not expecting this to go into main. I just want to play multiplayer, and this honestly works pretty well.

[Hendricks266]

icecoldduke, on 20 July 2016 - 02:47 PM, said:

So the way I have it is the server sends down a initial snapshot which contains all of the sprite/wall/sector info for the map. Then afterwards the snapshot only contains deltas.

This is networking 101. Got anything 400-level?

[Danukem]

How about if icecoldduke programs the networking however the fuck he wants so he can enjoy playing with his son and we stop talking about it. Then, when he's done with that and works on the renderer again, we can bicker about that instead.

[TerminX]

Trooper Dan, on 20 July 2016 - 02:59 PM, said:

How about if icecoldduke programs the networking however the fuck he wants so he can enjoy playing with his son and we stop talking about it. Then, when he's done with that and works on the renderer again, we can bicker about that instead.

No, sorry, not interested in letting uninformed statements like "you should be able to send the same amount of data in SW and EDuke32" be made without correcting them.

[icecoldduke]

Hendricks266, on 20 July 2016 - 02:53 PM, said:

This is networking 101. Got anything 400-level?

It really depends on what your doing. Sometimes all it takes is the 101 level . No need to over engineer. Btw how well did Duke3D megaton perform in high latency situations?

[Mblackwell]

Trooper Dan, on 20 July 2016 - 02:59 PM, said:

How about if icecoldduke programs the networking however the fuck he wants so he can enjoy playing with his son and we stop talking about it. Then, when he's done with that and works on the renderer again, we can bicker about that instead.

He's the one that brought it up. And then someone asked why it wasn't done in EDuke32.

No reason to be mad about it.

[icecoldduke]

TerminX, on 20 July 2016 - 03:07 PM, said:

No, sorry, not interested in letting uninformed statements like "you should be able to send the same amount of data in SW and EDuke32" be made without correcting them.

How am I wrong?

[TerminX]

icecoldduke, on 20 July 2016 - 03:09 PM, said:

Btw how well did Duke3D megaton perform in high latency situations?

Like shit, because waiting the full round trip time before anything happens in the game world is unacceptable.

icecoldduke, on 20 July 2016 - 03:10 PM, said:

How am I wrong?

I don't have time for the long-winded explanation required at the moment. The amount of data is pretty similar if only considering Duke Nukem 3D itself. But, you didn't say Duke Nukem 3D, you said EDuke32, where all you need is a giant map with tons of moving sectors and hundreds of actors active at once to make your idea of a working multiplayer setup fall to pieces.

[icecoldduke]

TerminX, on 20 July 2016 - 03:11 PM, said:

Like shit, because waiting the full round trip time before anything happens in the game world is unacceptable.

Yeah it performed like shit from what I remember. From what I can tell of the code, they are just snapping the positions in place. They are also not just sending deltas, they are sending full snapshots from what I can tell as well. I'm sure what you guys have works well with pings above 100ms. So far I pinged my friends box and with a ping time of 50ms it works quite well actually.

I have done a "proper networking pass" on shipped games, and is this the best? No of course not. Does it get the job done? Is it playable? Yes it is in fact.

[Paul B]

icecoldduke, on 20 July 2016 - 03:09 PM, said:

Btw how well did Duke3D megaton perform in high latency situations?

I appreciated what Megaton tried to do by bringing multi-player to Duke 3D through Steam, it was an awesome concept. However, the reality was it was terrible lag and very frustrating to play with others online, unless you were under the same roof.

[TerminX]

icecoldduke, on 20 July 2016 - 03:17 PM, said:

Yeah it performed like shit from what I remember. From what I can tell of the code, they are just snapping the positions in place. They are also not just sending deltas, they are sending full snapshots from what I can tell as well.

No, it's the original input packet based code that runs all players in lockstep so they don't go out of sync.

icecoldduke, on 20 July 2016 - 03:17 PM, said:

I have done a "proper networking pass" on shipped games, and is this the best? No of course not. Does it get the job done? Is it playable? Yes it is in fact.

OK. What's your point? If you want to keep bringing up "shipped games", maybe this would be an opportune time to mention that code we've written is in shipped versions of this game. It's pretty irrelevant to bring up networking in modern engines because it's an apples to oranges comparison and experience there is truly almost inapplicable here.

[icecoldduke]

TerminX, on 20 July 2016 - 03:23 PM, said:

No, it's the original input packet based code that runs all players in lockstep so they don't go out of sync.

Oh I see. Then yeah that would be awful. To be clear I'm not doing that model. You would be correct dnLoadSnapshot and dnTakeSnapshot only get called while waiting for the players.

Did they bother to test multiplayer over the internet before they shipped?

[Kyanos]

icecoldduke, on 20 July 2016 - 03:26 PM, said:

Did they bother to test multiplayer over the internet before they shipped?

It worked well across NA, even Canada to Brazil played fine, just cross the pond games were bad. Or any one player on wifi lol.

[Danukem]

Mblackwell, on 20 July 2016 - 03:10 PM, said:

He's the one that brought it up. And then someone asked why it wasn't done in EDuke32.

No reason to be mad about it.

No I'm not mad at all. It's just that I see this as a distraction from getting the renderer done and by arguing about it here we are prolonging that distraction. It's too bad that someone had to ask the typical "why wasn't this done already years ago" question. I saw that before the replies and I was actually tempted to delete it, but that would have been a dick move.

[Micky C]

My bad.

By the sounds of things, everyone will be happy with icecoldduke working on SW multiplayer up to the point where he can play some games on it, then returning back to the renderer. Then full-on eduke multiplayer can be brought back into focus at a later stage.

[icecoldduke]

TerminX, on 20 July 2016 - 03:23 PM, said:

OK. What's your point? If you want to keep bringing up "shipped games", maybe this would be an opportune time to mention that code we've written is in shipped versions of this game. It's pretty irrelevant to bring up networking in modern engines because it's an apples to oranges comparison and experience there is truly almost inapplicable here.

How is it apples to oranges? How is the amount of data that needs to be replicated down different from SW to Duke3D? I would love to know the approach you guys are taking.

[Mblackwell]

Trooper Dan, on 20 July 2016 - 03:56 PM, said:

No I'm not mad at all. It's just that I see this as a distraction from getting the renderer done and by arguing about it here we are prolonging that distraction. It's too bad that someone had to ask the typical "why wasn't this done already years ago" question. I saw that before the replies and I was actually tempted to delete it, but that would have been a dick move.

Ok then. Same page!

[icecoldduke]

In this video both players can kill each other and move around. I choose to use the sword. In reality all the weapons seem to work fine. Accept for the hud, player sprite animations, and some other optimizations I want to do; SW MP is working great.

[stumppy84]

Good work!! Cheers!!

[icecoldduke]

Drek, on 20 July 2016 - 03:39 PM, said:

It worked well across NA, even Canada to Brazil played fine, just cross the pond games were bad. Or any one player on wifi lol.

I would think with the old net model, performance for everyone would get scaled by the worst connection in the match. In PolymerNG, if a client joins a match and they have a shitty connection it won't effect any other client in the match.

[TerminX]

icecoldduke, on 20 July 2016 - 04:03 PM, said:

How is it apples to oranges? How is the amount of data that needs to be replicated down different from SW to Duke3D? I would love to know the approach you guys are taking.

It's apples to oranges because modern networked games are written with the general specifications of their networking capabilities already in mind. This is completely different from retrofitting client/server multiplayer into a game that was built on the principle that any part of the game can modify any other part of the game at any time, as long as the input is the same on all clients so that the result matches up.

The difference in data that would need to be sent for SW vs EDuke32 should be obvious, because SW doesn't have a scripting system or any way to introduce unknown behavior. You can't just send updates for every sprite, wall, sector, etc in the game every tic instead of logically determining what needs to be updated and when. I mean, you can, but it's a neanderthal level approach that would quickly fall apart as soon as you try spawning dozens or hundreds of particle/effect sprites, etc. There is also the issue of latency and network prediction... you can't just tell the client to wait for the server and not run any operations itself (poor interactivity), nor can you have the client run operations as usual and have the server force its version of things on the client every tic (poor gameplay experience).

[icecoldduke]

TerminX, on 20 July 2016 - 05:46 PM, said:

It's apples to oranges because modern networked games are written with the general specifications of their networking capabilities already in mind. This is completely different from retrofitting client/server multiplayer into a game that was built on the principle that any part of the game can modify any other part of the game at any time, as long as the input is the same on all clients so that the result matches up.

While some of that is true; I have been on projects were have thrown MP in the last minute.

TerminX, on 20 July 2016 - 05:46 PM, said:

The difference in data that would need to be sent for SW vs EDuke32 should be obvious, because SW doesn't have a scripting system or any way to introduce unknown behavior. You can't just send updates for every sprite, wall, sector, etc in the game every tic instead of logically determining what needs to be updated and when. I mean, you can, but it's a neanderthal level approach that would quickly fall apart as soon as you try spawning dozens or hundreds of particle/effect sprites, etc.

If you have a effect that would spawn 100's of new sprites, then you would be correct you would need a different approach. Are you are designing a network system that would just work with all existing mods without those authors having to go in and make there mods network ready? If you are I disagree with that solution. There is no "one size fits all" approach. .

TerminX, on 20 July 2016 - 05:46 PM, said:

There is also the issue of latency and network prediction... you can't just tell the client to wait for the server and not run any operations itself (poor interactivity), nor can you have the client run operations as usual and have the server force its version of things on the client every tic (poor gameplay experience).

If you run interpolation, then the client continues on until the server sends a update. Yes that would result in snapping if the client is far out of date from the server, but what other solution is there? Are you doing a peer to peer approach? If so thats not a good idea, that opens the door to hacking.

[Danukem]

icecoldduke, on 20 July 2016 - 05:56 PM, said:

If you have a effect that would spawn 100's of new sprites, then you would be correct you would need a different approach.

Even in the base game, there's lots of examples of sprites that spawn lots of other sprites (jibs, smoke, scraps, etc.) All it takes is a lot of this happening at once (e.g. caused by a chain reaction of explosions, very common in the base game) and there is your 100's of new sprites.