[MUD-Dev] Object Models

[msew]

At 13:02 11/26/2000 -0500, Travis Casey wrote:

> The usual problem that I've run into with adding things like that in
> muds isn't updating objects that use those components -- it's going
> back and changing everything that's already finished that *should*
> have used those components.

> To use a real example from a mud I worked on -- I added the ability
> for monsters to move along a pre-set path rather than randomly, so
> that guards could actually patrol a perimeter, go back and forth
> from one place to another, etc., without custom coding being
> necessary.  People building new areas used it, but no one wanted to
> do the work of going over all the existing areas, finding everywhere
> that that ability should have been used, and adding the line or two
> to each monster that should use it to make them use it.

The biggest step one can make as a programmer/designer is to
understand that to get the neat thing you just thought of into your
system that has been running and "finished" for a while now, you just
have to spend the N hours and go back and put it in the spots that
need it.

Using various inheritance, prototypes, properties files, etc etc will
help but at some point you will have to do significant rework of your
codebase, adding new content, adding new data to various objects, and
doing grunt work.  Even if you are constantly refactoring your code
and keeping all the older bits up to date, you are still going to have
to spend time to add something similar to the patrol paths. (ie
someone making a decision on various states of an object)

Programmers, as a general rule, despise any such thing.  We want to
just have things work and spending 4 hours typing in patrolStart=434,
patrolEnd=343 or worse listing out every room and having to go and
look at the area data to do this SUCKS.

One of the ways to deal with this is to make better tools.

Instead of making the area designer go into the area, find the rooms,
write down the info (hopefully not making a mistake), edit the file to
add the data (again hope for no mistake), get some admin to reset the
game to have your changes take effect, find the mistakes and repeat
the process all over again.  UGH THAT SUCKS

And certainly this is probably an average case.  Some places have much
better stuff for building and editing perhaps even dynamic where the
area designer can see the changes occur right before their eyes. And
others are editing src code and recompiling.

I am not advocating the uber tool of doom that knows about everything
and never needs to be changed, but instead advocating making tools
PART of the development of the game.  The tools should be just as
important as the graphics engine or the network code.  The tools get
updated as new features are incorporated.  Yes this will slow down the
project at some points but the over all net gain is immense.









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