0.2 - Design: And just how are we expected to do this?

DESIGN PHILOSOPHY

The WARPEDcore is designed around two primary features of MUSH coding. The object and the attribute.

1. Objects:

   The WARPEDcore Project concerns itself with five (5) primary object groups.

   PLANNED OBJECTS
   Group                   # objects
   Global Command Objects  6-9
   @function Objects       3
   The WARPEDcore          1
   Parents                 10-13
   Utilities               ?
   Total                   20-26 (plus utilities)
   

   1. Global Command objects -- objects located in the Master Room which contain $commands. The WARPEDcore assumes the potential for the existence of nine (9) different combinations of powers and users. Although it is understood that not all of the following will exist on any given MUSH, it is conceivable that they could. Furthermore, it is assumed -- through discussion with seasoned veteran game gods, coders, and developers -- that separation of commands in a manner along the lines of this structure is, indeed, a recommendable approach. In summary, Global Command objects (THINGs inside the Master ROOM object) tend to have:
      
      1. three primary user groups
         • all players, including mortals (MORT)
         • admins, defined as royalty and above (ROY)
         • wizards only (WIZ)
      2. three primary power requirements
         • no extra powers (MORT)
         • limited powers which are included in the ROYALTY flag (ROY)
         • extra powers only available from the WIZARD flag (WIZ)

      Each user group tends to need $command objects with powers equal to or greater than their own power level. There is some debate as to whether or not admins and wizards need $command objects for power levels less than they possess. Nonetheless, the WARPEDcore assumes it is a possibility and accounts for it as such.

      NOTE: The WARPEDcore does not recommend, nor does it account for, optional objects having specific @powers (e.g., see_all, tport_anywhere, tport_anything). The inside track from one MUSH developer asserts that privilege checking is more robust and reliable when checking for a flag, than when checking for a @power. Therefore, the WARPEDcore restricts its design assumptions to only the above three power categories: mortal (no additional powers/privs), royalty flag, and wizard flag.

      Using the above categories of users and powers, the following nine THINGs can be derived:

      The "users" below are assumed to be upwardly inclusive (i.e., mortals == mortals, royalty, and wizards; royalty == royalty and wizards; wizards == wizards only).

      • mortal powered commands for mortal users
      • royalty powered commands for mortal users
      • wizard powered commands for mortal users
      • mortal powered commands for royalty users (debatable, but possible)
      • royalty powered commands for royalty users
      • wizard powered commands for royalty users
      • mortal powered commands for wizard users (debatable, but possible)
      • royalty powered commands for wizard users (debatable, but possible)
      • wizard powered commands for wizard users
   2. @function THINGs -- THINGs containing attributes which are applied globally via the @function command. Similar to $command THINGs, the WARPEDcore assumes the need for a variety of power levels for various @functions (The WARPEDcore project is being developed on PennMUSH. Therefore, unlike $command THINGs, the WARPEDcore does not assume delineation of user groups for @function THINGs, because PennMUSH has a built-in @function/restrict command expressly for this purpose.). And, again, these power groups are:
      • no extra powers (MORT)
      • limited powers included in the ROYALTY flag (ROY)
      • extra powers only available from the WIZARD flag (WIZ)
   3. The WARPEDcore: A Registry -- At its most basic, primary level, this term references a single object serving two primary purposes:
      • a registry for, or database of, all of the other object types. (Details about this THING are contained in the remainder of this document.)
      • a set of core @functions shared and/or utilized by all other object types covered in the WARPEDcore design.
   4. Parents
      • In the Master Room, for example, the fewer attributes that need checked for $commands, the better. One way to accomplish this is to set all non-$command attributes no_command. But a simpler method is to simply use @parent, and put all of the non-$command attributes on the parent... and store the parent in the contents of the $command THING.
      • As @functions propagate, this same method can be used to separate the primary attribute (the one actually called by the @function-ed name) from any/all of its supplementary support attributes (written on the parent, which is stored in the contents of the @function THING itself).
      • When considered from an organizational perspective, each of the above 13 THINGs (9 possible $command THINGs, 3 @function THINGs, and the WARPEDcore) could, in a minimalist configuration, all use a single parent, since parenting operates with the privileges of the child THING. Alternatively, each of the above THINGs could have a parent of its own on which support attributes of various types are kept, plus a common 'grand'-parent for shared utility functions. This, too, has been deemed reasonable as 'good design structure'. And, as such, the WARPEDcore will anticipate this type of design and will have accomodations for dealing with it.
   5. Utilities -- this object category refers to WARPEDcore utilities only. That is, objects which are included under the umbrella of 'Official WARPEDcore Distribution' objects, but which are not members of the categories listed above (an example: a global testing and debugging zone and/or widget set).

   In summary, as far as objects are concerned, the WARPEDcore Project focuses on the fact that a MUSH requires a certain number of objects to build a game's global infrastructure (not including: add-in packages like Myrddin's BBoard, or custom-built packages like chargen). In common practice, as a game grows in size, more and more objects become part of the infrastructure. How many THINGs are in your game's Master ROOM? How many THINGs does your game use for @functions? How quickly can you locate the code for any given feature on your game? The WARPEDcore attempts to provide a paradigm for an infrastructure which uses a fixed number of objects in a versatile and well-organized manner.

2. Attributes

   The WARPEDcore assumes, and is designed to accomodate and account for, several specific types of attributes. Each type has been assigned a four-digit identifier for use in other aspects of the WARPEDcore (explained later in this document).

   Type        4dig        For...
   COMMAND     CMND        attributes containing $commands
   LISTEN      LSTN        attributes containing ^listen patterns
   UFUN        UFUN        attributes called via u(), filter(), etc.
   TRIGGER     TRIG        non-$command and non-^listen attribs 
                           which should be triggered with @trigger.
   DATA        DATA        attribs which contain data elements or 
                           data structures
   LIST        LIST        attribs which contain delimited lists
   LOCK        LOCK        attributes used in indirect locks
   ZONE        ZONE        zone-specific or zone-related attributes
   HELP        HELP        attributes containing help files
   NOTE        NOTE        attributes containing notes, comments, etc.
   TEMP        TEMP        temporary storage (users should be able 
                           to expect to freely delete these without 
                           disrupting functionality)
   

   **** DBREF - One person who reviewed this document suggested that there be a four-digit prefix for indicating storage of a #dbref pointer, such as DBRF. After lengthy consideration, it has been decided that "DBREF" is not actually an attribute category. Rather, when storing a #dbref in an attribute, that attribute is more correctly categorized as a DATA attribute (or, in the case of a list of #dbrefs, a LIST attribute). Furthermore, in any instance other than a PREFIX, it would likely not be used in the four-digit form (e.g., DATA.SUPPORT_FUNCS.DBREF). Thus, there is no reason (at least not within the design of WARPEDcore guidelines) to truncate DBREF any shorter than the five characters which have become standard and common (DBREF == DataBase REFerence number, aka #dbref). -- If, however, you disagree with this and wish to have a separate category and four-digit identifier for #dbrefs, there is sufficient flexibility in the documentation options to allow this in a WARPEDcore compliant manner (see the documentation options in later sections)

   NOTE: It is possible for a single attribute to belong to more than one of the above types (e.g., 'help' files for a specfic 'zone'). Which type is primary to the attribute is, of course, a subjective assessment. This issue is further addressed later in this document.