Failing In So Many Ways


Liang Nuren – Failing In So Many Ways

DAU Decomp

So I was recently chatting with @AngryFacing on Twitter about whether or not it’s worth supporting IOS4 anymore.  I told him I was pretty sure the IOS4 rate is very low and obtained permission from a VP at my studio to publish some (anonymized) numbers for a couple of our games.  Here’s what I found (model map from

Game 1

       period        |  os   | pct  
 2013-07-01 00:00:00 | iOS 6 | 0.91
 2013-07-01 00:00:00 | iOS 5 | 0.08
 2013-07-01 00:00:00 | iOS 7 | 0.00
 2013-07-01 00:00:00 | iOS 4 | 0.00

       period        |    name    | pct  
 2013-07-01 00:00:00 | iPad 2     | 0.22
 2013-07-01 00:00:00 | iPhone 4   | 0.19
 2013-07-01 00:00:00 | iPhone 4S  | 0.14
 2013-07-01 00:00:00 | iPhone 5   | 0.12
 2013-07-01 00:00:00 | iPad 3     | 0.09
 2013-07-01 00:00:00 | iPad Mini  | 0.07
 2013-07-01 00:00:00 | iPad 4     | 0.07
 2013-07-01 00:00:00 | iPad 1G    | 0.02
 2013-07-01 00:00:00 | iPhone 3GS | 0.00

Game 2:

       period        |   os   | pct  
 2013-07-01 00:00:00 | iOS 6  | 0.90
 2013-07-01 00:00:00 | iOS 5  | 0.09
 2013-07-01 00:00:00 | iOS 7  | 0.00

       period        |    name    | pct  
 2013-07-01 00:00:00 | iPad 2     | 0.25
 2013-07-01 00:00:00 | iPhone 4   | 0.21
 2013-07-01 00:00:00 | iPhone 5   | 0.14
 2013-07-01 00:00:00 | iPhone 4S  | 0.13
 2013-07-01 00:00:00 | iPad 3     | 0.10
 2013-07-01 00:00:00 | iPad Mini  | 0.08
 2013-07-01 00:00:00 | iPad 4     | 0.08
 2013-07-01 00:00:00 | iPad 1G    | 0.00
 2013-07-01 00:00:00 | iPhone 3GS | 0.00

Game 3:

       period        |  os   | pct  
 2013-07-01 00:00:00 | iOS 6 | 0.94
 2013-07-01 00:00:00 | iOS 5 | 0.04
 2013-07-01 00:00:00 | iOS 7 | 0.00

       period        |    name    | pct  
 2013-07-01 00:00:00 | iPad 2     | 0.24
 2013-07-01 00:00:00 | iPhone 4   | 0.24
 2013-07-01 00:00:00 | iPhone 4S  | 0.19
 2013-07-01 00:00:00 | iPhone 5   | 0.16
 2013-07-01 00:00:00 | iPad 3     | 0.09
 2013-07-01 00:00:00 | iPad 4     | 0.07
 2013-07-01 00:00:00 | iPad Mini  | 0.04
 2013-07-01 00:00:00 | iPhone 3GS | 0.00
 2013-07-01 00:00:00 | iPad 1G    | 0.00

Filed under: Game Design, Software Development

Python JSON Performance

So I’ve been pretty open about the fact that I’ve moved from data warehousing in the television and online ad industries to data warehousing in the gaming industry. The problem domains are so incredibly different. In the television and ad industries, there’s a relatively small amount of data that people are actually concerned about. Generally speaking, those industries are most interested in how many people saw something (viewed the ad), how many people interacted with it (clicked on it), and whether they went on to perform some other action (like buying a product).

However, in the gaming industry we’re interested in literally everything that a user does – and not in the creepy way. The primary goals are to monitor and improve user engagement, user enjoyment, and core business KPIs.  There are a lot of specific points to focus on and try to gather this information, and right now the industry standard appears to be a highly generalized event/payload system.

When looking at highly successful games like Temple Run (7M DAU [gamesbrief]) it’s only 150 events per user to get a billion events per day.  Between user segmentation and calculating different metrics it’s pretty easy to see why you’d have to process parts of the data enough times that you’re processing trillions of events and hundreds of GB of facts per day.

When I see something that looks that outrageous, I tend to ask myself whether that’s really the problem to be solving. The obvious answer is to gather less data but that’s exactly the opposite of what’s really needed. So is there a way that to get the needed answers without processing trillions of events per day? Yes I’d say that there is; but perhaps not with the highly generic uncorrelated event/payload system.  Any move in that direction would be moving off into technically uncharted territory – though not wholly uncharted for me. I’ve built a similar system before in another industry, albeit with much simpler data.

If you aren’t familiar at all with data warehousing, a ten thousand foot overview (slightly adapted for use in gaming) would look something like this.  First, the gaming client determines what are interesting facts to collect about user behavior and game performance. Then it transmit JSON events back to a server for logging and processing.  From there the data is generally batch processed and uploaded to a database* for viewing.

So as a basic sanity check, I’m doing some load testing to determine whether it is feasible to gather and process much higher resolution information about a massively successful game and it’s users than seems to be currently available in the industry.  Without going into proprietary details, I’ve manufactured analytics for a fake totalhelldeath game.  It marries Temple Run’s peak performance with a complicated economy resembling Eve Online’s.

From there, I’m compressing days of playtime into minutes and expanding the user base to be everyone with a registered credit card in the app store (~400M people as of 2012) [wikipedia].  The goal here is to see how far it’s possible to reasonably push an analytics platform in terms of metrics collection, processing, and reporting.  My best estimate for the amount of data to be processed per day in this load test is ~365 GB/day of uncompressed JSON.  While there’s still a lot that’s up in the air about this, I can share how dramatically the design requirements differ:


  • Reporting Platform: Custom reporting layer querying 12TB PostgreSQL reporting databases
  • Hardware: Bare metal processing cluster with bare metal databases
  • Input Data: ~51GB/day uncompressed binary (~150TB total uncompressed data store)
  • Processing throughput: 86.4 billion facts/day across 40 cores (1M facts/sec)

Analytics Load Test:

  • Reporting Platform: Reporting databases with generic reporting tool
  • Hardware: Amazon Instances
  • Input Data: ~365 GB/day uncompressed JSON (~40k per “hell fact” – detailed below)
  • Processing throughput: duplication factor * 8.5M facts/game day (100 * duplication facts/sec)

I’ve traditionally worked in a small team on products that have been established for years.  I have to admit that it’s a very different experience to be tasked with building literally everything from the ground up – from largely deciding what analytics points are reasonable to collect to building the system to extract and process it all. Furthermore, I don’t have years to put a perfect system into place, and I’m only one guy trying to one up the work of an entire industry.  The speed that I can develop at is critical: so maintaining Agile practices [wikipedia], successful iterations [wikipedia], and even the language I choose to develop in is of critical importance.

The primary motivator for my language choice was a combination of how quickly I can crank out high quality code and how well that code will perform.  Thus, my earlier blog post [blog] on language performance played a pretty significant role in which languages saw a prototype.  Python (and pypy specifically) seems well suited for the job and it’s the direction I’m moving forward with.  For now I’m building the simplest thing that could possibly work and hoping that the Pypy JIT will alleviate any immediate performance shortfalls.  And while I know that a JIT is basically a black box and you can’t guarantee performance, the problem space showed high suitability to JIT in the prototyping phase.  I foresee absolutely no problems handling the analytics for a 1M DAU game with Python – certainly not at the data resolution the industry is currently collecting.

But, I’m always on the look out for obvious performance bottlenecks.  That’s why I noticed something peculiar when I was building out some sample data a couple of days ago. On the previous project I worked on, I found that gzipping the output files in memory before writing to disk actually provided a large performance benefit because it wrote 10x less data to disk.  This shifted our application from being IO bound to being CPU bound and increased the throughput by several hundred percent.  I expected this to be even more true in a system attempting to process ~365GB of JSON per day, so I was quite surprised to find that enabling in-memory gzip cut overall application performance in half.  The implication here is that the application is already CPU bound.

It didn’t take much time before I’d narrowed down the primary culprit: json serialization in pypy was just painfully slow. It was a little bit surprising considering this page [] cites pypy’s superior json performance over cpython.  Pypy is still a net win despite the poor JSON serialization performance, but the win isn’t nearly as big as I’d like it to be. So after a bit of research I found several json libraries to test and had several ideas for how the project was going to fall out from here:

  • Use a different json library. Ideally it JITs better than built in and I can just keep going.
  • Accept pypy’s slow json serialization as a cost of (much) faster aggregation.
  • Accept cpython’s slower aggregation and optimize aggregation with Cython or a C extension later
  • Abandon JSON altogether and go with a different object serialization method (protobuf? xdr?)

After some consideration, I ruled out the idea of abandoning JSON altogether. By using JSON, I’m (potentially) able to import individual records at any level into a Mongo cluster and perform ad hoc queries. This is a very non-trivial benefit to just throw away! I looked at trying many JSON libraries, but ultimately settled on these three for various reasons (mostly relating to them working):

To test each of these libraries, I devised a simple test with the goal of having the modules serialize mock event data.  This is important because many benchmarks I’ve seen are built around very small contrived json structures.  I came up with the following devious plan in order to make sure that my code couldn’t really muck up the benhmark results:

  • create JSON encodable dummy totalhelldeath fact list
  • foreach module: dump list to file (module.dump(facts, fp))
  • foreach module: read list from file (facts = module.load(fp))

Just so that everything is immediately obvious: this was run on one core of an Amazon XL instance, and the charts are measuring facts serialized per second.  That means that bigger bars are better here.

Read Performance

There’s really no obvious stand out winner here, but it’s obvious that the builtin json library is lacking in both cpython and pypy. It obviously runs a bit faster with cpython, but it’s not enough to really write home about. However, simplejson and ujson really show that their performance is worth it. In my not-so-expert opinion, I’d say that ujson walks away with a slight victory here.

Write Performance

However, here there is an obvious standout winner. And in fact, the margin of victory is so large that I feel I’d be remiss if I didn’t say I checked file sizes to ensure it was actually serializing what I thought it was! There was a smallish file size difference (~8%), primarily coming from the fact that ujson serializes compact by default.

So now I’m left with a conundrum: ujson performance is mighty swell, and that can directly translate to dollars saved.  In this totalhelldeath situation, I could be sacrificing as much as 71k + 44k extra core-seconds per day by choosing Pypy over CPython.  In relative money terms, that means it effectively increases the cost of an Amazon XL instance by a third.  In absolute terms, it costs somewhere between $5.50 USD/day and $16 USD/day – depending on whether or not it’s necessary to spin up an extra instance or not.

Obviously food for thought. Obviously this load test isn’t going to finish by itself, so I’m putting Python’s (lack of) JSON performance behind me.  But the stand out performance from ujson’s write speed does mean that I’m going to be paying a lot closer attention to whether or not I should be pushing towards CPython, Cython, and Numpy instead of Pypy.  In the end I may have no choice but to ditch Pypy altogether – something that would make me a sad panda indeed.

Filed under: Data Warehousing, Game Design, Personal Life, Software Development

Tiericide Dev Blog: First Response

CCP recently posted a somewhat controversial dev blog [] about ship and skill rebalancing.  The major sticking point for many people has revolved around this phrase:

To sum up, this means that tech 1 sub-capital vessels would take a bit longer to train for (from 9 to 17 days for Battleships for instance), capitals would be less time consuming (30 days faster) and tech 2 ships like Interdictors and Command Ships would require 14-20 less days to train for.

If and when such changes occur, we would remove the generic Destroyer and Battlecruiser skills, reimburse the skill points (and possibly the cost) not to penalize players. Due to the way nested requirements work, it would also mean pilots would not need to re-train anything to fly Battleships or Cruisers. All of this is work in progress of course and subject to change, especially since we are still discussing skill reimbursement options.

I managed to land an early comment [] in the thread asking for clarification for people who have cross trained extensively, which Soundwave and Ytterbium quite thoroughly answered:

Destroyer and Battlecruiser reimbursement: it has been said before, but allow us to repeat again, that we do not want to cut ships you can already fly. Thus, having BC skill at 5 would mean you get all four variations at 5.

The net result to me is that I’ll have all racial Destroyers/BC skills at level 5 and it’ll almost certainly provide an immediate increase in the cost of my clone.  It will additionally mean that one of my PVP alts will end up with a more expensive clone than my target clone.  On the flip side, that’ll mean that people who haven’t trained Destroyers/BCs up yet will be stuck training longer to get the same massive result that I did so long ago.… but thats entirely the point.  On the flip side, it’ll become faster to get into various T2 ships like Interdictors and Command Ships, so new players aren’t totally screwed.

However, I feel like all this talk about skill points is distracting from the bigger message being presented:

In practice however, after assessing ship slots, EHP, speed, fitting potential and role overlap, we estimate almost half of our currently available ships to have suboptimal use, or are just be plain not worth it at all for pilots looking to min-max. … That is why we want to remove ship tiers altogether, then refocus our balancing philosophy to be based on role.

This is quite possibly the greatest balancing news I’ve seen in recent memory – its even better news than the Hybrid Buff.  However, the devil’s always in the details and I don’t feel we have enough details to make say much at this point.  My first reaction was that this was effectively creating a class system in Eve… and to a point I suppose it is.  However, there’s a lot of key differences and ultimately the ship line system is exactly how the currently successful ship lines work.  This means I really shouldn’t be too worried about the proposed ship lines and expanding on the concept will probably make the game significantly easier to balance.  Unfortunately, that simplicity comes at the cost of some “wildcard” play we’ve seen in the past, but ships capable of that tended to simply be bad at everything.

Overall – exciting times are ahead!

PS: If you ever plan to cross train: Train Destroyers 5, BC 5, Cruisers 3, and BS 1 in every race.  Now.

Filed under: Eve, Game Design, Gaming, ,

The Community Disadvantages of Classes

A while back Taugrim made a post on his blog here [] which pointed out the potential for population imbalance on PVP servers in SWTOR.  In it, he makes this statement:

The three things that I have seen kill World PVP in other games have been:

  1. Crappy class balance, which causes individuals to quit (so far, not a significant issue in SWTOR, although the JK/SW’s should get their CCs earlier)
  2. Crappy world PVP implementation (can’t comment on this, haven’t experienced Ilum yet)
  3. Population imbalance, which causes different issues on both side: boredom for the zergy faction, frustration for the gets-zerged faction (there is significant risk here for SWTOR, given that it’s a 2-faction game)

His first point about crappy class balance got me thinking along a track that I’d been kicking around since before I quit Rift.  Taugrim touches on this with his comment about “crappy class balance”, but I think the problem goes much deeper than simply killing world PVP.

Basically, one of the most destructive forces in modern MMOs is the class system itself, because the difficulty and foolishness in providing a perfectly balanced game combined with class communities simply rip the game’s community apart.  That it isn’t because class systems are worse for actual game play than classless systems (because they generally aren’t), but rather because of the fact that they are Massively Multiplayer Online Games.

Its the human element that ruins it, and that’s important because the human element of community is what keeps people playing (and paying for) the game.

Character Investment

Lets first agree that a player creates an extension of themselves when creating a character in a MMO, and they often pour hundreds of hours of blood, sweat, and tears into their characters.  While its not legally true, in a very real sense the character’s successes, failures, reputation, and even in game wealth belong to the player.  All of this effort provides an attachment to their character – and thus to the game itself.

However, a class based MMO forces special restrictions on the character (and thus the player).  For instance, class based systems frequently prevent a player from fully reacting to metagame shifts and game balance changes.  The player is almost certain to resent negative changes, even if the changes are required for the good of the game.  Rightly or wrongly, this resentment often makes people feel like they’re playing a losing hand.

In the worst cases (sometimes via self inflicted Fad Of The Month chasing), people re-roll alts to play while their main character is on ice.  On the positive side, this behavior allows the player  to “experience” (read: blitz) the intro parts of the game from a new perspective.  However, much more importantly it deprives them of access to all of the advantages and prestige of their main character – from their level and equipment to their in game skill/muscle memory and even reputation.

This deprivation – caused because the class system forcibly prevents the player from adapting their character to the new environment – breaks the player’s attachment to their character and thus the game itself.  The ability for players to adapt around broken and inefficient areas of the game means that players in a classless MMO can often slip around issues that become absolutely critical to a classed MMO’s long term health.

Class Imbalances Affect the Game – and Community

Its pretty obvious that class imbalances legitimately affect the game in a variety of ways – ranging from the way that the game is played to the way that the metagame is played.  For instance, a class that’s perceived as not performing isn’t as likely to be accepted on raids – effectively providing a barrier to participating in group content (either PVE or PVP).  This has several knock-on effects that tend to create feedback loops exacerbating game balance problems – whether large, small, or merely imagined:

  • An underperforming class is played less often, if for no other reason than its less fun to play a game where you frequently lose “unfairly”.  On the other hand, overperforming classes are frequently played because winning is fun.
  • Class scarcity can make abilities which rely on a certain “critical mass” for optimal performance can become nearly impossible to pull off.  But class overpopulation can make it trivially easy to execute certain mechanics that are impossible to counter for all intents and purposes.
  • Classes which rely on or play off of the over or underperforming class’ abilities are similarly affected – and this propagates even further between other classes
  • Under performing classes frequently lack the population “critical mass” to create active communities, and what community does exist tends to be bitter and angry.  On the other hand, over performing classes often have vibrant, active, and helpful communities.

The interesting thing here is that a classless MMO simply sidesteps most of these problems.  That’s not because there can’t be role imbalances, but  by virtue of allowing any character to fulfill any role.  The barrier to entry for participation in group content simply evaporates as the players adapt their characters to the new game environment.

Class Communities

Sub communities almost always spring up in a properly functioning MMO community of any size – and in class based games these communities tend to revolve around classes.  The existence of these communities make tons of sense too, because people who like the same parts and roles within the game are likely to want to talk to each other about it.  Invariably these communities will also spawn their own community leaders, because some people just have a lot of time to post and are just as good at communicating and teaching as they (hopefully) are at the game.

Two of the more obvious examples I can think of are Taugrim [] and Dissb [].  Both of these guys are great guys, both sharp as a whip, and provide great value to their respective communities.  Furthermore, they provide great value to their game community as a whole because they try so hard to learn the minutiae of every class.

However for every Taugrim and Dissb we see in a community, there are countless other people that cover spectrum in temperament and skill – each having wildly different expectations for what they are wanting to give to the community and get back out of it.  Most want to be constructive by engaging in general dialogue and sharing experiences with people who share similar interests.  Others want to be a pain in the rear and be generally disruptive… and really that’s to be expected in any online community.

However, the real problems with class communities don’t start until there’s a perceived game imbalance – and there will always be a perceived game imbalance.  Sometimes, its because there’s a real imbalance, sometimes its because of a disadvantaged situation and a Rock / Paper / Scissors / Lizard / Spock [wikipedia] balancing approach.  And sometimes its because the skill differential between your highly visible elite players and the average can be so high.

Class Balance Suggestions – and the Metagame

No matter how or why it starts, class communities are organized and prepared to wage bitter forum wars against every other class.  When there’s a widely perceived class imbalance, these communities assault and flood every forum from general to the class specific to ensure the problem has high visibility.  The quality of posting is highly variable – from objective comparisons and concrete examples of how and where the class balance is less than optimal to :raeg: poasting, ultimatums of unsubbing, and outright trolling.  And, of course, there’s also going to be countless ideas for how to fix the perceived game imbalance.

Some of these ideas are going to be made by reasonably smart people with solid understandings of that part of the game.  These ideas range from extremely insightful and balanced to subtly imbalanced – either because the author’s experience is too narrow and they’re “in the weeds” with the problem or because the author is out to meta game the dev staff into shifting the game imbalance to favor their class and play style.  The result is extremely predictable regardless of whether the poster is operating in good faith: people from every side rush to defend their own positions.  These forum fights are the ones that I’ve seen the most energy and anger poured into – hundreds and even thousands of player-hours poured into individual threads chock full of fanaticism and borderline hatred.

In the end, if there’s a real imbalance the company is going to have to fix it – either to fix the community or to keep their game afloat.  Afterall, nobody likes playing a loser.  Inevitably, the devs are going to be influenced by the community floated ideas and general community atmosphere.  The situation frequently deteriorates to the point that by the time the devs have come up with a solution on the testing server that there’s active efforts on the player base’s part to sabotage and misrepresent beta testing results.  In many ways this is the source of “knee-jerk” balancing and the creation of the FOTM cycle.

Its simply undeniable that these kinds of fights create animosity and divide the community.  Furthermore, these forum brawls and dirty tactics are inevitable because of the high stakes being played for – losing an argument can result in your character or play style being buffed to godhood or nerfed into obsolescence.  In a class based game this can mean months at a time of sacrificing the reputation, gear, and wealth that you’ve spent literally years building.

Really, it makes no sense to forcibly create these anger filled subdivisions within your community by introducing a class system.

Filed under: Eve, Game Design, Gaming, Rift, SWTOR, , , , , ,



According to the Rift Forums Community Ambassador (01-26-2012 01:48 PM):

Anyone know the state of rift?

The question is very hard to answer meaningfully. Right now, we have 16 servers in NA, population caps are about 2k concurrent players (could be a little more, but I don’t think so). A couple-few are filling up at peak hours, peak hours are usually 5-10% of player base (outside of launch, where it’s quite a bit higher)… so I’d guess rough order of 300k-350k players active in NA plus players elsewhere who are on NA servers.

Participation levels are way down since launch, but that’s a mix of population shifts and changes in hours people play.

We can’t get good info on rising or falling populations right now because of recent effective-mergers of shards; the 16 NA shards we see now are still getting people coming in from 11 shards recently repurposed for “trial” purposes.

In practice, I certainly do see a lot of people in the game who want to know what a soul is, or whether they have to reroll if they don’t like their build, or what it means then there’s a horn sound and a statement like “The heat of the forest begins to increase.” So basically newbies who haven’t played before.

I have read that there are at least 32,000 concurrent users.

16 servers with caps of 2k would be 32,000 if they were all full — but they aren’t, I’ve not seen more than 2-3 with queues in the last month or so. So a lot are a bit under.

It is worth remembering at this point that he’s a Community Ambassador, not a dev.  He’s got the inside track on information but its by no means authoritative.  But lets run with it.

According to Massively, Rift launched by adding 31 new servers for a total of 58 US and 41 EU servers.  Thus, the most peak concurrent users Rift has ever been capable of supporting was ~198k (assuming the same PCU max per server since launch).  According to Riftstatus there are currently 23 total active servers (16 US,  7 EU) for a maximum of 46k players online at any given time.  If the servers were always full during their respective timezones, we could expect 32k concurrent players in the US prime time and 14k in the EU prime time.

However, also according to Riftstatus, most servers cycle between low and medium population throughout the day.  Thus, it is not reasonable to assume that Rift has hit 46k PCU recently (even if we neglect timezone differences between US and EU TZ).  I don’t feel comfortable making arguments relating to the exact ranges that “high”, “medium”, and “low” represent but I’d be surprised if we’re looking at more than 20-25k players during any given US TZ prime time.


On the other hand, SWTOR is just a few months old and has many servers (124 US, 91 EU for a total of 215).  According to Eurogamer, SWTOR’s current vital stats include 1.7M subs and 350k peak concurrent users over 215 servers.  It doesn’t really tell us anything about the per server numbers though, so its hard to compare to Rift, except as perhaps “overall game health”.  But, it does give us some overall numbers to poke at, and those numbers are quite substantial indeed!

According to this thread from the SWTOR forums, someone doing a “personal audit” of the game population using map instance populations found 1400 people on his server.  Dividing the PCU evenly over all the servers worldwide would yield 1628 people per server.  Cramming all the players onto the US TZ servers would result in ~2800 people per server – but of course this simply provides an upper boundary because we know it isn’t happening.  Eve Online’s daily PCU is right as the EU TZ logs off and the US TZ logs on, so dividing across SWTOR’s East/EU servers yields 2023 per server – which is very similar to Rift’s 2k PCU/server.

According to Simutronics (the maker of HeroEngine – the engine used by Bioware to create SWTOR), a single HeroEngine server shard can theoretically support up to 100k concurrent users.  The HeroEngine Wiki provides an example of up to ~300 people per area map, and this is consistent with the observed player thread (and what I personally saw when I had time for SWTOR).  The engine developers go to some lengths to explain that proper game design has a strong effect on your hardware requirements and total scalability.  At some point, the suggested solution is to make the map smaller or instance it.  SWTOR went for instancing, so we can reasonably expect 150-200 people to be about as many people as could be involved in a major PVP engagement.  According to Taugrim the largest engagement he’s been in was 60-70 people with what he termed as “high lag”.

Eve Online

Eve Online has well published concurrent users by way of eve-offline.  I’ve gone over the rolling average for concurrent users in several other posts, but I’ll belabor the point once more since most of my previous posts focused on the rolling average for concurrent users.  Obviously the health metrics of the game itself is improving after the disaster that was Incarna.  But that doesn’t have much to do with today’s topic of conversation: PCU.  The peak concurrent users for Eve Online by Eve-Offline during February was 51748, and its all-time PCU was 60453 during Alliance Tournament 8.

Here’s Eve Online’s PCU for the last several months:

  • “2011-06-05 17:34:00” 49232
  • “2011-07-31 19:32:00” 48813
  • “2011-08-07 18:47:00” 49281
  • “2011-09-05 19:10:00” 48074
  • “2011-10-16 20:11:00” 45487
  • “2011-11-06 20:15:00” 44527
  • “2011-12-11 20:13:00” 48759
  • “2012-01-29 18:59:00” 50356

According to CCP Veritas (dev blog) there were > 1350 players in a single PVP engagement and Time Dilation kept the module response time for under one second.  Of course, just because module response time was low doesn’t mean that things were proceeding quickly, and Time Dilation scaled apparent time down to somewhere between 10-30% for a couple hours while the battle raged.  Jita (the primary market hub) regularly houses more than 1700 active players and I’ve put in a request for CCP Diagoras to see if he can give us Jita PCU numbers for the last several months.

As to the architecture of the game, I think its reasonably well known that each system (area) runs on a single thread on a server.  On the flip side, the server operates in a 1 Hz cycle which would be absolutely unacceptable in games like Rift and SWTOR.  Furthermore, players are assumed to continue moving in Eve Online as opposed to other MMOs where players have to hold a key to continue moving.

These kinds of design differences really emphasize what the HeroEngine wiki was trying to tell us: game design matters for scalability.

Filed under: Eve, Game Design, Gaming, Rift, SWTOR, , , , , , , ,