System

The Skycastle game engine has a concept of System designs, which are component based, modular ways to define procedural content and systems.

Composition
A given System defines a set of primitive Components, which are implemented in code. Primitive components and other components can be connected together to form a new component.

Instantiation Parameters
A component may take zero or more parameters, which are specified at instantiation time. The component can use the parameter values to calculate parameters for the components it consists of.

Some instantiation parameters may be impossible to change later for a component, while others might be freely configurable, and others require some rebuilding to implement. This should probably be specified as some kind of metadata for the parameters. (E.g. switching a light bulb on or off could be done at any time, while changing its colour would require some re-configuration and raw materials (color filters), but changing its luminance would be impossible without creating a new light bulb instance).

Run time Connections
A component may also have zero or more connections to other components. The connections are defined at design time (although they can be modified in-game on run time too). On run-time, in-game, the connections can move information objects, or energy, or matter, or money(?), etc. between the components.

In-game Instantiation
A component can be instantiated in-game, by building or acquiring all the primitive components it needs, with the instantiation parameter values specified by the component. The primitive components are then connected together according to the component design. This requires the availability of suitable raw materials (or existing components), the knowledge of the necessary skills, and the availability of suitable tools.

Typically the instantiation process is automated, so the player just specifies what component design to instantiate, and the game will schedule the necessary activities.

Out-of-game Instantiation
A component can also be instantiated by the game system itself, or by a game designer / system admin. E.g. a music component could be played as background music, or a noise used as sound effect. In these cases the primitive components do not need to be instantiated as physical game objects (or processes/performances), but can instead be run directly.

To facilitate this, the primitive components could perhaps have two instantiation modes or levels, one in-game, that lists raw material, tool, and skill requirements, and fails if the entities are damaged, and one out-of-game, that doesn't have any requirements, and isn't embodied by any in-game entities.

The out-of-game instantiation could also be used for previews of a system, e.g. listening to a music design being constructed, or viewing a house design.

Exactly how this will work for different Systems might vary, we'll need to go through them on a case by case basis, and see if there is some room for generalization.

Component Libraries
Components can also be shared, using an online system component library. Anyone can set up a library (typically it will be set up with when a game server is set up), and anyone can use components from a library (under an open license - either use a creative commons share alike, derivatives allowed license in all cases, or allow users to specify their own creative commons license if necessary). Component designs can also be shared and traded in-game (but anyone in-game should probably have access to the online component libraries). A game/editor client can connect to several libraries at once (and use some mechanism to automatically find them too).

An online component library could also have a web interface implemented for it, that allows browsing and downloading and discussing and rating components (these functions would be available from the editor application/game client too).