High Level Design Series: Fn Layers (ie Presentation vs BizLogic vs Data Models)

[Shem (aka MadScientist)]

I've been mulling over all the MUDs I've ever seen, heard about, or been able to peek at source code ... One of the things that strongly jumps out at me about MUD projects is how oven specific chunks of code are trying to do more than one thing at the same time.  This leads to code that is harder to maintain, extend, or support.  Plus, I like clean code.  To avoid this as much as possible, I decided I needed a high level map of what MUDs actually are trying to DO, in advance, so that I don't wander across too many functional borders (at least accidently) during my implimentation(s).

It appears that all MUDs (TinyM*, DIKU, LP, etc) have a core set of functional requirements that break down into the following functional categories.  I'm not convinced this list is complete at even this hierarchy tier; and it can definitely be extended.  However, I've seem to have hit a wall on thinking up entirely new non overlapping functionality areas.

MUD Core Requirements (ie Functional Layers:

• SANDBOX-FENCE - Infrastructure Boundary
• SECURITY - Anti Hacking, Spoofing, & Piracy
• LEGAL - Anti-Litigation Process & Documentation
• POLICY - Admin Toolbox (MUD, Players, Staff, etc)
• NETWORK - Sockets, Souls, Possession, & Binding
• USER INTERFACE - Presentation (Past, Present, & Future)
• WORLD (Obj Model) - Events, People, Places, & Things
• SYSTEM (RPG) - RPG Mechanics (Creation, Advancement, Skill Checks, Combat)
• SOCIAL - Gossip, Chat & Channels
• IDE - Editors, Compilers, & Language(s) Support
• DOX - Training, Support, & Sales & Marketing (S&M)
• STORY - Interactive Fiction Layer
• SERVICES (External) - FTP, WebHost, Social Media, Wiki

Can you folks think of anything that this list doesn't cover?

[chaos]

Admin interface is a meaningful topic distinct from user interface (or player interface, if you wish to consider admins properly a subset of user), policy and "IDE" (which I would call development, IDE is a term laden with specific significance).

As in other software engineering contexts, QA is probably meaningfully considered as a distinct (if far from separate) topic from development.

Persistence layer is a matter of such significance that I would draw a box around it separately from world, system and story.

Some MUDs have a commerce layer.

[chaos]

By commerce layer I meant player-to-MUD real-money commerce.  Player-to-player in-MUD commerce support is also a major item.

[Shem (aka MadScientist)]

Thanks for the Feedback.

COMMERCE - Good Idea!  (It had slipped my mind)

IDE ==> DEVELOPMENT
Whoops!  I typically try to NOT use overloaded/ambigious english words in planning, and you are right; IDE is a very overloaded term for this.

ADMIN UI   - I'll have to think about this.  Is this a presentation layer or task layer type issue?
   ie    Admin Toolbox (ie Dead Souls Admin Tool)
               + Modifications to Interface for custom tools
  or
         User Interface Layer
               + Players
               + Admins (... etc)
 or
        Admin Tool/Interface (something)
               How would this be described, functionally?

 

[Shem (aka MadScientist)]

Erk, I forgot two items.
QA - This one is a strange one.  SOME of this would be in the documentation layer; some would be in the Dev layer (ie any testing harness stubs, etc), and some of it would be external to the product itself (ie defect tracking).  However, as a Persistant RunTime Development Environment, as most MUDs are ... its almost like I need a PROJ MGMT layer to encapsulate feature planning/triage, release planning, player bug reports, deployment process, regression testing, etc as part of the produt itself.  I am not sure how to model that part of the software lifecycle inside of a MUDlib.  *Ponder*
PERSISTENCE - I had originally considered it part of the World OBJ Model; however, you are right ... the really cool things aren't possible unless its a major priority.  In fact, its almost a DEPLOYMENT/ROLLBACK + Continuity issue.  Good catch!
 

[quixadhal]

If you want real persistence, and you also want an LpMUD, my suggestion is to use DGD with one of the mudlibs that was designed to be persistent (Gurba and Phantasmal, I think).

DGD utilizes the concept of starting from a state dump, which restores the entire LPC state machine, along with all objects and whatnot, with the only things needing to be addressed as reconnecting player sockets and whatnot.  In fact, I believe the last thing I saw Dworkin working on was a "warmboot" idea that also preserved sockets and so forth.

It also has the concept of atomic code segments, which act like relational database transactions.  You can enter atomic code and everything done from that point on will either succeed or be rolled back on failure.

Dead Souls (FluffOS) features a lighter form of persistence, where states of world objects are saved and restored, but I don't think it would do things like letting you resume combat right where you left off before a reboot.