I have implemented client interpolation and it works well. But I don't like my current structure. It looks really ugly and created too many temporary objects, besides that it is really hard to maintain the code.

I am not going to show too many logic here as it is very tightly coupled with other parts of my game. Note that my code is written in javascript but if you show me some direction in generic language or C++ that's OK too because I think the logic should not be too different.

In my game I have hundreds of players and other NPCs, and every network update I get a timestamp. I just bundle them up in a very big state object. Let's call it "currentRenderState", similarly I have "previousRenderState" and "futureRenderState", which means the state I receive in last update and the state I receive in current update. I am going to interpolate from "previousRenderState" to "futureRenderState". The interpolation result will be stored in "currentRenderState". If next update state hasn't arrived and the player state hasn't reached "futureRenderState" I will interpolate from "currentRenderState" to "futureRenderState".

So my state object contains a lot of information.

state = {
  timestamp,
  allPlayerStates,
  allNPCStates
}

Here "allPlayerStates" is a very big object too. It contains all the states of all players and each player contains dozens or even hundreds of properties.

Every time I interpolate I need to clear the object in currentRenderState, also I need to reference allPlayerStates and allNPCStates in "previousRenderState" and "futureRenderState" to get one of the individual state and interpolate it. At the end of the interpolation I create a very big temporary state object and put the interpolation value into this state object and assign to "currentRenderState". Then in the interpolation code I loop through the "allPlayerStates" of "currentRenderState", and assign the value to each player on client side. Also I loop through "allNPCStates" to assign the value to each NPC on client side. This logic works, but I feel tiresome each time I read through my code. Is there a better way to organise my interpolation code, and probably make it more efficient too?

Looks like you're storing your state in the inverse way to how I'd store it.

I'd have each object responsible for its own state, and its past states. I can then ask each object "what is your state at time T" and it can produce an interpolated or extrapolated state accordingly.

However, you don't always need to store the current, interpolated state for an object. If I'm just using this system to decide where to render something on screen, I can just ask for that value to be produced when necessary.

It's also usually not necessary to explicitly label states as current/previous/future. States have timestamps, and you have the current time (or at least, the notional time that you intend rendering), and you can interpolate between whichever 2 states are either side of the current time to decide what to render.

Finally, treating NPC states and player states separately is making extra work for yourself, so why bother?

4 minutes ago, Kylotan said:

Looks like you're storing your state in the inverse way to how I'd store it.

I'd have each object responsible for its own state, and its past states. I can then ask each object "what is your state at time T" and it can produce an interpolated or extrapolated state accordingly.

However, you don't always need to store the current, interpolated state for an object. If I'm just using this system to decide where to render something on screen, I can just ask for that value to be produced when necessary.

It's also usually not necessary to explicitly label states as current/previous/future. States have timestamps, and you have the current time (or at least, the notional time that you intend rendering), and you can interpolate between whichever 2 states are either side of the current time to decide what to render.

Finally, treating NPC states and player states separately is making extra work for yourself, so why bother?

Thank you for your input. I have thought about putting the interpolation logic inside the loop of the player list. But maybe I am just being lazy not to test out if that works better or not because changing my interpolation code is really a headache. It can take up a day or even more. And it usually breaks my game and takes me even more time to debug.

The main reason of separating NPC and player states is that they are different thing. They behave totally diffenrently and NPC has only a few properties versus player which has a lot more properties.

Quote

However, you don't always need to store the current, interpolated state for an object. If I'm just using this system to decide where to render something on screen, I can just ask for that value to be produced when necessary.

In my game, it works like this: (Pseudo code, not in interpolation, but in the code when client receives an update)

previousRenderState = futureRenderState;

if (currentRenderState exists AND currentRenderState.timestamp > previousRenderState.timestamp) {

    previousRenderState = currentRenderState;

}

futureRenderState = (incoming update state values...);

So sometimes I need to assign the current state to the "previousRenderState" for better interpolation.

