Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Aug 2011
Offline Last Active Jun 17 2014 11:35 PM

Posts I've Made

In Topic: I just released my own networking solution, Bolt, for the Unity3D game engine.

03 June 2014 - 08:41 AM

Wow this looks really nice, is there a connection limit? Also do you have to have Unity Pro to use this library?

You do not need Unity Pro, no. It will function even on iOS and Android without Pro (check out the tutorial to see how it works). Bolt is developed for games of 2-128 players, it's not an "MMO SERVER" or anything like that.

In Topic: Threading and networking

17 March 2014 - 10:00 AM

If you want to see a source-code of an implementation of the 2nd solution that hplus described, you can check out my UdpKit networking library: https://github.com/fholm/udpkit

More specifically you can check out the chat example: https://github.com/fholm/udpkit/blob/master/src/managed/udpkit.example.chat/Program.cs as it implements this type of polling that hplus describes. All of this is in C# so maybe it doesnt apply for you.

In Topic: Simulation in time vs. frames (steps/ticks)

16 March 2014 - 10:11 AM

I think you're right, to keep nudging the clock back and forth is just going to cause issues. I think I over-complicated this a ton in my head. I just needed someone to agree with my initial idea (using ticks everywhere) to feel confident in it I think smile.png Thanks!

In Topic: Dealing with jitter in client update frequency

15 March 2014 - 09:32 AM

The solutions which exist to this problem are deceptively simple really:


1) Ignore it and don't try to compensate for it, I'm pretty certain a lot of AAA titles do this as you can see the artifact you're talking about in for example Battlefield 4
2) Since you know how fast a player can move in a certain situation (walking, running, crouching, falling, etc. etc.) you can limit the speed a player entity can move with, and let it spill over into the next frame if he's moving to fast. If he's moving too slow you speed him up a little bit instead
3) You can combine 1) with implementing a de-jitter buffer on the server which does 1 UC de-jittering instead of the usual 2 world state dejittering on the client, it introduces a bit of extra lag but should smooth everything out enough that you don't have to think about this.


Also you should always send UC unreliably in a real time game and just send them redundantly instead. Honestly I think I would prefer approach 2) as it keeps the rest of the logic super clean and deals with the visual artifacts where appropriate (in the part of the code which is responsible for the rendering). A lot of your solutions are heavily convoluted with a lot of extra data to keep track of or to send back and forth, or both. And I just don't see a big gain in trying to get 100% perfect rendering of remote entities in every possible situation, it simply won't be possible, again just look at something like BF4 which has a ton of visual bugs/quirks for the remote players (animations heavily out of sync, etc. etc.) and you simply dont care about this when youre actually playing.


However, it would be interesting to get the input on this from someone which has released an AAA FPS/TPS title.


Edit: I mean, just try to play BF4 on a crappy connection with some packetloss/jitter and ~150ms ping, and then see how you move in the world for someone with ~50ping and little jitter/loss. Your avatar will move and animate like crap.

In Topic: Client snapshot updates and fixed events

18 February 2014 - 10:05 AM

I do it like this. I don't count "time", i count simulation frames - aka "ticks". Both my server and client run with 60 ticks / second, and I send data between them every third tick (~16.67 * 3 = ~50ms). The first four bytes in each packet is the current local tick of the machine at the time the packet was sent. I have three types of events: Reliable, Unreliable and UnreliableFrameSynchronized. Reliable and Unreliable dont care about what time they were sent, they are just executed whenever they arrive. The frame synced events are kept in "sync" with the senders tick, so it happens at the correct tick on the remote. I basically just write 2 bits for each frame synced event which tell how many frames "before" the packet tick this event was.