Rigidbody networking of a soccer ball

Walther95

Hi, I'm trying to develop a symple soccer game with cars as rocket league. Basically 2 players control a ball to hit into the opponents goal.

I'm playing around with the setup from the PUN tutorial.

The cars (player) are a simple gameobject that contains: BoxCollider, RigidBody, PhotonView, PhotonRigidbodyView
Same for ball: a gameobject that contains: SphereCollider, RigidBody, PhotonView, PhotonRigidbodyView.

Obviously I set the PhotonView to observe the PhotonRigidbodyView

The script is very simple, the Ball's script contains OnCollisionEnter function. If it detect a collision by player, it will apply AddForce Impulse to the RigidBody Ball

Unforunately, during the test, it works perfectly only for MasterClient. The player client when collide the ball, suffers a small delay on push the ball.
Also sometimes the ball doesn't detect correctly the collision and cannot move it at all.

Tobias

I am sorry to say but the problems you describe are to be expected. PUN is using state transfer to sync the game over the network. As the authority over the entities is distributed, no player has a perfect view of what the state in the simulated world is.
With variable lag and loss, a player may notice too late how the ball moved for the other player(s), while it looked as if this client could push it.

The simplest example of a hard-to-network game is Pong. Simple on a single machine but quite tricky for multiplayer.

Synchronizing physics over the network is really tricky. There are a lot of articles about that and various approaches.
In the end, you need to make sure the clients run (pretty much) the same simulation with the same sequence of events.

PUN is not built to solve this scenario out of the box.
If you need a professional solution for this, I could recommend Photon Quantum.

Jofrsi

@Tobias I'm interested in Quantum, and have a question regarding its performance with a large amount of rigidbodies.

From what I've gathered about the old TrueSync, from talking to other devs, the system would run into performance issues with over 100 rigidbodies if there were a lot of operations, there's even a forum post here mentioning something like that.

I'm looking for a solution that can handle around 5000 rigidbodies, give or take. Most will be "idle" at any given moment, but I'm still interest in knowing if you have any idea of how Quantum will perform under these conditions.

erickpassos

Hi,

(One of the) Quantum developer here.

Quantum has nothing to do with TrueSync, so performance figures are totally unrelated (I also hapen to be the original developer of TrueSync).

100 rigidbodies should be just fine... We have resting optimization, etc... You can also freely remove/create, turn into rigidbody, any entity in runtime, etc.

However, 5000 RIGIDBODIES is not easy even for non-online, local player physics...

We handle a lot more than this number if you are talking about generally STATIC colliders (where we can have as many as needed, only constraint is memory).

But actually moveable Rigidbodies, 5000 is an unrealistic expectation (for any physics engine TBH, if you plan to actually make these networked, etc).

Notice I always consider a PRODUCTION environment, where you need to make a game that runs on actual player hardware (normally weaker computers, mobile phones, etc)... For a YoutTube demo with a super nice rig, of course it works...:)

Normally RTS games, for example (which use these kinds of numbers in reality) do NOT use physics engines... But technically simpler and more practical approaches.

Erick

Jofrsi

@erickpassos I created a prototype game with a scene with roughly 4.5 thousand rigidbodies, and when running the game Unity's built-in engine seems to have no problem on an i5 cpu with a couple of years, "idling" at 6% cpu usage with no player input and pushing ~45% in the most stressful possible conditions allowed, so akin to a production environment as you might put it.

I realize Quantum allows the at will creation of rigidbodies, but that just wouldn't provide the same player experience (I tried simulating that), which is why I was wondering, if Unity's built in engine can handle this perfectly fine, how might your engine perform? Can I expect performance to be comparable, or significantly different?

I realize this can potentially be a (very) hard question to answer, but an educated guess suffices.

Jofrsi

@erickpassos I created a prototype which has aprox. 4.5 thousand rigidbodies running in Unity's built-in engine. It manages to run fine, with rendering disabled, on an i5 with a couple of years. In a production environment, as you put it, it taxes 6% of the cpu on "idling" conditions, with no player input. It goes up to 40% under the most stressful conditions.

Keep in mind most of the rigidbodies are not being "operated" on most of the time. They're just sitting there mostly. Still, I would rather not disable the rigidbodies, as that would compromise the player experience.

Which is why I was wondering, if it can run this well in Unity's built-in engine, how might it fare with Quantum? Am I looking at a significantly different performance?