3D MMOG server side collision..

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.

dont do collision detecting with npc and other players, why do it? It dosent make a better RPG. or what do you think.

That was a pretty ignorant comment, considering the rampant amount of cheating in online games.

I know for a fact Asheron''s Call does fulll server-side collision detection

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?

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.

Yes, the server side check does not have to be as accurate either. The client can do a fairly accurate of something like collision detection with the environment. On the server you can just ''block'' up the environment and bounding boxes for the player to get a rough collision detection validation.

The idea is that *any* data comming from the client has to be validated and any data that is sent to the client should be only what the client needs to display. A couple of good ideas to follow:

1) Any data that is sent to the client has the possibility to be viewed. Example, if you have a lock to a door and you send the keycode along as part of the lock object then that is bad....

2) If it comes from the client then it must be validated. Example, client says ''Uhh, yeah, I opened that chest with this magical key''. Then if your server trusts that then that is bad....


-------
Andrew
PlaneShift - A MMORPG in development.

Thanks for all of the feedback guys! At this point just to get it done I''ll do the collision detection for the terrain client side. Later the server will do checks to make sure it is in fact valid (hopefully before public release..)

Again, thanks for the feedback!


-Nate S.

I find it rather odd that you''d be willing to spend $69,000 in addition to royalties at a rate of 4-6% plus $25,000 in support for such a robust network model, yet be incapable of designing an appropriate collision detection model for your game.

In any case, I would recommended you take a look at the havok or havok 2 engine for physics simulation, they are both of very high quality. Call up quazal (514)-395-4646 and they should be able to help you out with making a decision that will integrate well with quazal.

Cheers.

@Raymondo - We''re creating a shareware game, thus Quazal is free as long as we don''t make money. Also, the only money we''ve put into this project is for buying a few servers.

The only reason I wouldn''t look at www.replicanet.com is because they are do not provide a license for shareware projects such as mine. If they change their license system I''m sure they would get more developers interested =P


-Nate S.

Quote directly from their website >
"..Use of ReplicaNet Freeware is restricted to personal use and non-commercial applications only. Projects that are for shareware, public shows and exhibitions, use in schools and classrooms or educational courses is considered to be commercial use.."

There are not 2000 ways of doing this. When creating an "MMOG", you want things to be reliable and secure. If collision detection was to be done on the client side, it would be very easy to "hack" around and go through walls and/or entities.

Its simple, the server runs the game. The server runs the True game, the clients only display an approximation of the close environment. The server has to know everything thats going on. Now, some "MMORPG" games can simplify this process a bit. Collision against terrain is fairly fast, most of your 3D "MMORPG" games don''t have environments nearly as complicated and dynamic as an FPS game. They will have terrain, often tile based geometry or buildings loaded directly as models, which can be easily eliminated as a whole, when it comes to potential colliders. Some of these games might also rely on hacks like considering that when an object doesn''t move, it doesn''t need to be checked for collision detection.

Now, many of you might not understand this. "How can the server send the collision detection info to the clients fast enough?!? Don''t you know what lag is !?!?!". This is not an issue, because the clients perform what is called client prediction. The client simply run collision detection for the objects that are close to them, they predict what will happen. The server sends updates from time to time, which sometimes correct what the client had wrongly predicted. In some rare cases, where there is alot of lag, this will result in prediction errors, but its impossible to do without it. If the clients ran collision detection, everyone would see the events differently and the game would be badly synchronized due to the lag and packet loss.

The server *cannot* rely on the clients to do its job. Collision detection isn''t that much expensive calculations... Quake 3 runs collision detection against 3D worlds on the server side and you can run a dedicated Quake 3 server with several players in the game on a 486 (yes, believe me, you can).

---

Looking for a serious game project?
www.xgameproject.com

nstrg> For your information and everyone elses, the Freeware terms have been slightly relaxed now.

Shareware developers can still use the Freeware license. When your project is nearly finished, contact sales to negotiate a royalty based (pay per sale) license or a single payment license.

I hope this helps.
Regards


--
Martin Piper
Network programming made easy with ReplicaNet
http://www.ReplicaNet.com/

quote:

---

Original post by Anonymous Poster

quote:

---

Original post by Max_Payne
There are not 2000 ways of doing this. When creating an "MMOG", you want things to be reliable and secure. If collision detection was to be done on the client side, it would be very easy to "hack" around and go through walls and/or entities.

---

Everquest does collision on the client side.

---

Yeah, I''m sure it performs full collision detection on the client side without performing it on the server. I''m also quite sure you saw the source code to the game.

