Runtime control
This section describes runtime control, application state, and common expected behavior of client applications. Note that all of this is optional. For some applications, state is irrelevant, but applications that implement one or more of the states should probably consider the entire idea of what’s described here.
A typical simulator application can go through the following states, triggered by runtime control messages in parentheses:
Initial -> (Load scenario) Loading -> Ready -> (Start) Running -> (Pause) Paused -> (Start) Running -> (End) End or (Stop) Stopped -> (Play) Playback -> (Pause) Playback Paused -> (Play) Playback -> (End) Playback End or (Stop) Playback Stopped -> (Reset) Initial
To conform to the above state handling, a simulator application should:
- Initially present a “home screen” - with no environment or simulation models active
- Load a scenario when receiving the load scenario message, publish geometry and any other static information, but not start the simulation, publish entities or any other dynamic information
- Start the simulation at time = 0 when receiving the start message
- Pause the simulation and clock when receiving the pause message
- Continue the simulation when receiving start while being paused
- Stop the simulation when receiving an end message
- Destroy all entities, stop the simulation when receiving a stop message
- Return to the “home screen” or similar initial state when receiving a reset message
To support playback, a simulator application should:
- Go into “observer mode” (or whatever is appropriate) when receiving the play message
- Be able to spawn entities and react appropriately to position and state messages, from other simulators as well as those published by the application itself during simulation
- Not publish any entity or state information during playback
- Optionally support simulate-from-playback, which means playing back for a while, pausing and then starting a simulation from that state when receiving a start message
See the runtime control protobuf definition for more reference information.
Scenarios
A scenario typically specifies an environment model, initial position of entities in the world, and possibly pre-defined behavior of entities (the “game mechanics”). A scenario can be loaded right before a simulation starts. If you were to develop a training simulator, there would probably be a scenario designed for each “lesson” or “training session”.