[MUD-Dev] Ubiquity Scope & Requirements

[Greg Munt]

What follows are my scoping and requirements documents. I plan to publish
all my development documents on the web. I don't have any plans to publish
the code right now. I'd much rather have my design copied, rather than my
implementation.

If you can think of anything I've missed, please let me know! Additionally,
I'm hopeful that it will provoke discussion here.

            Defining The Project's Scope

            Considering the mistakes made in the development of Frontiers, I
            wanted my next project to begin as something simple, which,
through
            iterative development, would evolve into a fully-fledged,
complex
            online environment. Using Bartle's classification of player
goals, I
            considered the fact that one type of game could not be all
things to
            all people; Socialisers would not appreciate an environment
where
            commands not internally consistent remained unimplemented. (The
tell
            command, for example - it is difficult, if not impossible, to
            plausibly explain how people thousands of miles away from each
other
            can communicate. Exceptions to this rule warrant the
intervention of
            technology, or magic. I did not feel that such intervention
could be
            implemented effectively, within an online environment.)
            I had two choices: develop one style of mud, dedicated to one
            particular player goal, or develop a server with dedicated
subareas.
            (This would effectively be multiple games in a single mud.)
            Frontiers was an attempt to provide multiple games, for all. But
I
            only really knew about what Socialisers wanted. So, I decided
that
            my initial goal would be to develop a piece of software that
would
            cater specifically and wholly for Socialisers. After developing
            that, as fully as I could, I would enhance it through iterative
            development, establishing a 'world', with the original
            Socialiser-specific software becoming an OOC command shell.

            Analysing The Project Requirements

            Let's take a look at the basic requirements of a
Socialiser-specific
            online environment.

                IT'S ONLINE
                'Online' need not mean the Internet; however, the global
network
                is a very publicly accessible medium - and therefore a great
                provider of many potential users. Additionally it is
                well-standardised, and facilities to build Internet support
into
                software are common, and freely available.

                ITS USERS ARE PERMANENT, OR AT LEAST SEMI-PERMANENT
                Users need a permanent identity within the provided
environment.
                This sociological demand stems from the need for people to
                develop relationships with their peers, irrespective of the
                setting. Clubs, societies and guilds are a selection of the
many
                examples of this phenomenon. The required sense of identity
is
                used to further this sociological goal: it is difficult to
                develop a relationship with somebody if your name (and
therefore
                your friends' frame of reference to you) is unstable. Could
you
                be sure that Bubba is really Bubba? Maybe they are really
Boffo,
                who has taken Bubba's name? What happens when the real Bubba
                tries to connect?

                IT PROVIDES LOGIN SECURITY FOR ITS USERS
                To ensure that Bubba really is Bubba, and always will be,
user
                representations need to be secure. It is no good to save
Bubba
                in a database of some sort, only to allow anyone to connect
as
                him. A typical security method is to require a username and
                password combination to be input, before full entry into the
                world is permitted.

                IT SUPPORTS A PERSISTENT WORLD
                A persistent world is saved across server reboots. Some
muds,
                such as DIKUMUD and its derivatives, provide a static world
                which is reset at regular intervals. Reasons for this
include
                repopulating areas (replacing 'monsters' which have been
killed,
                for example) and resetting traps and puzzles. A persistent
world
                is more dynamic, in that things killed stay dead, and doors
                unlocked stay unlocked - just as in the real world.

                IT PROVIDES A CLEAR, SIMPLE AND INTUITIVE USER INTERFACE
                The traditional mud is text-only, accessed via a
                telnet-compatible client. However, the mainstream
Internet-aware
                public is quite engulfed by the graphical medium. First
Windows,
                then the Web, have shown how appealing a graphical user
                interface (GUI) is - and why mud-playing has remained on the
                sidelines. The average Internet user believes the Internet
and
                the Web to be synonymous, and, whilst a gross inaccuracy,
this
                large number of people has eluded most muds up until now -
                primarily, in my view, because they are not accessible via a
                well-known medium. The closest many people have come to
using
                muds, is through Microsoft Chat, or web-based chat rooms. If
                Ubiquity should use a web interface, the question of whether
to
                support telnet clients still remains. Since almost all of
the
                current mud users use these clients, it would be in
Ubiquity's
                best interests to support it - in the same way that it is
                important to have a web interface, to cater for the users
who
                are not telnet-aware. Additionally, it would perhaps allow
for
                the testing of lower-level functionality than can be visible
                from a GUI.

                IT PROVIDES VARIOUS SERVICES TO ITS USERS
                In order to determine what functionality it is that Ubiquity
                should provide, the Internet facilities that are currently
                available need to be looked at - those that satisfy
Socialiser
                goals. The reason for this, is that only a small minority of
                people will use something completely different to that which
                they are used to (this can be clearly seen by the dominance
of
                TinyMUD, LPMUD and DIKUMUD throughout the mud world); people
                tend to stick with what they know, even if a newer product
is
                much better. These services are as follows:
                    Email
                    Newsgroups
                    Internet-Relayed Chat (IRC)
                    Information Repositories
                    Games