Have I adaquatly described BULLET?

Networking & Multiplayer
#21

Besides saving bandwidth, I don’t get why people would like to use TCP for any fast paced action game. I know thats a bold statement given the amount of discussion on this and yes i’ve read through the whole TCP VS UDP thread. But hear me out :wink:

Typically you’d have two kinds of messages in your game; ones that need to be send reliable and ones that you should fire and forget about. In most fast paced multiplayer action games, you typically have objects that are controlled by remote players but which behaviour is difficult to predict, be it because of a high degree of freedom in movement etc. To be able to make an accurate prediction as possible of their behavior, we need a high as possible update rate of their current state. We need to forget about resending a lost packet as these would already be outdated when they arrive, we need to go on. Unfortunatly thats impossible because the way TCP is built, so UDP is clearly needed for that purpose.

Of course we still have the need for reliable messages and TCP was build just for that purpose. I also agree TCP performs just as well in the same environment as UDP and does a better job at delivering reliable messages than any reliable UDP protocol ever could, because TCP is implemented in hardware. So you could go and built something that uses UDP for the highrate updates and TCP for reliable messages. But using TCP and UDP together has some potential problems:

  • TCP doesn’t work with the UDP NAT punch through technique.
  • In certain situations (typically on narrow channels like modems or a slow DSL uplink), TCP can interfere with the UDP protocol layer, causing jitter in receiving UDP packets.
  • Using two protocols forces you to make two different outgoing/incoming connections and handle two different types of incoming messages, which probably means you’ll have to design your game to take this in account. This point is more of a design question though.

Now, it’s also possible to implement a reliable protocol using UDP. But this needs a solid design designing and massive amounts of testing to get working properly. Also using reliable UDP will probably give slightly less performance to TCP, but this is often not needed for the reliable messages and we’d talk about a very small amount here. But going with reliable UDP would prevent the all potential problems pointed out above. Also, there are already are some quite solid reliable UDP libraries around, even one ported to Java as I pointed out before (jEnet) which will save you this trouble.

Now I think this holds up only for games with fast interaction between players, TCP is probably a better choice when you don’t need that (because the internet is mostly build around TCP like mentioned before). Herkules Flying guns is a very good example that even a flight simulator can be done using TCP, deadreckoning on the aircraft works quite well I guess as their motion is pretty limited?

Thijs

#22

I agree thijs. In fact, that’s exactly the way JGN is built. ::slight_smile:

JGN now supports UDP and TCP as well as reliable UDP. You’ve got the best of both worlds. You can maintain a TCP and UDP connection internally and not have to worry about it, you can got straight UDP, straight TCP, or have several of each. In fact, this was necessary for my PhysicsNetworking API which is built on top of JGN. PhysicsMessages are sent via UDP but any player updates are sent over TCP.

-Matt Hicks

#23

I won’t say limited … it has steady derivatives, motivated by physics.

The WW1 flight sim theme was chosen with networking in mind. Besides having motions that can be predicted quite well it has many other advantages:

  • rel. Positions are hard to perceive exactly
  • shooting is not symmetric: the target has no clue wether the attackers position is excactly suitable for hitting. This gives easy (and 0-protocol) rules for this kind of interaction
  • few points where network artifacts get obvious (like gates or such)

Latency is not really an issue in FG.

#24

How can latency not be an issue? The dilema described by Jeff in reference to latency spikes due to TCP is always an issue if you have lag. Do you have an internal method of ignoring messages that are too old?

darkfrog

#25

Of course quality goes down with latency. The point is that in a networked environment, things are never exact. But in case of FG, things can stay believable over a wide range of latency. In the area of motion, you cannot tell wether a new position arrived 100ms earlier or later. This can easily be smoothed out.

In a properly setup HQ system, all stations share an understanding of time. Thus a client knows that some remote position/speed/force was established at a certain time and can do valid integration from there. The actual current position it computed due to older data is supposed to have only a limited error and smoothing out the diff can be carried out w/o the local user even noticing it.

In terms of shooting, machinegun bullets are very fast and it is impossible to avoid them. So if the local object is told that it was hit, it was hit, regardless wether that information is 100ms old. If I see a remote enemy starts shooting, I can see him shooting and again 100ms is not a delay I could determine even if my opponents screen is beside mine. If I had rockets or so, I’d take care their time-of-flight would be seconds … far above my expected latency.

This e.g. is completely different in Quakes brute force networking where you cannot even move without a reply from the server. Combined with an unsteady motion, you can percieve every single millisecond of latency. Q3 therefor is hardly playable over the internet in a fashion you got used to on a LAN.

OTOH, games like WarBirds play well even with 200 players online and you cannot tell the difference to a LAN game (WarBirds is TCP BTW).

Do PONG … don’t try TRON :slight_smile:

#26

This is getting a bit off-topic and I fear the moderators…

Every single thread seems to end in the fruitless TCPvsUDP debate. This time, we ended somewhere else, hence not discussing BULLET any more. Shouldn’t we start a new thread ‘Gameplay issues in networking’?

#27

