* Recognition/naming thoughts:
  * once a particular object is seen and identified, it should get a specific memory entry for it, so repeatedly looking at it doesn't keep triggering a memory check for the class of object and thus eventually succeed.

* Transactions will need to intercept:
  * Object attributes
  * Object creation/destruction (how to handle assignment of IDs on creation?)
  * Connection IO - note that this has to be at the post-postprocessing level, for example if a <obj/> referrs to an object that's been destroyed.
  * Connection state changes
  * Connection state info
  * Connection disconnect
  * Connection terminal change
  * Connection attachment change
  * User info change
  * User creation/deletion
  * Addition of events
* Module reloading will need to be an atomic action (all other threads suspended). Ideally, if a module load fails, we load the previous version.

* I looked at mpMUD 'version 1' (the circle clone) and found
  * These commands that we don't have now: cast eat assist kill score
  * Might be worthwhile to retrieve the text from the old 'advance' command and use it for something:
    | <self> looks at you oddly.
    | 
    | ...you feel a strange sensation as the world around you fades to black, then is
    | replaced by a swirling mass of colors which suddenly jumps at you, producing
    | such an explosion of light that your eyes hurt...
    | 
    | When you can see again, everything has returned to normal, but you feel...
     

* Symbol objects: everyone can refer to them, and they can't be manipulated; they stand in for a concept. e.g. "open chest with force".
  * ideas for symbol objects:
    * force (with force)
    * hiccups (give hiccups) :)
    * enthusiasm
    * love
    * Some socials would turn into symbol objects: hug, kiss, etc. This way we can borrow the existing consensual 'give'.
  * Some of them will actually affect an action taken (i.e. force), some of them are moods, and some of them are just silly