Ok, your method of interpolation is the simplest one and does require storing the current interpolated state. That's fine. I'd still store it on a per-object basis.

If you want a more concrete example of how to make your code look less "tiresome" then we're going to have to see the code.

7 minutes ago, Kylotan said:

Ok, your method of interpolation is the simplest one and does require storing the current interpolated state. That's fine. I'd still store it on a per-object basis.

If you want a more concrete example of how to make your code look less "tiresome" then we're going to have to see the code.

I agree with you too storing it on a per-object basis breaks it down into smaller unit so it's easier to debug. Unlike what I am doing now every time I debug or change some data structure it is a nightmare. But I still need to fix my code to adapt to the new structure.

@Kylotan But I am very curious though. How not to store the current interpolated state? You see, one of the biggest headaches I have when changing my code is that I have to assign my "currentRenderState" to the "previousRenderState" (outside of interpolation). This results in copying a very complicated object into another object, value by value, and I can't copy its reference otherwise weird things would happen and those states will become unstable because changing one state can affect another. 

If you simply store states as they come in, you can interpolate between them as necessary based on the current time. The current state is just a weighted average of a past state and a future state which is usually trivial to calculate once per frame for display purposes and then throw away. I explained this to you in a similar thread back in March. You have chosen a different route where, once you receive a new state update, you start interpolating towards that immediately, which requires that you assume your currently interpolated state is the starting point. (You still don't strictly need to be storing that interpolated state - you only need to 'commit' it to the 'previous' state when you get a new one to replace the 'future' state.) Both routes are valid, having different pros and cons, and I've implemented each.

You might also consider that if state copying is too expensive for you, it might mean you are copying too much state. Many games only ever need to store position and orientation for these purposes. Others might add velocity to that, or maybe the current animation(s) and frame number(s). It's still only a very small amount per entity.

Quote

If you simply store states as they come in, you can interpolate between them as necessary based on the current time. The current state is just a weighted average of a past state and a future state which is usually trivial to calculate once per frame for display purposes and then throw away. I explained this to you in a similar thread back in March. You have chosen a different route where, once you receive a new state update, you start interpolating towards that immediately, which requires that you assume your currently interpolated state is the starting point. (You still don't strictly need to be storing that interpolated state - you only need to 'commit' it to the 'previous' state when you get a new one to replace the 'future' state.) Both routes are valid, having different pros and cons, and I've implemented each.

Sorry I went the other route because I felt that was enough for my game and easier to implement. But what does 'commit' mean?

Quote

You might also consider that if state copying is too expensive for you, it might mean you are copying too much state. Many games only ever need to store position and orientation for these purposes. Others might add velocity to that, or maybe the current animation and frame number. It's still only a very small amount per entity.

Apart from those values I have "alive" to check if player is alive, and "username" because I need to show it on screen, and the player's "score". The player's position is not just x and y. It has many parts moving after it so I need to pass those position values too.

By 'commit' in this situation, I just meant 'store into previous state'. Because the interpolated value can just be a transient, calculated value, used merely for display. It's only when you receive a new state and need to treat the current state as the beginning of the interpolated range that you would actually need to store it.

It sounds to me like your state is not really all that large, and you're including things that shouldn't be in there anyway. Username is usually completely static, so it doesn't need to be in there. You can't interpolate it anyway. Dead or alive is certainly state, but you can't interpolate that, so again, it doesn't need to be in this specific data structure. I can't comment on position because for most MMOs this is literally one vector or matrix - if you have something more complex, it might well require a lot more state, or, it might just require a more sensible way of storing and deducing it.

@Kylotan I might have been too lazy to split those properties such as "alive" and "username". But I have this concern: because I am putting every state into a big object, when I query a state from a list of players or NPCs I can quickly get the property and display its status. Otherwise I will have to maintain and query another state list to get these properties. And if this other state list doesn't have the same player IDs with the current state  I am in big trouble.

Back to 'commiting' the current state. I think you mean recalculate it when I need to store it to the "previousRenderState"? Would that be doing extra calculation when that situation comes up?