Diablo 2 / Old School Runescape client/server theory.

[unenergizer]

Hey everyone,

Me and a friend are developing a small multiplayer game with similar features to both Diablo 2 and Old School Runescape (osrs). We have been working on the project for a few weeks and have a working client/server implementation. At first we wanted to make a Zelda: A Link To The Past type multiplayer game. After doing some research and playing about 20-30 online games we have found some features that we think would make a great game. That being said, we changed our decision to make a Zelda type game to something more of the style of Diablo 2 and OSRS.

Now, we are new to making multiplayer games and we do have some concerns about cheating. Obviously cheating ruins the fun and economy of games. I personally believe that their is no full-proof way to stop it, but we would like to prevent the most basic of cheats (faster run speeds, walking through walls, etc).

Here is a video of a little test we made. The test video does not show the inclusion of interpolation. So please forgive the movement jitter. Also this video was recorded before we decided to go with a tile/node based game.

kHNX_80H9us

Now on to some questions, this is where we need the most help. Our goal is to have roughly 600 (or more if possible) players on a server at one time. Also this is a point and click game. You point to an area on the map, and the player moves to it using A*. We would like to include diagonal movement in our path finding. Oh and this is a 2D top-down game.

To prevent cheating:

• For player movement, should A* be implemented on the server or client?
• For NPC/Follower/Pet movement, should A* be ran on the server or client?
• For Quest Giver (NPC) random walking around, this is obviously A* on server or predefined walking paths?

Originally the idea was to do player movement with A* on the client. Send the desired cords to the server, as the client ran through tiles, we send the x,y cord to the server. The server says if a tile can be passed through or not. If not, stop the player on the client from running. That was our beginning theory. Not sure if we are on the right track. If anyone else has experience with this type of client/server architecture, please share your experience. It has been difficult finding data on this subject, so any help is appreciated!

[williamwoles]

I am not very experienced (I have made some multiplayer games but they never went live actually), but I might share my opinion and observations with you:

1. Path calculation. Since I have been long time RS player (not very active though) I have seen multiple decisions made by their team. Initially from what I suspect the calculation was client side and it actually allowed to use mouse-less clients (or packet base clients) which would allow you to send to the server the coordinates you wanted, the server might have been doing some simple verifications to detect speed hacks and moving through obstacles, but at the end it was client who was taking care of path calculation. At some point (I cannot really remember the dates), the path calculation moved either completely to server or it was partially validated, since there was some delay from the moment you click to the moment your character starts moving. I believe that at the currently, all the critical logic is being calculated by the server, the client is what the name suggests is displaying what the server have calculated. Similar problem happened with rare items duping still in classic version of RS, where the client had some power in terms of decision in trade windows. Now, those are only guesses. Now there are drawbacks of moving logic to the server which is the load you create on the server machine. What I believe could be potentially good solution is what actually is happening in Web development is still let the client calculate, but validate occasionally. Save the point A and point B and the path client has provided (or even some hash) and make the calculation on the server with determined frequency. Paths not matching would mean that user might be cheating and you can suspend the account. Leave all non critical operations to be done by client by validate the user actions from time to time.

2. For followers you can re-use the calculated path, be aware though that game state can change (e.g the door can be closed or open), so at some point you might need to check the path availability if you know that the object on the time can change state in terms of open for passage or closed for passage. For NPCs which attack your heroes(e.g have different starting point), you might need to do the calculations on the server, since you want all the clients to see the NPC on the same position while it is moving.

3. For wandering NPCs you can have zone limitation with randomized short moving paths, so you do not need to go deep with your calculation or even randomized on walkable tiles only. Pre-defined path is only good in some cases, when the guy is patrolling some street for example, otherwise the behavior might not look natural.

Once again, I do not have much experience there, it is pure my opinion on the topic.