@mattm: thanks for sharing this!
Is there an easy way to effectively disable the movement of an object for a physics tick but keep it interacting with other things. I know it sounds like a really weird request but I am trying to move just a specific item on a physics tick and this would allow me to achieve this. The reason I want to do this is for my FPS client side prediction when the server is authorative; similar to http://gafferongames.com/game-physics/networked-physics/
1 Like
@normen
thanks a lot. Still havnât got to grips with what that mode means, must read more!
@nego
No problem. His articles are very informative and cover the basics of FPS network gaming very well. If you are going to attempt to implement this then let me know as I have several ideas and would appreciate someone to talk them through with and bounce ideas off!
Matt
1 Like
i am trying to implement something more complex, he refers to it in the section âgeneral networked physicsâ. I have not given so much thought about it, but all approaches require an âphysics_update_stepâ method
Have you been able to find such an method in jme3? I think it has something to do with BulletAppState.step(âŚ) but havent been able to reproduce how to form input parameters, what method to call and how to get all locations & velocities out of the âsteppedâ simulation
Just implement PhysicsTickListener, its called on each physics step.
@normen: Thx, could you give me another hint, if you were already dealing with a similar problem already, plz?
Lets say I save the whole physicsspace into a list, when an physicstick occurs.
Lets say I do this for the last 100 times a physics tick occured, so i get a list of 100 physicsspaces.
If i need to correct the 10th last physicsspace, i would load the 10th last physicsspace , make the corrections and step the physics update for 10 times.
Whats the best way to do this? If i find something in the native bullet library doc i will keep you updated!
After having similar problmes, I decided to use Rigidbody physic with a capsule shape. While a bit problemating with the tweaking it works quite good once everything is set to the right values. (Also this has the nice sideeffect of being traceable with jbullet rays (for example when a vehicle drives over you you see the whels bump over your body ^^)
@EmpirePhoenix: that sounds great! How do you handle uneven terrain which can make your character slide down the âhillâ? How do you step up on stairs?
Well with the friction the capsule has it is possible to set it in a way that let is slide kinda realistic, stairs are no problem because the capsule is round on the bottom, so actually (depending on stairsize) around have of the total walkforce can be used to move upwards. The larger the steps the more force is used, untill the force does not matter anymore (once you reach the vertical part of the capsule). ( again this needs much twekaing in combination with the friction, so the player is not too fast on horizontal flat ground, can still walk stairs with reasonable stepsize and hills under a certain degree.
Actually for the last I added a little extra, with a ray I check how the hitnormal of the ground under the player is, and if it is over a certain amount I apply a downward force)
1 Like
@nego
I have done quite a lot of work on this and will attempt to summarise my findings. I hope I am clear, if not just ask! Also, note that I am at the investigative stage at the moment. Whilst my code works for a few clients I have no idea whether it is scalable. It also has some limitations that are present in any system of this type. Also note that this is nothing new; it is based on reading about the half life 2 source engine and any articles related to this (such as the one above). I am also sure someone has used JME to implement this better.
My Aim
My aim is to create a game like half life 2 or battlefield 1942, i.e. a fast paced FPS with limited physics. To this end I require that moves by the client are not restricted to a round trip to the server (client prediction) and the server is authorative. It is these requirements that drive my game.
I am using bullet physics as these help model the vehicle models more realistically.
The physical interaction between more that one client and the environment is minimal. This is a key point; client side prediction will not work in a richly interactive physics environment so if you want to do this suck it up and accept the round trip; it is the only way if you want an authorative server. Hopefully the details below will indicate why.
- As you mentioned the stepping model is paramount. To achieve this I allow the physics on the client to run as normal. I use a physics listener and then every tick:
a) Check the user input and move my character on the client accordingly
b) send an update message to the server. This message details the user input and includes a client physics tick number, which is just an incrementing long. I send a message even if there is no input from the user; you will see why later.
c) store the end position of the character against the physics tick number. I typically keep about 20 of these - they are used for rewinding checks detailed below.
d) Store the input applied this tick against the tick number. This is used for rewinding if required
- Upon receiving an update message on the server
a) I disable all characters and models not controlled by this client (how is yet to be determined - for now I just disable the controls).
b) I perform a physics tick. Note this is a normal physics tick but when I want it! It will only move the items controlled by the sender of the update message.
c) At the end of the tick (this can be less frequent, but for now I do it here) I send the state of the character. This includes his position, rotation and the physics tick number in the update message.
- Upon receiving the state message on the client I check the sever position (in the message) with the position I knew the client to be at for this tick (see 1c above). If they are different (by more that set figure) I need to rewind. This is done as follows:
a) Set the character to the server position in the message and disable all other characters (stop them moving).
b) Using the values store in 1d replay the moves from the updated tick number to my present tick (the message from the server will be old). Get my new current position and update the character to this position. There are various ways for smoothing this. NOTE that each input move needs to be followed by a manual physics update for accuracy (this is why I disabled the other characters in a).
c) Get rid of all old moves that I have stored, i.e. any that occurred in ticks prior to the tick number in the state message.
And that is how I am currently implementing that article. A few things to note are:
a) All objects that obey physics have to be owned by a single client and get moved on that clients physics step. This is why complex physics interaction is not possible. For instance, If I hit a brick wall in a car the wall will step with updates from my character (my physics steps). This means the server and the client, from my perspective, are doing the same, and correct, thing. If someone else hits the wall at the same time the physics will not hold up. Tough luck, someone will take control and the other person will suffer the effects. This does not happen often so can be forgiven.
b) On the client, in my implementation, all other moving objects are time lagged and interpolated (by about 100ms). This means that they move smoothly even though the movement on the server will be jagged depending on the updates received. From the clients perspective everything will look fine, even though in reality you are responding to things that happened slightly in the past.
c) The real physics steps on the server will do nothing as the server steps are driven independently from each character only when they provide input (even if this input contains no actual user input and is just a âmy physics steppedâ message.
Hope this helps people.
Matt
1 Like
@EmpirePhoenix: thanks for explaining, if it can be tweaked as you say, rigidbodies could definitely be used for some realistic physics.
@mattm: thanks for taking your time to write down your current research on this manner
It seems that you have taken care of every detail.
I have some questions/suggestions though:
- How do you âforceâ the servers physics tick? Are you using the default physics ticks? If thats the case you would only be able to update 1 client per physics tick (as you have to disable all other controls)
- The same applies to the client correction. You say you manually step each physics tick from the point of correction to the pressence, applying each input at its respective prePhysics tick. At the end you get the corrected clients location and rotation out of it.
Is that corrected value copied into the actual client physics that runs parallely? Or are you just enabling the other controls again? If the latter question applies to be true, you get an illegal state out of it, as i perceive it:
Example:
If a ball was rolling on the floor before you stopped (disabled ) its controls, that ball would be 20 physics tick (worst case) in the past(!) after you enable its control again. This means that ball would be out of sync with other clients /server.
*Have you give some thoughts about syncing a richly interactive environement (as you refer to it)? Wouldnt it be possible to use the exact same approach used here, only with some differences?
-Server: for every client input for the same(!) object, you rewind and add all the inputs(from all clients) received so far and apply these added inputs
- Client: you dont get rid of the old moves right away, as you could receive more corrections for the same object that happened even prior than the currently corrected physics tick
I hope this was understandable, if i missed something, please correct me!
On the server I simply call the update method on the physics space whenever I get an update message through. Having disabled all the other items this update only affects the item I got the update for. The automatic physics ticks get ignored completely (all objects disabled).
On the client the rewinds are only used for getting the correct new position. Again, these are called manually using the update method. The real physics tick on the client is the only thing that properly advances the simulation forward. Of course, this means on the rewind the objects are not in their actual correct place, but again the limited interaction and server side authority makes this acceptable.
I think the key in both cases is that a physics tick can be called manually, you do not need to wait for it.
A rich interactive environment is much harder to simulate as you have to ensure that each client is providing messages to the server at the same time whist still being able to predict in a manner that will not cause too much snapping. This means speeding up or slowing down the client depending upon jitter etc, It also means a lagging client will hold up all the others - not good in a FPS. If you look at pretty much every FPS on the market the physics interaction is minimal - the physics that most impress are client owned; a car going along bouncy terrain, a plane swerving through the air etc. Each of these have very identifiable ownership of the physics objects and so can be predicted client side.
Matt
1 Like
Actually the source engien concept has one fundamental flaw. If you own css or similar just run directly behind another player who is moving in the same direction. Tada you have a problem with the client authoritative as those two are interacting with each other. (And tihs actually happens more often than you want, since in battlefield you play as a squad(and in css as a team ect)
Really depends on how you do this. Another nice trick for this is the way left4dead does. You are not solid but push each other away, so small inconsitencies are not that much fellable as you just get pushed a little.
1 Like