We created a multi-player rpg for mobile phones at startup weekend a few year ago. It actually did ok and it was growing pretty quickly. I hosted it on AppEngine to start and the resources just started going sky high. Players were initiating an attack at least once per second (not to mention all of the other server calls like messaging, weapon purchasing, scanning to see who is in your area).
I thought we were going to have to reengineer in order to try and make it as efficient as possible. The thing is, these addictive multi-player games that are all about throwing data back and forth end up taking huge amounts of resources.
That'd be great if you could elaborate a bit on how appengine wasn't fit or too expensive for your use case? Was performance an issue, or just costs? Thanks.
There were some issues with a high number of writes, but it has got better.
The unscheduled downtime also killed us.
But really, it was just the sheer amount of traffic. Real-time multi-player games that people have with them all the time can just create a ton of requests.
7000 users/server is actually pretty high for an MMO, though I don't know how Zynga's MMOs compare to something like World of Warcraft in terms of server resources needed. The numbers being floated around for World of Warcraft are around 75,000 cores for 10m subscribers, or about 133 subscribers per core. Obviously those aren't single-core servers, but it's still under 1k per server. Of course this and the Zynga numbers are also both subscriber numbers, not peak player numbers, and I'm not sure how play frequency/duration differs between the two companies' userbases.
Some MMO designers actually really want to bring that number even lower, though lots of other people at game companies are looking at ways to pack more users on each core. But from a designer's perspective, if you typically get less than 1/50 of a CPU slice per user, maybe 1/100, and much of that is taken up by doing basic bookkeeping, it's hard to put in things that even 1990s RPGs took for granted, like NPCs with at least passably interesting AI.
Could you point out a WoW mechanic that is actually taxing? From what I understand, WoW AI is a height agnostic beeline and battles are heavily scripted at best. The tricky part seems to be the real-time player interaction a.k.a 3d chatroom, which has nothing to do with game mechanics (e.g., IMVU).
Many standard rpg mechanics in a large, seamless, 3d world full of both NPCs and players can tax resources.
Movement is one already mentioned, but in general, AI isn't only turned on in combat. NPCs move outside of combat - most creatures in the world wander about or follow a pre-defined path. I don't recall if they did on WoW, but I know in Everquest creatures used spells of their class both in and out of combat, such as buffs and heals - a creature in Everquest would even heal and buff up their allies. If monsters are buffing, you now are tracking those buffs & their durations - when we added monsters buffing to our multiplayer game, we made them infinite in duration to get acceptable performance.
Another operation that could be taxing is calculating line of sight (LOS) - this factors into any action an NPC or player would do. You can't have monsters attacking players, or buffing allies, through walls.
The problems movement incurs aren't "game mechanics" so much as "3d chatroom mechanics".
Buff tracking as a performance hit is surprising to me, though. I'd presume you were tracking monster lifespan - with this and an offset for 'AI interruptions' (like for chasing players as the buff wore off) you could recover the buff times and remaining durations without touching the monsters when they were out of player LOS. I can see LOS as a more taxing system, but monster LOS has no z-axis and the dungeons don't seem to require too many nodes for a pathing graph...
At any rate, most MMOs have rather... shallow... gameplay mechanics, and I don't think it's really computation that's holding them back.
The easiest mechanic to point out is movement, and the synchronization of movement. At every step in the game, I'm moving along what would traditionally be game tiles, in a given orientation at a given velocity. While the 'world' is rendered around me on my PC, the movement and orientation changes all have to be upstreamed to the server and calculated for normalcy (to detect speed hacks, cheats, mountain climbing, etc).
One key difference may be the sheer amount of metrics that Zynga tracks. I've heard they keep stats of every (however mundane) action each user performs. It racks up to a huge amount of data.
We develop casual MMOs (think Club Penguin). These are not nearly as complex as a WOW, much closer to Farmville. In our case, like most MMOs, nearly all our messages go back and forth over persistent socket connections, not HTTP requests. Firewalls cause problems and often block persistent connections, but we can get a much much better through put.
For example, we developed a product for Turner on top of our platform. Take a worst case scenario - everyone in the game moves using arrow keys, and they're all moving. A typical room might have 25 people, each broadcasting their location roughly every 0.5 seconds. This location update is broadcast to all 24 other people in the room. So each person generates 2 messages into the server per second, but results in 48 broadcast messages per second. Of course there are 25 people in the room, all of whom are moving. So we have 2 x 25 = 50 messages into the server per second, and 48 x 25 = 1200 out going messages per second.
A typical node of our platform might support 4000 players. If each room supports 25 people then we have 160 rooms. Every second the server needs to broadcast 1200 x 160 = 192,000 or nearly 200,000 messages, and receives close to 8000 messages.
Movement packets are easy. We can route these through the system quickly, but then think about the "slow" requests, such as writes to the game state persistence store (Mongo DB) or slower still, writes to the SQL database.
With 8000 incoming messages, and a typical 64 thread processing pool each thread needs to churn through 125 messages per second. Or one message every 0.008 seconds. Those slow SQL writes might take 0.5 second, during which time 0.5/0.008 = 62 messages have backed up.
Many of our games (and im inferring Zynga's) store huge amounts of persistence / state data. Where has the player been, whats completed, timers, friends, etc, etc. Much more than you'd imagine - and thats not including the analytics data. These slower writes very quickly add up and reduce throughput.
Of course there are lots of things to optimise the number of messages, but this starts to give an idea for how quickly messages back up in a MMO type environment.
"...it takes roughly 20,000 computer systems, over a petabyte of storage, and over 4600 people. Using multiple data centers around the world, this works out to a total of 13,250 server blades, 75,000 CPU cores, and 112.5 terabytes of blade RAM."
It doesn't say if that's total or just US (since WoW is hosted by different partners in Asia, last I paid any attention).
1. The servers aren't all application servers. There's load balancers, memcache servers, lossy memcache servers, etc.
2. It's the cloud. It includes large instances, HA-Proxies, memcache servers, etc.
3. There's very high write characteristics for social gaming's data store, but the read is similar to normal web application.
4. He took an aggregate server #, and generalized it over a period of 30 weeks. It's directionally accurate, but I wouldn't take it literally.
"Up to 1000 servers per week" could simply mean that, there was this one week where they added 1000 servers. I'm pretty sure it's spin. We don't know what they're adding on average each week.
Apparently this are 1,000 ec2 instances not real servers. This changes a lot of things.
Btw how is it possible that 10 or 20 years ago using megaflops or MIPS (or other sane measures of computer power) was normal and now we are here talking about "servers"? :)
Edit: I'm searching around the internet if there is some new general measure of computer power that is able to reflect the real-world performance in non scientific applications. No luck so far.
1000 new servers a week is a ridiculous number for this sort of company. Their code must be really, really bad. Anyone who works there care to chime in? Is it all written in ColdFusion or something?
When Zynga launches a new game, they can get over 1M new DAILY players on that game within the first week. [1]
For their games, it seems that 7% of daily players are online at any given time. [2]
So within the first week of launch, you have, about 100,000 people playing, simultaneously.
Let's say the client is sending 5 requests per second to the game server. And let's say that this week, all 1000 servers went to the new game.
Now, of course that's just an AVERAGE across the day. In reality, there will be a cresting factor, like any distributed system, and sometimes the load will spike, say, 8x.
Is it ridiculous for a single server to process 500 requests per second on average and 4000 requests per second peak? That seems pretty standard by my book.
An average of 5 requests per second from a casual game's client is a sign of a poor design. Realistically you very close to 1 user action = 1 request. Now, a top tier starcraft micromanager may average pull 300 actions per (ed: minute), but an average user should be somewhere around 1 action per second to 6 actions a minute.
PS: The key to pulling this off is running the same simulation on the client using the same random seed.
User clicks attack blob with fork. > Client says: attacked blob at (timestamp, with fork) > Server says: blob took X damage at (timestamp) random seed at (value) > Client shows: A long string of actions that adds up to that value and or requests a new game state if something does not add up.
You're right. I had the Starcraft 300 action/minute metric in my head, and I've definitely seen Farmville players at that level, but the average is probably much closer to 60 actions/minute.
My original point was less about the actual numbers, and more about the exercise of estimating server load, instead of just blindly declaring that they must have crappy code.
100'000 people playing simultaneously adds up to say about 10'000 requests per second. Farmville-like games are not exactly rocket science - most of those requests should be processed sub-50ms total cpu-actual-usage time. that's 200 requests/s per server. Which adds up to 50 servers. Let's double that to account for db load too, and we're still an order of magnitude away from 1000 servers.
So each player generates a request every 10 seconds? Sorry, but that's way off. Every time they click, at least, generates a request. And then there's the famous Zynga tracking. There's no way it averages to less than a request a second.
And you really think those 100'000 are actively clicking around all the time? There are no doubt spurts of activity where they do one, even two clicks per second (most of which should not result in backend queries... surely Zynga has already implemented some kind of queuing mechanism to send those usage data in batches, rather than one by one). Most of the time, though, the users are most likely sitting there watching their crops grow - or even have another window open so they can pretend to work.
Note that it's not 1000 servers every week, it's up to 1000 servers in a given week. This was likely done to support the launch of a new game, and may factor in server turnover (they're on EC2).
That being said, launching 1000 nodes for non-batch jobs is still pretty remarkable.
Zynga can have absolutely crazy growth on launch. FarmVille was growing few million users a week.
Also keep in mind interactive multiplayer games with persistent state are different beasts compared to usual web applications. Games are very write heavy and do not cache well.
Zynga uses Apache PHP on the front end, memcached for active user play and MySQL on the back end. It uses memcached to store key value pairs to deal with active user play during sessions and then later writes it to disk.
I'm obviously asking the wrong person, but if they use memcached as a temporary datastore until another process can come along later and write the data to disk, what do they do if a memcache node fails?
Or would a node fail rare enough for the data loss to not matter much?
Zynga has acquired a bunch of different game studios. While I'm sure they've tried to retrofit the acquired games to better architectures, they probably weren't designed with scalability or efficiency in mind from the beginning.
Anyone else think this is a sad use of both human and computing resources? Technically interesting, yes, but all of that for playing freaking farmville?
Farmville is a perfect example of the self-actualization tier of Maslow's Hierarchy of Needs. [1]
The people playing Farmville are enjoying themselves and expressing themselves. Would it be better if they deployed that cognitive surplus and attention towards Wikipedia or a similar project? Of course.
But it doesn't make me sad that there are 215 million people in the world who have a comfortable enough life that they can afford to dabble in some casual games. In fact, I hope that in 100 years we can have all 7+ billion humans striving for self-actualization instead of food and water.
That doesn't suprise me, I was running a network for 150 computers while in college and one of the computers was always doing a crazy amount of download and upload (order of gigabyte a day). Our IDS flagged it and I started investigating what was going on. I finally figured out that the users was using a flash game site. I couldn't believe a darn stupid game could cause that much traffic but we asked the person to stop for a day and it was exactly that.
You'd think this stuff could be pretty efficient if done right, defer as much as possible to the flash application. I guess security is an issue if you do to much processing the the flash, probably a lot of servers to just to serve the flash.
If the flash is not changed very often why not a CDN for the flash delivery and then have the flash poll their servers with the farming actions, ect....
I'm sure they use a CDN for delivery of the flash assets. The flash is still most likely updated several times a day.
We used to batch commands in the client and submit every 6 seconds. It was still a crazy number of writes, because basically every click is a database update. MySQL is really bad at that sort of work load, but I migrated almost everything to Redis. Really fun problems to solve!
1000 servers per week number is not just realistic. I will like to believe the author misspoke otherwise it will take more that Zynga employees just to configure 1000 servers in a week time.
That's a question I'd like the answer to. A normal customer is limited to 20 on-demand or reserved instances per region. Could anyone request to have that limit raised to 1000 per week?
I read this and thought what a waste of electricity. Putting all those processors to work on folding proteins would have brought about so much more social good.
We created a multi-player rpg for mobile phones at startup weekend a few year ago. It actually did ok and it was growing pretty quickly. I hosted it on AppEngine to start and the resources just started going sky high. Players were initiating an attack at least once per second (not to mention all of the other server calls like messaging, weapon purchasing, scanning to see who is in your area).
I thought we were going to have to reengineer in order to try and make it as efficient as possible. The thing is, these addictive multi-player games that are all about throwing data back and forth end up taking huge amounts of resources.
We eventually ditched the game, but the site is still up at http://killyourneighbor.com