Understanding maps across client and server
Author
Multiplayer online games are an interest of mine for almost 10 years now. I am looking to create a small game to help one of my kids get into 3D modeling. I can do the coding and let junior get familiar with the field of 3D modeling and CAD and such things (that I have little stamina for - really it takes a special mind to do that). Afterwards he and his friends can play it on a server I will maintain.
I understand most of the concepts where it pertains to networking, as the bulk of my programming experience is with servers.
What I am having trouble with is grasping the concept of placing players on a map or in a mesh and how their locations are controlled by the server. Evidently collision detection on the client side is not trusted in some online games (lest those who hack be able to go through walls and gain an edge).
But I cannot get my mind wrapped around this - a mental block of sorts.
While the clients have the mesh loaded, for an instance or area, and the server sends the state data for other players or NPCs/Creatures, and so to place such entities in the mesh properly, how then, if not relying on client collision detection, does the server keep someone or some thing from going through a wall or large solid object?
I am trying to imagine that the server has something like a mock-up of the mesh and knows where the collidable objects are, but is this like a DOOM map or something more directly derived from the mesh itself? While I can imagine a topographical map design being usefull, there comes a problem with stairs and multileveled structures (and I need to put in castles or similar things like that to create a need for more challenging models).
When I enter a large structure with one door or portal, how does the server make me bounce off the wall if I don't use the door? And further, if I go over a cliff, what checking is being done on server side to actually make my little toon "fall"?
I know using the DOOM map idea shows my age. I'm old school and back in the day we had to code our graphics engines using linked lists of vertices and polygons, and put them into objects, and matrices that were broken out of their loops for speed and assember code in subroutines - and the occasional dinosaur attack in 3 feet of snow up hill on the way to the computer (a DOS box!).
If anyone can help me get this straight in my head, I would appreciate it. Once I can get past this point, I can start the server coding. (it will be in Perl if anyone is wondering but the rest of you old farts probably already assumed that).
Sounds like you're thinking about it right. Generally there are two meshes for every object in the game; a render mesh and a physics mesh. If the game is simple enough, then the physics mesh can replaced by something as simple as a bounding box. The server tracks all the physics objects for each level. Every time the player moves, something like this happens:
1) Player presses move key
2) Client does physics calculation to see if movement is allowed, then updates the position of the player locally.
3) Client sends an update to the server containing the new position.
4) Server validates the move by performing the same physics calculation the client did.
5) Server updates the player's position in its own memory, then sends a confirmation back to the client that the move was accepted.
If you're just making a friendly game for your kids though, client-authoritative movement might be entirely sufficient. In this style, the client is the only application that does physics calculations, and it sends movement updates to the server, which then trusts what all clients tell it implicitly.
1) Player presses move key
2) Client does physics calculation to see if movement is allowed, then updates the position of the player locally.
3) Client sends an update to the server containing the new position.
4) Server validates the move by performing the same physics calculation the client did.
5) Server updates the player's position in its own memory, then sends a confirmation back to the client that the move was accepted.
If you're just making a friendly game for your kids though, client-authoritative movement might be entirely sufficient. In this style, the client is the only application that does physics calculations, and it sends movement updates to the server, which then trusts what all clients tell it implicitly.
I wrote a long answer, and then I decided to put it on my web page instead. That way, I can refer to it more than once :-)
[Edited by - hplus0603 on September 29, 2006 10:59:46 PM]
[Edited by - hplus0603 on September 29, 2006 10:59:46 PM]
Author
I did not consider the mesh/physics idea. Thanks for the help.
Is the physics map to be the same as the mesh in any way? I am still having trouble with what to do in a structure or cave. I can imagine our grid of objects with their bounding boxes, and walls and such, but resolution of a map like this changes in structures?
Would such a physics map have to be arranged in a similar data structure as the mesh in the clients, such as an Oct tree?
Is the physics map to be the same as the mesh in any way? I am still having trouble with what to do in a structure or cave. I can imagine our grid of objects with their bounding boxes, and walls and such, but resolution of a map like this changes in structures?
Would such a physics map have to be arranged in a similar data structure as the mesh in the clients, such as an Oct tree?
The short answer is that you need to be loading and using the same data as the client. This is probably nontrivial if you're set on using Perl. Your server needs to duplicate all the collision detection work of the client. How to do this should become fairly obvious after you implement physics/collision on the client.
But I agree with Muse. This can be a lot of work, and if you're running a server where you can trust that the players aren't using hacked clients, you can mostly get away without doing these checks.
But I agree with Muse. This can be a lot of work, and if you're running a server where you can trust that the players aren't using hacked clients, you can mostly get away without doing these checks.
Comment on Nav-Meshes : They can be a simplification of the visible 'rendering' meshes. The geometry can be simplified to lower the triangle count (fewer point-on-triangle tests) -- slight errors in brushing walls can be allowed. They can also be expanded to have 'simpler' collision walls (and ceilings) if you allow jumping around, etc... Extra pre calculated data like slopes can also be included with other movement related data.
The Client and Server would both do the testing (Server only needing the Nav-Mesh)
but with the Client doing it first and NOT sending the proposed movement vector to the Server (only sending data for as far as running into something). The server still does the test, but only would find collisions if the Client was cheating (possibly still a bit less work for the Server because the 'move vector' would normally be shorter).
Multiple (overlapping) levels work with the nav-mesh method, but there are many complications when you allow jumping (or flying) -- requiring those nav-mesh walls and ceilings....
Projectiles require full 3D collision (but still could use simplified geometry...) and similar prechecking by Client.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement