fjholmstrom

I've implemented a networking library with uses the techniques described in the "Tribes Networking" paper, now in my current design I have a packet window size of 32 (aka. I can have 32 packets "in transit" at any point in time, if I have not heard about the 32:nd oldest packet, I can't send any new packets out).

 

I also have a time-out that says "if I have not heard anything from this peer in X seconds we should send something", so I send a special "Poke" package from the peer that hasn't heard anything for a while and if the "Poke" does reach the other end it will respond with a "What" package (It's called a "Poke... What?" sequence in code).

 

But my instinct tells me this would not be needed, if there comes a case where I actually end up with the entire window full the peer is most likely gone already? I'm not sure the way I deal with it using Poke/What is ideal either... I suppose in theory (at least assuming non-mobile) stuff you could just disconnect them once the entire packet window fills up with un-acked packages.

 

So basically my question is: How do you usually deal with detecting timed-out peers or peers that are gone? 

Assume my game is running at a rate of 60Hz (~16.66 ms) on both the server and client and updates from the server to the client is sent at 20Hz (50ms). Now since the game is running at 60Hz, there are two ways of calculating the interval for the client updates. I can either just do this: 

if((currentTime - lastSendTime) >= 0.05) {
     SendUpdate();
     lastSendTime = currentTime;
}

 

And just check this every frame for each client. But to me it seems like a cleaner solution would be to specify the client send rate in "every n:th" frame instead, so if I want to send at 20Hz when running at a 60Hz simulation rate I would just do this:

if(frameNumber % 3 == 0) {
    SendUpdate();
}

 

It just feels a lot cleaner, you don't need to keep a separate timer or have to deal with small inaccuracies in the local time of the server, etc. It also becomes nicely synchronized with updates to the game state on the server, etc. The reason I'm asking is because in the few examples of "professional" networking code you can find on the web, I see *everyone* using a the first method of a separate timer for the send time for each client, so I'm thinking I must be missing something here?

So, I have been working on my networking code more and more, and to be honest it's starting to look pretty nicely . But, enough talk... my question is pretty straight. When implementing a jitter buffer, where in the packet delivery chain is common place to put it? I see a few different options:

1. You apply the jitter buffer to the entire packet "receive" mechanism, basically buffering each packet as it comes in and then hands it out at the proper interval to the rest of the code.
2. Since some data might be time critical, you put the jitter buffer "after" the packet receive mechanism and move it to the specific parts of the application that need the buffering - for example rendering of positions.

Also is it common place to use a jitter buffer on both ends of the connection (server and client), or do you usually just run it on one (the client I would guess) ?

I've implemented large parts (~90% of the functionality) of the networking techniques described in the now famous paper "The TRIBES Engine Networking Model" (http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tribes_networking_model.pdf) in my C# networking library.

All in all I have to say that I'm incredibly pleased with the flexibility and performance that this networking scheme offers, but I've run into a bit of a problem. Since one of the features of the way the tribes model works is that the not all objects are updated every time, but rather a prioritization scheme picks which object updates should be written to each packet. What this means in practice is that position/rotation/velocity updates for your networked objects will not be received at a constant pace.

This creates a bit of a problem with displaying objects that move nice and smooth on screen, now even though I am no expert at this subject, the three main ideas behind rendering remote objects on screen are these:

• Interpolation/"Valve"-style, where you hold back on rendering for update_rate * 2, basically introducing some artificial lag but always (except in case of a lot of packet drop) rendering nice smooth movement on screen.
  
• Interpolation and then Extrapolate, basically interpolate from current to next known position as it comes in, and then extrapolate based on velocity from last known position until a new packet comes in, there are a few ways to go about this (linear, cubic splines, etc.).

And, in all honesty - I'm just not sure which model fits best for the type of "Most Recent State Data" model that the tribes networking paper describes. Using interpolation/valve could work, but it could lead to pretty large "delays". And using interpolation/extrapolation, while usable would probably lead to a lot of visible corrections, etc.

Any help on reasoning about this would be most appreciated

I've been messing around with creating my own "shield" shader, the basic idea is something like this - which can be seen in planetside 2: http://www.youtube.com/watch?v=gLHxPZu4blI&t=20m36s now rendering the basic shield on a mesh is not a problem, the problematic parts come when I want to create the "borders" you can see in the video where the shield touches the building itself. The same borders also appear when say a vehicle or player passes through the shield. Other effects im looking into creating is a "wave/circle" type of effect when a bullet hits the shield for example.

Anyway, I'm not looking for cut n paste shader code, but more for general pointers in the right direction to achieve these effects.