CAST II Game Engine

Introduction to CAST II

This article is a brief overview of the engine with many details omitted.

Core

A user application should use the core to manage the engine. Core is an instance of TCore class and is responsible for entities and subsystems management.

Subsystems

Each subsystem is responsible for some functionality (rendering, input, timer, etc). If its implementation is a platfrom/API dependent the subsystem is implemented in the form of a platfrom/API independent base class and its platfrom/API specific descendants. The platform independent super class serves as an interface to the subsystem.

Subsystems can be connected or disconnected during runtime

Scene

CAST II operates on entities which are organized in a hierarchy called scene.

Usally scenes are built in the engine's editor CAST II Editor (CASTEd) and stored in a .cbf file. Some parts of a scene such as levels can be stored in separate files and loaded on demand.

Scenes can be created from the code as well, but it's not an easy way.

Scenes are managed through engine's core. For example, to load a scene the TCore.LoadScene() method should be used.

Entities

Visible objects, cameras, textures, sounds and so on are entities -- instances of TItem class or one of its descendant classes.

Each entity has a name and entities can reference each other by the name. For example, a visible entity references to a material which should be used to render the entity.

Also entities can send and receive messages to/from other entities, the engine's core or application.

Entities has a list of properties. To get the list the TItem.AddProperties() method should be used. To set - the TItem.SetProperties() method. A certain property can be set by the TItem.SetProperty() method but it's more convenient to use the editor.

All game-specific objects are inherited from and/or composed of suitable entity classes.

Main cycle

Each iteration (frame) of the application's main cycle the TCore.Process() method should be called. The method is responsible for the following tasks:

subsystems synchronization
subsystems querying for messages
scene update
scene rendering
asynchronous messages handling

Messages

All important events such as user input, OS messages, various game-specific events and so on are converted by the engine into messages for further handling. CAST II based application can add its own handler to handle messages which were not handled by the engine or which requires a game-specific handling.

Messages in CAST II are object-oriented -- each message is an instance of a class which is inherited from TMessage. A message is identified by its class. This allows to include an arbitrary set of data in a message and handle messages hierarchically.

The messages are sent by means of TCore.SendMessage() or TItem.SendMessage() method. By combining various flags messages can be sent to:

a certain entity (mfRecipient)
immediate childs of a certain entity (mfChilds)
All entities down through hierarchy starting from a certain entity or from the root (mfBroadcast)
core handler which will forward the message to the application-specific handler (mfCore)

mfAsync flag specifies that the message should not be delivered immediately but at the end of the main cycle (before the next iteration).

Message are handled in the HandleMessage() method of entities, subsystems and the engine's core. Application also usally should have such method to include it in the message handling chain.

Scene update

Some entities should periodically update their state -- coordinates, animation frame, current AI task, etc. Such entities should be inherited from TProcessing class (all visible entities are) and override the TProcessing.Process() method which is called at the moment of the update.

The updates can be performed with a fixed frequency or once per frame (delta time based). Also updates can take into account (or not) simulation pause mode. All these settings can be tuned via so called processing classes which are properties of a scene root item.

The TCore.Timer subsystem is used for time calculations

In CAST II Editor processing classes can be created and modified through a scene root item's properties. The groups of properties is called "Processing". A processing class is assigned to an entity via selecting the desired processing class as a value of entities property called "Processing class".

Physics

At the moment only collision detection based on a set of bounding volumes (spheres, oriented boxes) implemented. A fully-function physics subsystem planned which will not depend on actual implementation library (Newton, PhysX, etc).

TProcessing.Colliding object contains all physics-related representation of an entity such as collision geometry, physics parameters and so on.

If an entity has a set of bounding volumes the built-in collision detection system will call TProcessing.OnCollision() method and generate a message when a collision is detected

Rendering

TCore.Renderer subsystem is responsible for rendering. At the moment DirectX 8.1 based renderer implementation is available. DirectX 9.0c and OpenGL 2.0 implementations are planned in the future.

Scenes are rendered through cameras (TCamera). So at least one camera is needed for a scene to be rendered. A property TCore.Renderer.MainCamera determines currently active camera. A camera can be referenced by a material (see below) as a texture.

An entity will be rendered when the following conditons are met:

the entity is an instance of TVisible or one of its descendant classes
the entity has a properly initialized tesselator -- an auxiliary object responsible for geometric representation of the entity. Usally initialized automatically.
the entity has a proper link to a material -- other entity responsible for rendering settings
the entity as well as all entities up through scene hierarchy has the visible flag set (isVisible included in TItem.State).
the entity is at least partially inside active camera's frustrum

Materials

Material is actually a three-level structure of entities (TMaterial, TTechnique, TRenderPass) which incapsulates all settings affecting visual appearance at rendering API level of entites to which the material is assigned.

Material itself (TMaterial) simply contains a set of so called techniques. At least one valid (see below) technique should be present in this set.

Technique (TTechnique) is an entity which specifies a way by which a material can be rendered. Often a material can be rendered in many ways with different detail level and hardware requirements. For example, for a camera which rendering a texture for reflections a lower detail level can be specified. Technique contains a set of render passed (TRenderPass), and a level of detail (LOD) assigned to it. If all the render passes can not be used for some reason (usally hardware incompatibilities) the technique will be marked as invalid. For rendering usally the first valid technique will be choosed by renderer but that choice can be affected by a detail level required.

A render pass is also an entity which actually contains appearance settings such as API states, textures, shaders and so on.

Input

For user input in CAST II is responsible TCore.Input subsytem which allows to bind to input events (key pressing, mouse moving, etc) and arbitrary sequences of the events one of the following actions:

a message dispatch -- bound with TInput.BindCommand() method
a delegate call -- bound with TInput.BindDelegate() method
an operation with memory referenced by a pointer (unsafe, so not recommended to use) -- TInput.BindPointer()

The following syntax is used to describe input events in bindings (EBNF)

BindElement =(<Key><Specifier>)|<Gesture>"^"
Key = A key name
Specifier = ","|"+"|"-"|":" - can be omitted at the end of the binding ("," will be assumed)
Gesture = "MouseMove"|"MouseMoveH"|"MouseMoveV"|"MouseRoll"| "MouseStrokeLeft"|"MouseStrokeRight"|"MouseStrokeUp"|"MouseStrokeDown"| "MouseStrokeLeftUp"|"MouseStrokeRightUp"|"MouseStrokeLeftDown"|"MouseStrokeRightDown" Binding = <BindElement> {<BindElement>}
Specifiers:
"," - click
"+" - key down
"-" - key up
":" - double click

Examples:

Alt+Q - the binding will be activated when user press Alt, then click (press and release) Q (without releasing Alt)
A,B,C - the binding will be activated when user click A, then B and then C
A+B,A- - the binding will be activated when user press A, then press and release B and then release A
RMB+MouseStrokeDown^MouseStrokeRight^RMB- - the binding will be activated when user hold right mouse button and move the mouse down and then right releasing RMB. This gesture is similar to one used in popular Opera browser to close a window.

A maximum timeout between two consequent events can be specified in binding method call

Game development outline

The outline with CAST II is as follows:

Game content (models, textures, artwork, sounds, etc) is imported into CAST II Editor. In the editor visible objects, cameras, light sources, materials and other entities are created and placed within the game world.

In order to create game-specific classes in CAST II the classes shoul be imported into the editor via its plugin system.

The saved scene can be loaded and tested in target game application at any moment.