[MUD-Dev] Thoughts on a simplified multiplayer game.

[Edward Glowacki]

Hmm... Here's my (many) comments.  Hope they don't come across too
harshly, my goal is not to tell you you're wrong on anything, but
just to give you some ideas to think about.  I give you the info,
you decide whether or not to pay attention to it. ;)

On Tue, 2003-05-20 at 19:23, Jason Slaughter wrote:

> as well as display an attractive graphical map to help in
> navigation (one of the difficulties I have with text based muds is
> navigation. Without some sort of spatial representation, I get
> lost.).

Zmud has a graphical mapper.  It's not perfect and doesn't work well
for all muds, but so long as the rooms' text structure and exit
labels are machine parsable (i.e. not mixed in with a paragraph of
prose), it usually does a decent job.

> The other goal of the client is to keep it small and easily
> downloadable, and to keep the system requirements quite low.

The "small and easily downloadable" part seems at odds with what you
say later about having images for every room, which would be very
bandwidth intensive.  So for the initial download it sounds like
you're expecting dial-up, while to play the game you're expecting
broadband.

> The goal of the server is to be extremely light weight (to get as
> many players as possible on a lower end machine),

I wouldn't worry about a "lower end machine".  Right now you can
probably piece together a suitable Athlon XP 2400+ machine for under
$500, and that will only get better over the time it takes for you
to get to a point where you have enough users that you outgrow
whatever you're planning on having it run on now.

> and to be scaleable (in case the game ever catches on and starts
> to be popular, I don't want to have to re-write the entire
> system... just add another server box and go), and also, to be
> completely self-contained (to not depend on any external database
> system or anything like that).

For some tasks, having an external server is not necessarily a bad
thing.  For example, storing user account information (username,
password, preferences, etc., not talking about their character
objects and stats though) in an SQL database might make sense so you
can integrate that into a web site.

> My overriding design philosophy is SIMPLICITY. Simplicity,
> simplicity, simplicity. Why? First of all, this is not a
> professional project. I don't have the resources to add all the
> features that a typical MMORPG has... I want to keep my goals
> manageable, easy to do, and realistic. Also, the more complicated
> something is, the more bugs it is going to have. Also, the more
> complicated something is, the more resources it is going to take,
> and I want to keep resource consumption to a minimum. I want a
> lean, mean, simple and elegant game... not some bloated
> monstrosity.

This sounds very reasonable.  =)

> First of all, my game is going to use UDP for sending a receiving
> data. Yes, UDP can cause trouble with some firewalls and for some
> users... but the benefits are just too attractive to not use: Most
> of the time the player is idle (they may be reading a text
> description, reading a message from a friend, typing a message or
> command, but they are doing something that from a server point of
> view means that they are idle.) This might be counter-intuitive
> from a text mud point of view, because in a telnet based text mud
> the server is also doing much of the work of a client (for
> example, parsing commands, displaying information). But no
> connection needs to be maintained during idle time. Second, each
> UDP message is a discrete encrypted game message, I don't have to
> worry about sending streams of text. It simplifies the design a
> lot.

I don't buy this argument.  UDP is an unreliable protocol, so you're
never *guaranteed* that what you send will be received, or in what
order.  Something like "lite fuse, drop bomb, move east" might end
up as "move east, like fuse, (drop bomb command lost in transit)".
Boom.  By the time you make sure commands arrive, and do so in
order, you've re-implemented TCP and destroyed your simplicity.  You
might as well just set up a TCP connection or even an SSL-enabled
TCP connection for its encryption.  It doesn't really cost anything
to hold on to some TCP connections on the server side, and (as you
mentioned) it does make it a lot easier for people with firewalls to
use TCP.


> 1. Each room specifies a graphic file (maybe from URL) and a set
> of coordinates. For example, you might specify for the town square
> map "www.mygame.com/town_map.jpg:124,53"... for the nearby docks
> "www.mygame.com/town_map.jpg:96:91". For a secret room underneath
> the sewer, you might use a different graphic file, like
> "www.mygame.com/town_map_sewers:124,53". The client simply loads
> the graphic from the web site (or cache), and centers the graphic
> on the coordinates, and perhaps puts some kind of "you are here"
> crosshairs or icon there. The map doesn't need to be just a simple
> line map. It could be a very detailed and attractive 3D rendered
> graphic, it could be a very attractive and stylized hand-painted
> map.
 
