Author Topic: Best pratices for lot of bullets/laser/shots handling  (Read 2588 times)

David

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 10
    • View Profile
Best pratices for lot of bullets/laser/shots handling
« on: November 21, 2013, 03:30:21 PM »
Hi,

I'm currently trying TNet on a small prototype project I'm coding, a small multiplayer space shooter game. As the spaceships in my game can have some quite big shooting rates, I was wondering what's the best way to handle many "laser shots" per second.

I first tried the naive approach with TNManager.create from the player's starship control script, creating a laserShot prefab on the correct position/rotation. This TNObject is then moved locally by each player at a constant speed (so I don't need to sync position after initial creation), I check collisions with a raycast and I only apply damage to an enemy ship (via a RFC on the hit ship) if the laserShot "isMine" so the shot's result is always consistent. I only call RFC on this object when a new player is connecting so he can see the shots created before his arrival at the correct position. This seemed quite "elegant" to me but I have a small problem with this:

It seems that when I have a quite important ping (tried on an amazon ec2 server with 250ms ping) on the server that the TNManager.create is a little laggy and I can see that my ship's firing rate is not constant nor as fast as when I'm playing solo.

I tried to implement some pool system, with each player creating a pool of laserShots when connecting via a RCC call that adds the newly created laserShot in a pool, but it takes quite a long time and it "floods" the server with create calls each time a new player is connecting. And I suppose that having a lot of "pre-created" TNObject isn't that good performance-wise as there will be a lot of calls to OnNetworkPlayerJoin callback each time a new player connect with properties synchronisation (activated or not, position, rotation...).

Do any of you have any tips on how to handle this problem ?

Thanks !!!
« Last Edit: November 21, 2013, 04:06:50 PM by David »

David

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 10
    • View Profile
Re: Best pratices for lot of bullets/laser/shots handling
« Reply #1 on: November 22, 2013, 01:53:14 AM »
Just thought about the pool system I suggested, it would be much more efficient to have only one "laserPool" prefab with its own TNObject, and send/receive updates about its currently active children. Feel free to comment if you have any other idea  ;D

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Best pratices for lot of bullets/laser/shots handling
« Reply #2 on: November 22, 2013, 03:37:36 AM »
I'd recommend synchronizing the "started firing" and "stopped firing" events (which can be as simple as tno.send("SetFire", Target.AllSaved, isCurrentlyFiring)).

Frequent calls should be local because it doesn't matter if they are not 100% accurate.

David

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 10
    • View Profile
Re: Best pratices for lot of bullets/laser/shots handling
« Reply #3 on: November 22, 2013, 11:41:50 AM »
It seems to work great like this, thanks. I don't know why I tried so hard to keep a TNObject involved for each shot :o

For those interested here is how it works now :

As Aren suggested, from my starship's controller I now only synchronize the fire input (button state change or on/off value based on axis) with the other players. Each player will then process the input and use Instantiate (I'll add a pool system later) to create the laserShots locally. I just keep a bool in the laserShot manager script to know if the shot has been spawned by the current player (set with TNObject.isMine) so only one player computes and synchronize the damage done by his shots with others.

I will just need to keep a track of the currently "active" laserShots in my starship controller class to synchronize their position with a connecting player (but they don't live for a long time, maybe it's not really needed).