Sign in to follow this  

Multiplayer sprites

This topic is 3938 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

I was toying around, and ended up with this sprite class:
enum CollisionType
{
	NoCollisions,
	BoundingCircle,
	BoundingSquare
};

class Sprite
{
	//...

public:
	Sprite(float x_, float y_, float collisionRadius_, CollisionType collisionType_, float textureSize_);

	float x;
	float y;
	float collisionRadius;
	CollisionType collisionType;
	GLuint texture;
	float textureSize;
	
	void draw();
	bool collidesWith(const Sprite &other);
};


It's simple but does its job very well. There isn't any support for motion or animation, that's where the question comes: With the eye one multiplayer and the latency that comes with it, it seems a good idea to keep multiple 'gamestates', like the one last received from the server and the client side predicted one. For the question: how does this combine with the sprites? Should I make copies of the sprites (thereby also duplicating texturing information), or.. I don't know, any ideas?

Share this post


Link to post
Share on other sites
If I'm following your question correctly, I would just have different functions for each game state. Instead of just an Update() function, have something like UpdateState1(), UpdateState2(), and call the appropriate one based on the gamestate.

Share this post


Link to post
Share on other sites
You should try to use serialization. So you would pretty much just serialize all of the sprites variables into one string which would be something like x,y,collision radius etc. Then you would store this serialized game state for each state that you want to have on record.
When you want to read it back you would go Sprite.deserialize(serialized string).

I havnt done this yet, but as far as I understand this is how its done.
However i'll try and give some code (might be wrong though?)


std::stream Sprite::Serialize()
{
std::stream data;
data << x << y << collisionRadius << collisionType; //You could add or remove more
retrun data;
}

void Sprite::Deserialize(std::stream data)
{

data >> x >> y >> collisionRadius >> collisionType;

}



Edit: If you search the forums (or even google for that matter) you should come accross lots of information.
I hope that this is what you were looking for :)

Share this post


Link to post
Share on other sites
Yes that's pretty close to a solution. But it would seem like it might be handy to have several gamestates available at the same time, instead of one (which would work nice with serialization). Or won't I need this? Or, to go a bit further: is there any reason to even have multiple gamestates available at once, ie can't I just overwrite the client prediction when the new state comes in?

Share this post


Link to post
Share on other sites
I am not an expert on this subject so dont take my opinion as law as im sure there are more educated people on here who could answer your question better.
I beleive the whole point of haveing multiple game states is so that the client can request the changes between stateX and the current state on the server. It would request the changes since the last update it got by sending a packet requesting an update since packet(x).
The server then would compare the changes between the current gamestate the the previous state(x) and send the client the delta change. The client then would update the current world state with the changes, and repeat the process, doing its own calculations to keep things smooth.
The server would keep an array of all of the old objects in a serialized state and would have a function to check the changes between to two states to send them off to the client upon request.

If you need to know more i'll try my best to help!

Share this post


Link to post
Share on other sites

This topic is 3938 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this