Chrono in Unreal, part 9: The sequence
The demo runs nine minutes without intervention and has to show the same thing every run although the physics is not reproducible to the second: a wheel grips earlier once, the boat beaches later once, the drone’s battery is at 15 percent at 487 seconds once and at 490 the next time. This part describes the sequence as what it is, a phase programme with events as transitions. The series: part 1 overview, part 2 architecture, part 3 traps, part 6 parasail, part 7 drone, part 8 light.
The demo the series is about. On YouTube in 1080p the console is readable.
Who conducts
The vehicle pawn is the conductor. It holds the vehicle’s autopilot as a state machine with eight phases, it knows the state of the drone, the parasail, the ball game and the pufferfish, and it is the only place where scenes are switched. The other actors have small state machines of their own, the boat its waypoints and the beach run, the drone its twelve flight steps, the ball game holding, throw, catch, wide throw, fetch, but they do not decide when the demo moves on. They report states, the pawn switches.
That is the one rule that keeps the course stable: a scene begins when the previous one has reached its state, not when a clock has run out. There are clocks, but they start on an event and measure from there.
The programme
The times are those of the shown run; they vary by a few seconds from run to run.
Start (0 to 16 s). Engine off, the driver waves at the drone hanging in front of the windscreen. At 12.5 s the starter, at 16 s throttle. The drone climbs into its orbit. The boat with the parasail starts its laps off the coast at 4 s, far away, and is only heard in the vehicle when it comes close.
Course (to about 60 s). Over the sandbank, the cobble field, the stones, a slalom around the boulders, the ramp. The drone follows in its orbit, the autopilot drives waypoints with a pure pursuit, with the guards from part 2 that hold in every phase.
Dune (about 60 to 90 s). At the foot of the dune, as soon as the vehicle points uphill, the selector goes to 2. The climb starts with open differentials and full throttle. When the speed drops under 8 km/h the centre and the rear lock, and the vehicle gets up. On the crest the locks open again. That is an event, not a time: at 68 seconds in one run, at 70 in another.
Drift and drive to the north beach (to about 125 s). 22 seconds of drift behind the dune, then via two waypoints to the north beach, a short drift over its own tracks. At the transition to the beach the ball game is relocated to the coast, onto a shore line 1.3 metres above the water, so the loop around the players stays clear of the wash.
Beach (about 125 to 215 s). The step sequence along the water’s edge: eastwards on the dry sand as a run-up, a turn inland, then the run westwards at full throttle on the firm wet sand of the 0.3 metre line. On this run, when the vehicle is about nine seconds from the players, one of them throws the ball too far, onto the lane. The vehicle’s guard sees the ball in the lane and brakes from over 50 km/h to a standstill while the second player runs across the lane and fetches it. In the soft sand the vehicle then backs up and pulls forward four times, every direction change with half a second in neutral, before it drives on. Then on westwards on the dry sand to the turning point. The height of the lane above the water is the control variable here: in the wash the saturated sand takes ten km/h off the vehicle, and the braking comes from 46 instead of 55.