---

Looking for a serious game project?
www.xgameproject.com

"Yeah, I''m sure it performs full collision detection on the client side without performing it on the server."

It does and perhaps at the same time, there is some of it running on the server, tho id wager not much.

I''ve played the game for a good 3 years or so, not to mention studied the packet types of the game and other such things so I know a little bit about the game.

First off movement updates are primarily sent to the server from the client. The server probably has some sanity checking going on to make sure values sent are within reason.

Secondly, in whats known as the "old world", basically all the zones that make up the original game, some of the doors were metal jail like doors that you could get through if you pushed on them for 30 seconds or so. Imagine turning into rubberman and squeezing your way through in between the bars. The number and locations of these doors and the ability to just walk through them, really didnt unbalance the game in any major way since all of them but 1 you could click on and open anyway. This was clearly an exploit of the collision detection on the client side.

While were on the topic of collision detection, there are a few areas in the game where one could get themselves stuck in a wall, either by using a method similar to the one above or some other method. As a result, you could essentially walk out of the gameworld in to the void and begin to fall. Once you fell to a certain -z value the game would detect that you were beneath the world and then send you to a safe point in the zone. In the case of a dungeon, usually the entrance. Occasionally you would never get ported and would suffer a 20,000 hp damage fall, pretty much killing you. A GM would have to come to summon your corpse and usually gave you a GM rez (0% exp loss and full health and mana).

Next we have an oddity of what i call "The David Copperfield Effect". For most entities that are not part of the base world mesh (Things like trees, doors, small buildings, and some other structures), monsters have the ability to just walk through them. On the client side the monster will appear to collide with it and act appropriately, like sliding off the side of a building perhaps. On the server side however the monster will for the most part continue on a straight path through the object. Once the server sends out a positional update for the monster, the monster will snap to that position thats pretty much on a straight path in front of the direction it was moving when it collided with the object on the client side.

For monsters in general, I think that the server perhaps might do some collision detection on these entities with the base geometry of the world, for clients on the other hand, I''m pretty sure they could walk through walls if they so desired by modifying the code.

GM''s however, and I''m not totally sure how they do this, but either they or the server can detect people who cheat by warping around by modifying positional values on the client. Probably just a simple sanity check or two. Recently a number of people were banned for using a program called macroquest2 (macroquest.sourceforge.net) to do such a thing. As I said above tho, I''m willing to bet that walking through walls and whatnot could be done for the most part undetected.

-=[ Megahertz ]=-

It''s not a good idea to have complete collision detection server side, at best you should have a quick check to see if where a player is going is legal(cheatpurposes), but keep the rest clientside.

quote:

---

Original post by Siaon
It''s not a good idea to have complete collision detection server side, at best you should have a quick check to see if where a player is going is legal(cheatpurposes), but keep the rest clientside.

---

Why? Sounds to me like your trusting the client (the cardinal no-no rule of multiplayer programming), which is exactly why EQ is having all these exploit problems that have been mentioned.

Maybe I''m missing the boat here or something. Collision detection isn''t that expensive, and as long as you do some reasonable limiting of what your checking (e.g. landblock limitations where you only test the player against items within the landblock they are in and possibly adjacent blocks) I don''t really see why the server couldn''t handle the load. Or am I wrong there?

Sending a collision detection packet that affects movement is no different than sending a movement velocity change, which is something I do already anyway as part of my normal movement routines. So there''s no difficulty there.

It seems to me (and granted I have not yet done any implementation work in this area) that you''d want to do collision detection server side as a definitive referee, and do it client side to avoid the lag problems (which would cause rubber-banding/popping otherwise).

Ideally yes, youd want the server to control as much of that as possible, and nowadays with 3Ghz cpus its probably more than feasable.

Everquest was developed prolly 5 years ago and technology back then might not have afforded them the luxury of having server side collision detection.

Like I said above, some zones in EQ can have upwards of 600 mobs in it, and now that I think about it, none of those can be culled since its server side and not really dependant on the view of any one client. I couldnt tell you how long a pass through a collision detection routine takes, but just throwing out numbers at 1ms a monster (and if anybody has a more realistic number here, by all means toss it out) with 600 monsters thats over half a second just in collision code alone, not to mention the AI, waits on DB queries, network traffic, etc..

The execution time of the CD routine is going to largely be dependent on how many polygons you have to weed through to find the potential colliders.

If any of the above seems way off base, please correct my thinking.

-=[ Megahertz ]=-