> The benefit of this type of system is how simple and easy it is. I
> mean, it is SIMPLE (and I really, really, like simple). It also
> allows any type of artwork to be exploited (for example, I could
> have a painter, or cartoonist, or almost any type of visual artist
> do a map for the game, and it simply would be a matter of scanning
> in the image and uploading it).
 
> 2. The map is broken up into equal sized grids, with each grid
> space being a room, and having its own graphic. The nice part
> about this, is that it is easy to do stuff like black out places
> you havent explored yet, to give you visibility and reduce that
> visibility at nighttime, etc. Also, you can re-use graphics (a
> generic style building or room can have it's graphics
> re-used). The bad part of this, is that making artwork for it is a
> bit more complicated... it cannot easily be done by anyone... and
> with non-professional games, where art assets are at a premium, it
> seems like you want to simplify the process of creating art
> assets. This method does not do that.
 
> There are also other methods I could use, of course... but these
> are by far the simplest, and simplicity is part of my design
> philosophy. This is something I am a bit torn in, and some
> feedback from people would be very welcomed.

Keep in mind that if the graphics are loaded from the server
on-demand, then you're going to have a significant performance
penalty.  Consider that the amount of data (including images, room
description, lists of characters and objects, etc.) for a single
room is probably on the order of a simple web page, simple actions
like moving between rooms is going to be a painstaking process as
you wait for all the data and content to load.  Even if it's only
2-3 seconds to download an image, that's essentially a 2-3 second
delay for *every* move command, so your game will have to handle
that latency.  Aggressive mobs from a typical MUD would tear a
character to pieces if the player has that much delay in movement.

> And now on to what will probably be the more controversial design
> decision. I plan to super simplify the mechanics of the game
> system. I know most mud players are saying to themselves
> "WHHHHHHAAAAAAAAAATTTTTTTTTT!!! Why would you want to do something
> dumb like that?!?!?!". Most people here seem to be very much
> focused on making their game systems more realistic, adding more
> features,

Some of the best (and most re-playable) games out there have the
simplest mechanics.  But there are two facets of simplicity: player
understanding and underlying game mechanics.  Simple game mechanics
can potentially lead to complex interactions, and conversely complex
game mechanics can potentially be boiled down to very simple
representations.  Chess is a good example of the former, and the
answer to the question "am I stronger than he is?" is an example of
the latter.

> etc. However, having a simplified game mechanics has some very
> very important benefits. First, it gives the game a very low
> learning curve. A player can learn the basics of the system and be
> in and playing in no time at all.

Random thought: I think it was the board game "Othello" that billed
itself as "A minute to learn, a lifetime to master". =)

> Simplified mechanics are easier on the server.

*Can* be easier on the server.  Depends on the equations behind the
mechanics.  Honestly, unless you have severe performance bottlenecks
that are having a major negative effect on your game, I wouldn't
worry too much about being "easier on the server".  Hardware is
constantly getting faster and cheaper, and there's no reason not to
have the computer do as much as possible for you and your players.

> A simplified system is easier to program, and debug (an important
> consideration for a non-pro project). Also, a more simplified game
> mechanics makes it easier to set up "game metrics". This was
> something that I don't seem much talk about in the MUD/MMOG world,
> but helped me out a lot when I was working on a card game. I set
> up a set of metrics and equations that measured the "power rating"
> of cards. The game was quite complex, and there was literally
> millions of possible combinations of cards and unforeseen
> consequences in the actions of cards. It would be impossible to
> test and foresee all the possible combinations. But it only took a
> day to set up some rules of thumb, equations, etc., for evaluating
> the power of a card. This "metric" was actually incredibly
> powerful in discovering cards that imbalanced the game or ruined
> game play. Yes, the system was hardly scientific, and required
> some subjective analysis in the system, but IT WORKED AND IT
> WORKED WONDERFULLY. Being able to create a system of metrics for
> evaluating something like game items would go a long way in
> avoiding having to "nerf" items or things like that.

I understand that this is a project you're doing for yourself.  But
if you plan on having lots of players, make sure you none of these
issues affects *their* view of the game.  A contrived example: Don't
take out the ability to use an axe instead of a sword just because
you can't find a good metric for measuring the effect of an axe in
combat.

> How I intend to simplify the game system:
 
> Everything in the game is an "Entity", and an entity has
> attributes. Any Entity can be asigned any number of "tags", which
> consist of a "field", and a "value". For example, you could create
> an entity "Guard", assign him the field "entity_type" and the
> value of "guard", assign him the field of "hitpoints" and a value
> of "10". One simple universal data type for every entity in the
> game...

