Author Topic: Performance  (Read 4104 times)

voncarp

  • Jr. Member
  • **
  • Thank You
  • -Given: 13
  • -Receive: 2
  • Posts: 91
    • View Profile
Performance
« on: August 05, 2014, 01:46:38 PM »
Multiplayer LAN works fairly decent for me as in the following video:

https://www.youtube.com/watch?v=g2_xxMGr1wk

Its a bit jumpy because at the time I made the video, I didn't separate the renderers.  But, everything works pretty smooth.

I tested this on the free Amazon server and everything is choppy, glitchy, and laggy.  I've read on here that the Amazons free version is pretty weak, so I rented a dedicated server from GoDaddy to test and everything is still choppy, glitchy, and laggy.

Is the disparity between LAN and online games really that big?  Could it be that my code is not that well written or is my design of the game poor for there to be such a huge difference?

I use tno.send for everything.   Do I need to switch to tno.sendquickly?

Is there something else I'm missing?  Or is Tnet not made for this type of game?  Its not a high action FPS shooter as you can see in the video everything moves pretty slow. 

Any thoughts would be appreciated.

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Performance
« Reply #1 on: August 05, 2014, 01:59:20 PM »
Yes, the delay between packets can be quite drastic. You won't notice it much over LAN, but you need to deal with that for online gameplay.

Separating renderers is a key thing to do, but it's also very important to think of what you're sending. Sending position updates frequently is a bad idea. Sending input values that cause the movement is a better approach.

In Windward what I do is have input modify the movement values on the vehicle script, and these movement values (X and Y axes) get sent to everyone frequently if/when they change. All clients have an up to date movement vectors. I also sync the position / rotation / velocity, but I do this infrequently -- once every 2 seconds in my case, or when the object collides with something. This way all clients have smooth movement from doing their own movement logic, and auto-correct the position every so often as well. Having a renderer smoothly following the rigidbody makes the correction transition not noticeable.

Deozaan

  • Newbie
  • *
  • Thank You
  • -Given: 44
  • -Receive: 4
  • Posts: 42
    • View Profile
    • Deozaan.com
Re: Performance
« Reply #2 on: August 07, 2014, 01:30:18 PM »
Aren,

Following the method you just described, would you recommend using SendQuickly for the frequent input changes and using Send for the infrequent position syncing?

Or do you think it's all important enouogh to use Send? Or perhaps it's all unimportant enough to use SendQuickly?

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Performance
« Reply #3 on: August 08, 2014, 06:58:37 AM »
Nah, stick to regular Send, and make sure you send it via Target.AllSaved or Target.OthersSaved. Don't send input more than 10 times per second, as it's highly unlikely that you would need that kind of precision. Also it's best to compare it against the previous value, and if it hasn't changed much, skip the send operation (all this assumes joystick input using axes.. if you're only using the keyboard, then this is even easier).

nah0y

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 2
  • Posts: 430
  • \o/
    • View Profile
Re: Performance
« Reply #4 on: September 15, 2014, 06:04:01 AM »
Separating renderers is a key thing to do


Hello,
What do you mean by separating renderers? We usually just send position updates, I mean, nothing renderer related.

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Performance
« Reply #5 on: September 16, 2014, 09:56:40 AM »
Make the renderer lag behind the ridigbody same way I have the cubes trail behind their rigidbody in the 2nd example.

nah0y

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 2
  • Posts: 430
  • \o/
    • View Profile
Re: Performance
« Reply #6 on: September 17, 2014, 02:12:50 AM »
Hum... you mean having the renderer as a child of the rigidbody and using something like your SpringTransform script?
(In example 2 I don't see any trail)

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Performance
« Reply #7 on: September 17, 2014, 01:32:54 PM »
There is no trail. Hit Pause while the cube is falling and examine where its renderer is and where its collider is. The two aren't in the same place.

This is done in order to smooth out any jitter resulted from unevenness of network updates.

nah0y

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 2
  • Posts: 430
  • \o/
    • View Profile
Re: Performance
« Reply #8 on: September 18, 2014, 02:40:20 AM »
Nice! Thanks :)