Interactive simulation occurs when humans control or interact with simulated players. Many gaming, testing, training, and mission rehearsal systems make use of interactive simulation, such as PC-based action games, full-motion pilot training simulators, embedded command and control system trainers, and large-scale military training exercise systems. In each case, the full scenario comprises live humans and simulated players.
FLAMES® supports interactive simulation through its Interactive Client and Interactive Server features. Interactive simulation can also be supported with FLAMES using DIS and HLA. Some of the differences between the Interactive Client/Server features and DIS/HLA are explained at the end of this page.
Interactive Client and Interactive Server
The FLAMES Interactive Client and Interactive Server features are a collection of services that allow external systems to interact with FLAMES as it executes a scenario. The Interactive Server feature executes within FLAMES during scenario execution and allows FLAMES to act as a simulation “server”. The Interactive Client feature is a software library containing several high-level functions that can be called within any external system to allow it to interact with FLAMES as a “client”. Together, these two features manage interactive execution and all client/server network communications.
When executing FLAMES with the Interactive Server enabled, the majority of the functionality of all simulated players usually resides within a single instance of FLAMES. Multiple client systems can then execute simultaneously on separate computers and communicate with FLAMES over a computer network. These client systems allow human operators and real-world systems to extract information from and exercise control over the players represented within FLAMES.
If the client system is software, the Interactive Client functions can be bound into the client and called directly from the client software. If the client system is hardware or software that cannot be modified, an intermediate client application can be developed that communicates with FLAMES using Interactive Client functions and communicates with the hardware or software system in any manner that is supported by the system.
The functions in the Interactive Client library conduct all communications with FLAMES. Client systems do not need to perform any low-level network operations or be concerned with any protocols or communications standards. Clients interact with FLAMES using high-level functions that in many cases are identical to the functions used by software that runs within FLAMES. Developing client systems is, therefore, quite straightforward and communication with FLAMES is very reliable.
Client systems can interact with FLAMES to perform a wide variety of operations, including:
- Establish and terminate a network connection with FLAMES
- Pause, resume, and terminate the execution of a scenario
- Alter the scenario execution rate
- Create, delete, kill, and revive players in the scenario
- Request and receive true spatial state data on all players in the scenario at a specified interval
- Redefine the composition of players in the scenario and alter the tasks that players are to perform
- Attach to and take control over one or more players in the scenario
- Query a model attached to a player for the value of its internal attributes
- Set the value of internal attributes for a model attached to a player
- Issue commands to a player or the models attached to a player
- Specify that the client system should be notified when a command is issued to a player within FLAMES, so that the appropriate action can be taken by the client system or the human operator of the client system
- Direct FLAMES to perform several administrative functions, such as enabling additional data recording, loading new data from the FLAMES scenario database, or creating a checkpoint file
Embedded Command and Control System Trainers
As explained on other pages, FLAMES provides robust support for simulating communication systems and for modeling real-world messages with realistic content. One of the unique features of the Interactive Client/Server is allowing a client system to send a message to any player in the scenario or to receive a copy of any message sent to any player in the scenario. This capability provides the foundation for FLAMES well-established ability to support embedded command and control testing and training simulations. Through an intermediate client system, real-world command and control systems can become interactive participants in a FLAMES scenario using their native message sets. A low-overhead, FLAMES-based simulation running on a single computer can provide the synthetic environment for one or multiple command and control systems. Several command and control testing and training systems have been developed for U.S. and international militaries that exploit these features of FLAMES.
The Interactive Simulation option is enabled without a runtime license in a FLAMES Runtime Suite application if the application is executing with only the bundled components loaded. Therefore, you can try it out using the free copy of the Runtime Suite. If custom component plug-ins are loaded, a runtime license to the Interactive Simulation option is required to enable the option. Runtime licenses must be purchased separately. In addition, ALL of the custom component plug-ins loaded by the application must have been developed on computers that were licensed for the Interactive Simulation development option.
An Interactive Simulation option development license is required in order to create custom component plug-ins using the FLAMES Development Suite that support the option. Development licenses must be purchased separately. As stated above, the functionality of the Interactive Simulation option is enabled in an application only if ALL of the component plug-ins loaded by the application were developed on computers that were licensed for the Interactive Simulation development option.
Comparing Interactive Client/Server to DIS/HLA
While the FLAMES Interactive Client/Server and DIS/HLA have some similar capabilities, the Interactive Client/Server features are fundamentally different from DIS/HLA. Some of the major differences between the two approaches are summarized in the table below.
Interactive Client/Server Approach
|Designed to allow humans or external systems to control simulated players that are resident in a simulation.||Designed to allow simulated players (entities) that reside in different simulations to interact over a network.|
|Interaction between simulated players takes place within the simulation, where network bandwidth and latency limitations do not apply.||Interaction between simulated players takes place over the network, where network bandwidth and latency limitations can seriously reduce the performance of the simulations.|
|Data is transmitted between the server and clients using efficient, reliable point-to-point network communications.||Data is usually transmitted between simulations using complex and sometimes unreliable broadcast or multi-cast network communications.|
|No communication protocols are required.||Complex communication protocols must be followed by all simulations (such as DIS PDU standards or HLA FOMs).|
|An image of each player in the scenario is usually not required in each client. Therefore, no network resources are required to keep these images up to date.||An image of each player in the scenario must usually be maintained in each simulation. A large amount of network bandwidth can be required to keep these images up to date.|
|System models can be the same for each simulation, helping to create a “level playing field” that makes results more reliable.||System models are different for each simulation, which often causes results to be questionable or unreliable.|
|Models used in interactive simulation can usually also be used in non-interactive, analytical simulation.||Models used in distributed simulation are often not suitable for use in non-interactive, analytical simulation.|
|A single terrain database can be used for the entire scenario thereby eliminating terrain database correlation issues.||Each simulation uses its own terrain database. Correlating these databases is often difficult and sometimes impossible.|
|All scenario inputs reside in a common database that can be edited by one set of tools.||Each simulation has its own input database and scenario editing tools.|
|A single set of post-processing tools can be used.||Each simulation has its own post-processing tools.|
One of the potential limitations of the Client/Server approach is the requirement for a large computer to host FLAMES when large scenarios are being executed. This limitation is becoming less of a problem as computers get faster and support larger amounts of memory. In addition, scenario execution speed can be increased by FLAMES’ support for multithreaded scenario execution that exploits the power of today’s multi-processor and multi-core computers. In some situations, scenario execution speed can also be increased by executing the scenario using multiple instances of FLAMES, each of which executes a different part of the scenario. The instances of FLAMES can then communicate with each other using DIS and/or HLA.