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

[Pandora]

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

That is, if you do make a client that does special things, use the
above protocols, or else make your own and open it so that if
someone else comes along with a different client, or you somehow
become unable to continue working on your own, they aren't locked
out.

> 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.

But otherwise, sure include all you want!  Many online games,
especially the low budget ones, have you download the graphics while
you're not playing (i.e. packaged with the game, or as modules) and
then the only network protocol is the movements and coordinations of
the graphical sprites and/or 3D figures.

> 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.

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.

> 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.

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

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?

>   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.

>   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.

>   Shortcut command buttons

Best leave this to the discretion of the user.  It's almost
impossible to predict just what set of shortcut commands the user
will find useful.

>   Visual control to manage combat - Combat is to be round-based,
>   with all players choosing their actions for the next round ahead
>   of time - some sort of visual control would be much easier to
>   manage than typing in several commands.

Generally not.. having a visual control really only starts to make
things more convenient when you have "Seiken Densetsu" level games,
where you can literally reduce the complexity of an action to "Go
over to the enemy and hit them with your sword."

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.

--
Pandora "Starling/Tasci/Antinomy/Figment/???" synx
pgp key at http://synx.dyndns.org/starling.asc
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev