[MUD-Dev] Re: Why did it take years?

[Adam Wiggins]

On Tue, 27 Oct 1998, Cynbe ru Taren wrote:
> Ola Fosheim <olag at ifi.uio.no> asks:
> | Yes, and that leads to another question, why did it take years?
> 
> Which is a very fair question.

And has been asked many a time before.  No one, even other programmers,
seem to realize the amount of time and effort that goes into a release
product, even if the product isn't especially groundbreaking.

>  * A typical industry estimate seems to be 20 lines of code per
>    day per programmer:

Wow!  I had no idea how efficient I am!  I write at *least* 30 lines
of code per day! :)

>     bnm.t   5140        Big integers.

I presume this is BigNum stuff, eg an arbitrarily sized array of
integers which can be operated on as one big number.
Why do you need this for Muq, might I ask?

>     job.t  33893        Implementations of various bytecodes.

Internal language is always a big one.  This is probably why
stock diku manages to do lots of stuff with pretty line-inefficient
code, and still end up a lean 30k lines or so.  No internal language.

> As Fred Brooks comments in the Mythical Man Month, it's the tarpit
> that gets to you:  It's not that any one part is hard, but that you
> have to do -all- of them...

Yes!  The main thing that seems to happen on a project that drags it
down is *not* people not working.  It's failing to account for the
sheer amount of /stuff/ that goes into a usable product.

A simple task breakdown can show where all your time goes, but at the
end you're still left wondering, "Gee, why did that take so long?"

For example, let's say Bubba writes an RFC-compliant telnet module
in one month (in his spare time).  Seem reasonable?  Okay, then
he takes another month to do the basic world DB.  Another month does
characters.  Another month does rooms, and basic character motion.
Another month to do socials.  Another month to do object interaction
and equipment (wear/wield/..).  Another month to do immortal commands.
Another month to do experience, gold, and levels.  Another month to
do zones and reset/repop.  Another month to do some basic skills.
Another month to do some basic spells.  A last month to beta test.

Congradulations, Bubba!  You've just spent a year of your life writing
a really bare-bones version of CircleMUD.

Was Bubba not being productive, not working hard enough?  Hardly.
By all accounts, if he did all of the above in his spare time, he
worked very fast and very efficiently.  So why, after investing a year
of his life, is he left with something most of us would scoff at (and
it's still not playable, there's no areas!).

Moral: it takes a long time to do anything like this.  It takes a REALLY
long time to do anything *good*.  This is assuming, of course, that nothing
really bad happens along the way to slow you down...

> Muq total: 200,000 lines

Sounds reasonable.
Does this include your world, eg rooms and mobiles and whatnot?
There's more than 'pure' source to a game.

> DevMUD seems to me to be contemplating addressing a fair number of
> difficult problems which Muq does not: With Muq, I've deliberately
> tried to avoid doing anything terribly exotic, in favor of shipping
> something solid relatively soon: If using Muq as an estimation base,
> you may want to add (say) a *2 multiplier on for extra code required,
> and another *2 for extra coding effort to break new ground rather than
> following pretty familiar coding trails?  If so, that would put you at
> about 24 person-years to completion, it would seem, assuming no time
> lost to defections or bickering.

My guess it that the first release of DevMUD will be pretty bad as a mud
goes (ie, very few commands and whatnot).  The idea being that from *there*,
someone could take it and turn it into a real, playable game.  Making a good
engine is not the same task as making a good game.

> (PS:  I did a quick count of the number of source lines in
> Golgotha:  About 250,000.

I quick wc -l on *.{cc,hh} shows 194976 total lines.
The breakdown is like so:

2500 lines for their make tool.

8000 lines of max tools and plugins (don't get me started about
      this - I've had to write more plugins to fix bugs in 3dsmax
      in the past few years than I care to recall)

25000 lines of render code (includes dx5 and glide support)

6500 lines of test (example) programs

Their 'i4' library - utilities used by the game (86k total):
30000 lines (!) of loaders, most of which is jpg and mp3
11000 lines of internal widget library
11000 lines of FMV display (includes versions for Glide, the Saturn,
       Mac sprokets, Win32, OpenGL, Linux svgalib, and X11)
5000 lines of lisp interpreter/compiler
4000 lines of sound code (supports both directsound and /dev/audio)
4500 lines of "device" code (mouse, keyboard, system timer, etc)
4500 lines of file access code (mac, win32, Linux, Saturn)
700 lines of threading code (Linux, Saturn, win32)
1700 lines of string code
2000 lines of memory management
2000 lines of math (angle, vector, matrix, spline..)
~10000 lines of other random stuff including quantization, status control,
      error logging, checksum, compression, dll control, font draw, etc

The actual game itself (68k total):
13000 for the editor
23000 for game objects (specific vehicles, weapons, effects, props..)
32000 for everything else, including maps, levels, character states,
      frontend, savegames, networking, control, etc etc etc


It seems to me that much of i4 is superfluous.  I hate full motion
video anyways, so I'd be more than happy to chop 40k lines of mp3
playback code.  Other than that it's all pretty important stuff,
so 46k of just client libraries seems reasonable.

As for the game itself - it's hard to judge.  A client is a little different
from a full-fledged game in that it probably doesn't need quite as much
stuff.  Rather than simulating the game world, it only has to respond to
commands from the server about what to put on the screen, and where.

Still, I'd guess that other than the FMV stuff, the max tools, and
the test crap, you need everything else in the client.  That's
40k for the i4, 25k for the renderer, and (let's say) 35k for the
game.  100k lines of code, which sounds about right.

Revenant (at least at the time I left Cinematix) was already 100,000
lines of code, not counting support stuff (including 3dsmax plugins,
resource compilers, and other assorted crap).  I wrote most of
that code in the space of 1.5 years of very hard work.  (To be fair,
about 20,000 lines of it was assembly language, which racks up
the line count VERY quickly since each single line does a whole lot less.)

Even so, it was still missing a lot of major game framework stuff.
And it was FAR from a robust game; the physics and object interactions
were very basic, the skills and spells not well fleshed out, and the
network code was nonexistent (but planned "real soon now").

>   On a quick scan, I see very little overlap between what the Muq
> server does and what Golgotha does, so if you want an all-out
> programmable distributed multimedia virtual world server/client, a
> good quick estimate come from summing them: About 350,000 lines of
> hardcode source and 500,000 total lines by the time you have a really
> impressive softcode layer on top of it.

Yes, which makes stealing Golgotha as the client very attractive.
Obviously a lot of work needs to be done with it, but this could
actually be a seperate project from the server.  Also, the code
seems quite well written and organized, but unfortunately
they insist on a naming sceme that drives me crazy - all lower case,
tons of underscores, and "_class" tacked onto the end of every
class name.

>   This is starting to approach the megaline barrier at which even
> well-funded efforts run by experienced professionals start seeing
> about a 50% failure rate, no...?  Time for a thoughtful pause. :)

Well look at it this way - the other choice is to a) write another
LP clone or b) not do it.  I think an ambitious, but eventually
unsuccessful project would be more fun than either of these.
Of course, you don't see me jumping up to volunteer just yet, now
do you...:)

Adam W.