System Overview - magic-lantern-studio/mle-documentation GitHub Wiki

Table of Contents

There are three primary portions in the first-level decomposition of the Magic Lantern project:

  1. authoring tools,
  2. core data structures (SDK), and
  3. mastering modules.

There are interfaces between each pair, and each breaks down into finer decompositions.

Authoring Tools

The tools are the most visible part of the project to the end user, the author of the applications. The tools provide the user interface, implementing the authoring metaphors. Of primary concern to the tool development effort is maximizing the expressiveness of the author through high-level operations and very high usability. The important parts of the authoring tools suite are as follows:

  • Composer. This component enables the user to create scenes that contain autonomous objects, the actors, that implement the interaction and presentation of the title. The composer is similar to, but much less functional than, a traditional 3D modeler. It does not allow for the creation of a 3D model, or the description of sophisticated animations (other than those that are described purely by code).
  • Actor Class Editor. This component provides support for the creation of new actors within the system, those actors being the unit of action and autonomy within the title.
  • Actor Editors. Acting in conjunction to the composer, the actor editors allow for specific tailoring of actors to describe title-specific states and behaviors. These editors are often specific to the design of the actors they control.

Core Data Structures and Algorithms

At the core of the Magic Lantern system is a set of data structures and algorithms that describe the execution of the titles that can be produced. These components define a multimedia virtual machine, tailored to the description of real-time, interactive, 3D titles. Of primary concern to the development of these components is the ability to describe compelling titles, using highly expressive computational structures tailored to interactive titles with lifelike characters. Additionally, in the Rehearsal Player, the ability to debug, instrument, and carefully control the title under rehearsal is key.

The major pieces are as follows:

  • Digital Workprint. Referred to as the DWP, this item is a file format that describes all elements of the title under production. It is extensible, in that tools can add new objects to its definition, and thus is a generalized object store. The two major facets of the DWP are its syntax (allowing for the storage of arbitrary objects) and its prescribed semantics (allowing for the description of specific Magic Lantern objects).
  • Rehearsal Player. This is a suite of components that act as an interpreter for the information specified in the DWP. The rehearsal player is integral to the authoring process; within it the author exercises and incrementally improves the title. There is a complex underlying structure to the player, including the actor model, a messsaging system, timelines and scripts.
  • Actor model. The unit of autonomous action within a title is called an actor, which is a mixture of data and code. The visible data of an actor are called properties and the code is divided into portable and non-portable portions. The portable part computes the behavior of the actor, responding to incoming messages and other global state. The non-portable part, called roles, delivers the visible/audible manifestations of the actor to the player of the title. Scores describe time-deterministic animations, scripts provide algorithmic prototyping, and messages allow the actor to make requests of or pass information to other actors. Within the rehearsal player are time-variant data structures, called the title and actor store, that keep track of the execution progress of the titles.
  • Behavioral specification. As a separately described capability, a methodology for describing the desired "compelling behaviors" is stated. Using this methodology, an author can create actors that interact with their environment, which includes other actors and global conditions.

Mastering to Targets

In Magic Lantern, mastering refers to more than the traditional definition of media conversion and laying out the bits on the final distribution medium. In Magic Lantern, mastring refers to the process of converting the specification in the Digital Workprint into a form that executes efficiently on the target platform.

The components of the mastering project are as follows:

  • Code generator. Starting with scores, scripts and other specification information within the DWP, this part of the process generates code or data files that are efficient representations of those structures.
  • Runtime player and libraries. There is a runtime player for Magic Lantern titles which is identical in semantics to the Rehearsal Player, but potentially fully different in implementation. Underlying the player is a set of portable APIs (not necessarily represented by portable code) that allows for the enhancement of portable code in actors.
  • Media converter. All media assets used in the definition of the title and its simulation on the workstation must be converted into a form that is suitable for the target palyer. Magic Lantern provides a set of media conversion tools to cover this need, as well as DWP-scanning tools that find what needs conversion.

Player API

This section discusses the data structures and APIs that are internal to the player. These concepts and APIs survive to the runtime. The APIs may be used by authors creating actors, roles, or stages - supported extensions within the Magic Lantern framework.

The Player internal components include:

  1. Actors, the autonomous unit of action within a title. Actors contain the code that implements behaviors as well as code for presenting themselves as delivered media.
  2. The actor store, which supports modular addressing of actors by other actors.
  3. Roles, those parts of actors that create the presentation of the actor using media libraries.
  4. The stage, which provides a programming interface for roles.

Functional Requirements

  1. Provide a model powerful enough to describe any title.
  2. Provide a simple programming model for actor creators.
  3. Allow customization of actors, roles, and stages.
  4. Allow extension of actor capabilites through behaviors.
  5. Define components that can be mastered into time and space efficient representations.

Actor Model

The actor model specifies the fundamental programming abstraction employed by the Magic Lantern SDK. Please refer to the following document for more detailed information: Actor Model Introduction.

Actor Store

The actor store is the current collection of actor instances while the Magic Lantern title is running. Please refer to the following document for more detailed information: Actor Store Introduction.