Using this system, I can imagine complex things in the game that
have a large number of fields and values.  Managing such a list of
attributes could get messy.  If each object has a copy of each
attribute, you can't easily go back and make changes without doing
something like a global search-and-replace.

What you might want is more of an object-oriented style, where
"Entity" is a base class which all other object types in the game
inherit.  That way if you wanted to give all swords the ability to
"slash", you could add a "slash" method to the sword object, and it
will correctly propagate down to all the appropriate objects.  Yes
it may be a bit more complex to code initially, but it may be easier
(and more powerful) in the long run.

> Everything is simplified into an action/target relationship. Any
> skill you have, any usable item you have, is an "action", and it
> can have certain "targets". For example, you may use your kung-fu
> skills on a guard, or use your first aid on yourself, or use your
> key on the door. The function for handling this object would
> essentially be simplified to this: perform_action(performer,
> action, target), and any action would simply manipulate fields and
> values on the performer and target, as well as broadcast text to
> players.

In order for this to work, an "action" will need to be some sort of
function, which brings up the question of how to associate functions
with game objects.  Back to object-oriented...

> How would this work in the interface? The interface by default
> presents your map, your text window, and a list of objects and
> players in the room. Click on any player or object, and it brings
> up a little submenu of the actions you can take on that
> entity. For example, click on a guard, and the options might be
> "speak-to, attack, give, scrutinize, etc.", depending on the
> skills and items you have. click on your option, and you take your
> action. Or, lets say you want to use a med-kit on yourself. Click
> your inventory, click on med-kit, and one of the sub-options is
> "Use on self", and you click on that.

One of the great features of a text MUD is its text interface,
i.e. the keyboard, which can be very efficient.  When you start
switching to the mouse, you lose efficiency
(keyboard-to-mouse-and-back is an expensive operation time-wise...).
Also, once you start relying on the mouse for basic gameplay
actions, your game largely becomes a graphical game as opposed to a
text game.  Be careful here.  Done poorly, your game will have an
identity crisis, "Am I a text game, or am I a graphical game?"  and
you'll probably have trouble selling (pitching, convincing,
enticing, whatever, not necessarily selling for cash) the game to
players.  Done well, and you could have a great game that takes
advantages of a graphical environment to enhance the old-school text
interface and hit a nice niche in the market.  Actually I've been
pondering this hybrid graphical/text concept for a while without
being convinced it would really work.  I would *guess* that most
people that want graphics already play GUI games, while those that
are text-game players would probably be difficult to pull away from
their preferred text environment without a significantly well-done
game.

> Some people will probably say "but there is so much that cannot be
> done with that model", and while I welcome people pointing out
> flaws in my ideas (that is why I am writing this!), for the most
> part I would say that is something that just has to be dealt
> with. For what I am trying to achieve, simplicity and ease of use
> takes priority over depth.

Ease of use, definitely.  Simplicity, maybe.  But some amount of
depth is vital.  Otherwise you end up with everyone in the game
using the exact same techniques.

> However, even with this simplified system, I think it can achieve
> a lot of depth in the game play. Certainly not as complex as a
> typical mud, but I think rewarding gameplay and roleplay is
> possible using this model. Look at how simple chess is, and how
> much depth it has.

Heheh, I started writing about the simplicity of chess and its depth
in my previous paragraph before I got to this one... hehe... =)

Depending on how many people you have playing your game, rewarding
role playing may be difficult.  I know a lot of games that encourage
or enforce role playing, but to actually reward it and do so
consistently (especially as the size of the player base grows)
sounds like a nightmare to me.

> Also, I am looking for good ideas to simplify content creation,
> and make it as non-technical as possible. Keeping the game system
> simple goes a long way, but there are probably some other ideas.

If you're looking for a large audience of content creators, then
you'll want to build the content creation interface with as much
polish as your game interface.  For any interface, make sure you
understand the goals your users are trying to reach and try to make
the interface streamline the path to get there.  The KISS philosophy
you've been describing for the rest of your game should work
especially well here.

> I think a large and complex world can go a long way in making up
> for a simplified game system. Having a GUI based world builder is
> an absolute necessity, and it might even be worth it to integrate
> world building into the game client.

You know what they say (about the WWW anyways), "Content is king." 
=)

> Anyway, here is some of the ideas that I am working with now. Some
> of the most knowledgeable people about muds and multiplayer games
> are probably on this list, and so I look forward to your comments
> (even critical comments).

I think most of my comments fell into that "critical" category. =(
Hopefully they're still useful.  And good luck making your game! =)

-ED
--
Edward Glowacki
glowack2 at msu.edu

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