From Forbes.com (Ordinary Hero) comes a low-down on the success of City of Heroes.
Here is a taste.
Lewis spent $2.5 million of his own money, plus loans of $4.5 million from his distributor, the U.S. arm of South Korea game company NCsoft, to create City of Heroes. NCsoft is spending another $18 million a year to market and operate the game and provide customer support...
In the 18 months before the Heroes debut, Cryptic's staff of 35 made the art and story come alive in 480,000 lines of code. The code is separated into 740 computer instruction files that handle everything from dressing up a character in an almost infinite selection of outfits (a total 10 to the 27th power, in fact) to flying through the city, as well as 25,000 graphics files. At peak hours 30,000 automated villains roam each of ten versions of the city. All the possibilities are managed by 600 2-gigahertz chips (from AMD) in ten servers. They can manage four teraflops, equivalent to the world's biggest supercomputer...
Here was what I was wondering: 480K lines of code, $7 million initial development budget. Based on a software (lines of code) valuation/methodology described here for GNU/Linux, one might believe that for that amount of code one would have seen a development budget of, say $16.8 million ($35/line * 480K), instead of a paltry $7 million.
Hmm those cost estimate assume that each LOC costs a fixed amount, this is wrong. Programmer productivity (ie. LOC/day) goes down as the LOCs go up, although 500KLOC is pretty big.
Posted by: Factory | Oct 09, 2004 at 07:04
The whole idea of assigning a $ value to a line of code is absurd. It makes about as much sense as saying one book is worth more than another based on the number of sentences. Code is not sold by line nor can the worth of an application be judged by the number of lines of code it took to write it or even the cost it took to develop it. Like most everything else an application is worth what people are willing to pay for it which is more a function of how well it performs it's task and how great the need is for the service it provides than how much code was needed to build it.
Posted by: BMiller | Oct 09, 2004 at 15:59
I found the opening line of this story to be flat out wrong, and even contradicted within the article:
"Michael Lewis has the hottest new Internet game, besting the big boys by playing down plasma guns in favor of something more powerful: story."
CoH may be many things but it sure isn't long on story. The article goes on to describe the process in which features and choices were streamlined, and decision points removed.
Michael Lewis and crew were very successful in determining and highlighting the crucially FUN combat elements of gameplay (and also that amazing character creation, a game in itself for my 11 year old). While there is definitely enough story to keep things cohesive and coherent, compared to the ponderous historical baggage heaped on players by almost any other MMO, it is practically spontaneous.
Posted by: BridgetAG | Oct 09, 2004 at 18:18
> The whole idea of assigning a $ value to a line of code is absurd.
Its a metric (e.g. see here), yes an imperfect metric. E.g. hard to compare across different types of applications/ projects. As with all data points, however, they have their uses when considered in the aggregate.
Just a few statistics about MUDS (from here):
CircleMUD:
Code size: 36000 lines of C code.
Crimson2:
Code size: 51,919 lines, 1,727,144 bytes (1.7 Megs) lines of C code
(server only)
Envy:
Code size: 46000 lines of C code.
Missing are labor (or $, as a proxy measure) inputs. But already a few interesting observations. There is a cluster of MUDs at around 50k LOC. What does that mean? Perhaps a "sweet spot" - good balance between features and what MUD teams can manage.
Complexity comparisons. CoH is 10x more complicated than Crimson2?
etc.
Posted by: Nathan Combs | Oct 09, 2004 at 23:25
If a typical MUD is 50 kloc, and COH is 480 kloc, does that mean the remaining 430 KLoc is devoted mostly to graphical eye candy?
Or are COH's physics model (MUD-physics, not newtonian), AI, and other "depth"-producing code significantly better than what's experienced in a typical MUD?
Why is the "depth" part of a VW limited to 50 kloc?
Is it due to UI limitations, where limited computer input devices prevent really complex interaction with the world and diminish the need for more depth? (After all, MMORPGs don't even allow NLP commands like MUDs, preventing the user from attempting many actions.)
Or is it that writing more than 50 kloc of "depth" won't be noticed by the mass market?
Is too much AI a bad thing for players since they won't win as easily?
Posted by: Mike Rozak | Oct 10, 2004 at 01:24
For comparison, code size for MUD1 was:
MUDDL code defining the world: 10,347 lines
Loader code, to parse MUDDL into usable data: 2,723 lines
MUD code, to handle I/O and interpret MUDDL data: 9,580 lines
Total: 22,650 lines
Richard
Posted by: Richard Bartle | Oct 10, 2004 at 06:16
Wow. My first thoughts are that 480K lines of code is not a lot. I've worked on far larger projects. 740 computer instruction files sounds a bit worrying as it implies large, unwieldy translation units (and large, unwieldy objects if translation units are a 1-1 mapping to object definitions).
The cost of each line definitely varies with project size, dramatically. I'm quite happy to author 1000s of lines a day on small projects or in virgin territory, but if what I'm doing touches on lots of sub-systems in a big project, that might drop to 10s a day.
The utility of line counts is debatable, but I think Cryptic have done well keeping the line count down to 480K. Hopefully it means they've kept things simple and that they'll have a far easier maintenence job going forward.
Posted by: Jim Purbrick | Oct 10, 2004 at 07:28
Incidentally, by way of comparison, Achaea (text MUD) is about 350k lines of code, not counting probably an extra 75-100k lines of script in our mobprogging language to control quests/most mob AI and the like or any of the millions of words of text.
I'm not sure comparing Circle or Envy or whatnot to a finished product like CoH is really the way to go. Downloadable codebases are pretty bare bones and are really quite crappy for the most part.
--matt
Posted by: Matt Mihaly | Oct 10, 2004 at 13:21
Check out Jack Emmert, who designed City of Heroes, at Accelerating Change 2004 as he debates Steve Salyer in topic, Real Money in Virtual Economies. Interesting items will be covered along with a tech night too. Other speakers include Will Wright, Cory Ondrejka, Richard Marks, Doug Engelbart and more. It sounds like a conference right up your alley.
Posted by: Jimbob Peltaire | Oct 10, 2004 at 20:35
>If a typical MUD is 50 kloc, and COH is 480 kloc, does
>that mean the remaining 430 KLoc is devoted mostly to
>graphical eye candy?
That's a lot. It takes an astonishing amount of code to handle all of the graphical requirements of MMOs, which we all pretty much have to take on because the visual competition with each other is so fierce. Never mind the features, there's a dizzying amount of code in just getting your game to function on all of the possible hardware configurations there are (despite Microsoft's claims, DirectX requires a lot of handholding to do the job). Also, the tools required to make art and levels to run in said graphics engine can require substantial code and support (Raph has said publically that the first milestone of their entire programming staff on Star Wars Galaxies was just building these tools).
Other stuff we worry about that I don't think most text muds worry about as much: CSR tools, data mining, account server hooks and other professional service requirements. Difficult coding problems like collision and line of sight. Client->server network protocol, and whatever security may protect it. Patchers. And, of course, your 'large world' solution, whether you have a distributed world over many servers like most games do, or run a shard on one giant, honkin' multiproc box, as Shadowbane does. Both add a fair amount of complexity that most hobbyist text muds probably don't have to worry about.
In Shadowbane, the server-side 'game' code that would equate to most of what's on a text mud is probably our simplest and easiest-to-debug code in the game.
Posted by: Damion Schubert | Oct 11, 2004 at 00:45
Damion Schubert wrote That's a lot. It takes an astonishing amount of code to handle all of the graphical requirements of MMOs, which we all pretty much have to take on because the visual competition with each other is so fierce.
I'm not complaining about the size... my graphics, text-to-speech, and sound FX tools/modules for my graphical IF/MUD software take up about 11 mb of .cpp files (about 180 kloc?). The tools include a full 3D modeller, which is a good part of the load.
What intrigues me is that the core components of the game, which are basically what a text-MUD provides, haven't gotten that much more complex over time, and are a much smaller percentage of the overall budget.
For all of their whiz-bang graphics, the underlying physics of fantasy MMORPGs doesn't seem to be that much deeper than what Wizardry (circa 1981) offered. Back in 1981, I would have expected not only improvements in graphics, but also in the physics.
Likewise, AI has improved only marginally; while contemporary AI is certainly better than Wizardry, it's not staggeringly better.
Mass-market programmers are perfectly capable of programming more intricate physics and AI. I wonder why they aren't improved as much as they could be. (Some of the questions from my previous post allude to the answers I expect to hear.)
Posted by: Mike Rozak | Oct 11, 2004 at 01:38
The game mechanics are often even simpler than text MUDs. Think about it: how many different powers are there really in City of Heroes? A lot of this has to do with the limitations of graphics. One of the nice things about text is that, if words can describe it, you can do it. Graphics are a lot more limiting.
Mike Rozak wrote Mass-market programmers are perfectly capable of programming more intricate physics and AI. I wonder why they aren't improved as much as they could be.
AI is one of the most expensive things to deal with, and a hell of a lot of time and manpower is spent dealing with the computation power required by all the mobs needed by an MMO. The problem is the sheer number of AIs that have to be handled, and how they interact with each other. The linked article mentions that a CoH shard has 30K mobs running around at a time. Unfortunately, most of our computation time is spent dealing with pathfinding, collision and line of sight, and ensuring that players don't find a way to cheat. We often have to deal with simplified models on the server in order to keep the CPU costs under control. As such, designers are typically asked to keep other aspects of AI simple.
That's not to say that's how it should be. From a design standpoint, your AI has all of the potential. Your AI in theory is what SHOULD be making combat fun. Somebody is really going to focus on AI, and they're going to do very well, because really, THAT'S what will reinvent the treadmill.
Posted by: Damion Schubert | Oct 11, 2004 at 02:13
"Besides the obvious "an MMOG is not an Operating System" - what else can we say?"
One might conclude that game developers are paid less and work harder than programmers in other sectors. You might call it 'enhanced productivity,' but from what I've seen, it's an exercise in bad management and a systemic abuse of the developer's good spirit.
The money saved might make a production budget seem more attractive, but in reality, it's a debt against future projects re-employing those burned-out veteran programmers. Fortunately for management, there's always more programmers where they came from.
Posted by: Avi Bar-Zeev | Oct 11, 2004 at 09:51
The biggest problem I se with lines of code comparison is the tremendous potential for variance you have when dealing with individual code constructs.
The number of lines of code it takes to do something varies by language, by platform, and by programmer skill.
A piece of code that performs a particular function may be written in ten lines of code in one instance but take over 100 in another. The number of lines is no indication of which one is better nor is it necesraily an accurate indication of complexity.
Short code segments can be the most difficult to work with as they often involve certain syntactical shortcuts that make a few lines contain a great deal of functionality that can be difficult to follow.
There is no guarantee's with long code segments either. Something very long may be very clear, flexible and easy to work with or it may be a hopeless jumble of meandering logic depending on the abilities of the coder who wrote it as well as the abilities of the person attempting to decipher it.
I firmly believe that lines of code is useless as a point of comparison. You have about as much chance of deriving useful information from such observations as you do of determining the best olympic runner by counting the number of freckles on the athlete's nose.
Posted by: BMiller | Oct 11, 2004 at 11:46
Nathan: "Here was what I was wondering... 480K lines of code... $7 million initial development budget... Based on a software (lines of code) valuation/methodology described here for GNU/Linux, one might believe that for that amount of code one would have seen a development budget of, say $16.8 million ($35/line * 480K), instead of a paltry $7 million. Besides the obvious "an MMOG is not an Operating System" - what else can we say?"
Keep in mind cryptic is about 1/3 programmers, 1/3 artists, and 1/3 designers. We're also big fans of code brevity. If you want to use fancy measurements like KLOC/$ the programmers were by far the least productive of the three groups* I suspect the estimated cost per line of code in the article is exaggerated.
* What do you measure artists in? KLOPs! (P for pixel!)
Avi: "The money saved might make a production budget seem more attractive, but in reality, it's a debt against future projects re-employing those burned-out veteran programmers. Fortunately for management, there's always more programmers where they came from."
High productivity implies bad management? That's a pretty negative conclusion from one data point. Uh, by the way, are you looking for work? We seem to be short a few programmers... :) http://www.crypticstudios.com/
Posted by: bruce rogers | Oct 11, 2004 at 16:11
I think the more interesting thing in the article is the account of the point at which the game started to go wrong in its development--the point about simplicity is familiar, but there are some other interesting things, particularly the claim that at its lowest moment, some of the development team were making undocumented changes and pursuing their own agenda.
I suspect *that* point might tell us a lot about how other MMOGs (and other games) have gone wrong, and about what went right in this case--it makes CoH's success seem more interesting than a simple instance of "simplicity in design".
Posted by: Timothy Burke | Oct 11, 2004 at 22:29
Bruce: "High productivity implies bad management? That's a pretty negative conclusion from one data point. Uh, by the way, are you looking for work? We seem to be short a few programmers... :) http://www.crypticstudios.com/"
Funny. I should point out that my opinion comes from watching companies other than crypticstudios. So my data points are many, but no reflection on you.
In a job interview last year, I had to kindly explain to the HR person that their expectation of 80 hour weeks for the last six months of a project was not reasonable or effective.
The way I'd rephrase your characterization of my generalization is that "high productivity never results from bad management, but it can sure seem that way to bad managers."
I'm sure working on CoH would be far more fun than my current gig, but, alas, I'm in NY now. :)
Posted by: Avi Bar-Zeev | Oct 12, 2004 at 23:16
I HATED Sims Online... it was terrible. I am ashamed that i wasted money with it as long as I did.
Posted by: Sheeple | Feb 27, 2006 at 15:43