[DGD] Belated return

Dread Quixadhal quixadhal at gmail.com
Wed Feb 11 04:12:08 CET 2015


True enough, although I will dismiss the maintenance cost issue for the
simple reason that a dedicated client is part of your game (or should be).
I think that's the key issue here.  MUD people think of a client as
something extra, something that's not required, and that's exactly
backwards from every successful (online) game out there.

A dedicated client is part of your game, just like your combat code, or
your data storage.  It's the part that runs (or can run) on your players'
machines, but it's every bit as much a part of your game.

But yeah, you're right in that the mud "community" refuses to come to any
kind of agreement on... anything.  It lacks any real authority figures
(most of those who could have filled that role are long gone), and the ease
of grabbing a generic MUD and starting your own band means cohesive teams
are pretty rare these days.

I think the only reason I3 has become the "intermud standard" now is that
the main IMC2 network died a horrible death by politics a few years ago.
Yet, it lumbers on using code from the late 90's...

The zombie version of the Energizer bunny. ;)


On Tue, Feb 10, 2015 at 10:18 AM, <bart at wotf.org> wrote:

> All good points, but you can have pretty much the best of both (or the
> worst
> of both, depending on your POV) by using a web based client, no additional
> software to install for the user, yet enough client-side intelligence for
> redirection and what not.
>
> A significant hurdle for having a dedicated client for what are essentially
> games built by hobbyists in their spare time is it being yet another piece
> of
> software to maintain, introduces some nice versioning and cross-platform
> headaches. This can be addressed partially by creating a client that can be
> used for many muds, but seeing how the 'mud world' can't even seem to
> agree on
> something as simple as intermud chat protocols or a protocol to query the
> status of a mud, I am not going to bet on such a solution.
>
> Bart.
>
> On Tue, 10 Feb 2015 08:04:42 -0500, Dread Quixadhal wrote
> > And there you have your answer.
> >
> > EVERY MMO out there (to my knowledge) uses a client that was built
> > specifically for that game.  Only the MUD community somehow has a problem
> > with this, probably because the old timers among us cling to the raw
> > TCP sockets which happen to work with most TELNET clients.
> >
> > MUD's did not choose to use TELNET because it was the best choice.  They
> > used it because, at that time, it was the simplest and most readily
> > available client, and didn't require the majority of players to install
> > their own software.  Remember, back in those days you couldn't just
> > set up your own machine on the internet.  Most players were students
> > and had limited disk quotas and might not have been allowed to
> > install custom software, even if they had access to it.
> >
> > On Mon, Feb 9, 2015 at 8:16 PM, Blain <blain20 at gmail.com> wrote:
> >
> > > I was just pondering one day how to deal with a connection limit and it
> > > spiraled out of control to wondering how MMO's handle it with their
> > > proprietary client.  I noticed WoW has multiple world servers and the
> > > client handles the disconnecting and reconnecting on its own.  So to
> > > simulate this in a MUD, one would need to tell the MUD client to do it,
> > > thus limiting one to only doing this for players who are using clients
> that
> > > can handle it or creating ones own proprietary client to distribute and
> > > force all users to use.
> > >
> > > On Mon, Feb 9, 2015 at 7:24 AM, <bart at wotf.org> wrote:
> > >
> > > > On Sat, 7 Feb 2015 16:32:46 -0600, Blain
> > > > wrote
> > > > > Geez.  I'd send them an itemized bill and
> > > > demand for just
> > > > > compensation. ;)
> > > > >
> > > > > I was working on my lib again for a bit,
> > > > but got sucked back into finishing
> > > > > up some project reviewing on AA.  I'm
> > > > really enjoying DGD, though I
> > > > > wish I had more time to devote to my
> > > > project.
> > > > >
> > > > > While I've got your attention, I was
> > > > curious if you (or anyone else that
> > > > > might be listening) would know how MMOs
> > > > seem to hand the client's
> > > > > connection off from server to server, or
> > > > do they just tell the
> > > > > client where next to connect, perhaps?  I
> > > > know that some MUD clients
> > > > > can be told to change connection, but I
> > > > was looking for a way to
> > > > > have two or more servers, one for login
> > > > and one or more for game
> > > > > playing, but yet only give out the login
> > > > server for initial
> > > > > connecting.  It seems to me that basic
> > > > telnet cannot handle such
> > > > > redirection without tunneling and thus
> > > > tying up that port on the
> > > > > login server.  I was just pondering this
> > > > one day.
> > > >
> > > > What is it you want to achieve with this?
> > > > Is the main worry the port being
> > > > tied up or would it be load on that
> > > > specific server.
> > > >
> > > > So far, my experience is that server load
> > > > is a much bigger issue, and is
> > > > easily solved by having a dedicated server
> > > > for session handling, and
> > > > 'background' servers for handling the (cpu
> > > > and memory heavy) game logic.
> > > >
> > > > So users always use the 'login server' and
> > > > are 'tunnelled' to the actual game
> > > > server where they belong.
> > > >
> > > > Bart.
> > > > --
> > > > http://www.flickr.com/photos/mrobjective/
> > > > http://www.om-d.org/
> > > >
> > > > ____________________________________________
> > > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > > >
> > > ____________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
>
>
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>



More information about the DGD mailing list