[MUD-Dev] DAoC dev team

[Dave Rickey]

-----Original Message-----
From: Adam Martin <ya_hoo_com at yahoo.com>
> From: "Dave Rickey" <daver at mythicentertainment.com>

>>   1 Producer
>>   2 Network/Infrastructure Specialists (including Darrin Hyrup from
>>     this list)
>>   1 World Dev Lead
>>   3 Full-time Quest Developers
>>   3 Part-time Quest Developers
>>   5 World Developers (terrain, building placement, mob placement,
>>     itemization, etc.)
>>   2 Art Co-Leads
>>   1 Technical Art Specialist
>>   3 Artists
>>   1 Animator

>> And that accounts for everyone at the company except for Mark
>> Jacobs and CS.  Almost all of those wore multiple hats.  If I
>> drew a table of organization, it would look like a plate of
>> spaghetti (at one point, I had 3 "direct" bosses and one
>> "trainee" who was simulataneously my subordinate and that of two
>> of my bosses).  If it didn't work so well, it would be insane.

> First thing - I hope you don't mind me asking the following
> questions, they're intended to be in the same vein as what has
> been said so far so I hope you don't feel there's any commercial
> sensitivity to them. Apologies if they seem too direct/probing -
> in that case please feel free to say "no comment".

> Second thing, if answering the questions is OK, please could you
> send any reply direct to MUD-DEV - I haven't posted this to the
> list because this email in itself doesn't actually contain any
> positive content :).

> Thanks for what you've said so far - very interesting. Just a few
> questions out of interest to help my understanding:

>   - What roughly does the "Producer" do? IME, I've seen this title
>   used to >cover almost as wide a range of actual roles as the
>   term "Manager" :) so its >lost any meaning to me

Ummm..., Lead Cat Herder?  Our producer (Matt Firor) is pretty much
why the chaotic organizational model worked so well, he was the one
at the center of it all keeping track of all the relationships and
dependancies, and coordinating efforts.  He practices what we've
come to call "Verbal Aikido", you go into his office mad enough to
chew nails, and come out not only having forgotten why you were
angry, but vaguely embarassed about it.  ;-)

>   - What kind of tasks does the customer service programmer do? I
>   would have > thought that CS-generated bugs (i.e. things found
>   post-release by customers) > would be handled by the main team,
>   so I'm guessing the CS programmer does > the billing interfaces
>   etc?

The CS programmer (Scott Jennings) wrote the tools for the CS team.
The system implements what outside the game industry is considered
normal customer service tools and integrates them with the game.
Any contact by CS with a customer (email, in-game /appeal, or phone
call) either raises or re-opens a "ticket", which is used to keep a
record of the interaction.  Those tickets are then retained, and in
any future interaction with the customer the CSR can see what the
background is.  His code ties into the billing and account
management software, but is separate from it.  The theory was that
many of the CS created PR problems other games have had were either
the direct result of inadequate tools, or the result of policies
implemented because the tools were inadequate.  He has somewhat
unique experience with such things.

>   - Would it be about right to say that 50% of the team were doing
>   significant > raw *code* development? As opposed to the other
>   50% who were doing any of: > project management, *content*
>   generation (artwork, quest-plots, and >
>   world-maps/world-terrain/world-buildings), or *high-level*
>   development (by > which I'm presuming coding quests in a
>   high-level scripting language).

More like 8 out of the 30, less than 30%.  Most of the team worked
on content development the majority of the time.  A lot of things
that you would think require code are actually the result of
server-side databases (for example, the Trades system involves very
little code, which mostly reads database entries that point it to
other database entries).  We'd usually anticipate a wide range of
possibly desirable structures for game systems, and build the system
to support all of them based on the entries in the database.  The
Trades system, for example, has a basic algorithm for skill
advancement, but each actual recipe can modify factors in that
algorithm to increase or reduce the chance of skill advancement.
This meant that when I was tuning the advancement rates for
tradesmen, I didn't need constant programmer support tweaking and
re-tweaking the algorithm to get the curve I was after.

Basicly, the idea was to implement a flexible system and a minimal
method for turning it into content (at the early stages, this
involved editing server databases by hand from the game console),
which would be used for experiments.  Once we had a good grasp of
how we'd want to use the system, tools would be built to allow
content for the system to be generated quickly.

>   - You didn't mention anyone specifically working on AI -
>   presumably this was > parcelled out among the quest developers -
>   would you say this is more a > result of the PvP focus of DAoC
>   than for any other reason, i.e. would you > normally expect to
>   have dedicated AI personnel?

Our AI was a collaboration between one of the server programmers and
one of the tools programmers, creating a system for the world
builders and quest developers to adapt.  It's not cutting-edge, more
of a flexible state machine with simple script-like functionality.
It can display some fairly complicated behaviour, but can require a
lot of up-front work to do so.  However, it is inherently
extensible, and we expect to build more sophisticated systems on top
of it (which could also be said for most of the rest of the system).

--Dave Rickey

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