🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

MMORPG server/client spec

Started by
12 comments, last by Torquai 23 years, 3 months ago
When making a MMORPG what parts of computations should be handled by the server and what should the client do? Like: Collision detecting - server/client? Weapon hits - server/client? Damage - server/client? Movement - server/client? other things? Thanks in advance -Thomas Løvlie Semi-Pro Delphi Developer
-Thomas LøvlieSemi-Pro Delphi Developer
Advertisement
I'm certainly no expert, but in my opinion, anything done on the client can be changed, just look at all the diablo cheat things available. I would suggest anything that like weapon hits, and movement be done on the server.
Just my 2 cents.

Edited by - EAX on March 27, 2001 2:08:15 PM
EAX
Anything that can be used to cheat should be done on the server.

From your list:

collision: check on the client, but check on server every so often in case of cheats (say 1 or 2 seconds)
weapon hits, damage: SERVER! "Gee it looks like I hit you for 900 points of damage"
movement: check on client, with periodic checks on server. executed on server.


Anything that can be used to cheat should be done on the server.

From your list:

collision: check on the client, but check on server every so often in case of cheats (say 1 or 2 seconds)
weapon hits, damage: SERVER! "Gee it looks like I hit you for 900 points of damage"
movement: check on client, with periodic checks on server. executed on server.


Good ideas guys, what do you think about this. The client does everything, but has to report to the server, the server reads the data and responds to the client only in case of error.

Movement: every two seconds the client sends current speed to the server.
Damage: the damage is reported to the server along with the weapon type, this way the server can check for valid damage

This way the server only needs to read the data wth minor processing, allowing more to be done on the client.

-Thomas Løvlie
Semi-Pro Delphi Developer
-Thomas LøvlieSemi-Pro Delphi Developer
It''s not all that easy for various reasons, for example if the client thinks an NPC is going to die, but the server tells it that the client actually missed...

I think the way to design it is this:

Do everything on the server. Everything.
Then implement client prediction of the events, without reducing the code on the server.

If you think that this would mean recoding a lot of things (which could be true, depending on the game), then use this method while designing the networking code of the game, i.e. emulate the implementation in your mind...

cu,
Prefect

Resist Windows XP''s Invasive Production Activation Technology!
Sanity is the trademark of a weak mind.
Widelands - laid back, free software strategy
Prefect:

What I meant on the damage thing was that the client calculates the hit and damage, he then sends then hit location, damage, and weapon used to the server. The server then checks for a valid amount, reduces damage if the other player has any shields or like, and informs both clients about the actual damage.

Just like a standard ropleplaying session, the player tells the DM, ''I hit the goblin for 4hp with my battleaxe'', that is ok, but if he says ''I hit the goblin for 435hp with my spear'', you know he''s lying because the max damage for a spear is 1-6.

That way noone can cheat in major damage control.

And movement is reported every two seconds, that way noone can speed cheat.

This way the server does''nt do calculations, only verifications


-Thomas Løvlie
Semi-Pro Delphi Developer
-Thomas LøvlieSemi-Pro Delphi Developer
Ok... but then, depending on how complex the hit calculation is, it might be better to ao all the calculations on the server only, as it has to do them anyway, and you save network bandwidth by only sending an "attack was triggered" packet.

cu,
Prefect

Resist Windows XP''s Invasive Production Activation Technology!
Sanity is the trademark of a weak mind.
Widelands - laid back, free software strategy
Prefect is approaching the idea from the correct standpoint. The Server should do and know everything about the game world at any point in time. How often you update this is going to depend upon your features, platform, bandwidth, and a slew of other factors.

The client should be used for two things, displaying what the server is telling it, and passing commands off to the server for processing. To minimize the round trips on the network, it is possible to use prediction algorithms for nearly everything. When you use them, you have to understand that the prediction is just that, a prediction and there is a significant margin for error that could effect playability. This is the reason why things ''warp'' to you in Everquest. The only other point about prediction is that prediction works well for things that the client is not directly interacting with at that moment in time. For things that the client interacts with more frequently, it is best to let the server drive the interaction and do little to no prediction on the client.

Never trust a single bit of information that the client sends to the server. Validate it in any method possible on the server side. You will more than likely have two sets of various lists, one on the client and one on the server. Redundant code in the server and on the client is necessary at this point for security reasons.

DiabloII has tried to find the middle ground but there are still numerous cheats available within the game. Cheating destroys the economy of an MMORPG which is vital to its sustainability. For this reason and the many other subsystems that cheating either destroys or adversely modifies is the reason why I suggest that the server does everything all the time. The client in this case becomes a sophisticated terminal application with which to view your world from.

Hope this helps.
Kressilac
Derek Licciardi (Kressilac)Elysian Productions Inc.
Interesting.

You know where can I learn more about prediction?

Like moving, how often should the client report movement? Should the server predict where the client is at all times and the correct when it gets the position?

-Thomas Løvlie
Semi-Pro Delphi Developer
-Thomas LøvlieSemi-Pro Delphi Developer

This topic is closed to new replies.

Advertisement