Guild of Writers

The Plasma game engine was developed by HeadSpin Technologies and afterwards by Cyan Worlds. It was open-sourced in 2011 under the name of the CyanWorlds.com Engine (CWE), and is now independently being developed by Open Uru, H'uru and various other third parties. The name of Plasma is now more-or-less synonymous with CyanWorlds.com Engine, which constitutes the open-source release of the engine.

History

Plasma is an extremely old engine dating back from 1997 when it was still being developped by Headspin (at that time, the engine itself was also called Headspin). Headspin was purchased by Cyan Worlds the next year for their new game, D'ni In Real Time, which eventually evolved into the game known today as Uru. There are various versions of Plasma, with several games corresponding with each:

Plasma 1
- realMyst
Plasma 2.0
- < 63.11 Uru Live BETA
- Build 63.11 Uru: Ages Beyond Myst/To D'ni/Untìl Uru
- Build 63.12 Uru: The Path of the Shell
- Build 69.X Myst Online: Uru Live [Beta, Live 1 - 4]
- Build 70 Myst Online: Uru Live [Live 5+]
Plasma 2.1
- Crowthistle
- Myst V: End of Ages
Plasma 3.0
- Cosmic Osmo's Hex Isle

Knowledge about Plasma generally centers around Plasma 2 and 3; in the case of Uru, only Plasma 2.0 is of interest.

Games

Plasma has been used in all of Cyan Worlds' real-time games (the various mobile platform games excluded), including:

Open-Source

Cyan Worlds open-sourced the Plasma engine on the 6th of April 2011 under the name CyanWorlds.com Engine. The repositories for the source code as released by Cyan can be found at the OpenUru.org Foundry.

H'uru Fork

The Guild of Writers' H'uru team is developing a fork of the CyanWorlds.com Engine aimed to lower the barrier of entry to Plasma development, fix bugs, and add features. The H'uru fork of Plasma currently requires a DirtSand server to function. MOSS and MOULa are unsupported as of now, however, the H'uru client does work on those servers to a limited degree. Offline single player has been considered, but not implemented. For more information, see the Open Source Task List.

Basics

Plasma 2.0, the engine used for Uru for today has what is called a "Keyed Object Messaging System" at its core. The entire system was designed by Mark Finch (former Plasma programmer held in great esteem by some GoW developers). A few concepts are therefore required to understand Plasma's inner workings.

Note: All of that applies to 2.1 and 3.0 also, except for the "generate our content" bit.

Acronyms

Throughout the code and documentation, several convetional acronyms are used (although it is possible that they are dropped occasionally to simply matters):

hk - Havok
hs - HeadSpin
pf - Plasma Feature
pl - Plasma
prp - Plasma Registry Page (often simply called "Page" or "Node")
px - PhysX

The Creatable

Plasma stores the bulk of its data in classes called "Creatables," meaning that they can be created on-the-fly by the Plasma Factory. Each creatable has its own 2-byte index... Notable creatables include all of the main PRP classes and all messages.

The Location

Plasma uses objects known as "Locations" to know where a certain object is located. The location (which varies in size and structure from Plasma version to version) stores three things:

The Age's Sequence Prefix,
The PRP's Sequence Suffix (found in the .age file),
The PRP's Flags.

This data is essential for Plasma to be able to lookup resources.

The Key

The deceptively simple-sounding key (also called [Uru]Object[Ref/Desc] on COBBS) contains the creatable ID, the location, and the name of the resource. They play a vital role in the messaging system, detailed below.

Messaging

At its core, Plasma uses a Dispatcher to send messages to all kinds of different objects within itself. Three classes need to be explained before tackling further subjects. They are the hsKeyedObject, the plMessage and the plReceiver classes.

As you know, a creatable can be created on-the-fly. Receivers, are derived from creatables and expose a new layer of functionality: they can receive messages sent from the dispatcher. KeyedObjects further derive from this functionality by adding a Key, which serves as a unique identifier for the object (and a header). Messages, which also derive from Creatable, can be sent via the dispatcher. Messages specify a Key as its sender and a list of Keys that it should be sent to. Many classes further expand the functionality of Message and KeyedObject, telling the engine when to render, what to render, conditions for certain events and much more.

State Mechanism

The state mechanism is another sprawling aspect of Plasma. Developers are most familiar with "SDL" that is defined in files and use Python to be synchronized. However this is not the only kind of state used by Plasma.

Derived from the KeyedObject, there is a class named the SynchedObject, whose task is two-fold: ensure state is saved when the player leaves the Age and how the game is synced over the network (this responsibility is removed in Plasma 2.1 and 3). SynchedObject has an extensive amount of flags, several of which have to do with state and which states shouldn't be saved, or, as Plasma labels them, Excluded States. The bulk of the objects contained in the PRPs are derived from SynchedObject.

Many objects in Cyan's Ages choose to exclude all of the persistent states, yielding to a manual state mechanism such as SDL and Python, which offers better (and more sane) multiplayer control.

Interfaces

Entities that control the world in Plasma are stored as SceneObjects, which can have visible geometry (or not), have collision (or not), have attached audio (or not), and advanced modifiers (or not). These SceneObjects are derived from SynchedObject, so control is preserved over whether their state is saved or managed manually by SDL and Python. They can further be extended by linking ObjectInterfaces to them.

Object Interfaces serve as a "gateway" of sorts to different kinds of data. There are interfaces that specify geometry in the "big geometry object," a simulation interface that specifies the flags of the simulation, audio interfaces that control if audio is playing, how it's playing, etc., and coordinate interfaces that describe the orientation of the object (which further allows developers to animate the object, should they choose to do so).

Generally, messages are sent to these interfaces to do many essential tasks such as disabling rendering, turning the sound on/off, positioning the objects, and suppressing the physics (something Cyan does quite often).