Seems like there's plenty of room in the MMO industry, if most of them are this bad. Is there some sort of pathological psychology that's involved with wanting to make your own little world that works for bad group dynamics in MMO dev teams?
The canonical book is Richard Bartle's Designing Virtual Worlds. The first essay is from him, and a classic known by all MMO developers. The next three are an academic essay by Bartle on virtual economies, and a two-part essay by Radu Privantu on the day-to-day practicalities. The last is also by Privantu, a ~5000 word post mortem on the genesis, growth and maturity of Eternal Lands, a simple but moderately successful fantasy MUD.
There's about a full day's worth of reading here (or two if you read it carefully), but it will pay for itself many times over if you are ever thinking seriously of starting or joining the dev team of an MMO.
Many of the lessons therein could easily be extrapolated to other online contexts, especially those built around a persistent social model.
Thankfully I've never worked on an MMO, but "AAA" console games are bad enough. My take on the issue is similar to that in the article: management sucks. These are usually well-meaning people, but as they say the road to hell is paved with good intentions.
As far as I can tell there's a vicious cycle going on in the game industry: they won't hire people who don't love games and aren't in it because they are super-passionate about making games. I'm not saying you shouldn't love your job. I'm saying there's too strong a bias towards love of games in favour of actual ability in hiring. Outsiders "wouldn't understand the business", after all.
Personally, I've always cared more about the tech than anything else. I didn't go into the industry because I wanted to design games, I just love the technical challenges. I do also very much enjoy playing games, but the activities are completely separate for me, the fact that they both involve games is more coincidental than anything else. I guess I managed to get past the interview stage due to that coincidence or because I knew what to say. For better or worse, it probably afforded me a different perspective than many other people "on the inside".
In any case, I soon noticed there were few people like me in the industry. It's no coincidence the creative director is the one everyone looks up to. They all want his job. They don't really want to be managing hordes of programmers, artists, level designers and testers. They don't want to be hacking away at the guts of the AI. Working on iterating continuously on just 1 or 2 levels for the duration of 2-3 years, again and again, is just one step along the way. After all, they could still be stuck in QA like their friends, playing the same game every day for 2-3 years. But soon, they'll be designing their own games!
If you think hiring great programmers is hard and unquantifiable, try hiring game designers. By the time you can tell if they're any good they'll have scaled the ranks and be the object of worship somewhere and who's going to give that up or given up and left the industry. So the main selection criterion is persistence despite terrible working conditions. It's not a big step to plain delusion. So either they really really love what they're doing, or they're not skilled/talented enough to do similar work in an industry that pays more and treats them better.
Now, to get back to the point: who are these people managing development teams and large studios? They seem to be people who stuck around for long enough but weren't awesome enough at whatever they were doing to become creative director, technical director, whatever. They're not doing this because they love managing people. They're doing this because they want to be creative director, or because they're stuck. Worst of all, they don't seem to want to run a business. I know people always complain that big business gets in the way of making great games. I call bullshit. Not living in the real (business) world gets in the way of making great games.
There are exceptions, of course, as always. As far as I can tell, few companies encourage that kind of culture, though.
(FWIW, I still do game programming, but only as a contractor, for small companies, and only about 50% of the time in order to preserve my sanity)
"As far as I can tell there's a vicious cycle going on in the game industry: they won't hire people who don't love games and aren't in it because they are super-passionate about making games."
That's funny. The CS program at my school is filled with people who want to work in the game industry because they love games. I have the same reaction as you--just because playing games is fun doesn't imply making games is fun, and vice versa. Someone might loathe actually playing a game but have a real fun time writing the AI for it.
My point exactly. The majority of them are probably learning to program purely as a means to an end. They don't really care about the tech, they just know that if you're smart enough to be a good-enough programmer, it's the easiest way into the industry. (there is often a certain mystique associated with breaking into the game industry. As a decent C or C++ programmer it's really not very hard at all)
In school I started calling that CS student demographic "gamer scum", and the term gained some currency among my friends and coworkers/faculty -- students were allowed to work on games for their projects, but they were cajoled and were not expected to succeed.
I do admit to developing a fighting game once as a project, but it was with physical robots!
The noteworthy example of a non-gamer hire is Bobby Kotick, CEO of Activision Blizzard. I've never seen any positive gamer news covering him because of his desire to beat franchises to death with yearly updates.
(As much as gamers claim to despise franchises and sequelmania, it's all the market seems to want.)
I think non-gamer people are a lot more common on the publisher side. Which maybe explains how publishers get away with the massive power imbalance compared to developers. I've never worked for a publisher, just pure development studios, so I can't really comment.
http://www.stackless.com/ stackless python
See in particular the articles about Eve, who co-developed this to produce a non-sharded world (in other words, one that isn't split into virtualized incidences walling players in different 'dungeons' away from each other).
Eve can get away with fudging some of these problems to an extent because it takes place in space and so travel is achieved by use of things like warp gates and hyperspace jumps - you can just fly off into space with normal engines but given the astronomical distances being simulated this isn't practical for actual travel, only for tactical combat advantage (scouting or sniping at enemy ships).
As with a most other online games, players tend to congregate around a central point because of navigational and trade benefits. In Eve's case this is a system called Jita which regularly had 500 ships in one local volume, leading to horrendous lag. Load balancing can become a particular problem and so does client bandwidth since you're suddenly trying to feed everyone 1000 vectors per second.
Having played EVE I would suggest they use shard more than most games, they just let you move from one shard to another. They might call them star systems and let people move between them. And they don't repeat exactly from shard to shard, but that just means the world is filled with the same random quests given out by different NPC's. The point of shards is to limit the number of people in each area and they don't let 5,000 players into the same zone at the same time.
You could do the same thing with a classic MMO by having limited resources in a zone that respawn in real time. It actually a reasonable idea, kill all the gnoll's in that dungeon and they don't respawn. However, it's more fun to for most people to be able to repeat the same dungeon over and over with little effort. You could do the same thing with quick movement between zones but then you get the empty feeling when there are not enough players to fill the world.
It just works better in space, however, awsome random content generation could do the same thing on land.
PS: As to the market's being linked, City of Heroes does the same thing; all shards share the same market.
One thing has been bugging me about Eve lately: why are the "shards" tied to physical locations of all the same granularity?
If you made the unit of player interaction a "shard" this would yield inherent dynamic load balancing.
How about a space game that doesn't have any fixed locations of importance? Have space be huge, mostly desolate, scattered with raw resources. Everything is in terms of "motherships" warping between star systems, occasionally stopping at a system to gather resources. Players would berth their smaller ships aboard the motherships or at stations in the systems. However, everything of importance (resource spawns and quest sites) would only be reachable by hitching a ride aboard a mothership.
Most player ships would only be capable of warps spanning in-system distances. Really wealthy players would be able to buy their own "motherships." Motherships would be invulnerable to attack while in-system, due to the use of the drive fields in a defensive configuration. However, while in-transit between star systems, motherships are subject to "warp-intercept," which is the formation of a warp-bubble or "pocket universe" around the two ships when they get too close to each other in warp-space.
Motherships cannot be destroyed, but they can be captured. To capture a mothership, one needs to mount an attack with player ships and destroy enough of the mothership's defensive fields and guns to allow boarding. Boarding switches the game to an FPS mode, with the object of securing one of the ship's "command centers."
Some NPC motherships will be capturable. However, maintaining control of one of those will require a 24/7 presence. At the point that no players occupy the command center, a NPC mothership will revert to NPC control.
It does feel like shards because of the gates and the relative similarity between galaxies but the fact is that if every inhabitant of the game were to move towards the center they would all eventually converge (assuming the system handled it,) something not possible in true shards.
The game engine still fails if to many people gather in the same area. The game design and zone limts artifically avoid this, but it has nothing to do with stackless python.
What I should have said is each zone runs on a seperate physical server (or part of one) and their innovation is to build a game that let's move across HW systms with little issue.
Note: They use a shared database for some game states, but they don't let any CPU read memory from any other CPU directly. It's a question of system archtecture not language features.
- totally dynamic load balancing on the servers
- cross-game chat at all times
- cross-game market (well, there are multiple regional markets but distance is part of the game mechanic).
