[MUD-Dev] Custom Client or Plain ole' Telnet?

[Matt Chatterley]

On 21/09/05, Pandora <pubsynx7hye at pacbell.net> wrote:
> Matt Chatterley wrote:

>> Simply put - do I go with a custom client, or implement a telnet
>> interface?

> You might go with a custom client, but implement it by an open
> standards protocol.  There's a few good proposals going around for
> making a specialized protocol for MU* clients and online text
> adventure games specifically, not just generic Telnet.

>  http://www.zuggsoft.com/zmud/mxp.htm
>  http://www.belfry.com/fuzzball/trebuchet/mcp.html

This is an excellent idea - I hadn't considered this (although
Pueblo has also been mentioned). I'll check these out for sure -
although I suspect they'll be aimed more at delivery of graphics and
sound - whereas "layout" of information is more what I'm after
(although probably achievable with one of these) - if not, as you
also suggested, I could implement a protocol and publish the
standard so that anyone who wants to create a client could
potentially do so.

>> The main disadvantage is that this restricts me to a text-only
>> set of input/output streams.

> One of the biggest disadvantage of using graphics in your online
> game is your bandwidth requirement suddenly jumps up by a factor
> of 10 or more.  A written alphabet is the most efficient
> compression algorithm _ever_ created.  It takes words and phrases
> with many layers of meaning, and tons of information, and
> compresses them down to such a small sequence of symbols.  gzip,
> bzip2,LRW, nothing comes close to the compression that is words ->
> ASCII text.

Granted - very eloquent way to put this too ;) I prefer descriptive
text for rooms and objects because if well written, it's more
meaningful (and far more emotive) than an image - my intent here
isn't to create a graphical mud (partly because I can't draw for
toffee, and partly because I personally find that text based games
hold my attention better!).

>> So, are the 'bells and whistles' worth the extra work creating a
>> good quality, stable client, and the limitation that it will not
>> be available for all platforms (currently planning to implement
>> the project in .NET, therefore aiming at windows, possibly Linux,

> I would implement it in python if I were you.

>  http://www.python.org http://www.pygame.org

> But that's just my 2gil perhaps.  .NET is highly overrated.

Yeah, possibly - however, the hidden motive here is to force myself
to work on a large scale project using the .NET framework, since I
will soon be working with it as part of my day job, and I want to
learn as much as possible first.

Plus my storage engine of choice is SQL Server (because I'm aiming
for full persistancy, and already know MSSQL inside out from work -
therefore it's the quickest RDBMS for me to develop on in my scant
spare time) - and .NET is the obvious (will grant not necessarily
best) choice for interfacing to it.

That said, there is no reason at all to force the client to be
written in the same language as the server..

> As for whether the 'bells and whistles' are worth it, you should
> include in your game (and any client you write) exactly what you
> need to convey your artistic vision to the gamer.  No more, no
> less.  If you want an occasional sound to play, or a graphical
> map, that should be pretty trivial to implement.  If you do it
> well, even people without your fancy client will be able to
> manually use whatever information is displayed.

True - in a game with audio/graphic elements, I always thought that
webpages could be used to supplement the experience for telnet
users.

>> Players would also have to download and install the program -
>> does this prevent people from playing?

> Uh... nnno.  It should be fine. Anyone who can't download it from
> you, can either download a copy from their friends, or trade
> CD/DVDs burned with it.

I was thinking more of people playing from University labs, etc - or
is this a thing of the past (last time I really worked on a Mud was
probably in '98/99) ;)

>>   Strategic Combat View - where are opponents and allies relative
>>   to your ava=3Dar?

> Aka the 'scan' command of MUD infamy.  :) It might be useful, even
> essential.  Do we have any reason to know where our opponents and
> allies are, say if it were a covert ops themed game?

Yes, players will indeed! One of the key elements I am keen to push
forward in terms of game play is the concept that PC are the
"heroes" (and possibly villains) of the world - larger scale combat
is going to be quite common; both from the POV of PC's controlling a
small army, and group combat.

If you consider a case where two PCs are attacked by a group of 12
goblins, and one of the PCs has a longbow, while the other has a
broadsword, their positioning relative to the enemy (plus how
far/quickly the enemy is able to move) is going to determine how
many shots the bowman can get off before he is forced to engage in
hand-to-hand combat. Meanwhile, if the swordsman is fully
surrounded, he is going to have problems defending against attacks
from behind if he's fighting to the front as well..

Also important for spellcasters, who will want to make sure their
"exploding circle of painfulness" spell doesn't catch any of their
friends in it's blast radius..

>>   Map View of wilderness areas - "Normal" Mud type areas exist as
>>   points in a wider countryside/wilderness area which must be
>>   traversed.

> Ah the famous world map.  You can if you want.  Many MUDs do this,
> by building their MUD and also drawing a map that is posted on
> their website, with the approximate city, dungeon, etc. locations
> aligned geographically.  Traversals are mostly annoyances to the
> player and don't have any real game value, but certain things like
> trading games, or shipping games, might depend on the player
> choosing the best route to be successful.

Aye. I want to tie this in a bit more by adding a few extras (the
idea of dynamic areas, originally called 'dspace' is one I ran
accross ages ago - always felt it had potential but was frequently
abused).

  1. Traversal by commands akin to map navigations (e.g. input where
  you want to go and wait. If nothing happens, you will arrive as
  fast as your character can get there). No need to type 'north' 600
  times.

  2. Mounts and vehicles. Ride on a horse, travel by cart or coach
  (much quicker than walking), or even fly if you can find a
  suitable steed or vehicle (magic carpets, anyone?)

  3. Random encounters - akin to D&D's random encounter system; you
  may be attacked by monsters or characters native to the region
  through which you are travelling, or by a band of roaming
  thieves. Encounters could also be more peaceful - encountering
  NPCs who have suffered a misfortune, etc.

  4. Trade routes - trading routes between cities will be
  predetermined (although a cart of sugar from A to B will not
  always go EXACTLY the same way), and it might be possible to
  intercept these merchants..

  5. Exploration - in some areas, you may find things just as
  interesting as the 'dungeons' out in the wilderness; especially if
  you're looking for a rare plant or herb.

  6. Construction - If you have the money and the manpower, nothing
  is going to prevent you from establishing your own settlement or
  territory..

>>   Point'n'Click inventory

> Overrated.  I like being able to type 'hit troll with sword' or
> 'grab sword' and can do it faster than I can click on a sword,
> start to drag, lose the button, go back and click on it, start to
> drag, can't align it properly over the hand icon, let go it zips
> back to inventory, drag it again--oops I died.

Me too. But I suspect not everyone feels the same. Turn-based combat
(requring a 'timeout' to elapse or a 'i have finished my turn'
command to be entered) does alleviate the need to enter commands at
lightning speed, though.

I definitely want a sort of visual interface for the 'magic spell
design' component of the game, for spell casters, though. Also
'dungeon design' will be handled in a similar way, with a visual,
physical map allowing the various attributes of objects to be edited
directly.

> What you most need to focus on are those damnable HUD displays
> that people have to tolerate on MUDs.  You get in combat, and
> suddenly informational messages are scrolling by at breakneck
> speed, some of them repetitive status updates.  If you could turn
> that into some sort of combat summary window, that updated in
> realtime, and allowed you to replace old info with new info
> instead of just scrolling it up, then I'd be very interested in
> what you did.

Hmm. This I need to contemplate. It's a very good idea - rather than
the old 'floating bar' at the bottom of the main window, a sort of
'status report' could be maintained elsewhere...

Cheers,

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