the thing being that modified clients could constantly "snitch" the server for all the players it sees, and slow everything down...

I was going to put that you''d have to include a time delay between snitches, but I thought it was kind of obvious.

ah yes you''re right... didn''t think about it... good point then

Collision detection server-side is certainly viable in this day and age. The person who came up with the 360MB/sec bandwidth requirement is missing the boat on several issues.

First of all, there are backbones that can handle that load They would probably go a bit over the top in the price range for 100,000 players at $10 per month, though. But fortunately, that would not be necessary.

Out of those 100,000 clients, many of them will be out in the open, meaning that you don't really need to perform much collision detection for them. If client-A is 100 units away from the nearest collidable obstacle (not including the ground), then we don't really need to perform collision detection on them for (100/max velocity per frame) frames, unless they use a teleport spell or something. This just decreased our load 10-fold easily. Now, out of those 100,000, at any given time, probably 50,000 will be inactive, meaning they haven't moved at all in a few minutes. If an entity isn't moving, it isn't colliding. So you don't really need to perform collision detection for them, or even send them any updates, until something happens that they are the target of (or if somebody tries to walk through them), or until they send you an update that they are moving again. At most you will need to test the distance from other units against them, which is very easy to do, and doesn't require any bandwidth. This just cut our collision detection in half, easily. So now we are at a 20-fold savings. 18MB/s, at $500 per mbps (which is pretty high), would cost about $72,000 per month. If you are generating $1,000,000 in revenue per month (100,000 players at $10 per month), that is easily within your budget. Considering that is probably an upper-limit to what you will need, you can get the bandwidth burstable, and probably pay half of that. Even at $5 per month per player($500k), $40k per month for bandwidth is not going to break the bank, in order to have a nice, cheat-free MMORPG.

However, you won't need nearly that much. First of all, 30fps is overkill for server-side collision detection that is only meant to verify the client-side collision detection. You could easily do it at 5fps, cutting the bandwidth requirements by 6. If you stick through a wall for 1/5th of a second, that's not a very big deal. Now we've cut bandwidth costs down to under 10k per month for a title that is making a million per month.

Even if you're only charging $1 per month, generating 100k, 10k for bandwidth is manageable. For 100k players, you will probably want a little more bandwidth than that, to be safe, but not that much. You wouldn't need to spend more than 20k for bandwidth. And you could easily afford to build a small server farm to handle the processing, 4 or 5 P4s could handle any collision detection you throw at it with a reasonable rate of accuracy without breaking a sweat. Segment them so that each PC on the farm is responsible for a particular region of the world, with one extra PC for redundancy checks.

After seeing the massive hack-attacks on Everquest, I would not pay one red cent for any MMORPG that did not do server-side detection.

Of course, for a freeware or shareware title, 10k would probably be too much, but you're probably not going to get 100,000 players in a freeware MMORPG, unless it is really amazing, in which case you should be charging for it

Peace

[edited by - krippy2k on January 12, 2004 6:22:11 PM]

My alpha world engine uses client side Collision detection and I have server side built in but not active.

I am well aware of "hacks" etc but I just designed the game better. I''m not saying server side collision is not necessary but 9/10 client side is really whats needed for most events.

As far as hacking goes, all my game client does is update the "state" of the player entity so there is absolutely zero way of the player "hacking" their way to forbidden locations. All the server sees is a request from the client to adjust the player entities heading/speed. Sure on the client side the player can theoretically teleport himself using mem hacks or whatever to trick his client but while conected to the server he is simply be warped back to his "real" location seconds later. They can not agro locked mobs or chests etc because mob agro is based on their "real" location stored on the server, not whatever location the client thinks he''s at. If the client were to hack his way through a locked area to a chest and attempt to interact with the chest, his client would send a request to the server to open entity#6283 and the server would check his real location and say you are unable to reach that item.

As far as some of the more persitant cheaters, I''ve looked at the issue from various standpoints and really cant make a good argument for Server side detection for the CPU cost. In DaoC you have kids rigging up their Tx and Rx wires on their ethernet cables so they can switch them off to "ghost" through an area and then turn it on when they get to where they want to be. That''s just bad coding on Mythics part. If a player using my client sends info but doesnt recieve or vice versa, the server just bides it''s time untill the player is timed out and booted or resyncs and discovers his "real" location is back where he shut off his Rx/Tx channel.

There are valid arguments both for and against Server side CD and in form my experience I would recomend you do what suits your datastream architecture the best. I designed my datastream around client side detection and I''m very happy with the design and the results. IS it perfect? Nope =) Is it functional? Yup. And it was a feature of my World engine so it cost me no extra development time. Winner all round =)

Cheers guys,

Mark

Slyxsith> if I understood you well, the only yhing that prevents the client from going to an invalid location is the client itself?
if you''re in front of a wall and try to go forward, the client collision detection will block you and not send heading/speed packets to the server so you don''t go through?

just tell yourself people have the source code of your client and can recompile it. (through asm disassembly for example).
then your whole system becomes completely exploitable if the server performs no collision detection.

"Sure on the client side the player can theoretically teleport himself using mem hacks or whatever to trick his client but while conected to the server he is simply be warped back to his "real" location seconds later."

and if the "hacker" "hacks" the client itself and modifyes the code so that collision detection isn''t performed for that client any more? then the player can go through walls?

"I am well aware of "hacks" etc but I just designed the game better"

sorry but IMHO, it doesn''t seem so :|
(if I misunderstood your explanations, sorry)

No worries Bibi but you did misunderstand the code.

The server keeps the entity locations of all objects, including player objects.. If the player hacks the client and walks through walls etc, well that is sad that they may potentially be able to see whats on the other side of the wall, but in order to do anything, interact with anything or attack / agro anything they need to resync with the server which will tell them they are actually still at location x,y,z.

As an example, cheaters in DAoC by Mythic entertainment are currently using spliced network cables with toggle switches to turn off their transmit and recieve channels temporarily to "ghost" through walls etc. They can do this because of the poor "prediction" code in DAoC. The server allows the player some leeway in where they are actually located. Meaning that the server takes positional information from the client and compares it to it''s prediction code and puts the client at a happy medium.

In my current engine the client can appear to walk wherever they like in an area. They can turn off their RX or TX channels and walk all over but when the try and interact with the server in any way they resync and the server says "Uhh uh" You belong over here. And it happily puts them back on the correct side of the wall, locked door or what have you. In my movement model the server has the last and only word. The cleint is no more than a controller sending request to the server to change direction etc.

I am not saying this system is perfect but it does work and lets face it I am looking for solid solutions to take me through alpha. I am not going to waste precious man hours of coders time trying to reinvent the wheel. There are enough wicked world engines out there that when my project is ready I''m going to partner with a current world engine developer and go from there.

Thanks for the concern but at this time that kind of hack can''t be done. Because the server is basically God as far as the state of everythign in the game there is zero risk of client manipulation of the entity location info. =)

Mark


Aakrana: The Forgotten Lands
Currently seeking help from:
C++ coder
ZeroC / ICE programmer

Hmmmm, if you''re not doing any collision server side, how would the server know the player did something illegal?

e.g. A client uses a hack to go through a wall, but otherwise all movement is according to regular rules (ie no teleportation or speed hacks, they walk normally). From the server perspective, using only velocities/directions (which is a good idea, that''s also what I''m doing), the client position is perfectly acceptable, it would have no idea there is an intervening wall in the way.

Thus the server would allow any interactions with chests, items, whatever, because as far as it knows, the client is in a perfectly legal position.

In order to catch this, the server *has* to know that wall is there, and therefore it *has* to do collision detection against that wall to determine the player is not where they should be.

I understand how your system works to prevent speed or teleportation hacks (mine works exactly the same way), but I''m not understanding how you are preventing disabling of collision detection hacks.

Unless I misunderstood something (possible!), I think your system has a bit of a problem

RonHiller> exactly

The only possilble mechanism i can think of is to zone everything. And when the player enters another zone ( not MMORPG zone but a spatially and logically grouped area within a unique ID in a single world.) through a prortal will their zone ID change. But that means the world woudl have literally millions of zones.

-ddn