time step simulation independently for different objects

[greeniekin]

I know this sounds stupid, but I just want to know if it can be done with bullet. A quick google didn't give me anything


What I want to do do time step for each "entity" separately.
So an entity that is given all it's information quickly can step in time as you would expect.
Though an entity waiting for a series of instructions will be able to quickly do it's own time step quickly to catch up to the normal simulation.

I do not expect the catch up simulation to be able get old values from other objects while doing the catch up simulation.

I know you will think it stupid and will get a lot of information why you should never do that.

Though I would much appreciate any help anyone can give me.

[Basroil]

I do not expect the catch up simulation to be able get old values from other objects while doing the catch up simulation.

I know you will think it stupid and will get a lot of information why you should never do that.

Is there any reason why you can't step the simulation normally and just apply new targets for objects independently? Basically, either these "entities" belong to one world or they are independent of each other. If they are one world, you should step them together even if you use old data, if they are independent then just make multiple worlds each stepping at it's own pace (which can be made to work faster on multi-processor systems too).

You can disable simulation (force deactivation) for certain parts at a time, but it'll get messy and you'll certainly have collision response issues.

[greeniekin]

Well I am fiddling with some some game networking.

What I was thinking there are really 2 types of networks.
one is the client tells the server where it is. which means even with high pings and packet loss the player will not feel like they are lagging(the jerkiness of your character) Though is easy to hack.

The other is the server is authoritative the client sends messages and are put in the queue to be calculated as the world steps, and client predicts. The client is then informed if there is a difference between the server after it is simulated normally and causes jerkiness(plus other things).it is very bad with unstable ping or some packet loss.

My thought was middle of the road make the server instantly step through the commands received and returns if the state is the same. It also allows a dropped packets commands to be re-sent and calculated. which in the authoritative model would kind of needed to be dropped or you queue for a players commands will get really big and make the client simulation and server further apart in time. Some dynamic interp per player will be needed for rendering though. It will hopefully be more tolerant. if not cause some miner weirdness. Like a player walking faster after a lost packet to get to the right position.

Since players might run into each other players need to be in the same world. duplicating everything for each world sounds painful.

While I know I could just implement client based movement and have a distance per second measure to make sure they do not cheat I kind of want to avoid that.

The idea seems to work though i am just moving squares around no 3d physics.

[c6burns]

IMHO changing the way the physical world is stepped is completely unnecessary for networking the simulation. When you asked about this, I thought you were going to be trying to do something way crazier than just networking. I think you will only make more work for yourself, but that's certainly your prerogative.

If you consider that a decent network framerate is 4 frames per second, interp and extrap will hide any rubber banding and you don't have to dig into the physics lib and dirty it up.

[Basroil]

I'm going to have to second c6burns here, just simulate normally and update when necessary. If hitboxes are necessary, players will thank you for instant updates far more than they will complain that there's an occasional large jump.

You should experiment with available netcode before trying to dive in, and do know it's never a one-man show when building those types of systems, there's too much to do and too many bugs to fix. Even AAA titles can have shoddy netcode, including the BF4 debacle that came from using a technique similar to what you described. And when they do have bad netcode, players will complain more about usability than aesthetics.

[greeniekin]

Rubber banding for your own player can not be avoided when there is a predication error or packet loss. my way would make packet loss not matter(to a degree) and would shorten the time of prediction errors.

I know games struggle with networking. Though I do not really have a dead line to meet or a game that desperately just needs to be made. Otherwise I would just use a a complete engine like source or unity. I am just dabbling.

Also Basroil the number one reason netcode issues are caused is not because they do not send states as quickly as possible. It is not using lag compensation(or non-identical prediction code). Which at 300 to 400 ping your state is nearly half a second behind yet with the non authoritative model I will not notice any lag. This idea has my interest because of sauerbraten.org . there are no Australian games ever running. only u.s. or in europe. I have 300 to 400 ping. Yet it is perfectly playable. Where as cs:go sometimes isn't playable with games in australia. Networking is like special relativity depending on your perspective space and time is different and not necessarily uniform.

