[MUD-Dev] Skotos Bulk System - a Technical Summary (LONG)

Christopher Allen ChristopherA at Skotos.net
Fri Apr 28 19:40:08 CEST 2000


Here is another of our "Technical Summary" documents that describe
the design and technology behind our Skotos product.

As we have been focused on social interaction, the physical world
behind our game has lagged in design. Bulk is one of the "world"
properties that most all games have implemented, so I suspect that
you'll have suggestions (and objections ;-) and that you'll find
holes in it that we have not.

Enjoy!

------------------------------------------------------------------------
.. Christopher Allen                                 Skotos Tech Inc. ..
..                           1512 Walnut St., Berkeley, CA 94709-1513 ..
.. <http://www.Skotos.net>               o510/649-4030  f510/649-4034 .. 



The Skotos Bulk System - A Tech Summary
=======================================
(c)2000 by Skotos Tech Inc. <http://www.skotos.net>


Models of a Physical World
==========================
All multiplayer interactive fiction games model the physical world in 
simplified ways. These models prohibit character actions that should not 
be possible. Without such prohibitions players' suspension of disbelief 
would be broken.

Most of these systems have a model for bulk. These models might have a 
variety of results from limiting item storage (i.e., limiting character 
inventory) to modifying character abilities (i.e., reducing stamina).

Some systems also model dimensionality, allowing objects to have a size. 
These models determine whether items can fit in containers (or rooms) or 
describe the size of items relative to one another.


Approaches
----------
Many multiplayer interactive fiction systems take a minimalist approach 
to modeling the physical world.

In the simplest model of bulk, items are given a mass and containers are 
given a maximum mass. This is easy for players to understand. However, 
differing densities cause paradoxes such as a feather pillow taking up 
the same amount of space in a container as a gold coin.

Most systems extend this model to give items a bulk and containers a 
maximum bulk. Again, this is easy for players to understand. It also 
doesn't require much extra work by the world builder. However 
inconsistencies still crop up that undercut the realism of the simulated 
world.

A few systems have drastically increased the number of physical 
attributes of an item. This results in more realistic physics but also 
produces a very complex model. World builders must put more effort into 
each item. Inconsistencies and errors are common.


Problems Solved by the Skotos Bulk System
-----------------------------------------
A chatroom wouldn't require a complex bulk system. However in a fully 
featured game players will inevitably encounter complex situations 
involving bulk. The Skotos Bulk System models tricky situations such as:

   * Large winged dragons trying to get into houses. The dragon would 
     not fit through a small door (without destroying it and, possibly, 
     the house).
   * Multiple swords being shoved into a scabbard. A scabbard would be 
     designed to fit a specific variety and size of sword. And, a player 
     could stuff a scabbard with cotton in order to fit a smaller weapon 
     like a dirk (or a banana).
   * Objects being pushed through small holes. A rope could be fed 
     through a small hole into a large cave. Sadly an elephant would not 
     fit through the same hole.
   * People of different size contesting for seating room. A particular 
     oak bench might be able to seat two ogres, four humans, or six 
     dwarves.


Summary of the Skotos Bulk System
=================================
The Skotos Bulk System is built on ten attributes based on physical 
values and one attribute which is used for relative dimensionality. 
Three of the physical values are calculated.

The three basic physical values are:
   * Mass                   ( kilograms [kg] )
   * Density                ( 1000 * kg/m^3 ) 
   * Longest Dimension      ( meters [m] )

Four additional values are used primarily for containers:
   * Capacity               ( cubic meters [m^3])
   * Max Weight             ( kilograms [kg])
   * Max Depth              ( meters [m])
   * Max Entrance Area      ( square meters [m^2])

The three derived physical values are:
   * Minimum Volume         ( cubic meters [m^3])
   * Actual Volume          ( cubic meters [m^3])
   * Minimum Frontal Area   ( square meters [m^2])

It should be noted that the derived values can produce approximations 
that aren't quite correct. The idea is to arrive at a good compromise 
between data entry and realism.
 
In addition there is one special purpose attribute:
   * Relative Size          ( percentage )


Basic Attributes
----------------

**Mass**

Unit: kilograms [kg]

Mass measures the amount of matter in an object. It's the simplest 
physical measurement.

Examples:
   * A huge iron kettle will have a mass of 30 kg.
   * A wooden staff would have a mass of 1 kg.


**Density**

Unit: 1000 * kg/m^3

Density affects the compactness of an object. World builders choose 
density from a list of materials.

The densities of some common materials are:
   * Wood    0.7
   * Water   1.0
   * Iron    7.8

Examples:
   * The iron kettle has a density of 7.8.
   * The wooden staff has a density of 0.7.

A commonly used alternative to density is "specific gravity", the 
dimensionless ratio of an object's density to that of water. Thanks to 
of our choice of units, where one cubic meter of water weighs 1000 kg, 
density and specific gravity are equal in value. 


**Longest Dimension**

Unit: meters [m]

Longest Dimension is the greatest of the object's x, y, and z 
dimensions. 

Examples:
   * The cauldron is a hemisphere with a 0.5 meter radius.  Its longest 
     dimension is its width (or diameter); 1 meter.
   * The wooden staff has a longest dimension of 2 meters (its length).


Basic Container Attributes
--------------------------

**Capacity**

Unit: cubic meters

Capacity is the total volume an item can hold or carry; containers are 
the object which most often use this value. A non-container may list 
capacity to denote "dead space" inside an object.

*Capacity* limits the *Actual Volume* that may be put in a container.

Examples:
   * The huge iron cauldron has a capacity of 0.26 cubic meters. (This 
     figure was actually derived because of our understanding of the 
     cauldron's shape. The volume of a sphere = 4/3 * pi * r^3 = 4/3 * 
     3.14 * .125 = .52. The cauldron is only half a sphere, so the 
     capacity is determined to be .26 cubic meters. Other calculations, 
     guesses or real examples would be required for other types of 
     objects.)
   * The wooden staff has a capacity of 0.


**Max Weight**

Unit: kilograms [kg]

Maximum weight is how much a container can hold until it bursts, rips, 
cracks, or whatever. (The Skotos system currently assumes common sense 
and will stop all attempts to overflow a container.)

*Max Weight* limits the *Mass* that may be put in a container.

Examples:
   * The huge iron kettle could hold a great deal of weight (500 kg).
   * The wooden staff can hold nothing (0 kg).


**Max Depth**

Unit: meters [m]

The maximum depth measures how big of an item can fit inside of a 
container.

*Max Depth* limits the *Longest Dimension* of what may be put in a 
container.

Examples:
   * The huge iron kettle would have a max depth the same as its height, 
     .5 meter.
   * The wooden staff has 0 max depth.


**Max Entrance Area**

Unit: square meters [m^2]

Usually this value defines the opening of a bag or chest, but it also 
works when describing sizes of doors or openings to other areas. Max 
entrance area is actually an attribute of a detail which belongs to an 
object. This makes it simple to model an object with multiple entrance: 
there are multiple entrance details, each with max entrance area 
defined.

*Max Entrance Area* limits the *Minimum Frontal Area* of what may be put 
in a container.

Examples:
   * The iron cauldron has a circular entrance with a diameter of 1 
     meter. The max entrance area is thus equal to area of the circle, 
     which is = pi * r^2 = 3.14 * .5^2 = 3.14 * .25 = .79 square meters. 
     We could compute this figure precisely because we knew the 
     cauldron's shape; other objects would vary.
   * The wooden staff is not a container and has no entrances.


Derived Attributes
------------------

**Minimum Volume**

Unit: cubic meters [m^3]

Calculation: mass in kg / (1000 * density)

This value is the volume of the item in its most compressed form. 

Examples:
   * The minimum volume of a huge iron kettle = 30 kg / (1000 * 7.8) = 
     30 kg / 7800 = .00385 cubic meters.
   * The minimum volume of a wooden staff = 1 kg / (1000 * 0.7) = 1 kg / 
     700 = .00143 cubic meters.


**Actual Volume**

Unit: cubic meters [m^3]

Calculation: capacity in cubic meters + minimum volume in cubic meters

This values define the normal volume when the object is not in its most 
compressed form.

Examples:
   * The actual volume of the huge iron kettle = .26 m^3 + .00385 m^3 =  
   .264 m^3.
   * The actual volume of the wooden staff = 0 m^3 + .00143 m^3 = .00143 
   m^3.


**Minimum Frontal Area**

Unit: square meters [m^2]

Calculation: actual volume in cubic meters / longest dimension in meters

Minimum Frontal Area is more commonly known as the smallest face of the 
item. It helps define what an object can fit into.

Examples:
   * The smallest face of a huge iron kettle = .264 m^3 / 1 m = .264 m^2._
   * The smallest face of a wooden staff = .00143 m^3 / 2 m = .00072 m^2._


Other Attributes
----------------

**Relative Size**

Unit: percentage of "expected" size

This is the scale of an object. A relative size of 100(%) means that the 
object is average size when compared to the expectations of a normal, 
knowledgeable human. Thus relative size is independent of actual bulk: a 
ring, a chair, and a bed could each be relative size 100(%) if each was 
normal human size. The relative size system, being subjective and 
perceptual, is not directly derived from any of the objective 
attributes.

If the relative size of an object is 0(%), then it is assumed that the 
average human has no ability to measure the scale of the object. Some 
new or unusual objects might be given a relative size of 0(%) until they 
become common enough for characters to compare them, at which time they 
would get actual size values.

For more information on Relative Size, see "Relative Size - A Technical 
Summary".

Examples:
   * The .5 meter tall cauldron is a little shorter than most cauldrons. 
     Its relative size is 90%.
   * The 2 meter tall staff is about normal human size. Its relative 
     size is 100%.


Estimating Physical Attributes
==============================
The Skotos Bulk System offers a good compromise between data entry and 
realism. However Skotos StoryBuilders may want to option to enter even 
fewer values. This might be particularly important if the StoryBuilder 
doesn't have particularly good ideas about all of the physical values. 
The Skotos Bulk System accommodates this:

   * A few values are absolutely required.
   * The Skotos Bulk System will guess other values.
   * The Skotos Bulk System permanently stores the knowledge of which 
     values are guessed and which have been entered.


Entering the Required Values
----------------------------
Two of the three basic physical values must be entered for the Skotos 
Bulk System to guess the others. *Density* is required. The StoryBuilder 
will be able to choose from a list of materials. The StoryBuilder must 
also enter either *Mass* or *Longest Dimension*. 

The StoryBuilder must also declare whether an object is a container or 
not.

After the StoryBuilder has entered these values, The Skotos Bulk System 
can guess everything else.


Guessing the Other Values
-------------------------
In order to estimate physical attributes of an object based on limited 
information the Skotos Bulk System has to make some crude 
approximations. 

For a non-container the Skotos Bulk System approximates the object as a 
square.

If density and longest dimension have been supplied and the object is 
not a container:
   * capacity = 0
   * max weight = 0
   * max depth = 0
   * max entrance area = 0
   * minimum volume = longest dimension^3
   * mass = minimum volume * 1000 * density
   * actual volume = capacity + minimum volume
   * minimum frontal area = actual volume / longest dimension
   * relative size = 100

If density and mass have been supplied and the object is not a 
container:
   * capacity = 0
   * max weight = 0
   * max depth = 0
   * max entrance area = 0
   * minimum volume = mass / 1000 * density
   * actual volume = capacity + minimum volume
   * longest dimension = cube root of actual volume
   * minimum front area = actual volume / longest dimension
   * relative size = 100

For a container the Skotos Bulk System has to guess how much of the 
actual volume is the minimum volume (i.e., the volume of the container 
material) and how much of the actual volume is the capacity (i.e., the 
volume of space inside the container material). It is presumed that 
capacity is typically 90% of the actual volume. In addition it is 
estimated that there is one entrance and it takes up all of one side of 
the cube.

If density and longest dimension have been supplied and the object is a 
container:
   * max weight = based on the material given in density
   * max depth = longest dimension 
   * max entrance area = longest dimension^2
   * actual volume = longest dimension^3 
   * minimum volume = .1 * actual volume
   * capacity = actual volume - minimum volume
   * mass = minimum volume * 1000 * density
   * minimum frontal area = actual volume / longest dimension
   * relative size = 100

If density and mass have been supplied and the object is a container:
   * max weight = based on the material given in density
   * minimum volume = mass / (1000 * density)
   * actual volume = minimum volume * 10
   * capacity = actual volume - minimum volume
   * longest dimension = cube root of actual volume
   * max depth = longest dimension
   * max entrance area = longest dimension^2
   * minimum frontal area = actual volume / longest dimension
   * relative size = 100


Labeling the Estimated Values
-----------------------------
Many StoryBuilders will look at the estimated values and then enter 
their own values. The Skotos Bulk System includes features to make this 
simple:
   * All estimated values are clearly labeled as such.
   * Whenever a new value is entered by hand, all of the estimated 
     values are recalculated, as appropriate.


State of Development
====================
Development on the basic logic of the bulk system is nearly complete. 
The developer interface functionality is currently at a proof-of-concept 
level. Attributes such as strength and tentacle length will determine 
how individual characters relate to the bulk system; these checks will 
need to be implemented on a per game basis. 

Open Issues
-----------
   * Maximum depth defines the longest dimension of an item that 
     can be fully inside a container. However there are many cases where 
     it is acceptable for an item to not be fully in its container. 
     Swords are not totally inside scabbards. Pencils do not go all the 
     way into pencil sharpeners. 

   * Liquids, gases, and squishy or foldable items are not yet modeled 
     by this system. The addition of some boolean values could possibly 
     remedy this.

   * When you pick something up, should we give some additional info 
     about it such as: "It's heavy," "It's unwieldy," "It flops around," 
     etc.? How about throwing in the "Touch" info automatically for the 
     object?

   * In particular games, we will want to display non-metric units.

   * Entering additional information such as the rough shape of an 
     object could allow for better estimations. This might be worth 
     doing at some point.

   * Exactly how to recalculate the estimated values when one new value 
     is entered by hand is not clear. An algorithm tree to allow for 
     every possibility would be complex. Currently, as many of the 
     formulas as possible are written in a way that they will 
     automatically recalculate correctly.




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



More information about the mud-dev-archive mailing list