What would be most accurate Java server-side pair to PhysX

We are making a game with client-side prediction physics simulation and it also has an authoritative server written in Java which needs to correct whenever the client simulation goes off too much.

By "too much" I mean by some margin of error which needs correction. This is because I doubt it is ever possible to get the same simulation on client and server, not just because they are different machines but also because I can't use PhysX (or some port of it) on the server side.

Therefore I am looking into couple of frameworks to use as plain server-side physics simulation. I found a couple of them:

1. ODE4j - port of ODE to Java (actively developed)
2. JBullet - port of Bullet to Java (seems very outdated - based on Bullet 2.72 which is like 2008)
3. jMonkeyEngine (seems actively developed)

I do not need rendering capabilities except for debugging purposes while in development.

My main concern is that although physics is uniform all across the Universe , any given framework might have different set of fine-tuning params than PhysX.
Also what is exposed by Unity to PhysX is surely not the full set of parameters that can be set. So I am concerned it may not be possible to approximate the two simulations on client and server.

ODE4j looks most promising in terms of being actively developed, but its documentation looks very poor, I didn't find proper community or support. It basically refers to the original C++ ODE for information. Unfortunately even the original ODE has its Wiki down.

Do you guys have experience on this part and what approach is best? Thank you!

 

bump... anyone ?

 

It's the wrong way to go about it. All these physics engines have *entirely* different numerical response. They aren't even remotely close.

The temporal behaviour may be similar, but as far as network state and client state goes, they will be extremely different. So your solution is simple: make sure the server physics are the physics you're running in Unity. That is: don't use Unity's physics engine.

This assumes you want to be using:

Whatever you do though, you'll want the same physics engine for server and client.

 

It depends.
Is the Java server a hard requirement? I would advise against it if you still have a choice. (Nothing is wrong with Java, but serving Unity clients is not the best choice, I would roll a headless Unity instead)
If Java is already set in stone, then how much time do you have? Can you postpone this decision a "little bit"?
PhysX 4 is open source. I think (!) ports will span out soon, including Java. If it happens AND if Unity rolls it out, you will have common ground. (Risky business, since you would depend on two major variable)
You can create the Java bindings for PhysX 4, this way you would only have to wait for Unity to implement it. (One step closer, but still risky like hell)
But it all depends on your deadlines and ability to adapt and willingness to wait for something unreliable.
Or you can drop Unity's Physx implementation and try to create a binding for your server and for your client in Unity from the open sourced 4. It can be a lot of work, so it depends on your resources and may not span out properly.

Or you create a PhysX simulatior in Unity and bind it to Java somehow yourself but it's still risky business and requires resources.

 

Hello, would you elaborate more on "different numerical response", I don't understand this part.
Because I already started some integration with Open Dynamics Engine (ODE) I saw Unity's Drag (on that particular object - value of 1) ended up being 0.033 (1x fixed frame time) linear damping on ODE. But it seems pretty similar already. Do you mean using different units?

Interesting, I didn't know they are going open source. It is a good decision. However time is critical I cannot afford year or two waiting for ports to Unity and Java.
Headless Unity is not an option as I am building a large scale performance server. I would guess headless Unity would do for something like a local network of couple of players

 

You need to change your approach. Use kinematic physics and change your design so it's all on the client. You don't need physics on the server. You just need to synchronize the clients and use some interpolation to make it look good. No it won't all be exact but this is a game not a scientific simulation. If it looks good enough it's good enough.

At times you might want to do things like LOS calculations. Even there you have options that don't require a physics engine. You can export the collider geometry to the server and do ray intersection, the math isn't that hard. Or you could just trust the client for stuff like that. Many games do that.

Change your thinking from a brute force approach to a more selective one. Don't pull in an entire physics engine when all you really need is just one or two things. Stop and question what it is you really need. I have yet to find a use case where I really needed a physics engine server side. Where linking in Physx for example would have been a better approach.

If you are worried about hacking, don't. Don't do stupid stuff, but don't worry about will someone hack stuff like LOS or projectiles. Because by the time you are popular enough where hacking is a problem, you will be able to afford people that know how to solve that. And there are good and relatively simple solutions for all of it that don't require running physics on the server.

 

Thank you for your insight, I really appreciate it!
Here is the scenario:
The player runs, drops bombs and can kick them. Both are client predicted - the movement and the kick, they happen instantly. The bombs (before going off) can interact with other bombs, no matter if owned by current player or other players. In that case they become client predicted too. There is also lots of other stuff but this is the problematic one.
So there are three different approaches to this:

1. Client performs just own simulation and client-predicts own stuff and just sends that data to the server (which does not do any simulation, just relays the data to the other clients). The other clients show your stuff as kinematic and it is not physically simulated. In that case if my connection starts dropping, I either need to heavily extrapolate those bombs on other clients or just freeze them in the air. Unfortunately extrapolating physically simulated stuff is not a good idea. The server does not validate input.
2. Client performs own simulation + input from other clients. That way it doesn't care whether the other clients' connections are ok. In this case it does state sync whenever data from those other client's predicted stuff comes in and fine-tunes its simulation. The server does not do simulation again, so it can't validate
3. Client performs just own simulation and sends its input to the server. The server simulates the input and corrects the client if it gets too much off. The server also sends just the position/orientation of bodies which appear as kinematic to the client. The server can also validate however it likes.

Scenario 1 seems very problematic to me as it relies too much on the client's connection to the server which is often faulty.
Scenario 2 is much better as it does not involve server physics and there will be no "hiccups" in the movement of other player's objects. But no server validation.
The third scenario is mainly best in terms of input validation but it involves running the simulation on the server

I'd be glad if you share your thoughts!!

 

The way I handle everything combat related is that part is server authoritative. Client makes an action request, say to drop or kick a bomb. Server records the drop/kick and sends a message to all nearby clients that the action took place. So the action doesn't happen on the client until it gets a response. This includes the initiating client.

This results in potential skill lag for the initiating client, but it's the more fair system and it evens out latency better.

Player movement I let the client run ahead, it's just one of those things where instant feedback is really noticeable, And with all actions server authoritative not much of a downside.

 

thank you!
Unfortunately we can't afford this. The spawn of the bomb + the kick and the force applied to it need to happen instantly. This is because we involve certain mechanics that require real-time handling of the bomb.
Yes what you say will solve the problem but will involve a delay and it will break our mechanic

 

Nothing in multiplayer is real time. You can't remove latency. Your only choice is to some degree where to put it.

If a player action spawns a bomb and you instantiate it when they hit the buttton, it will be some time before other players get the data and can instantiate it. If the player action triggers a request to spawn, and it has to wait on the response to actually spawn it, then the difference in time between when player A and B see the instantiation is reduced.

So what is right depends on what matters most to you. Is it more important that the player initiating the action see an instant result. Or is it more important that multiple clients see it happening as close in time as possible.

The total amount of latency is the same.

No right or wrong as to where the latency goes, whatever feels best for your game.

 

Yes, the player seeing instant result of his bomb handling is most important. The other players seeing some more delay in that player's actions not as much.

and yes, all that stuff will be client predicted. So the simulation needs to be performed either on the server or the other clients as well (Scenario 2 or 3).
You are right that it doesn't necessarily need the simulation on the server. However there is no convenient way to validate the player's input (let's say movement and bomb kick trajectory), if the simulation is not on the server.
I also thought of some kind of peer client validation (i.e. other clients perform my client's simulation too and all issue a command if the simulation is not right, to the server). In that case cheating may be detected without server validation.