Jump to content

  • Log In with Google      Sign In   
  • Create Account


How to implement a circular buffer of previous gamestates


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 simonlourson   Members   -  Reputation: 140

Like
0Likes
Like

Posted 14 June 2013 - 08:54 AM

Hi!

 

I am trying to develop a fast pace networked action game. I've read some articles and tutorial on the subject, and I've come across a problem in my implementation.

 

I've successfully implemented client side prediction, but I've run into a performance issue.

 

Both my server and my clients maintain a circular buffer of previous gamestates.

 

The server has this buffer so it can replay client input that are received late because of lag.

 

The client has this buffer so it can replay it's input (the ones that have not yet been acknowledged).

 

Now here comes the performance issue : I am coding in C#, and the way I went about implementing my circular buffer is this:

 

Each GameState is store into a LinkedList. The first item in the LinkedList is the most recent, the last is the older.

 

When I need to replay part of my circular buffer, I do it like this :

 

1) I clone the last GameState.

2) I store the clone into Last.Previous

3) I update Last.Previous

 

This "works", the client side prediction works flawlessly, my simulation is deterministic, and I the entity I control never "snaps".

 

However, with all the cloning going on, the c# garbage collector is on it's knees, and it's starting to show!

 

Is there a best practice (more efficient than what I am doing currently) to implement a circular buffer of past gamestates, and replaying them?



Sponsor:

#2 hplus0603   Moderators   -  Reputation: 4904

Like
1Likes
Like

Posted 14 June 2013 - 11:20 AM

You should re-use your game state objects, instead of cloning them.

Also, use a fixed-size array for your cyclic buffer.

You allocate this once on start-up, and then re-use the objects forever.

The "update simulation" code should then be structured to take two GameState objects: One for "previous state" and one for "write new state here." The additional argument to that code is the user input state.

 

For objects that you have to free/re-allocate, use an object pool. Rather than freeing the object, put it on a free list. When allocating an object, check the free list first, and only call new if the free list is empty.


enum Bool { True, False, FileNotFound };

#3 nfactorial   Members   -  Reputation: 712

Like
0Likes
Like

Posted 14 June 2013 - 11:23 AM

You should only ever need to store two object states, the 'previous' and the 'current'. Where the 'previous' is the last concrete snapshot taken from the server and the 'current' is the extrapolated local calculation. You don't go into details about what is contained in your state information, but I would recommend a flat array of structures rather than a list of objects. Structs in c-sharp are value types and thus should be a lot less heavy on the garbage collector.

 

[edit] pretty much what hplus says above.

 

n!


Edited by nfactorial, 14 June 2013 - 11:24 AM.


#4 hplus0603   Moderators   -  Reputation: 4904

Like
0Likes
Like

Posted 15 June 2013 - 11:00 PM

You should only ever need to store two object states, the 'previous' and the 'current'.

 

If you actually read the question, you will see that simonlourson does "time rewind" when receiving "previous" messages. To do that, you need game state snapshots for previous points in time.


enum Bool { True, False, FileNotFound };

#5 simonlourson   Members   -  Reputation: 140

Like
0Likes
Like

Posted 17 June 2013 - 01:48 AM

Thank you for the very good advice !






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS