Author Topic: TNet optimizations and techniques.  (Read 488 times)

armitage1982

  • Newbie
  • *
  • Thank You
  • -Given: 7
  • -Receive: 1
  • Posts: 15
    • View Profile
TNet optimizations and techniques.
« on: April 24, 2015, 04:59:26 AM »
Hi Michael

I'm interested in TNet and by following this excellent GDC 2015 video from Glenn Fiedler I know it's hard to get a smooth simulation based on physics.

  • Does TNet use a parametric frame buffering system to handle UDP lost package ? (queuing / unqueuing x frames in advance)
  • I read in the FAQ that you're using smooth rendering interpolation for missing steps. Is your interpolation based on Hermit (forcing to pass exactly through each keyframe position) ?
  • I need a fast out of the box network system for max 100 rigidbodies and 4 realtime players. Do you think TNet can handle such simulation without too much jittering and congested packages ?
  • I think I will use the recommended EC2 Amazon free edition. Ping are between 50ms to 150ms. What worries me the most is the Bandwidth consumption. I guess I have no other choice than only sending the inputs with a physic state once every 3 or 4 times per seconds ? Or do TNet feature compression systems to send more data on regular basis ?
  • Glenn use a sequence number do determine the age of each package and drop them if they're too old. Does TNet feature such things or do we have to write it ?
  • Finally Anything to know about TNet when aiming android mobile ?

I'm currently in a 4 weeks game Jam and would like too add networking to our project but avoiding the Unity Networking system (for the same reasons I'm using NGUI :).
Thanks for reading me :)
« Last Edit: April 24, 2015, 05:10:34 AM by armitage1982 »

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: TNet optimizations and techniques.
« Reply #1 on: April 24, 2015, 08:13:54 AM »
1. No, TNet doesn't do any buffering with UDP packets. If you want them to arrive in a specific order, stick to TCP.

2. I am not sure what you're referring to but I don't do missing step interpolation. What TNet suggests doing by default is separating your renderer from your rigidbody. I always have renderer smoothly following the rigidbody. In Windward's case I sync the ship positions only once every ~2-4 seconds, and in-between I just do regular physics-based movement. The values that cause the movement (basically user input) are sync'd much more frequently than that, resulting in each client performing their interpolation using the latest data available and correcting the positions every so often. Since the rigidbody is also separate from the renderer, any corrections are done using interpolation, smoothly adjusting the position to where it should be after the correction packet arrives.

3. If you're smart about it, and don't simply brute-force all that data several times per second for every single object, then sure. In Windward there are usually ~10 ships, each capable of firing ~20 cannonballs per second, resulting in 10*20=200 active physics objects at a given time. I handle that by not even bothering to sync the cannonballs. Each one is created from an RFC packet rather than TNManager.Create, so they are all basically local to the user. Each cannonball's lifetime is only 2 seconds at most, so it's not noticeable that they are not synchronized beyond the first creation.

4. Again, be smart about it and you will be fine. That said, Amazon EC2 may not be your best choice for a real-time game. TNet doesn't do compression. The AutoSync component will check to see if the value has changed since the last time you tried to send it, but I don't recommend using AutoSync scripts for anything other than prototyping. It's always easier to optimize your own RFCs.

5. Same as #1: TNet's primary form of communication is through TCP, not UDP -- and TCP is always ordered and doesn't need this. UDP packets are used if you use tno.SendQuickly, and they are not ordered. It's very rare for packets to arrive out of order in this state of age. UDP packets generally arrive, or don't. I suggest using UDP packets only for things like frequent state updates that you do several times per second, where each state gets overwritten by the following. Consequently, I stick to TCP myself in Windward.

6. Unity 4 would require a Pro license on mobile. WP8 doesn't support sockets the same way so TNet won't work. iOS/Android work as expected, and I have a mobile game using TNet called Starlink.

armitage1982

  • Newbie
  • *
  • Thank You
  • -Given: 7
  • -Receive: 1
  • Posts: 15
    • View Profile
Re: TNet optimizations and techniques.
« Reply #2 on: April 24, 2015, 03:27:57 PM »
Thanks a lot for answering me so fast, it's really appreciated with my tight planning.
Especially since I know you repeat many answers on daily bases (sorry for that ;) )

May I ask you a suggestion for a more suitable server than Amazon EC2 ? Is it because the bandwidth is ridiculously low on the Free tier ?

Our team have very limited funds that's why we talk a lot about a LAN version first because it's a very demanding physical game that won't probably make it online without ton's of hacks.

Have you ever experiment packet congestion ?

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: TNet optimizations and techniques.
« Reply #3 on: April 27, 2015, 04:51:12 PM »
It's less about bandwidth, more about low resources of EC2. My EC2 instance is fine for a game like Starlink, but for anything more I wouldn't use it. You can expect pings to start at around 150 and go up from there, usually fluctuating around 200-300 ms. I'm not the best person to ask about hosting services though... for Windward I just run a few of them on my home connection. Makes debugging easier.

The best way to deal with packet congestion is to avoid it. ;) Code smart, limit the number of updates going out as much as possible. Use local interpolation and/or prediction as needed.