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 ]=-

quote:

---

Original post by Max_Payne
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.

---

If you play the game you would realise that your sarcasm is out of place.
Everquest does do client side collision detection, there is no server correction for player movement.

This can be demonstrated in two ways.
1) Have a friend open a door so that both clients are able to see the door open. Disconnect the network cable for the client you want to make walk through the door. Have the friend close the door. Now the server thinks the door is closed, but the other client, not getting the dooor close message still sees an open door. Being quick run through the still open door, thn plug in the network cable before the client times out. Your friend will see your character teleport to the other side of the door.
This demonstrates no server side correction.
If the server did correct then the server would have detected the movement through the door and would have corrected the client.

2) While alternating between your character on a horse and stepping down from a horse continuously squeeze yourself up against any wall. After approximatly five horse summons cycles your client will melt through the wall. The other players will see your client model go through the wall as well. Once you are through the wall you are outside the collision geometry and are free to move to anywhere else in the map. For this it is a good idea to use levitate.
This demonstrates client side only collision detection.

Both of these things are exploits though and if you get seen by the GMs to be using them you get banned.


So as you can see what was said about Everquest is true and don''t be sarcastic when people say things you don''t understand. or agree with. Instead accept you were wrong and move on. Thank you.

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 ]=-

A tunned octree implementation can query and modify around 10,000 objects in about 1-2 ms for a 1 GHZ CPU. I''ve seen these numbers before on the graphics forum for sorting polygons, and the like. I''ve implemented them before, which even though unoptimzied are close enough to that performance metric as to make me think its quite acchiveable.

Given a random distribution of 600 mobs which can be composed of say 1-10 creatures, so 6000 individual creatures, even if they all moved every tick it would ammount to 1-2 ms of CPU time per logical update step for sorting and updating the octree. Using the most primtiive collision algorithim of sphere on sphere, you can prevent them from collidiing, with minimal CPU time. Using the octree, you can reduce the collision set down to just the local area, so maybe 0-3 colliding checks per entity. Suffice it to say, this simple form of collision check, won''t be a load on the CPU. What will be much more of a load will be managing the game core, executing scripts and the networking overhead.

Now this doesn''t assume checks against the world static terrain objects. That will add some overhead as well.

Good Luck!

-ddn

Hmm, ive been trying to make it a point to say monster instead of mob since thats kinda an MMORPG term, derived from Mobile Object i believe. 1 Mob = 1 Monster.

Honestly you probably dont want mobs to collide with other mobs nor players, theres quite a few exploits that players could use to keep the mob from attacking somebody who is for example high on the mobs hate list but out of range of the mob. The other players could make a wall and prevent the mob from getting to that other player who is continally holding aggro (hate) on the mob. Players on the other hand should collide with the mobs.

In any event, its the collision with the world that worries me. Just to throw some more numbers out, say each node in your octree has 500 polygons in it, 500 polys * 600 mobs, thats 300,000 polygons that are going to have to be tested to as potential colliders, then you still have to find the collision and resolve it. That''s going to take a serious chunk of time.


-=[ Megahertz ]=-

quote:

---

Have a friend open a door so that both clients are able to see the door open. Disconnect the network cable for the client you want to make walk through the door. Have the friend close the door. Now the server thinks the door is closed, but the other client, not getting the dooor close message still sees an open door. Being quick run through the still open door, thn plug in the network cable before the client times out. Your friend will see your character teleport to the other side of the door.
This demonstrates no server side correction.
If the server did correct then the server would have detected the movement through the door and would have corrected the client.

---

Right, I assumed everquest was a well designed game. Either way, this proves my point. Collision detection has to be performed on the server side for the game to be reliable, and this does not mean no collision detection on the client side, it just means the server has the final say on everything. Exploits, especially in large scale MMO games, should be avoided.

---

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