[MUD-Dev] Star Wars Galaxies: 1 character per server

[Koster]

From: Travis Nixon

> Your "mathematical proof" was based on one extremely faulty
> premise: that the maximum number of players is based on database
> space, that the maximum number of players is somehow directly
> related to how many characters each player on the server has, when
> its actually a function of how many people are playing online at
> the same time, and what percentage of your players tend to be
> online at the same time during "prime time", both of which are
> figures that have absolutely nothing whatsoever to do with how
> many characters each player has, since each player is only playing
> one character at a time.

Hmm. I think you are making a generalized assumption concerning
persistence models.

I used to cite a spectrum of persistence models for muds. In some
early muds, for example, the only persistent data was actually your
character. I remember when LPMuds started adding the ability to save
your equipment (!)  which is something taken very much for granted
nowadays. There was also the gradual addition of elements such as
saving your corpse in the game database, should the game server go
down, so as to minimize the amount of losses there. Then gradually
more elements such as housing were added, and so on.

Brad McQuaid calls this the "extended character state" model.

The opposite model is the "world state" model where everything is
persisted.  MUSHes and MOOs use this model. Naturally, the storage
requirements are larger than they are for merely storing character
state. UO had significantly more storage needs than EverQuest did,
for example.

The world state model permits various player freedoms and
expressions beyond the extended character model. Most particularly,
it permits dynamic items belonging to no particular player. (Whereas
the extended character state model permits dynamic items only
belonging to players; everything else in the world is static,
cyclical, or at best resets itself when the server is rebooted).

To go further within these models, there is also the issue of how
templatized the data stored actually is. In most muds, if you have
"Doombringer, the Sword of Death," and so do several other people,
all that need be saved is a single pointer to the Doombringer
template, since the items do not vary significantly. There may be a
few extra values stored independently, such as perhaps a damage or
decay value, and then of course there's the practice of "stringing"
to replace the description... The more flexible the item system is,
however, the more data must be stored there.

Now, since this apparently endless discussion was begun by SWG, I
should explain that SWG uses an extended character state model that
attempts to provide the benefits of a world state model. We do not
persist everything in the game, not by a long shot. In fact, there
is no dropping of items on the ground (which was probably a
significant percentage of the world state in UO at any given time,
at least until the decay times were made more aggressive!).

However, the list of things that we do persist is pretty
extensive. A single character record in SWG consists of the
following:

  - The character, which has the usual statistical array of
  attributes and states, the usual text storage for a player
  bio/description, etc. In addition to the familiar, however, SWG
  adds in various niceties for 3d, such as around 30 different
  customization values for appearance which must be both stored and
  transmitted over the wire; a suite of matchmaking data for the
  in-game matchmaking service; the player's email inbox; a set of
  "badges" for task completion; and a few other things.

  - the character's equipment. This is also fairly typical. Figure
  25 items here. Keep in mind that an item in SWG is *completely
  dynamic*. Almost nothing about it is templatized. This is because
  the game relies heavily on a crafting system, and therefore every
  single statistic about the item must be stored, rather than looked
  up from a template. In addition, it incurs storage for visual
  customization, etc. This makes items fairly heavy.
 
  - the character's inventory.

  - the character's datapad, which is a secondary inventory for
  "data items" which include waypoints, missions, etc.

  - The character's house.

  - Every item within the character's house.

  - The character's shops (yes, multiples).

  - All the furniture within each shop.

  - The character's vendors, each of whom incurs a fair amount of
  customization storage, like a player, only without the
  player-specific niceties.

  - the character's vendors' equipment.

  - all the shop stock on each vendor.

  - the character's permanent installations, such as the minin
  facilities, factories, and so on that he can drop in the game, and
  which remain active 24/7 regardless of his presence. A character
  is allowed a lot of these. (And yes, they also vary statistically,
  since they are also crafted items).

  - the character's pets, droids, or hirelings. These may also
  change statistically over time (in SWG, when you tame a baby
  bantha, it eventually grows up to a big bantha if you can keep it
  alive).

  - Any equipment or inventory that pets, droids, or hirelings may
  have.

  - Any items that the player may have placed up for sale on someone
  else's vendor.

  - Any items that the player may have placed up for auction on the
  in-game marketplace (it's an in-game auction system similar to
  eBay in some ways).

This is for characters only. In addition to this, SWG uses a partial
persistence model for its world state. Most spawns and encounters
are non-persistent and are re-created from the relatiely static
spawn data, just like most muds. However, we have a class of spawned
entities that DO persist and that provide a dynamic layer to the
spawning system. These lairs, as we call them, appear on the
landscape and remain until destroyed.

Lastly, there's another important thing to consider. SWG, like UO,
has an arbitrarily extensible data structure for any object. We use
a system we call "objvars" or "object variables," which are full
variables of any data type that can be attached to any given object
and accessed and modified via script. These also persist. Object
variables are relatively heavy, so if the data is something that
will be frequently used, we put it in the data structure of the
object itself, but if not, we attach it and detach it as needed. So
the base data structure for an object is not necessarily of a known
size, dependent on the needs of the game system.

It is important to note that most of the items listed above are
online regardless of whether or not the player is. At this point,
the issue of simultaneous players becomes lower in significance for
the calculations, just as it does in a true world state model.

> Hard drives are cheap, and databases scale much more easily than
> network connections and bandwidth requirements.

Suffice it to say that we are talking about multiple terabyte
databases here. Even with all the various customization elements
that we stream down, SWG fits comfortably within the pipe of a 56k
modem--and we haven't turned on network compression yet. Yes, hard
drive space is cheap, relatively speaking, but the price of a
dynamic world is a lot of storage.

This doesn't even get into the savings we've made. Our fractal
terrain is equivalent to 140 gigabytes of storage on your hard disk,
discounting any flora.

-Raph

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