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

[Jason Slaughter]

OK, I am working on my own MUD/MMORPG project, and here are some of
my design ideas and areas where I am unsure on. I figured this would
be a perfect place to throw around ideas. I am new to multiplayer
games, and am working on this project as a learning experience, so
please be patient if I don't express some of my ideas quite so
clearly.

My basic design goal: To design an easy to use multiplayer online
game, with it's own graphical client. The goal for the client is to
automate, simplify, and streamline game play, to eliminate typing
MUD style commands (or to cut them down to a bare minimum), 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.). The other goal of
the client is to keep it small and easily downloadable, and to keep
the system requirements quite low. The goal of the server is to be
extremely light weight (to get as many players as possible on a
lower end machine), 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).

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.

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.

The game will be room-based like a typical mud, with text room
descriptions, but will use graphical mapping. For a person like
myself, this is the main reason I do not play muds. I need some sort
of spatial representation in order to be able to navigate. My mind
just cannot make a spatial map purely from text
descriptions. Perhaps it is my own peculiar handicap, or perhaps
other people feel the same way and this is why muds haven't caught
on in a bigger way. Some muds have ascii character maps, but those
are far and few between, and usually the maps are quite limited. It
is a constant frustration for me: I would love to play muds, and
there are THOUSANDS of them out there ready to play, but none of
them implement this basic basic feature that I really need to play.
Here are the two methods of handling mapping and solving that
problem that I am contemplating:

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.

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,
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. Also, a simplified system means that more
casual gamers might like to play the game. Simplified mechanics are
easier on the server. 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.

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

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.

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.

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

Objects will be assigned an action they can perform, one action to
object, if they can be picked up and used by players. But for other
things, I need behaviors. Behaviors check certain criteria at
intervals and then perform actions. Assign a behavior to an object
to make it an NPC, a mob, a ferry, or whatever specific function it
needs to do. Where I strongly need input is generating a list of
different basic types of behaviors. I want to keep things simple, so
I want the least possible behaviors that can encompass most
role-playing situations. I don't want to have to code a behavior for
each type of object... and there is to be no scripting, so behaviors
have to encompass everything. Behaviors simply look at the room
around them, and then take some sort of action based on a criteria.

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

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

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