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?
