Managing the player data deluge

Let’s consider the established players. They have their own problem, one that they themselves create.

You see, the BattleCell map is big. Really big. It won’t take long for a new player to realize that they cannot singlehandedly conquer a map having 55 million cells. Cue the automation? Nope. Not even then. Much too big. Federations? Possibly, but no. They would have to be ridiculously large. But let’s not jump to the end-game just yet.

Our challenge is the information volume. The sheer number of timed actions that each established player initiates usually creates logistical tracking and organizational challenges. One’s daily routine demands a simple answer to a complex question. When and where does my next significant event occur?

Some actions do complete instantaneously. If they buy a cell, it’s instantly theirs. If they buy some troops, they are immediately available. In fact, if they buy most anything, a building, an empire upgrade, ships, stalkers, missiles, whatever… almost anything, it’s instantaneous.

On the other hand, most big ticket items require time to obtain. It takes a few days to build each missile silo. A city? Wait 6 hours, or build it yourself. Oh, and all movements require time to complete. Each player can have thousands of timed actions that all complete at different times, and at different coordinates throughout the world.

We organize each player’s in-progress actions into groups by both geographic location and completion time. If two troop groups arrive at the same destination, one in an hour and the other in 4 hours, then that is two events. Likewise, if two troop groups arrive at the same time, but different destinations, then that is also two events. The end result looks something like this:

But, I do want to say something about how we do it. It is the fun in what we do. We take all the events for each user and graph them in 3 dimensions: latitude, longitude and time. Then we perform hierarchical (agglomerative) clustering analysis on the dataset. We do this in Javascript, on the browser side, to avoid the computational hit to our servers. We also avoid impacting the player’s experience by running the analysis in a web worker.

Here is a nice Javascript library that does all the cluster analysis work for us: https://github.com/harthur/clusterfck

And here is a quick intro to web workers:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

Then we test by generating some 3 dimensional sample data. We “pre-grouped” our test data to simplify the process of confirming that the clustering analysis works as intended. For sanity checks, we verified our test data by graphing it in 3 dimensions. Not much to look at, but does provide instant data validation.

Player balance: new vs. established

To be successful, a long-running game world must give new players the same risk/reward game experience that the now-mature players had when they joined, be that months or even years before.

In BattleCell, we achieve this balance by eschewing the typical one-dimensional growth ladder. Instead, we use the game story to propel players on a multi-dimensional growth curve where bigger and more is not necessarily better.

Each player’s objective changes as they progress through the game.  At first, their objective may be to grow their empire as big as they can. When they reach a certain size, the objective shifts to grow their federation as big as they can (to a small extent, by acquiring more cells, or the easier path, by acquiring new members). Next, the objective evolves yet again, to obtain the maximum Global Credits possible.  After that, the objective may be to build the biggest federation knowledge archive… and so on.

Without getting into story particulars, the point is that when two players have the same objective, they are competing and so are far more likely to experience conflict. However, when two players have differing goals, they are much more likely to find themselves in a symbiotic relationship —at least, when our game mechanics work as designed.

Of course, this alone does not nothing to prevent a bigger player from going out of their way to abuse smaller players.  So, we have a few specific mechanics intended to assist on that front:

1. Small empires can purchase cells at a lower prices than big empires.
2. Small empire stalkers are more efficient thieves. They can steal more from each cell they traverse.
3. Field fortifications are available to small empires at a discount. (These are temporary structures that significantly increase the defensibility of a cell.)
4. Large empires are discouraged from attacking small empires by diminishing the value of conquered cells.  Cells conquered by a large empire from a small empire produce fewer daily credits; and, depending on the empire size discrepancy, may even produce no credits whatsoever.
5. Each player has a numerically computed reputation. When a player behaves badly, their reputation goes down. If it gets low enough it warrants getting flushed down the toilet, then their empire suffers. Morale decreases. Both offensive as well as defensive capabilities suffer. The rest, we leave to the dog-eat-dog nature of mankind.

We have various other mechanics in place, designed to foster a cooperative environment between established empires and new players.  We also anticipate regularly adjusting the mechanics to refine this balance, as the game story evolves.

However, we expect that the elephant in the room which determines how established players engage new players is something that we have not yet mentioned. Stop and think about the size of the game map, 55 million cells. That elephant is inescapable. Time.

More on time, in time.

Exponential growth doesn’t work

Many games use the exponential growth curve to maintain player interest as they climb up the experience ladder.  They do this, because it works.

Here’s the gist:

At 100 resource points, the player obtains a new tool that allows them to double the rate at which they earn more resource points. This keeps the player engaged, thinking that they will get their next 100 resource points twice as fast –which they do. However, the next new tool becomes available at 300 resource points, which takes longer than the original 100 points took to gather. That’s fine too, since the original 100 points were gathered relatively fast. The player doesn’t mind spending 1.5 times as long to get to the next level… They’re earning points twice as fast!

Now take this process and repeat 10, 20, even 100 times, and you’ve got yourself a game.  It works so well that  other aspects of the game are almost superfluous. Check out the irrefutable demo: Cookie Clicker

In fact, this formula is so effective that many MMO games use this very approach to keep players engaged. Here’s a few:

• Travian
• Neptune’s Pride
• Tiberium Alliances
• Starpires
• OGame

But they all run into the same rub. Not long after a player joins, their exponential growth makes them an insurmountable opponent to subsequent players who join weeks, months or even years later.

To avoid this pitfall, MMOs start new games (worlds) at regular/advertised intervals throughout the year.  Players, new and old, inexperienced as well as seasoned, all start at “ground zero” with each new game.  This effectively synchronizes everyone to the same exponential growth curve, allowing players to start on an equal footing and steer their destiny going forward.

But the world doesn’t work like that.

More importantly, BattleCell can’t work like that.  With a single massive game map designed to host hundreds of thousands of active players, BattleCell must implement an alternative engagement formula that keeps long-playing members from clobbering vulnerable new players.  It quickly becomes evident that even without the exponential growth mechanism, our gameplay must provide balance between new players and well established members who have been playing for a year or more.

Apparently, the BattleCell gameplay itself needs to evolve out of our initial stated objectives: a single massive map and long-term player engagement.  These initial constraints are inevitably driving us to a unique gameplay, a bonus for our 4X game.

One massive persistent map

In 2008, I set it in my mind to create a single massive game map able to host hundreds of thousands of active players.  What I wanted, I had not seen before; and I wanted to build it as an AJAX website using the Google Maps API.  Cue June of 2008.

I expected the biggest challenge to be the system architecture. Boy was I wrong.

The real trick is balancing new player experience with established players in a long-lasting multi-year game.  Compounding that, BattleCell’s map can host well over 100,000 active players, all eager to pounce on those most vulnerable –the newbie who takes their time deciding whether they even want to join, years behind their biggest competitors.

I’ll discuss our experiences, challenges, and solutions as we work our way through this project.  This has been, and continues to be a learning experience.  Most solutions have not worked well.  Though, some have.

BattleCell is now in open beta.  You’re welcome to try it out. But the gameplay is not complete. We’ll be adding the finishing touches over the next few months, and we want to hear from you.  Give us your thoughts, suggestions, and concerns.

http://www.battlecell.com