[MUD-Dev] Object and class heirarchies -- are they really necessary?
darius at connect.com.au
Wed Mar 29 10:13:56 New Zealand Daylight Time 2000
>>> Marian Griffith wrote
> On Tue 28 Mar, Kevin Littlejohn wrote:
> I tried to follow this thread, decided that most of it went rather
> over my head but there was one thing I wanted to ask about.
> > It is _very_ handy for being able to change the world physics without
> > restarts - introduce new concepts (like weight, size, etc) on-line, tinker
> > with them, remove them again, without actually disturbing
> > players/builders/visitors.
> I do not understand why this would be so important. Why not simply
> restart the mud after you made some extensive changes? Every other
> mud that I have played had, at some point in time, a test game up,
> that was used for new ideas. If they worked out they were incorpo-
> rated in the actual game, if not, they were discarded. Seems much
> more sensible to me to do things that way.
In the development cycle, it saves a lot of time - being able to throw some
changes in, get people to comment, tweak them slightly, repeat until
happy... without a complete restart cycle. It's nice.
Further on that, tho, one of my goals is to have a proper 24x7 game -
taking the system down for a restart to introduce a new attribute doesn't
fit with that. I'm building the engine so that there's as few "single
points of failure" as possible - the database is probably the key one, and
that's solvable through application of dollars in the worst case ;)
So I guess, for us it's convenience. I like being able to tinker with
things without kicking everyone off. I like that if there's a bug in what
I'm doing, the worst that'll happen is everyone will get "Something bad
happened" messages on everything they do until I tweak the db to set it
right. I dislike the idea that something I could do could cause everyone
to be unceremoniously dumped from the game and unable to log back in until
the engine comes back up.
We'll most probably run a seperate test game eventually, when things are
stable. But in the first development stages, it's nice to be able to
tinker easily. The engine itself is also potentially useful in a lot of
non-mud scenarios, most of which I haven't considered - rule of thumb is to
stay as flexible as possible, in case someone comes up with a use we
haven't considered yet (within reason).
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev