<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] Next gen MUD wishlist -->
<!--X-From-R13: Pelpr Vneevatgba <oelprNarcghar.arg> -->
<!--X-Date: Wed, 23 Feb 2000 19:45:42 -0800 -->
<!--X-Message-Id: Pine.LNX.4.10.10002231210060.14066-100000#pulsar,neptune.net -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: Pine.LNX.4.10.10002221806460.18555-100000#aeowyn,treyarch.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] Next gen MUD wishlist</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:bryce#neptune,net">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00460.html">Previous</a>
| <a href="msg00463.html">Next</a>
]
Thread:
[ <a href="msg00458.html">Previous</a>
| <a href="msg00480.html">Next</a>
]
Index:
[ <A HREF="author.html#00461">Author</A>
| <A HREF="#00461">Date</A>
| <A HREF="thread.html#00461">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] Next gen MUD wishlist</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] Next gen MUD wishlist</LI>
<LI><em>From</em>: Bryce Harrington <<A HREF="mailto:bryce#neptune,net">bryce#neptune,net</A>></LI>
<LI><em>Date</em>: Wed, 23 Feb 2000 13:04:55 -0800 (PST)</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
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#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00458" HREF="msg00458.html">Re: [MUD-Dev] Next gen MUD wishlist</A></STRONG>
<UL><LI><EM>From:</EM> <adam#treyarch,com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00460.html">RE: [MUD-Dev] Next gen MUD wishlist</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00463.html">[MUD-Dev] Distribution</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00458.html">Re: [MUD-Dev] Next gen MUD wishlist</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00480.html">Re: [MUD-Dev] Next gen MUD wishlist</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00461"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00461"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] Next gen MUD wishlist</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00429" HREF="msg00429.html">Re: [MUD-Dev] Next gen MUD wishlist</A></strong>,
Bruce <a href="mailto:bruce#puremagic,com">bruce#puremagic,com</a>, Sat 19 Feb 2000, 05:04 GMT
<UL>
<LI><strong><A NAME="00430" HREF="msg00430.html">Re: [MUD-Dev] Next gen MUD wishlist</A></strong>,
J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Sat 19 Feb 2000, 06:56 GMT
<UL>
<LI><strong><A NAME="00431" HREF="msg00431.html">Re: [MUD-Dev] Next gen MUD wishlist</A></strong>,
Chris Jones <a href="mailto:cjones#v-wave,com">cjones#v-wave,com</a>, Sat 19 Feb 2000, 17:36 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
<LI><strong><A NAME="00458" HREF="msg00458.html">Re: [MUD-Dev] Next gen MUD wishlist</A></strong>,
adam <a href="mailto:adam#treyarch,com">adam#treyarch,com</a>, Wed 23 Feb 2000, 02:09 GMT
<UL>
<LI><strong><A NAME="00461" HREF="msg00461.html">Re: [MUD-Dev] Next gen MUD wishlist</A></strong>,
Bryce Harrington <a href="mailto:bryce#neptune,net">bryce#neptune,net</a>, Thu 24 Feb 2000, 03:45 GMT
</LI>
<LI><strong><A NAME="00480" HREF="msg00480.html">Re: [MUD-Dev] Next gen MUD wishlist</A></strong>,
Bruce <a href="mailto:bruce#puremagic,com">bruce#puremagic,com</a>, Sat 26 Feb 2000, 21:19 GMT
</LI>
</UL>
</LI>
</ul>
</ul>
</ul>
<LI><strong><A NAME="00369" HREF="msg00369.html">RE: [MUD-DEV] a shrinking pool of players?</A></strong>,
Sellers, Michael <a href="mailto:MSellers#maxis,com">MSellers#maxis,com</a>, Wed 16 Feb 2000, 17:51 GMT
</LI>
<LI><strong><A NAME="00367" HREF="msg00367.html">RE: [MUD-DEV] a shrinking pool of players?</A></strong>,
Sellers, Michael <a href="mailto:MSellers#maxis,com">MSellers#maxis,com</a>, Wed 16 Feb 2000, 17:51 GMT
</LI>
<LI><strong><A NAME="00372" HREF="msg00372.html">RE: [MUD-DEV] a shrinking pool of players?</A></strong>,
Koster, Raph <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Wed 16 Feb 2000, 18:04 GMT
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>