I am aware of that is a difficult question and depends on the game mechanics and game type being applied. So, many answers can be given. For the sake of simplicity, it would be better to consider a typical online MMO game in order to make easy to find a satisfying answer.

This is the question partly related to my previous question in terms of reducing networking cost.

Ernest Adams & Joris Dormans who are the authors of the book had well described five major game mechanics which are widely used in many online games. (By the way, the book is very useful who needs to obtain new approaches to game mechanics.)

Above mentioned book describes five major mechanics as follows:

1) Physics

2) Internal Economy

3) Progression mechanisms

4) Tactical maneuvering

5) Social interaction

Of course, every game has its own characteristics depending on the game scenario and additional mechanics can be added to the game logic. However, one of the real difficulty is that deciding which mechanics are better to implement on client side and which are not. These are crucial decisions because each of them may have side effects including client side cheating risk and network bandwidth usage.

Many designer prefers to implement physics mechanics on server side in networked games because it is the most guarantied way to prevent cheating although it needs much more network bandwidth and powerful hosting investment. However, I think others are open for discussing.

We've been working to implement all above mechanics in our game project with Unity3D and C#. We had planned to implement all of them in server game logic. But now, we think that it might be possible to implement some of them in client side scripts rather than using fully authorative server. So, it means we need to implement semi-authorative server logic where some mechanics managed by server logic and others controlled in client side scripts.

We need semi-authorative architecture design ideas to speed up our project.


UPDATE: It would be better to isolate the question. I know that, client side prediction, interpolation and extrapolation that all have to be implemented on server side. These are primary physics requirements that allow me to provide character movements smoothly. Client passes predictions, server approves them or sends back corrections. This is OK.

If we consider the internal economy, this type of games typically encompasses items easily identified as resources : money, energy, ammunition, and so on. However, a game’s economy is not limited to concrete, tangible items; it can also include abstractions such as health, popularity, and magical power.

How much risk would I take if I try to handle all of them in client side scripts in terms of cheating? In contrast, if I try to handle all of them on server side would I cause lot more traffic? How do I optimize it?

Other mechanics may also include similar crucial metrics that needs to be saved.

I think, anti-cheating mechanisms should be the most important thing for every commercial game developer. I seen many videos on youtube few years ago that teaches how to hack farmville game on client side.

  • 1
    You can't implement physics solely on the server unless you don't want people to play your laggy game. A player will not tolerate a round trip to the server for their input to be acknowledged. Every sane real time game will do physics on the client side as well, with the server validating that the client's predictions are correct. Anything related "cheating" must be validated on the server; never trust the client. That aside, asking for resources is off topic and a project-wide architecture is too broad and vague a topic for one question. – Doval Oct 1 '14 at 19:26
  • @Doval: The request for resources seems to be an addendum rather than the primary question, so it's likely fine. Otherwise, spot on! – Magus Oct 1 '14 at 19:28
  • Thanks for your answers. This is our first game project, so we've not still resolved some core concepts. Your answers mostly based on physics especially client side prediction. It would be nice if you can also give me some additional ideas for other mechanics. Thanks. – aog Oct 1 '14 at 20:13
  • @aog: While I might otherwise gladly discuss game mechanics with you, the StackExchange is not the place. It's for questions and answers. If you do have other distinct questions, feel free to ask them. Your question will not be well received if it's really several questions and not focused. – Magus Oct 6 '14 at 14:29

Almost all of them!

Now, this does depend on the type of game of course, but surprising as it may seem, most mechanics do need to be run on the client. Note that they only need to be run on the client. The server must always have the final say. I'm talking about a simulation.

Physics are the most obvious case of all. If you jump, the server may receive that information after 100ms, and another player in 100ms more. There isn't time to confirm that you may jump until after 200ms at the least. Your client must do something. It's simulation may need to be corrected, but in most cases 200ms delays are unacceptable.

This "anti-lag" leads to many issues, and is a very complex topic which you should probably research independently.

Note that this also depends on the type of game. In a turn-based game, the server can do all the work safely, because you do not require immediate feedback.

| improve this answer | |
  • Today, but in future: neowin.net/news/… – Den Oct 1 '14 at 21:24
  • 1
    @Den: Yes, the processing is done somewhere else, and the framerate is "high" for a console game. The issue, though, is with latency. If you have the server in the same room and get it down to a 10ms response time, you can do some amazing things. If the demo had used a laser weapon (thereby not allowing the calculations to be started while the projectile is in motion), it might have turned out differently, not to mention resolving inconsistencies between multiple players. – Magus Oct 1 '14 at 21:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.