Also my method is not making a players states lagged like I think you see it as. in a normal method your commands reach the server and are not executed for a while because there are 3 or 4 ticks worth of commands that need to be executed and are just delayed(doubled 6 to 8 with lost packet). mine They are instantly processed and the state is available to other players. I have a pretty good understanding on networking and have written the netcode and entity system already. So it is not like I just thought of this 2 minutes before posting here.

This is really short summary about some of the thoery. Much has been skipped as well as why other changes to a normal system will not work.

Though I am just experimenting. This will only work out to be about 0.05 to 0.10 seconds of physics simulation time to catch up.

Though I have a feeling the answer to my bullet related question is simply no it can not be done. It would be nice to hear it from someone though.

[c6burns]

You can't do exactly what you want without modifying the library. Would love to proven wrong though and learn something new. Also I think this is a fun thought experiment, but when you get to the implementation the fun will sink out of it really fast.

[Basroil]

Also Basroil the number one reason netcode issues are caused is not because they do not send states as quickly as possible.

The biggest issue isn't sending states quickly, it's sending them at different rates and times for different players. If your ping is 200ms and another player's is 200, the total time from their motion to you seeing it could be 400ms in bad cases, and you could be looking at almost a second if you include you shooting them. By that time they could have registered another command and either they get pissed off because you shot them where they "weren't" or you get pissed off because your point blank shot missed for "no reason". It doesn't really matter how your client side physics work, that closed loop will always exist to some degree.

It is not using lag compensation(or non-identical prediction code). Which at 300 to 400 ping your state is nearly half a second behind yet with the non authoritative model I will not notice any lag. This idea has my interest because of sauerbraten.org . there are no Australian games ever running. only u.s. or in europe. I have 300 to 400 ping. Yet it is perfectly playable.

Yet they don't use physics at all! You can check their source code at sourceforge, it's not actually using physics, rather just updating states compared to a surface (and providing contact and raycast components). That's far easier to deal with... but even then it specifically states all work is done with constant frame-rate.

Where as cs:go sometimes isn't playable with games in australia. Networking is like special relativity depending on your perspective space and time is different and not necessarily uniform.

Latency issues are entirely dependent on gameplay. An RTS game can have a second or two of lag without causing too much issue, and a turn based game could theoretically could have a minute of lag and nobody cares. But an FPS where you parkour with lasers and one where you slowly run with rockets also have very different latency limits thanks to gameplay (both player movement speed, projectile speed, and accuracy requirements).

Also my method is not making a players states lagged like I think you see it as. in a normal method your commands reach the server and are not executed for a while because there are 3 or 4 ticks worth of commands that need to be executed and are just delayed(doubled 6 to 8 with lost packet). mine They are instantly processed and the state is available to other players. I have a pretty good understanding on networking and have written the netcode and entity system already. So it is not like I just thought of this 2 minutes before posting here.

This is really short summary about some of the thoery. Much has been skipped as well as why other changes to a normal system will not work.

Though I am just experimenting. This will only work out to be about 0.05 to 0.10 seconds of physics simulation time to catch up.

Though I have a feeling the answer to my bullet related question is simply no it can not be done. It would be nice to hear it from someone though.

1) It's not about making states lagged as much as understanding that what you will be showing users an outdated model that does not represent the player's motions. It's your choice to pursue that, and with the right game mechanics it can work just fine.
2) I don't understand why you think that stepping the world at a fixed rate but only changing states for players when the data is there will lead to more than 1 frame of lag (from data in to data out). You can always set targets regardless of if there is new data, I do it all the time in a simulation that is 240fps but each component only updates once every 8ms in order, and it works perfectly. In fact, you can update any and all available data as it comes in that way, there is no queue to speak of.
3) If you already wrote the netcode specifications, then simply implement the client end as-is. From the sound of it though, you have yet to implement the server side code.
4) How are you getting 50-100ms of calculation? Assuming 60fps server code you'll probably have 1-15ms of physics calculations (depending on what you are doing and how much) per frame, not 50-100.

I think the issue here is that nobody's on the same page when it comes to your idea, and to be honest it doesn't sound like the idea, as I can interpret it, would be a physics problem to begin with. It would probably best to first discuss the netcode (serverside simulation and client update) with people more familiar with that, and then worry about exact physics implmentation

[greeniekin]

Basroil it is great that I am getting so much well thought out information from here. I will need to think about it more as it is past midnight here and I have been dealing with what turned out to be corrupted extended partition all day(linux to the rescue) and am hugely frustrated.
While it is true each application/genre benefits from different networking models. Really the best model I could think of would be client side information with hitscan per tick provided by client and time per distance checking to see if what happened is remotely possible. Though I was thinking of a unified client/server script that unified them. Silly and stupid I know in the real world we need performance. 2 separate codes for server and client is nothing for a game.

your point about different update frames is also important as it does require different interp values per entity as opposed to the nice clean server side linear only calculation we are use to. with the client side having 1 interp time and 1 prediction time.

cs became famous with the lag compensation of rewinding players by the lag time and calculating the shot. Thus countering the lag for the person making those ever critical sniper(hitscan) shots. Which would sometimes result in people clearly under cover dying from a shot from a very lagged client. This became ever so important because people notice lag easily from there own perspective. So the goal was to reduce lag from the players perspective as much as possible(also why we have player predication, or client authoritative works so well). While in my method it would become increasingly convoluted to rewind time(each entity having it's own time line) it could still use some already existing lag compensation methods. Like target compensation rather than rewinding. Where as if the client said who it's cross hair is over as a co-ordinate relative to a player it's aiming at rather than rewinding. This can be limited by the difference by the supplied angle and the given angle calculated by the target(to stop hacking). From what little I can remember I think halo implements this in multi-player. While this causes it's own problems like players who get under cover due to lag not getting hurt(thus punishing laggy players in unique circumstance). Looking into networking there is always compensations. In many game people complain about laggy players because they get shot when behind walls(because of rewind). Yet people will complain because of this alternative because from their perspective they shot them just before they got under cover. Unfortunately you can not please everyone.

While you also mentioned the network requirements of rpg's vs fps. saurebraten is an fps. Which is considered the most demanding of network models. It's client side calculations make it unbelievably tolerant(but very dangerous). Part of my idea for the client model for scripting was between frames to have a test between the clients sent position of and the server calculation. If a small variation in position then give the client the benefit. More so then the simple speed per second I mentioned before, as much smaller variation can end up with the same result. Except with less exploits . The idea is to give the observer the least amount of lag without allowing them to hack. I know it is all stupid and really as you stated real physics is more than collision. I was just thinking of a way one code base to be as tolerant to many clients as possible.

Also I have the server working as well. the server is the same as the client. The client is the same as the server. it just calculates the last time updated and calculates the interp as needed to be smooth. Which effects the rendered scene with an interp value and the server get's updates faster of course. Though all my experiments are in 2d with axis aligned squares. Nothing compared to 3d. Being 2d it is more movement and collision. No gravity and the only time a client will be wrong is if there is a collision. With artificial packet loss anyway.

Having your cake and eating it is not easy. it will not be used for an mmo. It is pretty much a client heavy model with a heavy sever check if with the instructions given it can get near the same place.

I suppose if you were aiming at the best tolerance of all you would turn off player collision and just take into account the static map. Thus making bullet engine kinda work and have a bullet physics for each player with just the static map.

It ends up the same as sauerbraten. Except with a large server side hack detection.

If you still think my premise is still wrong I would love to hear why. Or maybe my reading tomorrow less tired will enlighten me more.

Either way I appreciate your unbelievable insight into an incredibly convoluted idea. I have no doubt I will change what I think in 48 hours.


Edit:

Also I would like to mention that in saurebratens insta gib modes(eg one shot hit scan) I find lag much better than in normal mode with rockets. This is likely due to a number of issues like other players knowing item spawn times. Though I believe part is to special hitscan rifle mechanics to counter lag. Like counter strike.