We could have our actor 'act' all the movements and control inputs - OR - we can simulate the system and have the actor react to that simulation. the latter results in a better performance and a more realistic outcome. The actor can react to the simulation in real time and the simulation can be reset at any point.
So that's more narrative driven takes in less time.
We're using a standard UB connnected joystick here, Axes 0 and 1 are the X and Y movement, and Axis 2 is the thottle movement. It goes from -1 to 1 so we've normalised this to 0..1
The 'Trigger' is on button labelled 1 (actually 0 in code), we've connected the DOWN event to 'Throttle Boost' of 120%. The UP event returns the throttle to its last known position.
We're using button 8 (7) as a Simulation Reset event.
There's a linear relationship to power output based on 'rpm' and 'load' along with a second relationship between 'rpm' and 'throttle'. In this way when load is increased 'rpm' will fall as in the case with a real engine.
'engine' temperature is a function of power output, cooling factor and time. There's a tiny amount of 'jitter' in the cooling factor so that the 'engines' do not have exactly the same temperature.
Here's a fragment of the code:
'Overheat' and 'Failure' are thresholds. 'Overheat' simply issues an alarm event whereas 'Failure' stops power output and therefore we see the 'remains' of the 'engine' cooling down.
Overall the simulation is emitting events for: