Risk and Reward: Designing Air Tricks for a Pogo Game

In the first version of BOINGWARD, the pogo only bounced. While playing, something simple came to mind and I wrote it down as is: "if it pulls off a cool move, it should bounce higher." That sentence is a nice idea, but it is not a design. Which move? How much higher? And what if the player slams into the ground in the middle of the move? This post follows how that one sentence became a design doc, and then a system defined by numbers.

The overall story is in the series hub post, and the bounce physics the tricks build on is in the physics post.

Limits first

The design doc does not start with the reward; it starts with the limits. Tricks have to follow these rules:

• Optional. Every course can be finished without tricks. The bots that test the courses never do a trick; if a platform requires one, the test breaks.
• Risky. Landing in the middle of a trick is a penalty, not a free launch.
• Deterministic. Trick state advances on the physics step; two phones drawing at 30 and 144 frames per second get the same result from the same trick.
• The no-jump-button rule holds. Bouncing stays automatic; the trick button only rotates you in the air.
• Cosmetics have no physics. The rotation is visual only; the collision body never rotates.

That last point matters. The robot flipping in the air is an animation; as far as physics is concerned, the pogo always stands upright. So tricks never affect collisions, platform edges or multiplayer fairness.

Input: one button, four tricks

In the design, the player holds the TRICK button at the bottom right while in the air. The direction of the left stick at the moment the button is pressed decides which trick happens:

Stick at press	Trick	Rotation axis
Forward	Front flip	The camera's right axis, nose forward
Back	Back flip	The camera's right axis, nose backward
Left or right	Side flip	The travel axis
Centered	Spin	The vertical axis, 360 degrees

While the button is held, the stick does not steer, because it already picked the trick. Letting go brings steering back. There is no separate menu and no combo to memorize; it is simple enough to do with one thumb on a touch screen.

When can a trick start?

If you could trick on every bounce, the system would lose its meaning. A trick can only start if at least 0.7 seconds remain before the pogo falls back to its last launch height. A standard hop takes about 1 second in total, so tricks happen either on the way up or on big jumps (trampolines, boost pads, low gravity). So players can learn this window, the design has the button glow whenever a trick can start.

Rotation, full turns and recovery

While the button is held, the robot turns at 1.6 rotations per second. On release, the number of full turns is counted like this:

var turns := floori((angle + snap) / TAU)   # snap = 60 degrees

Thanks to the 60-degree allowance, a 300-degree rotation counts as a full turn, and the robot finishes the remaining angle as it straightens up. After release, any leftover angle unwinds to zero in 0.15 seconds. A rotation under 300 degrees earns nothing, but if the robot recovers before touching down, it costs nothing either.

Landing: three possible outcomes

The heart of the whole system is the moment of landing. When the tip touches down, one of three things happens:

• Clean landing: If at least one full turn is complete and the robot is within 20 degrees of upright, the landing counts as "style". That bounce's launch speed increases by the reward amount.
• Bail: If the robot touches down while still rotating, or more than 45 degrees from upright, it staggers, the combo resets and the landing does not launch at all.
• In between: If the turn is complete but the tilt is between 20 and 45 degrees, the turns are lost and you get a normal bounce, with no penalty.

That trio matters. With only "success or penalty", players would shy away from trying tricks. The middle zone takes back the reward without punishing the mistake.

The reward formula and the cap

The reward combines the turns completed with the variety of tricks:

reward = sum(turns x per-trick rate) x (1 + 0.5 x (distinct tricks - 1))
reward = at most the mode's cap

Per-turn rates: flip 0.10, side flip 0.08, spin 0.06. Combining different tricks in the same jump adds 50 percent for each extra type. For example, a back flip and a spin: (0.10 + 0.06) x 1.5 = 0.24.

The real design decision is the cap. The game mode sets it:

Mode	Cap	Effect (12 m/s base launch)
Spire	0.10	13.2 m/s, apex from 3.0 m to 3.6 m
Climb	0.30	15.6 m/s, apex from 3.0 m to about 5.1 m

The Spire is a timed race with medals; there, a trick means a small time gain or a shortcut, and it must not break the course. In the long climb mode, tricks are the main thrill, so the reward is large. The 0.24 from the example above gets clipped to 0.10 in the Spire and stays as is in the climb.

The reward is applied after the normal launch calculation, but the global speed cap still holds. Boost pads ignore the reward, because their result has to be fixed. The reward lasts for one bounce only; the next landing starts from zero.

Why it has to be frame-rate independent

The rotation angle advances on the physics step, not on the draw frame. That sounds like a detail, but it is not: if the angle followed the draw frame, a phone drawing at 120 frames would complete a turn at a slightly different moment, and the same trick would be clean on one device and a bail on another. The test suite runs the same trick attempt at 30, 60 and 144 frames per second and requires the result (tricks landed, reward rate, bounce count) to be identical.

How it looks on screen

The visual side of the tricks was built in a separate session. The robot rotates around its body center, one meter above the pogo's tip; during a spin its hands let go of the pogo stick, on a clean landing it squashes slightly and sparkles, and on a bail it wobbles. The design doc also has a plan for the UI: a short "STYLE +18%" on screen after a clean landing and a red "BAIL" after a failed one.

An honest note: as of October 4, the trick physics, tests and robot animations are in the main branch, but the on-screen TRICK button is not wired to the input system yet. The system is ready; the player's thumb just cannot reach it yet. I keep the current status on the BOINGWARD page.

Frequently Asked Questions

How do you balance risk and reward in game design?

Write the limits before defining the reward: is it optional, what is the penalty, what is the most it can give? In BOINGWARD a trick is never required, failure is a short penalty, and partial success carries no penalty but no reward either. The game mode sets the cap.

Why does the reward have a cap?

An uncapped reward breaks course design: a trick sends the player to a height the designer never planned for. A small cap in the timed race and a large one in the free climb let the same system play different roles in two modes.

Why is it important not to punish partial success?

If every failed attempt were punished, players would stop trying. When the turn is complete and the landing is only a bit tilted, losing the reward without a penalty encourages players to keep trying; the penalty is saved for a clearly bad landing.