[MUD-Dev] Next gen MUD wishlist

Bryce Harrington bryce at neptune.net
Wed Feb 23 13:04:55 New Zealand Daylight Time 2000


Okay, I've held off a bit so as not to needlessly spam the list.  Note
that this turned out to be more of a requirements doc than a wishlist,
due to the nature of input that received.  Because this is long, in the
future I will only put this on a website or similar, but I wanted to
gain a little more peer review before doing so.

Because of the controversialness of the licensing and performance
requirements I've not put them in this version.

All of the thanks for generating this set of requirements needs to go to
Fex, Mike, sdt, and Cyanide.  

The designish stuff has been broken out into a separate document which
will be worked later.  Wishlist items have likewise been segregated (if
there is interest on this list I may continue posting that to this forum
as it grows and as my time permits).  Performance requirements are being
worked separately and really will need some experience/experimentation
to see what is possible; there are a few different operational paradigms
being considered which have major impact on the performance required.

Anyway, here ya go.  If you can send me your feedback/advice on how to
improve these, it would be greatly appreciated.  This requirements
document (but not necessarily any design or implementation based off of
it) is covered under the OpenContent License (www.opencontent.org) so
please keep that in mind if you wish to reuse this for your own purposes
(which you are free to do).  



Requirements document for server design.
----------------------------------------

Notes:

References to "the target machine" are taken to be referring to a single
processor Pentium II class machine with 64 Mb of RAM and 256 Mb of
storage devoted to the simulation.


Contents:

1.      Game World
1.1     Entities
1.1.1   Attributes
1.1.2   Operations
1.1.3   Behaviour
1.2     Accounts
1.3     Persistence

2.      Communications

3.      User Interface
3.1     Configuration
3.2     Signals
3.3     Console
3.3.1   Other

4.      Debugging and Testing


Requirements:


1.   Game World

    A game world is a physical space populated with autonomous entities
    that is simulated by the server and a set of accounts that provide
    access to the world.

 *  A running instance of the server participates in the simulation of a
    single game world.

 *  The game world contains a 3d physical space.

 *  The physical space of the game world can contain a number of objects,
    referred to from this point on as entities. The number of entities
    is limited only by available memory and storage, with a minimum of
    1000 on the target machine.

    (see section 1.1 Entities for details)
    
 *  Interacting with game world entities will require the creation and
    use of an account on the system. The game world can contain an
    unlimited number of accounts.

    (see section 1.2 Accounts for details)

 *  The server updates the game world in such a way as to simulate the
    progression of a single linear thread of time in that world. The
    update process is capable of operating in real time, but can be
    paused and restarted by a server operator if necessary.

 *  The server supports the distribution of the simulation of a game
    world over more than one running server instance with proper
    synchronisation between such peer servers.

 *  The game world will have sufficient sophistication and performance
    to implement the world specified by TBD.


1.1 Game World - Entities

    Entities are distinct objects within the game world. It makes sense
    for a creature or a house to be an entity, as these are both
    distinct concepts that can be encapsulated and dealt with as a unit.

 * Entities consist of attributes.

       (see 1.1.1 Attributes for details)

 *  Entities are created from a template which describes the attributes
    an entity possesses and (where applicable) default values for them.

 *  Entities respond to a number of Operations

        (see section 1.1.2 Operations for details)

 *  Entities can adopt a physical representation which they may change
    at any time.

        (for example they may change in size or mass or location)

 *  Entities that have adopted a solid physical representation collide
    with and do not interpenetrate other solid entities.

        (future designs may modify this requirement to permit embedding,
        which can be simulated using entity combining)

 *  Entities can combine with other entities to form a new entity or
    split to form multiple new entities.

 *  Entities can contain other entities.

        (to allow a pickup/drop operation)

1.1.1   Game World - Entities - Attributes

    Attributes are named values which describe the state of an entity.

 *  Attributes may be added to or removed from an entity at any time

 *  Attributes are available to alteration at any time

 *  Attributes are used to represent the properties of entities within
    the game world.

        (such as their location and velocity and mass, whether they are
        visible, controllable...)

 *  Attributes may change their value as time passes.

 (such as the simulation of momentum and heat and age)


1.1.2  Game World - Entities - Operations

    An entity may invoke operations upon itself and upon other entities.

 *  The operations to which an entity responds may change at runtime

 *  A movement operation manipulates location attributes as well as
    others required to simulate a particular mode of movement.

        (velocity, acceleration etc as applicable. Constraints on
        movement will be decided by the simulation and may include
        restrictions due to physical properties)

 *  Some operations allow communication between entities, such as
    talking.


