Casting: Animations, Verifications, and Latency

For any MMO involving using abilities, a few concepts will almost always come into play. This can generally be boiled down to 2 basic elements: responsiveness and accuracy.

Responsiveness is how quickly the user interface reacts to a user's input - ideally, a spell should start casting (or at least look like it's started casting) as soon as the player tells the game to cast the spell.

Accuracy is how little an interface shows something happening when it really isn't. For instance, if a character tries to cast a spell on a player who is out of range, the animation for the spellcast shouldn't play because the spell can't actually be cast.

Now, if all we cared about was one or the other, it'd be quite simple to design a system that works perfect with any amount of latency:

If all we care about is responsiveness, then we just play an entire spellcast animation as soon as the client gets the input to cast the spell from the player, before we ever hear back from the server. After all, we don't care about accuracy, so we can just start animations whenever we want, so might as well start it ASAP.

If all we care about is accuracy, then we can just always wait for the server to tell us whether the cast is valid or not. Since responsiveness isn't an issue, we never play an animation until we're sure (because the server told us) a cast is valid.

The problem arises when we want to maximize both responsiveness and accuracy at the same time, since each goal leads us starting the cast animation at different times.

The answer to this problem is hybrid animations. Instead of creating a single cast animation for a fixed length of time, make a 3-segment animation (which can still be essentially a single animation, but divided up into 3 parts and designed with this division in mind). This animation has a very brief initial "start" segment, a "middle" segment which is fashioned in such a manner that it can be seamlessly looped, and an "end" segment, which is also short. If your game uses a global cooldown system, the total length of the start+end segments should fit within the global cooldown.

Then, your spellcast processing sequence goes something like this:

1. Player initiates spellcast via input.
2. Client performs simple checking based on local knowledge only to determine if it's "reasonable" for the player to attempt that spellcast. If it fails this check, the spell doesn't cast. (The kinds of things the client might check here include range, line of sight, whether the player can pay the spell's cost of mana/ap/energy/etc, whether the spell is on cooldown, and so on). If the simple check fails, the failure reason is displayed immediately and no animation is played.
3. If the simple check passes, client plays the "start" portion of the animation and sends a request to the server to cast the spell. When the "start" portion of the animation ends, the "middle" portion begins looping.
4. The server does a comprehensive check based on the server's knowledge for all conditions necessary for the spellcast, including those checks already done on the client. Yes, this means a redundant set of checks is done, but it's necessary for a more secure game (otherwise client-side hacks are much more powerful).
5. When the server's response arrives, the client checks to see if the server approved it. If it did, then the client continues to play the "middle" animation loop. If the server rejected the spellcast attempt, the client immediately stops playing the "middle" animation loop and displays a failure message.
6. The client then waits until either the player themselves interrupts the cast early, or it receives a message from the server indicating the spell stopped casting, whether through completing the duration of the cast, or via some means of interrupt.
7. If the player interrupts the cast (or if the message received from the server indicates it was interrupted), all animation is stopped and the interrupted message is displayed.
8. If the server indicates that the cast completed successfully without interrupt, then the "end" segment of the cast animation is played, as well as the spell's effect animation.

By using this system, a number of goals are achieved:

• The system is highly responsive because client-side checking can be done extremely fast, and thus the player sees an animation or a relevant failure message almost immediately after initiating the spellcast.
• The initial spellcast animation is mostly accurate because a large number of the cast conditions can be checked client-side without actually having to wait for the server.
• The actual casting is still secure, because the server needn't and doesn't trust the client as to whether the cast is valid.
• The final spellcast animation (and the spell effect animation) is always accurate because it is based on the server's authoritative response.
• None of the animation looks "awkward" because latency is simply folded into the looping "middle" animation, so the cast flows smoothly from initiation to completion.

Player Factions: Why 3 is the Magic Number for World PvP

There are basically 3 types of endgame elements most modern MMOs have available: PvE, instanced PvP, and open-field PvP. The rest of this article assumes we're discussing the last, open-field PvP.

Many MMOs have opted to have two player factions: World of Warcraft is probably the largest, but many others have also used a similar model, including Warhammer Online. A two-faction system has certain advantages in its simplicity - it's always clear who the enemy is, it's the simplest to write separate story lines for, and it has the least redundancy for level areas (if you choose to have faction-specific quests or areas, which are a near-necessity for any kind of immersion factor).

But a three-faction system has one key advantage that almost single-handedly makes it far more attractive for any game looking to create an environment for meaningful world PvP: it's self-balancing. Whenever any individual faction gains the upper hand, they automatically become the outnumbered, which means that overall control will almost assuredly continue to change hands over time. No single faction is likely to become so much larger than the others that it maintains constant dominance, simply because it would have to attract players at something along the lines of a 2:1 ratio of any other faction to be able to maintain population superiority over the other factions combined.

Furthermore, a three-faction system has the advantage that there's not a harsh penalty for being the "underdog". Sure, the smallest faction might not maintain control as often as the other two factions, but whenever they don't have control, they're also not the main target. Thus you don't have a system which devolves into one "bully" faction picking a smaller one, because the bully faction themselves is outnumbered by the greater opposition.

Since no faction is likely to hold on to the reins of power for too long, it's easier to implement bonuses for those who do currently have power without throwing balance out the window, which means it's easier to make world PvP objectives which actually have incentive to fight over them.

Of course, any number of factions greater than 3 also works for this, but more factions also make things more complicated, and splinter the playerbase. Depending on how your game is designed, this can still be feasible (see EVE for a good example of a many-faction system, though Corps and alliances), but should be undertaken with care - and is not so conducive to games which have a less sandbox approach than EVE.