Jetty and jump (about 215 to 262 s). A turning point 150 metres south of the ramp, a line-up 70 metres inland, then the full-throttle run north over the jetty’s ramp, whose end is kicked up. The vehicle flies, hits the water in the pool at the end of the jetty, the four wheels go in within half a second. The drone switches to the chase. The phase is done when the hull sits on the water surface over deep ground, or after 60 seconds.
Floating (about 262 to 300 s). With the water the engine goes off, the hull rocks on the swell, the coasting wheels push as paddle wheels. The hull floods, the vehicle sinks in thirty seconds and lies on the bottom; its pose is logged, because it is the reference point of the last scene. The pufferfish comes two seconds after the sinking begins.
Drone by day (about 262 to 343 s). While the vehicle is still going down, the drone flies one lap around the wreck, climbs to six metres and makes its low flight to the dune crest, the start point, where it arrives after a good 300 seconds. The camera on the left is meant to switch to the parasail only once the vehicle sits fully on the bottom. In the shown run it switches at 271 seconds, nine seconds after the water entry, while the roof is going under: the condition compares the world clock with a point in simulation time and fires twenty seconds early while the recording countdown runs. The video was kept as it was recorded.
Evening (from about 343 s). The evening begins with an event, not a time: the drone is up on the crest, and the pilot is done surfing. 40 seconds after the crest, as soon as the feet are out of the water again, the transition fires; until then the drone circles slowly up there. From here on the clocks of the night run, all relative to that moment. Immediately: sunset, exposure fixed, the drone dives from the crest to the canopy. At 45 percent of the sunset: boat lights, the drone’s strobe. At 30 percent of the dusk: the land breeze freshens. After 78 seconds: moonrise. After 100 seconds: the boat’s beach run. That order is the point of the scene, the moon has to be up before the boat beaches, and it survives every shift of the beginning.
Beaching and landing (about 465 to 480 s). The hull touches the sand, slides, and counts as stuck when it crawls slower than 0.6 metres per second over ground for two seconds, or eight seconds after the first contact. With that event the breeze dies and turns onshore. The canopy has landed when it stands less than 1.6 metres over the ground, or 60 seconds after the beaching.
The end (about 487 to 546 s). The canopy is down and the drone’s battery at 15 percent: return to the wreck. At 10 percent the forced landing, motors off only on the water, then floating. The pufferfish pass the windscreen one last time when the drone sits on the water. At 8 percent it shuts down, two seconds later the game ends. These times come from the battery model in part 7, not from a table; a run with less wind or a different formation lap ends a few seconds earlier or later.
The recording
The film is a screen recording of the running game with OBS, 1920 by 1080 at 60 frames per second, with the simulation’s sound. The first versions were recorded with x264 at medium quality and downscaled to 540p for the website, and the downscaled version was unusable: the water texture and the fine lights drowned in the encoder. The last version is recorded lossless, UT Video in an AVI file, about 55 megabytes per second and 31 gigabytes for the nine and a half minutes, and only afterwards encoded to AV1 at leisure. Lossless has two advantages: the encoder does not compete with the simulation for the GPU, and the downscale starts from a clean original. The route through the NVENC encoder with a fixed quantiser would have been the faster one; in OBS’s advanced output it aborted at the start without an error line, and there was no time for the cause.
Fallbacks
Every transition that waits for an event has a deadline after which it switches without the event. If the drone does not reach the crest or the surfing does not end, the evening begins 135 seconds after the sinking. If the canopy does not land, the drone flies to the wreck 240 seconds after the dusk anyway. If the boat does not come to rest, it counts as beached eight seconds after the ground contact. If the vehicle does not reach the turning point on the beach, the beach phase ends after 170 seconds. If it does not make it into the pool, the jump ends after 60 seconds.
A fallback is never the pretty variant, but it is the reason every run comes to an end and yields a video. In the last twenty runs none of them fired, and that is exactly how it should be: the fallback is the insurance, not the plan.
What proved itself
- Every trigger writes a log line with time and state, “Dusk begins at t=342.6 (drone on the crest)”, “Emergency brake ON at t=172.7, 54.7 km/h”. The line is the proof, not the impression while watching. The timeline of a run, the table above included, can be reconstructed from the log alone, and the 46 km/h in the same line of an earlier run were the reason to take the beach lane out of the wash.
- Scenes can be started individually. A console variable puts the vehicle into a phase: at the water’s edge at the start of the beach scene, at the turning point before the jetty, in the pool, or sunk at the measured position off the jetty with the heading from the log. A second one accelerates the drone’s battery, so the end comes in five minutes instead of nine. A third takes screenshots at fixed simulation times, with which a rebuild is checked without a spectator. With every rebuild of the night that was the difference between one run and four.
- The times of the night are relative to the start of the evening, not absolute. When the drone’s low flight became faster, the evening moved forward by thirty seconds, and the night stayed the same.
- An event that never occurs is the most common kind of error. The boat was never “stuck”, because the swell kept lifting and lowering the hull. A trigger needs a quantity that really comes to rest in the target state, here the speed over ground.
Keywords: simulation choreography state machine, autopilot phase programme, event-driven sequence, reproducible demo, vehicle simulation sequencing, debug start phases, serious gaming, simulation consulting Switzerland, swissEmbedded
A demo that brings every run to an end? We build sequences from states and events, with fallbacks and log lines that prove the run.
Unreal® and Unreal Engine® are trademarks or registered trademarks of Epic Games, Inc. in the United States of America and elsewhere; these articles are neither endorsed nor reviewed by Epic Games. Project Chrono is an open-source project of the University of Wisconsin-Madison and Politecnico di Milano under the BSD-3 licence.