1.1.1 Nameless MUCK 2 Concept of Operations Document
1.1.2 Version: 1.0
1.1.3 CVS version: $Id: conops.html,v 1.1 2004/06/24 21:22:47 brianj Exp $
1.1.4 Status: Draft
1.1.5 Created: March 26, 2004
1.1.6 Prepared by Brian Jones (brianj@otterspace.com)
This document describes what the NMC2 project will achieve. It is meant to be understandable to all parties with an interest in the NMC2 revision of the Nameless MUCK Codebase 1.X project.
This is based on the IEEE Standard 1362-1998. This puts the added burden of accommodating the standard, but the much greater benefits of precision and clarity. We intend that this project be an accurate and adequate representation of the project and one of the primary sources for evaluation of the final system.
The Nameless MUCK Codebase project (of which NMC2 is version 2) is a system that provides presence and persistence to multiple people concurrently.
The system allows users to send commands textually and receive text back. The system is fully interactive; commands may be sent at any time. Furthermore, text can be presented without responding to a command (the system is completely asynchronous). The nature of the commands support chat (similar to instant messages) and role-play. The commands also support the creation and selection of content with a persistent object storage scheme. People can thus customize their objects to provide their internal presence (avatar or character), locations (rooms) and accouterments (things).
The system is currently in use with dozens of sites and thousands of users. Each site stands totally alone at this point.
The NMC2 upgrades the existing features to include peer connectivity between sites as well as enhancing the types of communication protocols and content which can be shared.
A primary goal is to allow upgrades to NMC2 from not only NMC 1.x sites, but other TinyMUCK derivatives such as Glow or ProtoMUCK. A secondary goal is to allow import of other MU servers, such as MUSH, MUD, or MOO.
Backwards compatibility is supported through the use of extensions to NMC2, not as a core aspect of NMC2. In this way, NMC2 isn't restricted to the models of NMC1 while still supporting its requirements.
The net effect is that users of existing systems should comfortable with NMC2 because it mostly seems the same to them as users until they start pushing the new features (if they do). Many users only do the basics and don't exercise even the existing installations.
2.1 Core Concepts lists the key terms for this project.
The NMC project was started as a branch from FB-MUCK 5.x series code to provide bug-fixes that weren't being included in the FB release. The project quickly expanded to include the goals of trivial upgrades for internal automation code in MUF and MPI, as well as easy scripting of content creation with update instead of re-create semantics.
We achieved these goals. However, without a good documentation set, the ability for people to benefit from our work was painfully reduced.
Our scope includes not only the server itself (which is currently in C and C++ portable between UNIX and Windows installations) but all the internal scripting support that makes the server provide full text-based VR.
Our end-users shouldn't be astonished after the change.
Our system policy is enablement. We don't mandate how any administration run their system internally, but we give them the programs and tools to enforce whatever policies they wish. Thus, some of our sites allow great freedom to content creators and members; some allow very little. In both cases, our software allows controlled access and policy to be configured without rewrites.
The current system is constrained severely by the protocol and database. The protocol makes it extremely difficult to do interactive graphical or automation clients because there is no certain way in machine-readable format to delineate messages and events. The database is restricted to objects and properties of integer and strings, with all complex data-types based on key/value pair mappings. Thus, even the source-code to internal MUF requires external operating system file support.
We actually approve of the support for the simple text format; we simply don't wish to be limited to only the simple text.
The current system is installed as an entire directory with nested directories. The system always comes with a pre-built bootstrap database (that may be the bare minimum or fully populated with extension software and starting content as desired).
When started, the system listens on a TCP port for connections from streaming telnet-clients or MUclients. Both telnet and MU clients use the same free-format protocol.
Members connect with either a stored character or as a guest to make a new character. Guests "become" characters and lose their guest status when activated by whatever local policy is selected.
Members issue commands which can be either system commands or actions defined in a per-location basis. The behavior of the commands can be over-ridden by each local installation and thus centralized pre-done help quickly becomes outdated. There are conventions (optional) for using "#help" on a command to request specific help. NMC conventions also support using "+help command" to request help.
Commands allow members to create content (new objects) and adjust the properties of that content. It also allows them to exchange messages.
Messages may be private between individuals, to all sharing a channel, or to all in the same location. There are also tools in place to allow messages to be propogated to other places allowing for read-only access to a larger set of members than may be obvious. This is used to allow remote viewing to interactive events where the character "has no justification" for being physically present.
The system runs in very few modes.
When its down, core maintenance, such as upgrading of binary executable files, can be done.
When the system is started, it can be started in "wizard only" mode which allows adminstration to interact with the database without non-administration members having access. This is used almost exclusively for correction to internal errors in the data-store.
In normal operation, the system allows connections by members, administration, and guests. All connections result in a "player object" providing presence. No matter how many connections a player has, they are all "equivalent" in that two telnet connections to the same player receive the same output and either can send commands. Thus, multiple connections don't provide any benefits in point of view or context.
Typically, guests perceive a more restricted command-set, so they see the system as having "guest mode" and "user mode" though these are not formal modes.
3.5.1 The NMC currently has the following classes of users:
3.5.2 Guests, programmers, builders, wizards and staffers are all types of player.
3.5.3 By convention, administrators are also players in that they have connections to the game.
Help is provided primarily via direct real-time messaging using the software. Also, web pages and email lists are available. Each game sits on a host which often provides another set of help for the invoking of the system itself.
Text-based systems are losing market to graphical-based systems. The biggest (and most telling) example would be the popularity of systems such as EverQuest and Ultima Online.
Furthermore, the current text-based implementations don't take advantage of any peer to peer operations. This means that groups require someone to grant them (or sell them) space on a server with a fixed IP address and sufficient resources to run the game. Yet, most any player has sufficient machine resources of their own, but without the network access.
Lastly, the dearth of documentation and quality of existing software make further incremental changes more and more expensive. The system has basically grown to reach its ultimate stage, and that stage isn't enough.
The primary change is from client/server to allowing peer to peer features as well. This lets the installations grow through relationships without requiring that each site compete.
To support this, we absolutely need support for operating-system agnostic development. We don't wish to restrict our users to a particular vendor of OS. This is crucial because the large graphical systems (such as EverQuest) require Windows for their clients. By allowing our users to run on a much larger base of machines, we raise the bar for all.
Furthermore, we can't justify making people learn proprietary scripting and extension technology today with so many popular and exceptional scripting language. So we are going to enable the addition of language interpreters or compilers to enable content authors to choose the language to suit the problem.
Lastly, we're going to provide the means for participation through remote servers. That allows identity to be established in one place instead of many, reducing the needs of users to maintain multiple passwords and presences.
Our changes are prioritized as follows:
This isn't yet Islands. The Islands concept replaces the notion of server with pure peer to peer. This system is a hybrid of servers which each support pure clients.
We decided not to include any sort of conceptual 3D support. Such could be added using the extension tools, but for now, the system content is still node-based rather than spatial.
We decided not to invent a new native-mode shell. We believe that there will be many shells provided because everybody thinks they know best all the time and it's not worth fighting over.
Modern systems are fast, have much memory, have large hard drives, and normally have reasonable bandwidth.
Most developers have less time than ever.
Most users want more than ever before.
Thus, our proposed system has to be done with us writing less code, requiring less documentation, and requiring less optimization than the prior system.
This has enormous implications on our objectives. We hope to use existing tools, products, language, libraries, etc., without creation of much software at all. We want to use standard languages for extension so we don't need to document the language or train in its use.
We want to focus on text-mode systems for presence and persistence rather than the more general task of Instant Messaging or Chat Systems. This allows us the focus to enable a smaller team to produce a specific result.
Those people without the means (hardware, memory, whatever) to run our system should not run it. We are not constraining ourselves at all to support for older systems.
5.2.1.1 All systems running the NMC2 server shall have the following minimum characteristics:
5.2.2.1 Clients shall have a telnet client.
5.2.2.2 Telnet shall be capable of handling all core features.
5.2.3.1 Definition: Extension language are tools that allow non-core Java developers to provide programmatic control and automation.
5.2.3.2 Every extension language shall provide full access to all core features.
5.2.3.3 Every extension language shall make available through a set of standard interfaces all features it adds to the system.
5.2.3.4 There shall be no extension language considered more important than any other.
5.2.4.1 There must be exactly one permission model used across all scripting and commands.
5.2.4.2 All permissions shall be specified in policies.
5.2.4.3 All policies shall support support cascading with over-write (meaning that a policy can be "derived" from an existing policy and made more strict, but never less strict).
5.2.4.4 Permissions shall be specified as enabling or disabling. This allows us to expressly grant or revoke a permission.
5.2.4.5 A permission revoked in a parent policy may not be re-enabled in a child policy.
5.2.4.6 A permission granted in a parent policy shall be allowed further restrictions or revocation in a child policy.
5.2.4.7 A master policy shall exist that is parent to all other policies which may not be changed from within the system through any means. Ideally, this file should be stored read-only by the underlying operating system or burned to read-only media. In this way, system owners ensure that no game ever exceeds their master choices regardless of what breaches within the game may occur.
5.2.4.8 The permission system shall consider quotas as part of the policy.
5.2.5.1 Definition: The system shall be considered available when users may connect and perform operations without restriction. See 5.4 for details of all various modes.
5.2.5.2 When available the system shall not restrict user operations.
5.2.5.3 The system shall become unavailable when management requires operations free from user involvement.
5.2.5.4 The system shall seek to remain in continuous operation with no periods of unavailability.
5.2.6.1 Tools shall be provided to allow access to the persistent data for extreme maintenance.
5.2.7.1 Definition: authentication is the process of establishing that a connection is associated with an identity in-system.
5.2.7.2 The core shall provide a username with password basic authentication scheme.
5.2.7.3 Extensions shall be allowed to add or replace the basic authentication scheme.
5.2.8.1 The system shall allow an optional module to report logging information through syslog protocol.
5.5.1 The following additional classes are supported in NMC2:
5.5.2 We remove support for any notion of Wizard class in NMC2. Instead, the policy of each site dictates who can do what precisely.
5.5.3 The term for people granted privileges through the policy to enforce and create policy is manager. This isn't a class so much as a recognition of the assigned security privileges.
5.5.4 The peer-site classes are people on their own remote system in the role there. Thus, while we describe them here, they don't appear on use-case diagrams or in use-cases. Remove the words "peer site" and you have the same job on their system that the job would be for the direct system.
6.2.1.1 Player connects to system with a client that speaks an acceptable protocol.
6.2.1.2 Player and system carry out protocol-specific authentication process.
6.2.1.3 System carries out new connection tasks as specified in each installation.
6.2.2.1 Player provides command to system through client in current protocol.
6.2.2.2 System processes command.
6.2.2.3 Any direct responses are provided through the protocol back to the player.
6.2.3.1 System delivers message (NOT response to a command) to the player.
6.2.12.1 Manager specifies account to disable
6.2.12.2 System disables account, blocking ability for login to succeed
6.2.12.3 System severs any existing connections via that account.
MUCK - Multi-User Character Kingdom (based on the TinyMUCK family)
MUD - Multi-User Dungeon
MUSH - Multi-User Shared Hallucinations
MOO - Muli-user Object Oriented system
installation program
acceptance test criteria
include usage information (how many users, objects, etc)
list limits of security: not encrypted, no powerful authentication, etc.
specify reliability: how long between failures, what is a failure
backup and restore options (disaster recovery planning)
responsiveness - describe lag/latency etc.
importance of allowing arbitrarily large amounts of content and users
importance of permissions by role and ACL