1.1.3   Game World - Entities - Behaviour

    The behaviour of an entity describes how the entity state changes
    over time, including invoking operations and manipulating attributes.

 *  Entity state may be manipulated directly to simulate dynamic physical
    properties.

        (for instance an entity which has velocity may continue to
        move as time passes without further operations being performed
        upon it)

 *  Entity behaviour can originate from modules and scripts loaded or
    linked dynamically by the server at start up time. It is optional to
    support the ability to reload such modules while simulating if they
    change.

 *  Entity behaviour can originate over the network from another peer
    that is participating in the simulation of the game world. The peer
    must have access permission to modify the entity in question.

 *  It is possible for a single entity to have behaviour that originates
    from a number of sources simultaneously.
    

1.2 Game World - Accounts

    Accounts form the connection between the real world and the game
    world.  Each one determines the access permissions of a single peer
    to modify entities within the game world. In a running server
    accounts are held by both players and other servers participating in
    the simulation.

 *  The server supports an unlimited number of accounts for each world.

 (however it can impose a limit for particular worlds)

 *  Each account is password protected, further authentication measures
    are optional. A system that permits easy and modular addition of new
    authentication measures is highly regarded.

 *  Access permission to an entity is fine grained and details access to
    individual attributes and operations. However, complete and total
    access to an entity or group of entities can be assigned to an account.

    (for instance, access to a human that allows control of its movement
    but not alteration of the number of limbs it possesses)


1.3 Game World - Persistence

    Persistence is the storage of the world in such a way that it
    persists after server shutdown and can be retrieved subsequently.

 *  The server is capable of maintaining persistant storage of its world
    across instances of the server. 

2.  Communications

 *  The server uses a game communications protocol called Atlas.

 *  The server authenticates incoming connections using the Atlas login
    protocol and the authentication method chosen for accounts.

    (see section 1.2 Accounts for details regarding authentication)

 *  The implementation of the Atlas protocol will be based on the
    provision of a library which supports the protocol and allows
    operation across the number of layers that the protocol
    encapsulates. This library shall be defined and designed in parallel
    to this server and its requirements are implicit here.

 *  The server supports communications over TCP/IP networks.

 *  The server is capable of catering to differing bandwidth requirements
    that may restrict peers. The level of bandwidth available will be
    described to the server by the peer during login.

 
3.   User Interface

    The user interface of the server is all the facilities that allow
    its operation to be controlled by the user and report information to
    the user.

3.1 User Interface - Configuration

 *  The server is able to store and retrieve its configuration.

 *  The server operator may edit server configuration files directly
    or access values indirectly via the console interface

        (see 3.3 User Interface - Console for details)


3.2   User Interface - Signals

 *  The server will respond to SIGHUP by explicitly shutting down all
    network connections. It will also re-read configuration files and
    perform clean up operations. It will then restart the simulation.

 *  The server will respond to SIGINT by terminating very
    gracefully. This involves disconnecting all network connections,
    erasing temporary files and optionally saving the world state.

 *  The server will respond to SIGTERM by terminating gracefully. This
    involves disconnecting all network connections and erasing temporary
    files but not saving the world state.

 *  The server will respond to SIGQUIT by terminating disgracefully. This
    involves terminating but not explicitly shutting down network
    connections or deleting any temporary files, then dumping core.

 *  The server will either bind specific functionality to SIGUSR1 and
    SIGUSR2 or ignore them completely. Either way it will be fully documented.

 *  The server will either bind specific functionality to SIGTSTP and
    SIGCONT or ignore them completely. Either way it will be fully documented.

 *  The server may choose to handle SIGPWR (signalling imminent loss of
    power) in a way likely to minimize risk of losing world integrity.


3.3 User Interface - Console

 *  An console based user interface will be provided with which the
    server operator can interact.

 *  The console will provide information on the current status of the
    server process to the operator.

 *  Debugging output will be routable to the console, especially during
    development.

 *  The console will allow configurable filtering of the information
    it may display.
    
        (for instance to allow debug information to be ignored)

 *  The console will be capable of be    and editing of account
    information.

 *  The server operator will have access to a view of the world as it is
    being simulated.

        (perhaps via a map editor, or a large scale map view)


4.   Debugging and Testing

 *  The server will as far as possible degrade gracefully on error and
    report those errors which can be determined by the system.

 *  The server will report missing files and terminate gracefully.

 *  A server crash will not corrupt persistent world data.

 *  The server must support logging to a file. The data logged will be
    configurable in the same way as the console output.


----------------------------------------

Again, sorry if this is considered spammy or off topic; I know it ought
to be reserved for a website, and in the future it shall be.  Any input
you can provide will be greatly appreciated, and especially if anyone
has wishlist tiems, I'll continue work on that.  We probably won't get
going full bore on creating a design for at least a few weeks, perhaps
even a few months.  However, we've got a really good start and some very
good ideas, already, in that area.  

Bryce





_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the MUD-Dev mailing list