BeastWorks CAGE (Component Assembled Game Engine)

Several libraries that can be used together or individually to build all kinds of applications

BWActions

Actions are verbs performed by or on actors.

This library consists of several component classes that can be assembled to build a behavior tree for actors to follow.

There are actions for assigning and comparing values, animating properties with splines, controlling character animation, movement, checking conditions, sending and responding to messages, running scripts, creating sounds and particles, picking, and more.

There are other actions that control the flow of logic, allowing actions to execute sequentially, asynchronously, or randomly.

BWActors

“Actor”, along with entity, element, and token, are common terms used to describe game or scene objects.

This library builds on top of components, wrapping and extending other libraries to provide a set of game-centric, general-purpose, configurable, logical, and graphical objects.

There are actors and related components that wrap models, user interface, cameras, animation, lights, models, materials, sensors (triggers), sound, shapes, terrain, water, particles, etc. Many of these are transformable (positionable) first-class actors.

Several other classes supply behaviors to actors like physics, motion, and scripts. There is currently support for bullet physics, newton game dynamics, and LUA scripting.

There are referential components like “agent” that allows actor templates or prefabs to be included.

BWAI

Classes and systems relating to navigation and steering behaviors

BWApp

Basic application interfaces and platform specific implementations using observers to monitor and control application state, update loop, input handling, etc.

BWComponent

The component library provides the component class, which integrate messaging, properties, reflection, serialization, and custom RTTI.

Components can be assembled together to form an object hierarchy that can represent a relational, logical, or graphical system.

In addition to a unique name relative to the scope of each component, a component may also have multiple tags, which can be used as a categorical labeling system and an alternative means of locating components.

The component manager and factory allow for dynamic creation, hierarchical cloning, and other features.

There are utilities for searching and traversing the component hierarchy.

BWCore

Core is required by most other libraries, defining information about the platform, custom types, assertion handling, asset-management, custom RTTI, abstract object factory template, reference-counting smart pointers/handles, logging, string hashes and tables. Some of these features should be shuffled to other libraries.

Custom RTTI is mainly for components, assets, and other objects that are usually registered with factories that need reliable type names.

BWDLLs

This is deprecated, from a time when things were Windows only and driven by plug-ins instead of scripts.

BWInput

Mostly deprecated from when the code base was built on direct input exclusively, but still stores defines for common input devices and values.

BWGraphics

Graphics obviously rely heavily upon math and core. From the bottom up we have classes for vertices, triangular faces, vertex an index arrays/buffers, lights, cameras,  meshes, materials, models, textures, skeletal animation, skinning, fonts, terrain, etc.

There’s support for loading any image format that free image allows, custom image loaders for platforms that do not support free image, any model format supported by the FBX SDK, additional loaders for 3DS, ASE, OBJ, MD5, MS3D, OGRE XML. Typically, the recommendation is convert the original format into the custom bwmodel format, which is the internal format that loads much faster with the smaller footprint on disk.

All platforms specific code is built into platform/API specific render managers that are based on a common interface, with implementations supporting DirectX, OpenGL, OpenGL ES 1.1-3.0, vertex and fragment shaders.

Currently, and intentionally, all implementations use forward rendering. Deferred rendering techniques are achievable by first forward rending with appropriate shaders to the necessary render targets.

BWMath

A set of classes and utility functions for storing mathematical data and performance related operations. Classes include colors, vectors of various dimensions, matrices, quaternions, axis aligned bounding boxes, oriented bounding boxes, rays, line segments, planes, points, angles, spheres, and intersection tests.

BWMemory

Contains a heap and block allocator, primarily used by the particle system. Reference counting and smart pointer classes should be moved here.

BWMessages

All communication between components and application is done via messages. This system previously used concrete classes for each event type but was tedious to maintain. Instead, the current implementation uses named parameters and packs data into a stream. Common system message types have utilities to simplify their creation and interpretation. Messages can be serialized to and from XML.

BWParticles

Particles are visual effects created from a system of points. This library provides classes for the creation and management of particle effects.

Particle systems are components that control the positioning, updating, lifetime, and memory management for particles. They have sub-components called particle effects.

Particle effects are components that wrap particle actions, defining the behavior of a specific particle type within a system. For example, a system might contain dust, sparks, and lightning, each of which would be a unique effect with distinct visuals and movement.

Particle actions define a single operation that affects all of the particles within an effect. Examples include applying velocity, acceleration, scale, forces, color changes, UV animation, and emitting other particles.

Particle renderers are a specific type of action that produces a geometric model for drawing the particles and an effect.

With any particle system, each particle exists in a parent, child, sibling hierarchy. The intention was to allow for tracers and streams of particles to be controlled purely by the rendering code so that more complicated effects like chain lightning to be created with the same system as explosions and magic.

BWParticleActions

Behaviors that operate on particles over time, allowing emission, position, scale, rotation, motion, and other attributes to be animated and applied. There are several actions available and the library is extendable because it is component-based. Just create a new action and register it with the factory.

BWParticleRenderers

A set of the most common methods for turning particle data into geometry. This library implements points, billboards, beams, tracers, geometric particles, and more.

BWProperties

Provides a factory, interfaces, and implementations of several common property types based on strings, numbers, math classes, file types, splines, and more.

Properties can be converted to and from each other, strings, and XML. Any class may inherit from the property owner class to allow reflection but it’s currently, primarily used by components.

BWSounds

The lightweight audio library built on top of Open AL.

BWSplines

Contains template classes and functions for interpolation and building animation curves.

BWStates

This is a set of classes for a finite state machine.

BWWindows

Deprecated library for creating Windows-based applications, update loops, and message processing. This has been replaced by BWApp.

BWXML

A custom library for reading, writing, storing XML data, it provides parsers and handlers for SAX and DOM, as well as several data conversion operators.