As the topic says - Doing 3D collision detection for a MMOG on the server. I''m a bit perplexed by this one to tell you the truth, now on my last project it was straight forward because it was a simple 2D map. But when you enter the 3D world there is a remarkably larger amount of data to wade through each update for each player. I''ve considered quite a few options, including loading the entire world data into the server (which seems like a very bad idea..), just loading parts of the world data (zones), all the way down to just breaking the rules and letting the client do basic terrain collision detection. So anyway, do any of the masters here have some advice? Also, please don''t give me that normal crap about how MMOGs are too hard, etc, etc... I know how hard they are because I''ve been there. I created quite a successful 2D MMORPG a few years back, so I''ve lived through it =) Lastly, we''re using a number of middleware solutions to speed development along - this includes Quazal for networking, OGRE for 3D graphics and we''re currently looking into a physics simulator. Thanks for any suggestions! Nate S.

Let me know what you come up with, nstrng. This is an area I''m definitely dreading It''s coming up in the build list for my game and I still have no idea how I''m going to go about it.

AFAIK, Everquest doesnt have server side collision detection. I''m kinda curious as to just how feasible it is to do it serverside. I''m not sure about other MMORPGS but in Everquest a zone could be populated with upwards of 600 monsters.

Thats a lot of entities to run through a collision routine. I''m sure some of these could be culled a bit, perhaps based on distance and/or visibilty calculations, but even say 50 is a lot.

I think EQ can get away with it due to the design of their pathing system, which while it solves one problem, it seems to create a few more in the process.

-=[ Megahertz ]=-

IMHO, I would expect the collision detection to be done on both the client and the server. In a properly designed system, the same code and data could be used on both. If you only do collision detection on the server, the client will look jumpy as the player moves through an object only to get an updated location packet and jump back to the edge of the object. If you only do collision detection on the client, you are opening yourself up to cheaters.

I think the real question is how detailed do you want to be on the collision detection? If you are just worried about the ground, buildings, edge of the world, trees, etc, then this should not be a problem. These things are non-moving for the most part. The real problem is collision with moving objects such as NPC''s and players.

quote:Original post by Evil Bachus
I don''t see why you would need to do environment collision detection server-side. Let the client handle that. The server wouldn''t be able to send collision packets fast enough anyway, so players would probably end up walking through walls temporarily before being bounced back. To prevent that you''d have to have at least a little code on the client side for collision detection, so why not have it all there?

Because if you don''t do it server side the client can be hacked to disable collision detection giving the player the ability to go anywhere, which would be a major cheat. I think I agree with OneBeer, it needs to be done in both places. On the client end to satisfy the speed requirements (so you don''t get the bouncing through walls as you mention) and on the server end as a sanity check.