Suggests for a 2d networked game

Turns out doing UDP right is bastard hard. I recommend TCP.

Cas :slight_smile:

Kev, i was trying to not confuse those new to networking. Your protocol is basically the quake3 protocol and is the very rare case of UDP being a good idea. There is flow control and even a solution to the 2 generals problem built in to it.

But i will take issue with the TCP slower comment. The only time you get “reordering” is with packet loss in practice. The internet is not the same place it was in the 90s. In this case even the quake protocol doesn’t work well in practice either (jittery lag). Also since for a lot of games you don’t fit the whole state into a packet, you need the missing ones anyway. And now your implementing TCP on top of UDP again. Which a lot of people seem hell bent on doing. And doing badly.

FWIW I have done plenty with both. And even things like IPX stuff. Sure it can all work. But for most TCP “just works” and when it doesn’t, the alternatives don’t either. And they won’t work without a huge amount of effort and experience and testing in REAL WORLD CASES. Not that LAN your working on.

I don’t think I said you were trying to confuse people or that UDP was better than TCP - in fact I think I said (maybe I mistyped) that they both have their place.

Calling the quake3 protocol a rare case is a bit odd though - it’s a pretty common case for the type of games people want to network here. I’ve got N entities running round a map and I want them to shoot at each other. Pretty common I’d have thought. Though as I said if your model isn’t that then it doesn’t fit.

The only bit I took issue to was the “regurgitated “i heard that you do it this way””.

Cheers,

Kev

For info in Daedalus, I use TCP only ( via Kryonet ). Clients and server are sending update messages to each over 20 times per second and messages are sent each time an event occurs (bullet is fired, item is picked, player dies, player respawn … ) … so at the end it’s quite a lot of messages exchanged ( should try to put a counter to get a precise count per second :slight_smile: ) And all of this is running pretty well, even over internet.
Using UDP seemed to be really complicated to handle, and I was afraid to reimplement TCP over UDP at the end …

So for a bomberman, for sure go with TCP :wink:

That comment was clearly not directed you :D. And lets face it, a lot of UDP is $THIS or $THAT mostly from circulated internet rumors. When you really measure things, its a different story.

I call the quake protocol rare in that you do need the whole state to fit into a packet. What people often miss with UDP is that you can send packets that are larger than the MTU. The ip stack fragments them and resembles, clearly in order. But will not request a missing fragment, but let the reassembly timeout. That means you need to fit it into 1400 bytes or so in practice (its mostly 1500MTU these days i think). That is not a lot of entities or data really.

Long story short. Everything works when you have a good connection. Mostly nothing works when you don’t. And since when things stop working they often stop working in different ways, its hard to have a protocol that will work in that case, let alone all other possible cases.