[MUD-Dev] Forks or Frameworks?

Bryce Harrington bryce at neptune.net
Tue Dec 19 22:27:51 CET 2000


On Tue, 19 Dec 2000, Tess Snider wrote:

> Now, WorldForge *is* doing something which was not done in these
> MUDs, though that's mostly because they are text MUDs, and
> WorldForge is targeting graphical games.  That's *media*
> agnosticism.  The server's internal representation of the world is
> divorced from any notion of how the client represents it.  Because
> of this, you can hook up any kind of client that the artists have
> provided media for.  You could, for example, play a game with a
> first-person 3D client, while your friend on the computer next to
> you is playing in sprite-based isometric, if the artists for the
> game provide both kinds of media.  In fact, if you use one of the
> kinds of media that have been provided for your favourite world, you
> can even homebrew your own custom client.

One frequently given comment that I hear is "But how can it be fair??"
There is a perception that 3D is superior to 2D iso, and thus if one
player is stuck using the latter client against someone using the
former, they will be at a disadvantage.  From this logic they conclude
the entire concept of allowing for multiplicity of client types is
flawed.

However this thinking misses the point.  Big time.  Any one of the
following arguments could be made:

I.  If one client is superior, then great! everyone wins.  It's silly
to think we must be fair to the _clients_.  If wide competition causes
one client to be better at combat than all the rest, why then you've
got a damn good client and should be happy.  ;-)

II.  Combat isn't everything.  For the sake of the argument, assume
client A is better than client B during combat situations.  This does
not rule out the possibility that client B is still a worthwhile
combat because it is better suited to building houses, or conversing
with friends.

III.  YMMV.  Not all computers (nor humans) are born equal.  Providing
a variety of types of clients means that the game is not necessarily
always going to go to the kid with the richest daddy.  As an one time
CAD jockey I learned that sometimes, when you know the system super
well, it's fastest to switch out of 3D mode into a Top view, chuck the
mouse, and use the commandline.  I would find it pleasantly ironic to
find that the best players are the ones that eschew the fancy graphics
and plug into the data stream high up.

IV.  Choice!  I know there are a few people out there who are certain
_they_ know what is best for everyone, and are not afraid to dictate
to us how we should do things.  Okay, more than a few; they're a dime
a dozen.  Why deny them their fun?  Without the ability to argue over
simple game clients, we might force these kids to have to look to
organized religion or (worse) have to get one of those useless "life"
thingees.

V.  Fusion power.  One day I expect someone will look at the different
clients available and pick and choose all the best features to
implement an uber-client that has all the best achievements of all of
the clients.  I know, weak argument, but that's why I made it number
five...  ;-)

VI.  Wheel reinvention.  On more than one occasion I've run into a
situation where someone really, really, really wanted to write some
already-existing code.  Why?  Simple: for the pure joy and pleasure of
writing some software.  I suppose one could similarly ask why do yet
another painting of the Golden Gate Bridge.  People will be
reimplementing WorldForge's clients and servers as long as we exist.
And that's fine.  If nothing else, it'll help people gain some new
knowledge, and we forgers love nothing better than helping people
learn.  :-) (Environments where you can gain feedback, encouragement
and criticism, feel like you're doing something meaningful, and have a
variety of programming challenges available to choose from, are quite
rare, and IMHO immensely valuable to future coding gurus.)


--
Bryce Harrington
bryce @ neptune.net

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



More information about the mud-dev-archive mailing list