All internet games have to deal with latency of one form or another. You deal with it in your design to hide the latency.

As an example, the MMO demo Im writing for GDC right now does local motion and collision detection with an over-riding sanity check on the server to catch cheating.

Flighth sims actually have a huge amount of possible “slop” in the position. if yo uare willing to let the one firing determine hit or miss in fact its possible to cover almost any amount of “lag”.

Now letting the firing player determien hit or miss has cheat potential, but you can again do sanity checks on the serve to see if the result is “reasonable”.

#28

Yes, FlyingGuns in fact is widely open for cheating.

But, OTOH, … nobody ever tried and I’d be glad to find enough recognition that cheaters were attracted!

For FG is merely a tech project, I use simple, clean and minimal techniques and ignore all evil :slight_smile:

#29

In the PhysicsNetworking API I wrote, the implementing game can supply their own implementation of the interface PhysicsServerSession for the server that has a isValidPhysics() that receives all the information on the message received from the player that should be applied to a physics object. The implementing game simply defines its own checks within that and returns true if it’s valid (then the server applies it and spawns it off to the other clients) or false if it’s invalid (and rejects the physics message, sending back a message to that client with the correct position of that object). This allows for handling of clients that have either gotten seriously out of sync, or clients that are trying to hack the game.

It’s a pretty simple concept, don’t deal with it myself, pass it off to the game to deal with. :-p

-Matt Hicks

#30

In the end, the best dead reckoning (which is what this is called) always takes into account both the actual behavior of the obecjt in question and the ruekls of the game being played,.

#31

This supports both of those.

The only problem is whether the implementing game decides to take the time to add such validation. :o

-Matt Hicks

#32

OTOH “punch through” isn’t needed because you can simply map a TCP port on your NAT router and as long as you have either a fixed IP or a dynamic DNS entry the other user can find it.

But on a dial up you really dont want to use UDP at all because TCP has much better bandwidth charcteristics. (UDP ha a 30 byte header over that criticla last mile of PPP, TCP has 1 byte.
)

By doing TCP and a side channel of batched UDP we got a lot better bandwidth usage then a stream of individual UDP packets would.

Hide it in your comm library. Thats what we did with Bullet.

#33

This is off topic, but its the public reelase name of the Sun Game Server project.

Search for Darkstar in the boards for more info

#34

I like the idea of BULLET… the only thing I’m a bit skeptical about is (as pointed out before) that it’s based on stochastics. You have any expirience with how good this would work over the internet?

When TCP needs to resend alot of packages, there would be a big chance these in between UDP packets will get dropped too I guess? That would render the use of these UDP backups kinda useless… as it would only waste bandwidth?

Thijs

#35

Well, most of the time you will be receiving twice as many packets as you need. So long as you have the bandwidth to support it, it shouldn’t be a problem. You’ll gain the benefits of having a backup just in case the TCP message your waiting for gets lagged hopefully the UDP backup will make it through a lot sooner so you can continue and then just drop the TCP packet when it finally arrives.

-Matt Hicks

#36

[quote]Well, most of the time you will be receiving twice as many packets as you need. So long as you have the bandwidth to support it, it shouldn’t be a problem. You’ll gain the benefits of having a backup just in case the TCP message your waiting for gets lagged hopefully the UDP backup will make it through a lot sooner so you can continue and then just drop the TCP packet when it finally arrives.
[/quote]
yeah I got that, also bandwidth is supposely better used than with pure UDP (fx reliable with a UDP protocol) because TCP headers have much less overhead on PPP connections (2bytes vs 30 or something). Even with backup UDP packets bandwidth send periodically, it’s still much more efficient than with UDP only.

But how well does this UDP backup perform in reality? In the scenario’s where the UDP backup is usefull (when a TCP packet is dropped and resend, other TCP packets are stalled because of the resend) this UDP backup could fill in the gap and prevent stalling from hapening. But whenever TCP has problems with dropped packets, UDP will probably have that too, and hence these UDP backups might not get the desired effect in such environment. Im curious how this would play out and if anyone has any expirience with this way of sending data on the internet…

#37

I’m planning on spending some time looking into this further. I’ll post on here if I end up adding it to JGN.

BTW, how’s your networking API coming along thijs? I would be very interested in seeing it. Have you checked back at JGN recently? I just released beta 5 and it has support for P2P, NIO UDP, and several other new features.

-Matt Hicks

#38
#39

[quote]BTW, how’s your networking API coming along thijs? I would be very interested in seeing it. Have you checked back at JGN recently? I just released beta 5 and it has support for P2P, NIO UDP, and several other new features.
[/quote]
Well I haven’t done much work on it lately… (other projects interferred with more prio)
But I’ll pick up work on it soon again. The problem with it is that the project/company I’m doing this for prohibits from sharing with the rest of the world (closed source). But that might change in the near future though… :wink:

#40

I understand, that always seems to be the case with good projects, we can’t ever seem to get authorization to share. :o

Could you give an overview of the architecture of the API? I’m very interested in how other APIs approach developing an abstract networking solution.

-Matt Hicks