Build the game

Everything is built. This page is putting it together, running it, and seeing it from the inside.

The finished machine

Playing is the base state, and its Every Frame watches the mouse the whole time, whatever else is happening. Under it, five sub-states take turns:

Sub-state	What it does	Leaves by
Idle	Nothing, it is the resting place	the parent’s click check, to Aim
Aim	Calls Pick Target and keeps the destination	near → Walk, far → Slow Spin
Walk	Eases toward target until Is Near says arrived	arrived → Quick Spin
Quick Spin	A use of Make Rotation at 720°/s for 0.35s	done → Idle
Slow Spin	The same macro at 120°/s for 1.2s	done → Idle

Read down that table and it is the game in sentences, which it only does because the transitions were named as you went.

The finished machine: five sub-states inside Playing, with labelled arrows.

Compile and play

Hit Compile All in the top bar. Hengo saves the graph and writes plain GDScript into res://hengo/scripts/my_sprite.gd, then a report lists what compiled. Attach that file to the Runner node and press play.

Click near the sprite and it slides over, then spins fast. Click far and it jumps straight there, then spins slow. Click again mid-slide and it changes its mind.

Compile All and a full play session, watched from the Debug tab.

If the Actions counter is not zero

A step is missing something it needs. Click the counter for the list, and the cards it names are drawn red on the canvas.

Read what it wrote

Open res://hengo/scripts/my_sprite.gd from the FileSystem dock. It is worth reading once: a state is a class, a cell is a method, a variable is a script variable, and your macro uses are nested classes.

There is no interpreter and no runtime graph: this file is the whole thing, and it runs at the speed of code you would have typed. The full mapping is in Source and Build.

Watch it run

With the game still running, open the Debug tab in the side panel and press Refresh, then pick your live instance. On the canvas, the running state glows, the card that is executing lights up, and the transitions flash as they fire.

Leave it open and click around the scene. Watching Idle → Aim → Walk → Quick Spin → Idle light up in order is the fastest way to understand a machine, and the fastest way to find the state that is not being left.

This needs Debug Compilation on in the settings, which is the default, and the script compiled with it on. Debugging has the rest.

Make it yours

Three changes that each take a minute and use something you now know:

• Tune it from Godot. Add a speed variable, tick Is Export, and bind the Weight of the Lerp Toward to it. It shows up in Godot’s own inspector on the Runner node.
• Use Make Rotation a third time, somewhere else, with its own numbers. That is the point of a macro, and it costs one menu entry.
• Give the macro an entry. Add one called on spin, drop a Run on spin inside Spinning, and let each use put a different step there. Now the two spins can differ by more than numbers.

Where to go next

• Core Concepts, the vocabulary behind what you just built.
• The State Machine, the model in more depth.
• Functions & Macros, the shapes those two can take.
• The Interface, a tour of every screen, including the parts this path did not touch.
• Actions reference, everything you can drop on a state, generated from the plugin itself.
• Write a Custom Action, when the library is missing your step.
• Keyboard Shortcuts, to stop reaching for the mouse.