• Advertisement
Sign in to follow this  

Storing Object/Controller States for Client Prediction

This topic is 4256 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So, I'm writing a little 2D multiplayer shooter. It'll be using client-side prediction. Because of that, I need to maintain the previous states of the world for about half a second or so. Now, my physics update 60 times per second, and there could be a thousand or more objects in the game at any one time, so exactly how I want to lay these previous states out in memory confuses me. Here was my first attempt. I stored the histories in each object.
typedef struct ObjectState
{
   Position position;
   Rotation rotation;
   Controls controls;
   Position velocity;  
} ObjectState;

typedef struct WorldObject
{
   ObjectState currentState;
   ObjectID id;

   ObjectState history[50];
} WorldObject;

typedef struct World
{
   WorldObject objects[1000];
}

This approach seemed alright to me, but then I realized that objects might have ceased to exist 20 frames ago, or maybe they only came into existance 20 frames ago, and maybe that might have implications for the prediction. So I thought I'd make the states more universal.
typedef struct WorldObject
{
   Position position;
   Rotation rotation;
   Controls controls;
   Position velocity;  
   ObjectID id;
} WorldObject;

typedef struct State
{
   WorldObject objects[1000];
   long stateNumber;
} State;

typedef struct World
{
   State currentState;

   State history[50];
} World;

This seems a little bit better, assuming I don't actually use arrays like that, which both waste memory and enforce a constraint on the maximum number of objects. I'd probably use a circular buffer for the histories and who knows what for the objects array. Anyway, does this second approach seem like an acceptable way to store state? Is there a better way? Suggestions? Also, I'm wondering about events. For example, shooting, hitting a target, reaching the goal posts, crashing into something. Should the client be predicting these sort of events? I could see how predicting firing one or two bullets could be predicted, but predicting hitting an enemy player or an explosion or scoring a goal might be a bad idea. Thoughts?

Share this post


Link to post
Share on other sites
Advertisement
A thought just occured to me. I'm not actually rendering previous states, just extrapolating the current one based on the old ones. So, if an object's been removed, I don't need to worry about it anymore. And if an object has been created less than the maximum ago, that's fine too.

Maybe I should store the history on a per-object basis.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement