FLAMES^® programs do not contain any software that simulates the behavior of real-world systems. All such software resides outside of FLAMES programs in components. Components are stored in component plugin libraries (or, “plugins” for short) that are loaded dynamically by FLAMES applications. By using FLAMES with the desired set of plugins, you can simulate almost any system in almost any scenario imaginable.

After you install FLAMES on your computer, you will also have to get the components you need to create your desired scenarios. You can download FLAMES components from the FLAMES Store, acquire them from a third party, develop them yourself using the FLAMES Developer, or contract with Ternion or a third-party to develop them for you.

The FLAMES content available in the FLAMES Store often includes component plugins, example scenarios that use the components in the plugins, and documentation for the components and scenarios. Source code to most of the components in the FLAMES content is available in the FLAMES repositories.

Types of Components

A FLAMES component usually simulates the attributes and behavior of something that exists in the real world, such as a human, vehicle, sensor, communications device, or weapons effect. This type of component is often referred to as a “modeling component” or simply a “model”. Other types of “infrastructure” components are also supported, such as a view overlay, a management service, or an interface to an external system.

In every case, a FLAMES component is implemented as an individual software class that inherits one of the FLAMES primary classes. The primary classes define the overall structure of the component class and provide a wealth of built-in functionality the greatly simplifies the development of the component class. FLAMES defines a primary class for every type of component that might be required in a simulation.

FLAMES supports many different types of components, including those described below.

Unit Models

Every independent, interactive player in a FLAMES scenario is referred to as a Unit. The functionality of a Unit, including its ability to move, sense, communicate, think, and influence other Units, is composed using FORGE by attaching models to the Unit. The primary types of models that can be attached to Units are cognition, equipment, and attribute models.

Environment Models

Environment models store data that describes the natural and man-made environment in which a scenario takes place or data that applies to the overall scenario and not to specific Units. FLAMES supports several different types of environment models.

View Overlays

View overlays display supplemental information over the top of the 2D and 3D views of FORGE and FLASH. Just about anything can be drawn in an overlay, from simple lines and text annotation to full instrumentation for a heads-up display. Each overlay class can also define a view preferences object that will automatically be included in the View Preferences windows of FORGE and FLASH.

Service Components

Service components extend the functionality of the FLAMES Engine and are extremely powerful and flexible. Examples of service components are interfaces to external systems (such as image generators and live systems) and services that cause additional processing to be performed during scenario execution. All of the FLAMES options are implemented as one or more service components.