Games of many different genres now use Events: card battlers (Marvel War of Heroes, Rage of Bahamut), 4X games (Kingdom of Camelot, Crime city), and even Puzzles and Dragons. We also use events in a game that I was in charge of, Ayakashi, an Anime themed Card Battler, which became a sleeper hit at Zynga. Events are proven to drive revenue (often multiple times the revenue of non-event period), increases Concurrent User Return Rate, Reactivation Rate, and overall Engagement. The goal of this article is to give game designers some insight on how to effectively leverage this mechanism in their games.
An Event is defined as a limited time content/activity for online games. They are meta-games built on top of the existing core mechanisms of the game. The most common core mechanisms in games are Questing and Battle.
Questing is usually the main PVE mechanic or story mode, in which you complete one stage, and move on to the next. In most F2P games, questing requires energy (in addition to skills, luck, etc.) as a resource. Energy can take many forms: for some games it’s “lives”, for some “health” and for others it’s “troops”. The energy is consumed as you’re questing and it usually takes time to regenerate.
Most games also have a battle system in which you either battle against an in-game character (Boss) or against another player (PVP). Generally, most games require resources for these types of battle as well: sometimes it’s basic energy, but most games create a separate resource type. Without loss of generality, let’s call it Mana for the purposes of this article.
On the foundation of these few core mechanics of Battle and Questing (often masked by different fictions by different games), there are three common types of Events:
- Tower: a set of time limited PVE content, where the players’ goal is to reach a target as far as they can within that content.
- PVP: where the goal is to encourage players to battle against each other. This can take most variations, such as Gathering Points, Resources, or King of Hill. An additional dimension can be added through Guild PVP battles.
- Raid: where the goal is to battle a Boss that only appears during the time period of the Event.
With all types of Events, the backbone of the revenue source consists of recovery items for Energy or Mana. But to drive users to spend on recovery items, we must design the events carefully. There are four pillars of event design that one must keep in mind:
Rewards are the reason people play the game, and they should be tied to the core loop of your game. For example, in Ayakashi, the core goal is collecting cards; therefore, the rewards should be cards. In Ruby Blast (a casual match 3 game), the global competition events we organised, did not work well, as the rewards consisted of Coins (free currency), and there was no pinch for it in the game.
As a side note, many players see Events as a cheaper way of obtaining desirable rewards than the conventional means (such as Rare Cards) by putting in some elbow grease. This is one of the reasons why this drives recovery items spend.
Besides making rewards compelling, we also need to structure them properly.
The first approach is to structure them based on key players profile – have rewards for each of your players’ types: Beginners, Engaged Players, Extremely loyal players/regular players, and Whales. For example, in a tower event, even if a player just joined on the day of the event, as he participates, he should easily reach the first good reward. This way, his/her goal for next time will be to reach an even higher floor. However, you should also have rewards designed for your whales, as they bring in the most money.
The second approach is to structure rewards based on timing. Rewards should be given out during and at end of the Event. This way, the player is engaged for the entire duration. If you give out rewards during an event, it gives the player an opportunity to brag about it while the event is going on. It encourages others to participate.
Events are basically meta-games, and like all games, each Event needs to have goals. In addition, players need to feel progression towards those goals. For some event types, the progression is quite natural: for Tower Event consists in climbing the tower floors; for Raid Event, the raided Boss increases in level as you beat him. For PVP events though, it gets trickier. Therefore, most PVP events are based on accumulation of points. However, it isn’t enough to create progression on the high level; it’s important to create progression at lower level mechanisms as well, which I’ll illustrate using two case studies.
Case Study with Design Goal: Adding a wandering boss mechanism to a Tower Event to add interest, variety and more rewards.
Design 1: As you progress through the tower, you have a random chance of meeting a wandering boss. If you beat the wandering boss, you have a 10% chance of obtaining it as a card.
Design 2: The encounter with the boss is also random. If you beat the wandering boss, you have to trade 100 tokens to obtain him as a card. If you don’t have enough, by the act of beating the boss, you get 10 tokens.
Even though it is equally likely to get the reward in both designs, Design 2 is better because of progression. In Design 1, if the user fails to obtain the wandering boss a couple of times, he’ll think the odds are against him/her, and will stop playing. In Design 2, after the user gets some of the 10 tokens, he/she will be actively seeking out the wandering boss, hoping to progress some more.
Case Study with Design Goal: Leaderboard for an Event in a game where each game session is fighting against hordes of enemies.
Design 1: The ranking is based on the number of kills you did in the single best session during the event period.
Design 2: The ranking is based on accumulated number of kills in all sessions during the event period.
Design 3: The ranking is based on accumulated tokens. The tokens are dropped randomly as you kill the enemies, but drop rate increases as you kill more waves of enemies in a single session.
In Design 1, if a player achieves a high score in one session, there is no incentive for him/her to continue playing. Therefore, he/she won’t pay for recovery items. Players with limited skills, on the other hand, will never achieve higher than another player, so they’ll get discouraged and won’t participate. In Design 2 or Design 3, even if players have lower levels or lower skills, they would feel that they can grind (perhaps spend more on recovery items to play more often) and progress up the leaderboard. In Design 3, you can more carefully balance it so you reward players for skills as well as grind.
During the Event period itself, there’s a day to day urgency due to the fact that both the reward and the content are limited. However, that urgency isn’t enough. This is the biggest mistake new designers assume about events. The most important urgency is the session to session one. There must be a reason or need for players to immediately replay after a session, or they will not pay for recovery items for energy or mana.
Examples of Urgency:
- Most tower events, are tuned so you can barely reach the top if you always play as soon as your energy recovers. If you miss it, then you’ll have to pay for energy recovery.
- In some events, the number of rewards is limited for all global users, and it works on a first come first served basis.
- In some raid events, if you encounter a Raid Boss, you have X amount of time to beat it. Or else the Raid Boss runs away, and you’ll have to start from a much lower level boss. The time usually allowed for this is not enough for your Mana to recover without paying.
- In a PVP or Raid event, if you beat someone, and choose to fight again within the next X minutes, you’ll get a Y% attack boost. But that X minutes isn’t enough time for your Mana to recover.
In all these examples, the urgency is created for users to be constantly playing when able, and use recovery items for Mana or Energy to continue playing.
Almost all events have leaderboards, and give out rewards based on the leaderboard rankings. The competition is what drives revenue from whales. However, several qualities make some leaderboards better than others:
- Players aren’t safe in their leadership position. It can even change at the last minute.
- Players need to come back and check their position all the time.
- Players feel like they have a chance by simply playing more.
Case Study: Trying to design a leaderboard feature for a tower event.
Design 1: The first person to reach the top of the tower: it’s a race to the top.
Design 2: The ranking is based on collecting tokens: the tokens are randomly dropped as you climb the tower and beat the bosses.
In Design 1, as soon as the whale users reach the top there is no more incentive to continue play and pay. Furthermore, for regular users, once they see other whales already reach the top, they will become discouraged from continuing playing as well. In Design 2, the normal user will feel like they would have a chance if they just grind a bit more. It will force whales to constantly check and maintain their rankings till the last minute.
Once the main event mechanisms are created, there is an opportunity to create virtual items to help users exceed along the way. Ideally, the virtual items should be designed to help you reach the goal rather than give the goal away. Here are some examples:
- In Raid Events, items to increase attack power against Raid Boss.
- Big bundle of Energy during tower Events.
- Items that increase the chance of encounter with Raid Bosses.
Market/Promotion of Events
Since Events occur during a set time period, it is important to promote the event to increase the funnel. There are many tools or questions to consider:
- Discoverability and entry point: How easy is it for Users to find the event once it started?
- Pre-Announce Events for a certain time period before the Event. A/B Test to find the optimal period of time.
- Notifications: if your game is on mobile, you can consider Push Notifications.
- Give out free items for the next Event.
Events are a powerful tool used in many Mid-Core games to drive engagement and revenue. They are ultimately meta games, as they do not replace the core loop or compensate for the weak core mechanism of your game. While they are powerful, design considerations must be put in place before an Event can be successful. As you design the event, always think about the reason why users would pay. On the other hand, make sure all users can participate and get rewards regardless of whether they are payers or beginners.