From Guild of Writers Wiki

Contents 1 Forward 2 Introduction 3 History 4 The Basics 4.1 Acronmys 4.2 The Creatable 4.3 The Location 4.4 The Key 5 Messaging 6 State Mechanism 7 Interfaces

Forward

Before we dive into the big pile of goodness known as Plasma, I (Tsar Hoikas) would like to state what this page is here to accomplish. This is here not to provide information on how to hack the Plasma Engine, rather, it is here to explain the basics of the engine to you. Many people seem to have false notions of how the engine does things, and I would like to correct those misinterpretations.

I would also like to ask for you to refrain from editing this page. If you see something you believe is in error or have a request, please PM me or edit the "Discussion" page because this is an ongoing project, at this point I have only written about the core, I'm likely going to wait to receive suggestions before I add more parts.

As a final note, this article will use some programming jaron, since Plasma is a bit of programming (is it not?). You are encouraged to google (or otherwise decipher) any terms you don't understand, since it will prove beneficial to you in the long term. (I guarantee it.)

Introduction

Plasma. It is the engine that runs realMyst, Uru: Ages Beyond Myst, Myst V, Hex Isle, and Myst Online: Uru Live. Impressive? I would say so. Before we get deep into Plasma, I'd like to enumerate the Plasma Versions and their games for you.

Before you cry foul on these version numbers, they were extracted from the executable files themselves by yours truly.

• 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

My knowledge centers around Plasma 2.0 with a smattering of 2.1 and 3.0, so that is where our discussion will center. I know very little about Plasma 1, so don't expect for me to talk about it.

History

Okay, just a little bit more torture before we begin. I'm going to preface the entire discussion with this, Plasma is a very old engine. Brice Tebbs (former CTO, Cyan Worlds, Inc.) has stated that the earliest versions of Plasma ran on Glide, which some of you may remember from when 3dfx's Voodoo cards were the awesome (in fact, I ran realMyst on a Voodoo 3000 with glide... Awesome). Plasma has been around since before 1998 under the name of "HeadSpin," HeadSpin was purchased by Cyan for their new game, D'ni in Real Time, which evolved into what we today call Uru.

Anyway, enough relics of the past, let's get ready to go!

The Basics

Plasma 2.0, the engine we generate our content for today has what is called a "Keyed Object Messaging System" at its core. The whole system was designed by Mark Finch (genius, he's the guy who came up with those insane Wavesets). So, let's introduce a few concepts that you need to understand in order to really understand Plasma. (

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

Acronmys

Yeah, this is the easy part... Keep these acronyms in mind.

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

Often, these prefixes will be dropped for sanity's sake.

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 these nifty things called "Locations" to tell it where in the sam hill that thing is. The location (which varies in size and structure from Plasma Version) stores three things:

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

This data is essential for Plasma to be able to lookup resources. Which brings us to our final basic concept.

The Key

Ah yes, the key (On COBBS, they are called [Uru]Object[Ref/Desc]. The key sounds simple, but things rarely are as they appear. In Plasma, the key contains the creatable ID, the location, and the name of the resource. They play a vital role in the messaging system, which we will be getting into soon.

Messaging

At its core, Plasma uses a Dispatcher to send messages to all kinds of different objects within itself. Before we get too deep into this mumbo-jumbo, I need to introduce three classes to you. They are the hsKeyedObject, the plMessage, and the plReceiver.

As you know, 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 yet another sprawling creature inside Plasma. We are most familiar with "SDL" that we define in files and use Python to synch. Well, that's not the only kind of state that Plasma uses...

Derived from the KeyedObject, we further have a fun little friend named SynchedObject, whose task is two-fold: ensure state is saved when we leave the age and how we sync 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 we do not wish to save, 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 our 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 we have control over whether their state is saved or managed manually by SDL and Python. We can further extend them by linking ObjectInterfaces to them.

Object Interfaces serve as a "gateway" of sorts to different kinds of data. We have 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 us to animate the object, if we so choose).

Generally, we send messages 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).