* Idea: Invocation of object_find can be told what the 'context' is for purposes of defaulting to objects (tho we'll need a defaulting system tied into parsing)...e.g. "open canteen" puts the canteen in as generic default, container default, and drink default. 
If something happens in a direction, then "there" is appropriate.

* Multiple styles of object listings in 'look'. multiple lines, one line, amount of info on each object, etc.

* Have player object (or maybe connection) keep a list of objects that are currently visible to it. This allows unique identification of objects without revealing object IDs, easy way to have objects as commands, and also hopefully makes can_see cheap.

* inactive player bodies: maybe turn them over to the NPC AI engine? Leads to "Sorry, your character died while you were away", though.

* Have definition of floor material and _slope_ - easy to make a slippery, icy mountain, or a wooden house's second floor.

* Instead of using a trie for commands, perhaps keep a hash of ALL abbreviations => [list of cmd names matching]. Advantage: O(1) lookup time, instead of O(N) where N is length of string. Disadvantage: possibly memory-gobbling.

* Modules
  * Two types of modules:
    * current evaluated-Perl-code
      * Regularize field/verb/command/hook/method definitions into one system
      * Maybe turn them into actual Perl modules
      * Remove requirement to re-eval them to remove definitions
    * "pure definitions" (can be rewritten from in-memory data)
      * Allows modification of source code and help text from MUD interface
      * Subroutines must be stored as code AND text. 
  * Modules should have some sort of ID string at top to allow recognition

* Motion verb (walks etc.) affected by room, e.g. deep mud, and mood

* Communication:
  * Limit punctuation allowed in speech
  * Directed speech automatically sets volume
  * LegendMUD's moods: http://www.kanga.nu/archives/MUD-Dev-L/1998Q3/msg01141.php
    * Perhaps moods could be affected by last social

* A sort of guideline I thought up:
  "I want to be able to cast a weight-reduction spell, strap on some sufficiently wing-like devices, and fly, without requiring any "enable flying" hook on either the spell or the wings."
  * Well, maybe the wings.

* Templates:
  * Objects can be constructed given "templates". A template is essentially the definition of the form of an object; for example, there would be a "sword" template, which requires a hilt, and a blade, and the blade must be such a shape, and sharpened; HOWEVER, the template does NOT specify materials for the objects; a magically-supported sword made of ice is perfectly acceptable.
  * The purpose of templates is to give objects functionality: if the 'sword' template didn't exist, then the blade and hilt could not be used as a weapon, and possibly could not even be fastened together in the appropriate fashion.
  * Templates are knowledge belonging to the character.

* Have everything said [to / in the same room as] certain NPCs to be echoed in a certain room in administrator-land. This way, any non-busy administrator can quickly take over the NPC and respond.

* Combat:
  * body_pos shouldn't know about combat; combat should be moved to the 'doing' architecture.
  * Three combat "actions", which you can choose a mix of:
      Attack: Cause damage to opponent.
      Defend: Prevent damage to self.
      Protect: Prevent damage to other.
    
  * Another thought: It's easy to produce a fatal injury (provided one has a weapon, of course), so most of combat is attempting to injure the other _while not getting hurt yourself_. Therefore, invulnerability would be quite helpful, in that you don't have to worry about protecting yourself, BUT it doesn't mean that combat will be over instantly, because your opponent is protecting himself (blocking or dodging your attacks)

  * Damage
    $object->damage(
      type => <str:damage type>,
      by => <num:damage amount>,
      from => <obj:what caused damage, this is the weapon, not the wielder>,
    );
     
    The actual damage taken should be affected by the victim's armor, but not by the victim's skill at dodging/parrying attacks - after all, you might be damaged by stepping off a cliff.
    
    Flexible armor (even if it's chain mail) is more likely to result in bruises etc. than stiff armor (leather, plate)
    
    * Damage types:
      Impact
        Piercing
        Slashing
        Blunt
        Falling
      Elemental
        Fire
        Cold
        Electricity
        Water
        Acid

* World thoughts:
  * Seen in rec.games.frp.dnd: <news:slrn9lkccm.nal.neelk@brick.cswv.com> might have some interesting ideas
  
* Commands:
  * Argument parsing built into the command interpreter:
    * Benefits:
      * Auto usage messages
      * Auto help usage info
      * Helpful errors
      * Command defs can call regular methods
        * Problem: Many commands don't use world-objects or have optional objects. No methods there.
  * A hypothetical path of execution, loosely:
    > burn enemy
    self->do("burn enemy")
    | obj = self->object_find("enemy")
    | self->do_generic_verb("burn", obj)
    | | action = self->find_method_to_perform("cause_damage:fire")
    | | | obj = self->find_object_can("cause_damage:fire")
    | | \ return obj
    \ \ self->do_action(action, obj)

* Logging
  * Implement two types of logging:
    * An 'observer' object that sits in a room and logs nact()s, etc.
    * A 'logger' object that records everything every player in the room sees and does, including informational commands like 'who'.
  * Players ought to be informed if they enter a room being logged
  * User viewpoint:
    * Any events occuring in the world MAY be logged.
    * However, it is reasonable to assume that they aren't, IF the following applies to your character:
      * You are in a room with all doors closed.
      * There are no NPCs present.
      * You have no association with a deity.
    
* If has_bp object gets removed from a broken container, then its position should be changed to 'sitting' (or perhaps body_pos.mod is asked to do some sort of "lose balance" check?)

------- These ideas have been implemented -----------

* Have command to display graph of logins/logouts over last N hours, something like:
   # on   - off
            | 3a  4a  5a  6a  7a  8a  9a 10a 11a 12p 1p  2p  3p  ]
   Boffo:   |#############---------------------------------------]
   Marn:    |---------------------###############################]
 ->Bubba:   |--------------------------------------------------##]
   Player5: |####------------------##################-----------#]
  * This will prevent "I never see anyone else here!" in the early days of a mud.
  * Info will be gathered by scanning a dedicated logfile storing logins and logouts.
  * Player should be able to set local timezone?

* Problems with references as object fields: either completely disallow them (not good idea) or establish an API that works equally well for in-place modification or copy-change-write.

* Definition lists:
  * Current non-standardized examples: obj fields, obj methods, obj verb defs, hooks, commands, command aliases (will be generalized-synonyms)
  * Things that ought to be def-lists: connection states, command interpreter search (cmd_match)
  * Description
    * Each definition list is a MDefList object. MDefLists are created by adding entries to a root MDefList
    * Def-lists are 'mirrored' into (tied?) hashes (e.g. obj fields list is mirrored into %MObject::Fields
    * Def-lists have the following attributes:
      * Duplicates allowed? (e.g. hooks vs. obj fields)
      * Type of data (scalar, code-ref, hash-ref, array-ref)
        * Have a 'code-or-hash' type for methods/verbdefs/commands
        * Hash type can specify allowed fields.
    * Entries can be added from Perl modules or mp modules.

* Structure
  * Extract player management from MConnection and move it into 'MPlayer'. One MPlayer object exists for each PC in world (keeps track of ID for reconnection), 

* Instead of integrated code, functionality is implemented by "modules" which contain:
  * Methods for MObject (including field accessors, or maybe have some sort of "constraint" field system, e.g. "This field contains an array of MObjects")
  * Fields: Should be flexible - no _fixed_ field set, but modules can declare "implicitly accessed" fields ($obj->field).
  * Commands
    * should be able to specify min levels, and an arbitrary number of constant 'base levels' - e.g. specify "rnew: level <immortal> and up"
  * Should be able to test for existence of modules
  
* Commands
  * Should have automatic handling of object specifications: one, several, all, specific one.. but some commands can't take more than one (e.g. wear, sometimes), and what command syntax to use? perhaps:
    "widget" "widget.all" "widget.2" "widget.x5"
    Or should I implement a generic parser, so that it can recognize, say, "all widgets", "4th widget", "5 widgets"?
  * Include commands for generic actions (rub kick poke spin turn pull stomp throw or whatever), to   
handle things like BM's clan key, etc.

  
* Make sure _ALL_ paths are specified thru File::Spec or similar tool
  * Perhaps "MFile" class, inherits IO::File, but ->open() accepts only /-delimited relative paths, converting using File::Spec.

* Character advancement:
  * Should have 'types' of chars, in place of the <31, >30 level-makes-you-immortal system: perhaps "player, immortal, builder, admin, coder" etc.
  * Or maybe flags, e.g. "immortal" "can build" "can script" "can change world" "can modify core"...

* World thoughts:
  * Should be able to find out things like "all players in zone". Perhaps something like @{$ZoneRooms{'/core'}}.

* Output:
  * More detailed action outputs, for situations such as: invisible char makes noise. What do others see?
    * So have structure for:
       AVMsg => '<self.name> <self.is?scream:screams> and <self.is?jump:jumps><trap.vis? away from <trap.name>>!',
       AMsg => 'Someone screams<trap.vis? in the vicinity of <trap.name>:>.',
       VMsg => '<self.name> jumps away from <trap.name>!',
       trap => $thing,

       AVMsg => '<self.name> <self.is?yelp:yelps> and <self.is?drop:drops> <w.pname>!',
       AMsg => '<self.name> yelps.',
       VMsg => '<self.name> <self.is?drop:drops> <w.pname>.',
       w => $weapon,
       
       ('<self.name> <self.aud?<self.is?yelp:yelps>:><self.aud?<w.vis? and :>:><w.vis?<self.is?drop:drops> <w.pname>:>!',
        w => $weapon,
       );
    * Lowercase fields in structure are object refs or IDs.
    * Field 'self' is NOT implicit, because parser's "self" will be VIEWING object, not initiating object.
    * Condition syntax: <obj.field?truestr:falsestr>
    * Fields:
       .name of obj,
       .pname possessive name, replaces 'the'/'a' with his/her
       .is msg sending to this obj?,
       .vis receiver->can_see(object)?,
       .aud receiver->can_hear(object)?,
       .gendern .gendero .genderp gender nominative, objective, possessive
    * Also have "alias" feature, something like <!sdrops> expands to <self.is?drop:drops>
    * AMsg and VMsg will never be seen by the originator of the message, so they don't need <self?:> conditions.
    * <obj.name> actually behaves like <obj.is?you:<obj.name>>.
    * Perhaps...make the <> replacements work for ALL text output, that way we can make use of the 'memory' data in room descripts etc.

* Error handling:
  * All calls to code not part of the engine (e.g. module field handlers, commands, scripts) should be eval()ed.
  * Try to make core routines give good errors instead of randomly failing when they get bad args (or if object info is mangled).
  * In general, engine should be bulletproof (e.g. when checking prototype inheritance, check for nonexistent prototype)

------- These ideas have been discarded -----------

* Error handling:
  * Maybe Perl object scripts should be wrapped in a Safe?

* World thoughts (these were discarded)
  * Rooms OPTIONALLY have absolute positioning, if they do, then exit directions are auto-set from relative locations.
    * Rooms then are considered to have zero size, thus being not "boxes", but nodes in the graph of the MUD's visitable world.
    * Imms get display of distance walked, for information/zone layout checking
    * Positions should be 3d, coordinates: ew, ns, ud.
    * Zones should have absolute-position offsets defined in .zinf files.
  * Player ability to modify and/or destroy rooms. Destruction should "file away" the original rooms.

* Instead of specific subroutines for setting fields in MObject, have some mechanism to notify those who need to know when an object field changes.

* Crossing between mpMUDs (maybe)
  * Special login sequence - something like "name? PORTAL-CONNECT"
  * Accept connections only from MUDs on a list
  * Connections to other MUDs are represented as portals - should include list of connected players.
  * If connection to other MUD breaks, send appropriate message.
  * DON'T attempt to parse normal output from the other mud.
  * Don't save equipment anywhere but "home" mud.
  * Don't copy objects directly (field incompatibilies, too-powerful, too-weak weapons), but use corresponding prototypes, and create nonfunctional "virtual" objects if no prototype.
  * Allow virtual objects from other MUD in originating MUD?
  * Thought: A MUD with lots of portals to other MUDs could serve as a gathering place/"RWHO"ish system.
