🔒 Locked

Multiplayer sprites

Started by Sijmen Mar 6, 2007 at 1:14 PM 3 replies 1.2k views

Original Post

Mar 6, 2007 at 1:14 PM

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?

DeathBySpoon

Mar 7, 2007 at 4:01 PM

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.

starfleetrp

Mar 7, 2007 at 5:01 PM

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 :)

Sijmen

Author

Sijmen

Mar 7, 2007 at 7:19 PM

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?

starfleetrp

Mar 7, 2007 at 8:06 PM

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!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.