Server Side vs Client Side

Unity Engine
1

Hi everybody, first post so i’ll do a brief intro. I’m currently a culinary student in Chicago, but have completed most of a Computer Information Systems programing degree with DeVry about 10 years ago which resulted in a programing job on industrial cutting lasers. I’ve on/off studied programing, specifically video games since i was around 12, and have made levels for UT2k4 with models I did with the included Maya Demo.

I have started working on a Sandbox RPG, as a side project to help relax in what little spare time I have. I decided to use Unity as it is very powerful and closely mirrors the editor included with UT which i have experience with, and have chosen SmartFoxServer Pro to do the server - also because both are free. I’ve tracked down and studied alot of demo’s and tutorials and I am doing my final designs before starting, but have run into a question that i haven’t encountered in my research, hoping there’s an answer on here somewhere.

What exactly needs to be on the client side, and what has to be on the server - I understand that client is mostly the interfaces, where as the actual code will be running on the server. but for example, recording location in the game - I assume the maps need to be on the client side, and their location tracked and moved on server side. should i do hit checks on client side and send hits to the server, or should i send the attack to the server and let it figure out if there is a hit? do i put the character creator on the client, or again have everything they do on the server with the client just showing the graphical results?

with my current understanding, most of the game will actually be run on the server, while the client will be doing little more then graphics and UI - this almost sees like too much for the server to be doing once the 20 player limit of the free server is met, and more so if I decide to upgrade to a larger capacity once it’s done.

Thanks in advance.

2

I hate to say “it depends”, but the amount processed on the server is a design decision.

3

Unfortunately in my opinion there is no correct answer here. It all depends on the design and requirements of your game. I think if you consider a couple of general rules it might help clarify what needs to happen where:

  1. Never trust the client.
  2. Remember rule #1.

What it means is that any gameplay elements that you consider ‘important’ or that you would not want players to exploit need to be simulated on the server.

In your example above regarding hits, if you allow clients to determine if a ‘hit’ has occurred and then notify the server, you have a situation where a malicious client can cheat, saying they are scoring hits whenever they like. I would say there is nothing inherently ‘wrong’ with the client hit approach as long as you accept that your client may be hacked and understand the consequences to your players. If you are making a game just to have some fun with some friends, maybe this would be an acceptable risk. If you are trying to make a make a popular FPS title that will potentially have thousands of players, this would probably be an unacceptable risk.

For example, consider the impact that client side authority had on Diablo 1 multiplayer. Among other things, clients were allowed to present all their character profile information when joining a server. This meant that any number of client side hacks and character generators allowed players to specify any character attributes they wanted, with the result being that multiplayer gameplay was basically never fair.

The goal is usually to find a balance of what you can get away with allowing the clients to simulate -vs- simulating on the server, always trying to push off as much work as you can to the clients in the interest of scalability of the server.

Hope that helps :slight_smile: