Much Refactoring

Published September 11, 2011
Advertisement
The kids have given me a few spare minutes this weekend (and I've taken a few more besides) to work on my client/server state data.

Previously, I had some rudimentary state information in there and was concentrating on getting the basics of the terrain communicating back and forth. Fine for terrain work, but not so fine when I want things to start moving. So now, I want to get my non-terrain objects moving correctly on the client and server.

Part of the fun in all this is that the system is somewhat asymmetrical - and this was doing my head in for a while. The server has the definitive set of entity data - whether it's position and velocity, or inventory or achievements. The server also keeps track of who has a registered interest in a particular entity - whether it's because they're near (for visible updates such as position or clothing), or because they're operating an inspector (comparing achievements, for example). The server also has to be robust - I don't want an out-of-bounds update from a client crashing it. Motion updates from clients are error-corrected over time to account for latency and clamped to some sane maxima.

The client, on the other hand, is working a little differently. Only updates for entities under the player's direct control get sent back to the server, there is no clamping during position/velocity error correction, and there's (currently) no need for the notification message queue used on the server.

Given that previously I had, well, nothing, implementing some sort of even rudimentary entity system that came close to these objectives took three or four tries. There's a lot of cleanup to do, so the jury's still out, but I'm hoping that what I've come up with will work. Eventually.
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement