Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Aug 2011
Offline Last Active Oct 06 2014 11:35 PM

Posts I've Made

In Topic: multi-player games and physics engines

03 June 2014 - 02:11 AM

hplus0603, that makes a lot of sense. It was just in my mind all those methods seemed excessive for moving one object. Though like you said physics is not the most expensive part of a game engine and corrections should be infrequent.


I had a suspicion that was what cascading correction was. I suppose it might be worth rewinding other objects as well if you are stepping through for everything to miss those edge cases like a closed door.


That makes sense why no forums really talk about it. Also it was pretty obvious and I am pretty dumb ;)

In Topic: multi-player games and physics engines

02 June 2014 - 05:37 AM

hplus0603, Well I have bullet physics engine in my mind I'm really talking of any open source physics engines like ode or what ever.
Which is what seems to be confusing me since most articles about replaying movement on prediction error can just rewind that one object and step it through time. A lot of the time these people have articles about basic theory about creating a physics engine. Like gafferongames.com

I thought I would avoid making my own physics engine.


I'm not really sure what you mean by cascading correction. In my mind I had a picture of everything else except for the replayed object being frozen and these frozen object interacts like they are solid and static with the object being replayed. Yet after completing the error correction all frozen objects still retain and velocity or spin that they had before the prediction error.


Though cascading corrections sounds like something much more advanced than what I was thinking.



Maybe the answer is so obvious that no one ever talks about it and I'm just so dumb.

In Topic: multi-player games and physics engines

01 June 2014 - 03:22 AM

My message was not that clear as it was really late at the time.


The only way I can see how to rewind one entity and replay was to have a separate world for each entity and copy a static copy of each worlds dynamic one to each other. or when a prediction conflict occurs create a new world copy everything from the other world as static then recalculate the entities physics stuff.

There is one thing I just noticed for bullet physics engine is http://bulletphysics.org/mediawiki-1.5.8/index.php/Activation_States it has one that is DISABLE_SIMULATION. I'm hoping I can just set all other objects as DISABLE_SIMULATION and then apply an old state to an the object and just step forward 200ms of calculations for that one player and then reactivate all the objects and they keep their velocities. I assume there is a feature like this for ODE?

Is this what people do? Any help or ideas is much appreciated

In Topic: quake 3's state based delta compression

10 March 2014 - 06:50 AM

game ticks, frames, and packets aren't one and the same.. it's all about serializing and conveying the 'state' of the game.

I never said they were not the same. I said  that I have already implemented my first interpretation of quake 3 method which at the very least requires serialization and packets and game state as well as the compression. So I could not think they were the same. Also I explicitly said get the delta compression part out of your mind .


It is no doubt my fault as I am horrible at communicating. Why can't everyone just live in my brain.



Bullets need to be sent reliably. Ie, they must be guaranteed to be received. Send one original position shot. Then do all the physics simulation. Easy.

Why would bullets be guaranteed from the server to the client? if someone shot a bullet 1 second ago I'm not going to display it because it is out of date. If you think you need it to calculate someone's health that will be done by the players state on server.



I am not sure if your talking about inputs from the client to the server or not. I understand from the client to the server of queuing commands.


I am more talking about getting entities sate that is on the server to clients so they can show the entities state. It is like the player input thing but in reverse. send 3 states taken at different times in a packet. not guaranteed though because we do not need old information.

It would have been nice to get a confirmation if that is what quake 3 uses or that this is the general idea of how this model should be implemented. I suppose no one really knows. 


Missed papalazaru's message it was posted as I was writing.


Your idea about using state to communicate how many shots have been fired is interesting. I will give it some serious thought. Though things like flag caps I can represent with my broadcast event thing I have. 



I had a look around quake 3 source. Though it would take for ever to understand where everything is to figure out what to look out for.


In Topic: quake 3's state based delta compression

09 March 2014 - 09:33 AM

I seem to have confused everyone by saying delta compression. I understand the compression part.

What I do not know if multiple states for an entity are sent in the same packet.


when I said 3 frames are delta compressed I meant 3 frames are compressed and sent in same packet.

That article talks about the compression but does not actually say what was sent. Which is what I always hear.



Just to further clarify


if i'm sending 20 packets per secound and I'm doing 60 game calculations(frames) per second then there are missing states.  which mean (60-20=)40 frames per second are not sent and things like a fire state may only last 1 frame then there is only a 1 in 3 chance that the shots will fire on the client.

So the only way I can think that it would be to pack extra previous states(the 2 missing) into the same packet. I was wondering if this is what the quake 3 model does.