Actor_Model_Introduction

Overview

Actors are the principal operational elements in Magic Lantern and provide the fundamental programming abstraction and compositional unit. The granularity of actors in a title is determined by the title author. A brick, a wall, or an entire building could be reasonably implemented as a single actor, depending on title requirements. Practical limits of space, time, and conceptual complexity will constrain what actors will be. However, the authoring architecture imposes no overriding constraints.

The goals of the actor object model design are to:

• create a set of abstractions of a world sufficient to express most common application entities and their inter-relationships,
• provide flexibility in the construction, editing and debugging of actors and titles at authoring time, and
• allow creation of efficient mastered titles.

The actor design expresses an object model in which actor state is embodied as properties, and methods determine how the actor responds to stimuli.

The Magic Lantern actor object model is implemented in C++ and Java, depending on the platform the title author is targeting. The Magic Lantern object model, like that of C++, provides for abstraction, encapsulation and inhereitance. The Magic Lantern model is simpler than that of C++ in that it supports only single inheritance. It is also only an object model. It doesn't attempt to provide analogs to C++ language features like operator overloading.

Actors are also containers for other actors. At runtime, actors will be organized to represent containership, inherited geometrical relationships. At the present time, the design is to support a tree structure rooted by an actor that contains state and features for the entire title. An alternative is a more general directed graph. In either case, Magic Lantern will provide mechanisms for traversing and editing aactor containership hierarchies.

Functional Requirements

• Properties and methods can be added at authoring time, exetnding actors that have been previously compiled.
• Properties and methods can be accessed by external objects that know the owner is an actor, but don't have knwoledge of the specific type of actor.
• Actors can define local properties that have their own namespace and are accessible only by the actor itself or other actors with special knowledge of this particular actor type.
• Property and method access within an actor, or by objects that are familiar with the specific actor type (by including its header file), is efficient.
• Methods can be implemented in actor source code (C++/Java code attached to an actor as part of its definition), in compiled code added at authoring time, or in scripts.
• Actor overhead is low, meaning that an actor that contains nothing and does nothing is very efficient in time and space.
• Approximate size of player libraries and binary (text segment)