• Advertisement
Sign in to follow this  

Client-Server talking... What do they actually say?

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

Hello, I'm continuing on with my C# networking library. Now I have a question about the type of data that client and servers are going to pass between each other. The client only has rendering data, I know that. So when an entity comes into the player's view you'd have to send some sort of NewEntityPacket to the client. Now obviously this packet would have the co-ordinates, so the client could calculate the screen co-ords. It'd also have the direction the entity is facing. Now how does the client know what sprite to use (talking 2D here)? What I picture I learnt from the UO days. You have a huge file of all your sprites somewhere that are setup like one image. Then you have another file which defines some sort of SpriteID along with the location and size of the image. So the server can send the packet saying to Show entity 0x3234. Then you can use a lookup table (skip list, avltree whatever), to find the location/dimensions from the data file, then go to your huge image data and get that single sprite. This way you have a really thin client. No client hacking going on. Close? Way off? Suggestions? Not clear?

Share this post


Link to post
Share on other sites
Advertisement
are you just asking how to tell the client what sprite to use for a player? then yes, that is exactly what i would do. i would build a lookup tabling matching ID's to sprites. the server and client would build the same table, and the server would just send ID's to tell a client what sprite to use.

also, you might want to mention what type of game youre talking about, so you can get a better answer.

Share this post


Link to post
Share on other sites
Sorry,
I'm working on just a few players in a Server->Client 2D top down action shooter.

Sprite showing was my example. I guess I'm just trying to get a better idea of what to send, and what not to send. I thought there might be some general rule or something, as I wasn't sure in that situation.

Would you send this sprite info on every movment update? or would you store it in the clientside entity and only resend if it changes? Usually you don't want to store things because it's "hackable" but the sprite doesn't matter much. And they could just change the images anyway if they really wanted.

Lets say for my game a player entity enters the screen from the west side, so he's facing east. The client will get a NewEntityPacket with a hash or index or whatever to the "sprite facing east" image... Then, when he moves east again the client only gets a MoveEntityPacket? Then, when he turns would you send a RotateEntityPacket which has the new sprite indexer? Or would you just keep sending MoveEntityPackets which always contain the indexer, so the new move packet would contain the new rotated index? Or, would you only reference a GROUP of sprites for that object, store it in the client object, and let the client figure out which one to use based on a "direction facing" sent by the packet?

And how does queuing up annimations work? Is an annimation just a sprite index which reapeats the "image swapping" like an animated gif? And this annimation sequence would be stored in the sprite data file?

There are so many ways to handle this. What are the ways some of you guys do it?

Share this post


Link to post
Share on other sites
Quote:

Would you send this sprite info on every movment update? or would you store it in the clientside entity and only resend if it changes? Usually you don't want to store things because it's "hackable" but the sprite doesn't matter much. And they could just change the images anyway if they really wanted.


i definetly would NOT send the sprite data on every movement update. you should send data as little as possible. you should only send things like this when they change. things like this are not security problems, so you dont have to worry about security here, plus, even if the graphics was a security issue, you are still being secure. as long as the server tells the client what is happening, and nice vice versa, then everything is nice and secure (unless of course your server is untrusted - im not sure how that will work out [grin]).

Quote:

Lets say for my game a player entity enters the screen from the west side, so he's facing east. The client will get a NewEntityPacket with a hash or index or whatever to the "sprite facing east" image... Then, when he moves east again the client only gets a MoveEntityPacket? Then, when he turns would you send a RotateEntityPacket which has the new sprite indexer? Or would you just keep sending MoveEntityPackets which always contain the indexer, so the new move packet would contain the new rotated index? Or, would you only reference a GROUP of sprites for that object, store it in the client object, and let the client figure out which one to use based on a "direction facing" sent by the packet?


first of all, i would not just send a packet as soon as the player would be visable on screen. you should send something sooner then this, otherwise players will just appear to "pop in" out of nowhere. in fact, visability filtering is kind of tricky.. depending on your requirements, you might want to just tell a player about all other players (and vice versa) as soon as a player connects, and then you wont have to worry about visability filtering and "pop in". im guessing this is how at least some action games work, games like Quake 3 i believe have no visability filtering (and hence things like "aim bots" or "wall hacks" are possible).

about the movement, there are many ways to handle this. there are a few things you need to play with, 1) how much bandwith you use, 2) how accurate the simulation is, 3) how secure it is, 4) how responsive the simulation is, and probably another thing or two im forgetting [grin]. this is where things get complicated, and you kind of just have to keep tweaking things untill you get it perfect. you need to find the perfect balance of these things to get exactly what you want out of your game, and this all varies based on the type of game, your requirements, etc. if you have a more specfic question about movement i could try helping you with it.

one thing i would do is, try to think of how one thing can effect another directly, and then you can kill 2 birds with one stone. for example, why bother sending what direction a player is facing and what frame to draw, when you can just send velocity? if you know a players velocity, you should know how much to rotate that sprite and what sprite frame to draw, etc.

Quote:

And how does queuing up annimations work? Is an annimation just a sprite index which reapeats the "image swapping" like an animated gif? And this annimation sequence would be stored in the sprite data file?


this doesnt have much to do with networking, but yes, an animation is just a bunch of frames, where you draw a frame and then swap to the next frame after a certain amount of time, like in a cartoon. things like animations do not have to be in sync on all machines - the animation for a player on my machine might be on a different frame at the same time as your machine, but who cares? no one will ever know, and its just too much work and a waste of time to try to sync things like that.

Share this post


Link to post
Share on other sites
You need to introduce an entity ID, either as a persistent ID for the server, or as an ephemereal ID for the connection (mapping to a persistent ID on each side, but shorter to transmit). Typically, the first time you see something over the network, you'll get an "introduce entity" packet, which contains a bunch of data about the entity such as initial position, velocity and orientation, which entity template to use (which in turn maps to sprite, behaviors, sound files, etc), what equipment is on the entity, etc. Further updates will just refer to this entity by introduced ID and send only the data that changed since the last ack.

Share this post


Link to post
Share on other sites
Awesome!

Thanks to both of you, a lot has been cleared up. I'm sure I'll have some more specific questions later. Good ratings for all! Not that It'll do much for you guys. ;)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement