Here's what I've been thinking.

Say you're making a multiplayer game. A good way to structure it is to have all your game logic on the server and have the clients only be responsible for transmitting input to the server, drawing the current state of the game and UI. This usually leads to clean code and it also prevents client-side cheating.

Now say you have a unit in your game that fires a cannon with a certain cooldown. The reason it can't fire continuously is because it has to reload. This is represented by an animation. But the server also needs to be aware of the cooldown so you end up having to sync up the animation duration and the cooldown that the server understands. In this simple example you can just speed up or slow down the animation if you decide to change the cooldown, but there are definitely processes where it would be more reasonable to animate them and then have the game values depend on the actual animation.

Is there a smart way to avoid this? It seems that it puts a significant load on the programmer because he has to manually make sure that two decoupled pieces of code, that would probably be better of coupled, are in sync. If you didn't separate the presentation from logic you would just hook directly into the animation and have it trigger actions in the game.

  • 1
    Client- vs. server-side implementation is a complex trade-off with many pro's and con's. "What are the pro's and con's?" is probably too broad a question, but to answer "Which should I do?" in your case we don't have enough information. Please change your question to a smaller scope so we can usefully answer it within the SE reply format. – Kilian Foth Feb 13 '15 at 10:31
  • But I'm not asking which I should chose. I have already decided to split them up. I'm asking what the best way to deal with the consequences is. – Darwin Feb 13 '15 at 10:33
  • 2
    I don't think I fully get this, but doesn't the animation depend on the cooldown? If your cannon fires a salvo of 3 cannonballs at a time T with an interval of one second and a travel time of 2 seconds you would apply damage to the target at T + 2s, T+3s, T+4s. The programmer decides this and the animations need to match with the code, period. If I recally correctly from my WoW-playing days there were plenty of enemies dying 'mid-swing'. Didn't really bother me much... – JDT Feb 13 '15 at 10:58
  • 1
    @JDT I'd say that's true in most cases, but if you have some multi-stage process that needs to do something after each stage then surely the animator has a better feel for the timing than the programmer does. – Darwin Feb 13 '15 at 11:01
  • 1
    This is a semi-uneducated answer, but I think that in the Source engine, there's an animation (wrapper?) format that contains both the animation itself, and certain game-logic-altering effects of that animation. For instance, animations could definitely affect a unit's hitboxes, and as you said, they can have differing length. Likely, an animator compiles that animation through a setup process that solidifies that information, and the server uses part of it when calculating game logic. (So in a way, the animator decides the "reload time") – Katana314 Feb 13 '15 at 19:39

If you are doing multiplayer games, the timing of various actions must be well-thought out. Take a look at World of Warcraft, Diablo 3, League Of Legends... People create spreadsheets with rows and rows of data and calculations to determine the most effective skill combination for their purpose. And game designers balance the game accordingly.

In some cases games will switch the order in which effects are applied on a skill in the game because it is completely overpowered. For example, think of a skill that lowers armor and deals damage. The order in which this happens can make a HUGE difference as first lowering the armor would cause more damage to be dealt.

Big multiplayer games have people who deal with balancing issues and specifically look into timings. I would think that the timings are programmed into the game and animations need to match the timing. The "Feel" of the designer for animations is important, but ultimately balance is a matter of numbers and therefore the realm of the programmer.


Now say you have a unit in your game that fires a cannon with a certain cooldown. The reason it can't fire continuously is because it has to reload. This is represented by an animation. But the server also needs to be aware of the cooldown so you end up having to sync up the animation duration and the cooldown that the server understands.

The server awareness is primary and the first concern. The most important thing is that the right thing happens and only the server may decide that. The only thing it should ever believe the client about is the user's input. I know you know that but that has to be stated.

So, assuming your proposal is that the animator decides the timings and this information is passed to the server-side developer... you have simplified nothing and the code is still "duplicated". The server application still has to enforce the cooldown. The code still has to be written. It may be worse code than it would otherwise have been and it certainly will be more fragile because it has been dictated by a graphic designer's imagination and not the internal mechanics of the game. It is not simpler.

If the proposal were that the client application tells the server "I finished reloading, I'm firing again now" then you have handed your application over to the hackers. You have created a game where the user can toss a coin and decide whether or not it came up heads, then demand money from the NPC gambler who has "lost" the bet. Even if the user is not a cheat, remember that MMOs suffer from lag and that the client software also suffers from the load on the client computer (maybe some auto-disk-defrag task decided to start up). It can neither send reliable timings back to you nor reliably show to the user what is happening now. Which feeds into my next point...

Code duplication? The server application decides what happens, based on a combination of what the user has requested to happen, what the game dictates will happen, what events and conditions are providing other inputs (NPC activity, other user activity etc) and what the application will allow from the product of all those. The client just tries to present a plausible representation of what it has been told is happening, wrapped in a lot of glitter which has no existence in the actual game, having told the server what the user wanted to do (move forwards, swing a sword, change to secondary weapon, whatever). These are completely different tasks.


The game world "exists" in your servers. The player is trying to "live" in that world from his or her home computer. The player cannot do that (and will not want to play any more) if the representation of game events is not both plausible and consistent. They can live with a game where sometimes things get too laggy and slowed down (as in a huge multi-player raid/battle) for them always to see that they have run out of ammo - if the game is reliable in managing those events. They will not stay in a game where they may seem to have reloaded and be firing, only nothing is being shot. They will not trust such a game to manage any event, server side or not.

So for your game to be acceptable, some code duplication is essential. Client side developers/animators must know something about what is going on server-side, because they have to stay roughly in sync with it under very demanding conditions and make it believable and acceptable to the player. You are trying to make the same world exist in two widely separate places and in two separate applications which absolutely should not share any code (for reasons of security as well as simple separation of concerns). Try doing that without repeating anything. Duplication of the essentials of the game is the whole point.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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