I'm an MMO hacker that's shipped one unsuccessful game and one moderately successful game, and I have to comment on some points made in this article.
-MMOs fail due to bad management, design
Partially true. All the elements need to be there, and bad technology seems to be the biggest crippling force in games. We need more good hackers in the field.
-Good MMO studios aren't hiring.
Not true, even today.
-MMO studios all have terrible quality of life, pay, benefits.
Not true. Startup studios might, but if you're going into that situation you're either getting profit sharing, or a beginner getting a foot in the door.
-MMO engines don't exist, tech isn't reused.
This is becoming less true, but the third party tech out there is still untested. It's unlikely a great MMO company will sell its tech like Epic does with Unreal, since we need long term customers, and can't afford to undercut ourselves.
-Don't work in games unless you are a gaming fanatic.
Loving gameplay helps if you want to be a gameplay coder, but MMOs are vast. Networking, graphics, AI, scalability, the problems to be solved are endless. If you're bored at your job, I recommend giving the games industry a look.
"There are no MMO engines for sale that can make robust games. They just aren’t any good yet"
That's somewhat surprising to me. There's so many MMOs out there that have failed for one reason or another that you'd think someone would be trying to salvage their sunk costs by selling the engine.
Despite the competitiveness of the MMO market, there are still a lot of companies trying to break in, so you'd think that there'd be a decent sized market for a product which would shave years off of the development time.
I wonder if part of the problem comes from most MMO companies clinging to life for as long as they can, and then not having the money to rework their technology into something suitable for a third party. Certainly, there have been quality(from a technical standpoint, anyways) games that got released, got a few rounds of post launch patching, and then died from lack of users. I'd bet that with a bit of polish, that sort of proven technology would be a moneymaker.
Oh, there are a few such companies. Can't think of the names right now, but I did some research into this over the winter. A big problem is that the asset creation is very expensive, and balancing the economic factors is much easier said than done. If you are interested in this, Richard Bartle, inventor of MUD, is the leading thinker in the field.
The best technical system that I know of is the stackless python one developed for Eve Online, which I believe is profitable but has only about $300k players. Mind you, with that number it's insanely complex already. I had to stop playing, because to do so well requires the same level of commitment as a full time job.
I can imagine that asset creation might easily be as large an expense as building the technology.
However, one of the big killers of MMOs is problems with the launch. With some of these large high profile failures, they've already gone through this and worked out at least some of the bugs, so one would assume that this would make them more attractive to buyers.
Could a viable company be created with the goal of producing and selling an MMO engine, rather than an actual MMO?
You would be removing the expense and risk of creating the gameplay side of things (models, textures, quests etc), and could focus on getting the engine right. There would probably be some issues in selling the engine though: there would be a certain chicken-and-egg factor in selling an unproven engine to a new MMO-building company.
they exist. i work for one. the engine was built as we developed worlds on contracts for clients. once we got it to a certain point, we started licensing it out.
we term it a platform, as its something to build with an upon. all of the projects we've seen require extension and addition to the basic model we've defined to customize it for the project at hand. but we've baked in things that make doing so trivially easy.
Why not use an open source one? I saw a Google tech talk by Keith Fulton, one of the main architects of PlaneShift. He said that although the engine is GPLed, the characters, rules, scenery, etc. are all separate from the main project and can be scripted. So if someone wanted to, they could improve the GPL engine while creating proprietary art and storyline that could then be marketed.
Unfortunately, you can't use GPL or even LGPL licensed code on consoles, and try getting (L)GPL code past your publisher's/investors' lawyers. I had to go through an arduous approval process to be allowed to use zLib in a game.
Most <any industry> companies are "rudderless ships of doomed people."
I'm guessing it's especially true in software - everybody is involved in software nowadays but you can count the number of companies doing software really well on two hands and two feet.
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).
I wonder if the "secure distributed persistent communication" protocol developed by the E folks could be used to implement a virtual world running on a network of clients. I.e., one central server would send a client some model of a room, and the trust layer would prevent that client from moving walls around. (I'm being handwavey here because I'm not familiar with either E or MMOs, but maybe someone else can be inspired by this.)
And, yeah, I have a similarly low opinion of the game industry as this article. Looking at it from the outside I see no reason to be part of it, I'm happier to be a software company that does games rather than a games company. http://push.cx/2009/the-game-industry
-MMOs fail due to bad management, design
Partially true. All the elements need to be there, and bad technology seems to be the biggest crippling force in games. We need more good hackers in the field.
-Good MMO studios aren't hiring.
Not true, even today.
-MMO studios all have terrible quality of life, pay, benefits.
Not true. Startup studios might, but if you're going into that situation you're either getting profit sharing, or a beginner getting a foot in the door.
-MMO engines don't exist, tech isn't reused.
This is becoming less true, but the third party tech out there is still untested. It's unlikely a great MMO company will sell its tech like Epic does with Unreal, since we need long term customers, and can't afford to undercut ourselves.
-Don't work in games unless you are a gaming fanatic.
Loving gameplay helps if you want to be a gameplay coder, but MMOs are vast. Networking, graphics, AI, scalability, the problems to be solved are endless. If you're bored at your job, I recommend giving the games industry a look.