[MUD-Dev] Distributed Processing

[John Buehler]

Here's a new screwball idea for folks to munch on from the 'JB Files'.

Organize a game's server farm along skill lines.

This means that the algorithms and data devoted to a certain skill in
the game world are all on a machine or machines used only for that
skill.  For example, archery, or tracking, or baking, or some the
blacksmithing skills, etc.

Such an approach seems to have interesting features:

  1. Geographic concentration of character does not automatically
  produce increased specific machine loads.  Fluctuations in machine
  loading comes from fluctuations in skill use.  I theorize that, in
  large populations, skill usage will tend to remain in a reasonably
  consistent range and can be designed to.

  2. Each machine represents a skill and stores data specific to that
  skill on every object in the world.  This means that the world
  becomes modeled along the lines dictated by each skill.  An
  interesting case might be the use of any objects as a shield or as a
  club.  The 'bashing' skill machine, or more generically the 'combat'
  skill machine.

  3. Balancing loads on machines gets interesting.  I can use a 90MHz
  machine to deal with a rarely-used skill, while my skill machines
  that deal with combat will be large and many.

  4. The code space could be quite tiny, and the system can be tuned
  very specifically for the skill system implementation.

  5. Clients could communicate directly with skill machines, and
  vice-versa, instead of having many, disparate requests going through
  central servers.

  6. The obvious: multiprocessing.

While the goal is to have all data pertinent to a skill on the one or
few machines handling that skill, there will inevitably be data needed
from other, more generic systems.  Geographic location is a prime
example.  To deal with this, I can imagine a big ol' machine that does
one thing: sorts positions of objects using a quad tree or some such
thing.  That machine is responsible for answering queries about
objects that fall in certain areas, or handling automatic
notifications when an object reaches a certain geographic state.

For example, when an object moves into the defined 'upwind' area of a
bear's sense of smell.  The smell system manages only the perception
of smell for all characters, including the animals.  When the object
moves into the 'upwind' area, it gets notified.  It looks at its own
data about that object because it is 'scent' data and it owns that
data.  It's local.  Then it decides whether the brain running that
bear needs to be notified because it succeeded in actually noticing
the scent.

The brain is yet another machine.  It might be a big, honking system
that deals with all animals in the world, actually simulating them.
Or it might be a small machine that only does bears in a certain
geographical area.  Or bears are naturally limited to a geographical
area and they just don't leave that 'preserve'.

An obvious challenge here is ensuring that the crosstalk between
machines isn't so high that the machines spend a disproportionate
amount of time just processing all the local network traffic.

To continue the bear's sense of smell example, the weather machine
notifies the smell machine of changes in wind direction, permitting
the smell machine to notify the geographic machine to make changes
about when the smell machine should be notified.  To avoid having some
kind of 'movement to geography to smell to geography' round trip every
time the bear takes a step in order to update the geography machine's
area of interest for the bear's sense of smell, the geography machine
would have to be able to represent relative areas and such.

I also would like to see some scalability with respect to the AI being
tossed into the games.  If I can succeed in partitioning the AI
control of NPCs away from the rest of the system, then I can control
NPCs either automatically or by a gamemaster by rerouting messages
away from the AI machine and to the gamemaster's machine.  Further, I
can just treat the player's client as a generally untrusted
gamemaster's machine controlling a particular character in the game
world.  The 'scalability' comment arose from the desire to be able to
throw arbitrary amounts of processing power at the AI without
impacting the responsiveness of the system in general.

Anyway, I find this whole idea intriguing, but I've hardly begun to
play with the idea in any depth.

JB


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev