[MUD-Dev] MMORPG Comparison (UO, EQ, AC, AO, DAoC)

[Dave Rickey]

-----Original Message-----
From: John Buehler <johnbue at msn.com>
> Dave Rickey writes:

>> For the most part, it's been anti-climactic, we had one bad crash
>> Wednesday night, and beyond that nothing much has happened.
>> Everybody is still crossing their fingers for tonight, we figure
>> if we make it through the weekend we're pretty much solid.

> Is it permitted to ask about your development process?  As in, how
> you went about construction and how you went about verification of
> the system's behavior.

> Was it the classic approach of taking a bunch of talented
> engineers and designers and let them mix it up, make some internal
> demos, come up with specs, code some, refine the specs, discard
> the specs, code it up for real, and then play with it until it
> doesn't appear to crash any more?

Actually, the process was somewhate unique, different both from what
I've seen of other game shops and from my experience with business
software (both commercial and in-house projects).

Everything was a very iterative process, with an emphasis on
incrementalism.  Early discussions were held (usually 3-4 people,
1-2 each of programmers, content developers, management, and
designers, that math doesn't make much sense because most of us wore
multiple hats) for how a given part of the game should/would work,
the minimal code for supporting it was implemented, "proof of
concept" content would be developed using the system, revisions
would be made, etc.  Before serious work on cranking out content was
invested, a tools programmer would be brought in.  The design
document was more a ledger of what we had done than what we intended
to do.

Our QA process was pure blasphemy: Everyone was expected to track
and fix their own bugs.  There was a formal QA manager, whose job
consisted of independantly gathering, collating, and disseminating
bug reports, but he functioned strictly as a backup.  95%+ of the
bugs he documented were fixed before the list was seen by anyone.
We relied *heavily* on beta-tester reports, we don't have a single
"tester" on staff.  Everyone read the beta test bug and discussion
boards related to their area, and fixed their own, only when a
report went to the wrong board would it slip through to be caught
and raised by QA (even then, we usually back-channeled the reports
to each other first).

By most standards, we were very light on programmers, 4 people did
95% of the coding for both the client and the server (3 on each, 2
wore hats on both teams).  3 others concentrated strictly on content
development tools, 1 worked on nothing but the customer service
tools (brought in much later in development).

The tools were really the key to the whole project, along with the
support by the server engine to have all the server-side content and
most of the game mechanics altered on the fly without rebooting the
server.  This allowed for some *extremely* rapid turnarounds from
concept to implementation to revision, correcting bugs at every
stage.  The tools also made fixing bugs a comparatively painless
process, 99% of the time it was possible to use the tools to find
and correct a reported bug in minutes.  Whenever the tool was
inadequate, the tools programmers rewrote it to work better (usually
the same day).

The short turn-around and exceptional stability of the core systems
made bug identification fairly simple in most cases, the personal
responsibility of fixing your own bugs not only reduced the total
number, but put a feedback mechanism on the process (if you
introduced a lot of bugs, you were too busy finding and fixing them
to add more for a while).

In almost every case, decisions were made by small groups of no more
than 5 people, and responsibilities apportioned out so that no more
than 5 worked on any one thing (although which five could be
radically different from one piece of functionality to the next).
Again, this minimized time spent trying to figure out what
colleagues were doing, or which were responsible for what.

"Channels" were completely de-emphasized, if you needed to talk to a
server programmer about how the damage formula for 2-handed weapons
related to the skill of the character in 1 Handed Slashing, you went
to him and asked.  If you didn't know who was responsible for a
piece of functionality, somebody nearby always did.

At every level there was an emphasis on having no more process than
was neccessary, and no less than it took to get it right.  Because
of the way process tends to lead to innefficiencies, I suspect that
if Camelot hadn't been built by a team of 30, it could not have been
built by less than 100.

There were many other parts of the management approach to the
project that were unusual, but it might be unwise for me to discuss
them in public (even positively) without checking with them first.
In general, it was a "Skunk Works" approach, smart people were given
areas of responsibility and told they were being counted on, and
then left alone as much as feasible.

--Dave Rickey

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev