Mason Architecture

Mason Architecture

Version History

Hans Häggström, 2001-10-24, Draft
Hans Häggström, 2001-10-30, Reworked to four layer structure
Hans Häggström, 2001-11-03, Fleshed out the Physical Bodies section of physics, sketched in the others. Added requirement type CSS tags.
Hans Häggström, 2001-11-04, Added more stuff to the second layer, and brief lists to layer three and four.

Introduction

The Mason Game Architecture consists of four layers, that are separated with clean interfaces. The layers are Physics, Mason Platform, Mason Systems, and Content.

The Physics layer manages physical objects in the world, as well as some enviromental and material properties, such as temperature. It also handles physical attachments between items, and checking for wether they hold, break, or allow some relative movement.

The Mason Platform layer contains low level classes and interfaces that lay down the structure that more game specific item types and actions are implemented on. These include ActiveObject, Action, Connection, CommandInterface, Information Object, Skill, etc.

The Mason Systems layer implements special item types, such as Minds, Biological Bodies, Machine Parts, and so on. It also implements most of the fundamental and more complex actions, such as shaping items and attaching items.

The Content layer contains all the configurable and scriptable material, such as lists of skills and their properties, and more high level Actions that can be implemented as scripts using lower level actions and services provided by other RIMs, lists of machine parts with properties and what Actions they have, or what events they listen to and react to, or what connection ports they have and how they process packets or streams that arrive through connections. Also lists of creatures/races, along with default properties of their bodies and other parameters. Item types are also listed, along with their media, properties, and properties of any ActiveObjects that they contain.

Physics Layer

Includes:

  • Map System
    - Terrain height and material at given point and time, vertical digging, horizontal digging[extra], thin layers of material, layers of liquid. Support for item layers generated on the fly by the map system, that only store changes in the database/map system. Extra possibility support for large scale in-game generated effects such as forest fires. Also support for adding any kind of freely defined data of float, int or array of float/int type, for example climate data, animal ecology data, vegetation data, culture data, etc.
  • Physical Bodies
    • Entities
    • Ground
    • Bodies of Liquid [optional]
    • Clouds (gas cloud in container with gas, liquid cloud in container with liquid). [optional]
    • Planets [extra]
  • Containers
    • Stores physical bodies
    • Has atmosphere of some materials (can be gaseous, liquid, or just solid?)
    • Has enviromental properties, such as
      • Temperature [important]
      • Gravitation vector [important]
      • Pressure [optional]
      • Flow / wind vector [optional]
      • Light level [extra]
      These enviroment properties can depend on the location in different ways in different containers. An environment property can be:
      • global in the container, [required]
      • or just differ along the height (z coordinate?), [optional]
      • or 2D location (x, y coordinates), [optional]
      • or depend on the 3D position (x, y, z coordinates). [optional]
    • The container also works as reference coordinate system for physical bodies inside it
    • There can be many types of containers, that have different coordinate systems or storage system for bodies:
      • 3D container [required]
      • Sequential 'backpack-style' container, with maximum volume and bounding box requirements for contained bodies [important]
    • Has some kind of list of connections to other containers, and optionally keeps track of the flow of material and heat to/from the other container. This might also be used for sound progression calculation, and work as a basis of the spaces used in a portal based 3D engine, at least for indoor areas. Constructing a set of containers for rooms indoors can be a tricky problem. A map editor can help, by supplying room template coordinates that are used to build rooms and create corridors that connect them, etc.
  • Attachments
    - Static, or dynamic, that allow some degrees of freedom (rotate, move along track, move along plane). Treating a group of statically attached items as one entity, until enough force is applied to break attachments.
  • Movement
    - Apply forces created by gravitation, friction with flowing water/wind, friction against attached items, constraints of attached item(s), forces applied by the item itself, and bouyancy depending on pressure and density of surrounding medium, and density and volume of the body.
  • Collisions
    - Check collisions, send inpact events to colliding items, and resolve collision (partly elastic bounce, an attachment is formed, or the colliding items are merged (two lumps of mud), or one of the colliding items is somehow added to the other (a lump of sand is added to the ground).
  • Material Physics
    - Check if temperature, pressure, or mechanical shock passes some critical value for the material of an item, and change the material or cut attachments inside a compound item as a result.
  • Thermal Physics
    - Update the pressure and temperature properties of a container
  • Weather System
    - Keep track of current weather, using climate data obtained from map system, and major local events that can affect the weather, such as weather magic, volcanoes, smog, forest fires, etc.
Mason Platform Layer

Includes:

  • Item
    Contains reference to:
    • One shape, describing what 3D media, 2D sprite, textual description, etc should be used for this item. [required]
    • One or more shape, and the percentage between them that the item is [optional]
    • The material that this item is made of. [required]
    • A number of materials that this item is made of, and the percentage / mass of each. [extra]
    • A number of ActiveObjects, that can provide actions that this object can do, control interfaces describing how these actions can be invoked, event listeners listening to changes in the environment and running internal scripts, and extra attributes that this object has. [important]
  • ActiveObject
    - Can have attributes, actions, event listeners listening to enviromental changes, connections that transport energy(single stream, or signals(?)), matter (items and / or raw material), or information (streams or packets), to or from somewhere (usually another ActiveObject.
  • Action
    - Something that modifies the game world in some way, and is executed by an item that is an actor (a character, machine, etc. Not a hammer or other tool).
  • Control Interface
    - Interface that exposes some of the functionality of one or more ActiveObjects. Doesn't implement any own functionality.
  • Skill System
    - Skills, skill containers.
  • Material
    - Density, friction, etc, material constants.
    - Also reference to a material media description file or similar, describing textures to use, etc.
  • Shape
    - Reference to media to use.
  • Connection
    - Packets or Streams
    - Energy, Matter (items / material), Information (information objects, control / sensory streams).
    - Adressing & name system, networks [extra].
Mason Systems Layer

Includes:

  • Biological Body
  • Machine Part
  • Mind
  • Hard Coded Actions
Game Content Layer

Includes:

  • Races
  • Items
  • Materials
  • Scripted Actions
  • Media

Old content of this page, still partly to be merged:

The Mason architecture consists of several layers or systems, where each system uses only a few other systems above or below it in the hierarchy.

At the lowest level we have the Physics System that simulates the movement and temperature of physical bodies such as entities and terrain. At the highest level we have the Control System, that lets users or AI's connect to, and send commands to something that provides a Control Interface, and lets users show perception streams from the character or things they control in the client user interface.

Here's a list of the Mason systems:

  1. Map
  2. Physics
  3. Structure
  4. Actions
  5. Active Objects
  6. Connections
  7. Minds
  8. Control
In the following sections we present each system in a little more detail, listing important data structures that are used in it, and simulations or functions that it performs.

Map

Datastructures

Map Backend

The Map System will allow many different back ends for storing / fractally generating the map data. It should also be possible to use data from one back end for a certain area of the world, and from another back end for another. Mixing data from different backends might also be done in some different ways.

Initially we can store manually created maps in some suitable vector format.

Map Output Format

All the different map backends produce a similar output format, however. This is polygon based, and contains terrain, height, and possibly some other data.

Polygons in the map format could be marked as flat, smoothed, or of some certain fractal dimension at different scales. This could be used by clients to divide up a large landscape polygon when seen from close up, and make it smoother, or use a specific perlin noise or other standardized way to make the ground uneven, using fractal dimension and amplitude parameters given in the polygon data.

Initially only flat polygons would be supported, though.

Initially we also need to provide a translation layer if necessary to provide the map data in iso grid format, or in Blade format, depending on what Acorn clients support.

Functions

Retrieving map data

Get map data for a specific area at a specific resolution at a specific game date and time.

Modifying map data

Horizontal digging will probably be implemented in Mason at some point, as well as filling up areas with soil / other materials. It should be possible to dig at a specific area with a specific force(?), and get some amount of the terrain type at that position (and possibly also stones, gold nuggets, tree roots, or whatever the terrain type typically contains).

Physics

Datastructures

The physics datastructures includes different types of physical bodies, and containers, that are abstract things used for grouping physical bodies and representing the environment in an area.

Entities

Apple, house, human, etc.

Ground

Bodies of liquid

These can be tricky

Clouds of fluid

Clouds of gas in a gas, or a cloud of liquid in a liquid. These tend to spread out until they become thin enough to ignore, or fill up a container and modify the default medium of the container.

Containers

A container can contain a number of different physical bodies. A container also represents the environment for some area. It is possible to ask a container for the gravitation, flow (wind), pressure, temperature, light level, and so on, at a given point inside the container, at a given time.

There's different implementations for generating the enviromental variables. Some can be constant in some containers, such as pressure in a container at sealevel, or temperature inside a room. Others can vary according to height over ground surface, such as pressure in a container that contains high mountains as well as lower areas, and so on.

Functions

Position & Shape

Containment

Movement

Moving between containers

Collision detection

Bouyancy

If compare the weight and volume of an item to the pressure and gravitation at the current location in the container to determine if an extra lifting or sinking force should be added to the item.

Temperature

Flow (wind)

Structure

The structure system deals with attachments between items, and how attached items form entities, and when they break apart, and how complex item formations such as rooms and houses form containers.

Datastructures

Items

An item instance has a shape, or a shape somewhere between many different shapes (30% metal lump, 70% sword, for example). An item also consists of one or more materials, and it can have zero or more Active Objects, that determine it's functionality and behaviour.

Attachments

An attachment can be static (non moving rigid), or dynamic (allows movement along some dimensions of freedom (rotating door, sliding train, or moving car (held attached to the ground by gravitation normally)). An attachment has some strength, and could perhaps also contain some information about the materials / items used to create it.

Functions

Structural strength simulation

For a given set of attached objects, determine the maximal strain that can be placed on the system before it breaks apart, or needs more detailed analysis. Then tell this to the physics system that applies the forces, and have it check if there's high enough conflicting forces acting on an item(?).

Create / delete attachments

Actions

Actions are operations or scripts that some actor can perform. They have prerequirements, possibly invariants, and postconditions. They could be used by AI planners to construct plans too.

Datastructures

Functions

Active Objects

These have attributes, actions, possible ports for connections, and eventlisteners that can trigger actions. They can also contain other action objects.

Datastructures

Functions

Connections

A connection for moving energy, information, or matter.

Datastructures

Functions

Minds

Holds character memories, mental models, plans, skills, information objects and connections to the body / bodies / other minds.

Datastructures

Functions

Control

A system that allows a player to bind certain keys to invoke actions in an active object or mind that s/he has a control connection to, and also to display incoming sensory streams of different kinds in the client UI.

Datastructures

Functions

Implementation Order

We should try to follow a path that allows us to maintain a working game wile adding as small pieces at a time as possible. Initially we will use the Acorn implementation, and gradually replace parts with Mason Systems.

The Mason Systems often have alternative implementations for different subsystems, and initially simple stubs can be used, and those can later be replaced with more detailed subsystems without impacting the whole system or game.

Also, not all systems are needed initially. For example, initially a client can control a character body directly. Later we can add in a mind for the character, that relies user instructions to the character body, and also eventually adds own functionality such as scripability, skills, logging (=memory), etc.