[MUD-Dev] Creating a MUD - Overview of design

[J C Lawrence]

On Fri, 01 Feb 2002 01:10:31 -0700 
Bruce Mitchener <bruce at cubik.org> wrote:
> Amanda Walker wrote:

>> Figure out what your game does and doesn't need, *then* start

> Really, in an ideal world, this is what someone would do in all
> cases, for all aspects of the server, including persistence,
> memory management, threading models, not just networking protocol
> choices.

An old rule of thumb to distinguish what items should be developed
and maintained in house, and what should be farmed out, licensed or
otherwise externally maintained:

  How close is it to your core competency?

The classic example being router companies (ala Cisco, Juniper,
etc).  Every last scrap of their products relating to routing
packets and switching, etc is in-house.  Cisco in particular
aggressively shovels the rest of it, err, out-house, even if they
had to originally develop it to support their router products
because it is not part of their core competency.

Scripting language design, network layer/protocol design etc easily
seem to haunt the middle ground for MUD developers, close enough to
necessary to keep in-house, yet far enough out to be uncomfortable.

I tend to break it down this way:

  -- Some games and services sell off marketing schtick or whiz-bang
  vender-specific technical features (cf video card marketing).  In
  those case those items are your care competency and must be
  in-house (cf Quake).

  -- Ultimately your core competency for a MUD is in defining the
  game and then presenting that game to the player.

  -- A game-internal scripting language, if exposed to end-users
  (ala MOO), is your core competency.  You may initially base off an
  externally sourced item (eg CINT, Python) but you'll need to
  maintain and develop it in-house.

  -- If its only exposed to in-house admins/developers then
  it is close to your core competency but not necessarily part of
  it.  The language must allow your game to be expressed (where
  your game features and definition are core), but the language
  itself, outside of that expression, really has little to do with
  your service.  Depending on how you define your admins and
  content authors within the user base you serve (eg "We allow
  authors to create and express...") it could be in or out of
  house, with the overwhelming tendency being out-house.

    -- The primary criteria in internal scripting language then
    become:
 
      a) Expression of necessary features.

      b) Ease of use for expressing needed constructs

      c) Ease of education of users so that can express needed
      constructs with it (ie the "familiar language model").

      d) Integration expense of an externally sourced item versus
      in-house development (as a lost and growing sunk cost).

  -- Network protocols and stack implementations are really only
  faintly connected to service offerings.  Well, not unless you're
  talking about a technology demonstration ala the video card
  commentary above.  They're necessary but don't actually render an
  end user experience.  Generally perfect to farm out.

    -- The historical problem is that the network model is so
    ingrained with the data model that it has to be developed
    in-house.  The design may be based externally, but due to
    integration requirements has to be developed and maintained
    in-house.

      -- Which really just says that the protocol stacks and
      definitions for the space are not yet well enough developed or
      standardised.  There's a lack of canned, externally sourced
      solutions which are "good enough" in particular for graphical
      MUDs due to the data model problems.

None of which addresses the problem of "Which do I choose?", just
"where do I get or keep what I've chosen?"

--
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw at kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev