WorldForge Protocol requirements (revision #8)
- The protocol must be capable of:
- transmitting objects
- transmitting changes or additions to objects
(For the purposes of this document, an "object" will be taken to be a
bundle of properties. A property is a named or anonymous chunk of data,
in one of the "atomic types" of the protocol. Supported types of
properties should be described in the protocol specification. Two types
are mandated: objects must be able to contain sub-objects, and objects
must be able to contain some form of id or reference to other objects.
Basic types such as ints, strings and lists are of course highly
recommended if the protocol is to be at all useful).
- The protocol must be capable of describing such scenarios as:
- movement of things in a game world
- combat between things in a game world
- acquisition of things by other things in a game world
(For the purposes of this document, a "thing in a game world" will be
taken to mean exactly what it says. Sample things include pens, swords,
raging oceans and small furry animals. These things may be stored in
completely arbitrary fashion on a client or server, thus the protocol
must be capable of describing the above scenarios without making
assumptions concerning entity representation).
- The protocol must also be capable of handling situations involving:
- login negotiation between clients and servers, including authentication
- access control to update, create or destroy particular objects
- The protocol must be independent of:
- application layer (the application using it, the calling program),
for example: backstage, cyphesis, uclient, anvil...
- session layer (syntax, format, representation, what it looks like),
for example: XML, or packed binary, or gzip compressed lisp expressions.
- transport layer (the mechanism for getting it to places),
for example: TCP or UDP sockets, saving to a file, IPX, and so on.
- To be accepted however, a protocol needs to be demonstrated using one or
more actual session layers (syntaxes, formats...) that can represent:
- all the necessary semantics of the protocol
- 20 things in a game world becoming visible in at most 3860 bytes
- 20 things in a game world changing direction in at most 3860 bytes
(Note, the precise bandwidth numbers come from the STAGE requirements,
involving a certain number of clients on a server with a T1 line. It
can be assumed that all other servers will have similar if not more
stringent ones. The target is not hard to meet, it is just there to
impose a limit on any delusions of bandwidth grandeur a protocol
designer may be experiencing).
- These session layers must be defined completely in an appropriate way,
for instance a DTD for an XML based syntax, or detailed descriptions of
chunks for a packed binary format. Binary formats must also specify
either an endianess convention or a way to detect it at run-time. ASCII
formats must specify if they use alternative character sets or encodings
rather than pure ASCII.
- Although working code is not a pre-requisite for protocol acceptance, it
must be possible for an implementation of the protocol to be written in
any sane language, using sane libraries. No esoteric languages features
or unusual libraries must be required. The protocol API (the presentation
layer) as presented to an application must be simple and easy to use, for
both emitting and receiving.
Michael
Other people participated in developing requirements document: Bryce
and Fex
Aloril
Last modified: Thu Nov 4 06:54:06 EET 1999