Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Jan 2012
Offline Last Active Jun 02 2014 07:24 AM

Posts I've Made

In Topic: Network message solution for client/server architecture

17 January 2013 - 04:27 AM

First, note that I mainly use C# together with XNA and Unity3D, so maybe the rules for games and engines using C++ are different. Anyway, I strongly prefer the first option. While there are quite a few classes that needs to be created, I do not see this as a major drawback. It creates a very clear separation of "data that is put on the wire" and the other code which deals with this data. Everything gets encapsulated into one neat little package. And I suspect that even if you use something which is more akin to your second example (the SWG emulator one), you would still end up with some sort of encapsulation similar to an "Message" or equivalent to be able to do reliable sends, sequencing, etc. 


Just as an example, this is a "Message" (my networking lib calls them "Events") which is used to send the click position and target object in a physics based puzzle game:


public class ShootBallEvent : NetEvent
    public static readonly ushort Id = 0;

    public NetObject Target;
    public Vector3 Position;

    public ShootBallEvent()
        : base(Id, NetEventDelivery.Unreliable, NetEventDirection.ClientToServer)


    public override void Pack(NetConnection conn, NetPacket packet)

    public override void Unpack(NetConnection conn, NetPacket packet)
        Position = packet.ReadVector3();
        Target = packet.ReadNetObject();

    public override void Process(NetConnection conn)
        if (Target == null)

        if (!ReferenceEquals(Target.Owner, conn))

        // ... do stuff to Target and Position


I find this encapsulation to be very clear and easy to work with.

In Topic: Detecting and disconnecting peers that time out?

08 January 2013 - 12:46 PM

The "poke/what" packet sounds like a "heartbeat," which is sometimes used to keep idle connections alive. NAT gateways may be aggressive in tearing down connections if no traffic has been seen for a few seconds, so keeping the interval < 5 seconds is a good idea.

If you send packets on regular intervals, the heartbeat is not needed. And if you exceed your window size, and time out for a number of seconds, you can probably safely assume that the remote end isn't going to be having a good time playing the game, and treating it as dropped (which it probably is.)


What I do these days is keep a certain amount of "slack" (this may be buffer space, or window space, or whatever,) and as soon as that slack is exhausted (out of buffering, out of window space) I declare the other end unable to keep up, and drop the connection. This works for both TCP (buffering) and UDP (window space.)


Yes, I suppose the Poke/What thing is sort of like a heartbeat. But my library is built like the Tribes Networking paper described and uses a fixed (configurable per client) rate. So a heartbeat is completely unnecessary, as you say. And if one of the connections drop WINDOW_SIZE (defaults to 32 for me) packets *in a row* - their experience will most likely be horrible anyway.


While the way you do is kind of "aggressive" (lack of a better word), it  seems like a really clean approach - BTW when you say "slack", what exactly do you mean? Like I've said my window size is 32 packets, would "slack" be more packets on-top of that or?

In Topic: Best way of sending updates at fixed intervals.

08 January 2013 - 07:28 AM



If the simulation runs on a fixed timestep (60Hz) - I would take that as a guarantee of 60Hz, it might jitter a *tiny* bit back and forth but at least the whole simulation will "jitter" instead of individual connections send intervals. And yes, the slight aliasing which will happen with the first method is what hit me when I implemented it - but like you say the aliasing could be countered by simply doing some slight rounding or something equivalent. 


One thing which trips me up about using the second method of "frame hopping" (never heard that expression before) is this: What happens when I do get jitter on the server, what if I get HUGE jitter and I need to run 4 frames to "catch up" to real time. Then I will send two packets in quick succession... hm, but then again if that happens the client will just perceive it as network jitter anyway. The difference here I suppose is that timing it manually using (lastSend - currentTime) you would only send *one* packet for those four updates.

In Topic: Where to put the jitter buffer

06 January 2013 - 05:48 AM

The sender typically just sends as soon as possible. Additional latency there just adds latency, without any real help against jitter.


Ah yes, maybe I was not clear - assuming a Client/Server model, is it common place to de-jitter things sent form the server to the client and also de-jitter things sent from the clients to the server. Or is it usually just applied in one direction? I would assume both.



You may decide that "time critical" packets are delivered on receipt, rather than de-jittered. The question is then: What will the experience be when you actually have jitter, and those "time critical" packets are delivered with some delay (say, exactly the delay of your de-jitter buffer.) If the game is still a fine experience, then why not de-jitter everything all the time, if the game is still fun and the code simpler? There may be cases where instant delivery on receipt actually on average makes the game better; in that case, that might be a fine optimization to implement.


As always a very good point, and I'm leaning towards putting the entire packet in a jitter-buffer, as it just makes the entire code easier and cleaner (like you say). Also I worry about actually untangling what *can* be delivered instantly and what has to be de-jittered, it just seems like it would lead to a slew of possible de-sync issues and weird behavior.

In Topic: "Shield" shader - How to create "bullet effects" and borders?

20 December 2012 - 09:35 AM

OMG too long video can you capture that specific effect?

I linked with a time/second mark, but apparently the embedded youtube player didnt pick up on that, no need to be a douche about it.