Season 3 Plan

Ideas for season 3, mainly from real playtests. See below for bug reports too.

Running skill as achievement

• Powering through all levels in running state is effective but should be more deliberate by introducing a small cost in energy. In the easier levels this should not hurt at all. The tailored-clothes guard is a real test for it - running is required to jump over it when the tailored clothes have not been collected (dress-code bypass jump).

Season 3 starts without the running skill for the player. This will be earned later in the game, e.g. in the first underworld chest. I tried it - the waterfall in the underworld can be crossed without running, but the player must jump through and accept severe injuries. So it’s possible; the running skill should be earned in the chest just after the waterfall.

Can be indicated by the soccer shoes we already know. This time they are added to the inventory by collecting from a chest and not picked up from a platform.

I made some tests to see if level 1 (Minigolf) can be completed without the running skill. It’s hard, especially the bigger sandpits. So in season 3 there should be plenty of spare cola on elevated platforms so the player can finish it even after a respawn. This will probably need to be tuned right.

Running skill in Above the Clouds

• Similar to above for wind-gust zones where running is required. Player is required to use power economically across the level. A protection against the wind gust is a powerup idea for the second chest before the player enters the clouds scene.

Rewarding soccer goals

It’s possible to kick a ball into the goal - the one lingering in front of the goal is the easy one that always works. The trick is to push against the ball (just release the running button on the gamepad) and push it briefly at the right time (in my tests, just after or at a direction change of the ball). Result: the ball lands in the goal. So here is my idea for season 3: remove the static easy winning ball and increase the reward for a goal. I think it’s already possible to kick more than one ball into the goal. Add a reward multiplier of 2 (or 3?) to make it worthwhile. Of course - all still gated on soccer shoes in the inventory.

Fixed in August version already

Manual check (PF): dance session timeout in Underworld ejects to Tanzstunde, the level before the lesson. Seems to work. Not clear if the timer from Tanzstunde is counting, or if the lesson gets its own counter. Also, there is no visual indication of a timer running out. The timeout should be indicated by at least some FX.

Tanzstunde dance credits/score economy - needs a real redesign

Found 2026-08-08, same live TV session as the timeout-FX check above. The portal into the Underworld lesson used to be permanently one-shot per playthrough (a bug, not by design - fixed same session: PortalDef.used was a blanket lock meant for Soccer/Lidl Lunch’s farmable chest portals, and Tanzstunde/Clouds got swept into it by accident). Now that re-entry actually works, watching the score while repeatedly entering/dancing/ getting ejected/re-entering exposed a real design problem, not just a display glitch:

• computeScore() (hud.ts) is itemsCollected*100 + speedTier*250 + round(energy)*5 + danceCredits. danceCredits itself only ever goes up (+10 per perfect/good step, danceSequenceStep() in player.ts) - that part’s fine. But energy is baked into the same displayed number at a 5x weight, and danceSequenceStep() also costs -5 energy per step. Net effect: landing a good dance step - the moment you’re supposed to feel rewarded - visibly drops the on-screen score by 15, because the energy cost (-25 displayed) outweighs the credit gain (+10 displayed).
• Separately, walking into (or back into) the portal runs loadLevelData() -> player.respawn(), which snaps energy to full in one frame - an unrelated +ve jump in the same displayed number that has nothing to do with anything just earned. So across a few dance/eject/re-enter loops the visible score saws down-while-dancing, flat-while-ejected, up-on-re-entry. That’s what looked like nonsense live - it is nonsense, or at least two unrelated ledgers (an energy economy and a credits economy) got folded into one number that can’t represent both sensibly at once.
• With re-entry now working, DANCE_SESSION_TIMEOUT_S (bumped 60->120-> 300s as a same-session stopgap, see PLAYTEST-FINDINGS.md PF-19/PF-21) is worth reconsidering from scratch rather than re-tuning again: its original job was anti-farming for free, repeatable, no-downside visits, but if the portal can always be walked back into anyway, a time limit on a single visit doesn’t obviously add protection against anything a real cap on total earnable credits (or on how good the reward per visit can be) wouldn’t already cover more directly. Open question for season 3, not decided: does the timer keep any real job at all beyond a generous AFK-tab safeguard, or does fixing the crediting model (see below) make it redundant?

What to actually figure out before touching any of this again:

• Should danceCredits ever have shown up inside the same number as energy in the first place, or does it want its own separate, honest HUD readout (the way the countdown timer got its own readout this session)?
• If energy cost per step stays, should the displayed score stop including live energy at all (only bake in credits/items/speedTier), so spending energy on a dance step doesn’t read as a net loss?
• Should player.respawn()’s energy-to-full reset be scoped to actual respawns (falling, fatal hit) rather than firing on every portal entry via loadLevelData() - i.e. is “walking through a portal” supposed to refill energy at all, or is that itself the accidental part?
• Once the above is sorted, is DANCE_SESSION_TIMEOUT_S still pulling weight, or can it be dropped/pushed to something like 10+ minutes purely as an AFK safeguard with zero gameplay-balance role?

Update, same day: the ejected player standing at the door getting gently waltzed back into the portal by the dancePartner’s sway (originally kept on purpose as a charming find) was reconsidered and fixed properly instead

• a permanent spawn point shouldn’t depend on a moving hazard’s phase. PortalDef.exitSide:'right' (tanzstunde_s2.ts) now lands the ejected player clear of the dancer, with a 3px margin before the level’s own x=680 GAPS entry. Locked in by test_ejected_player_stays_put_not_pushed_into_gap_or_portal in smoke_test_season2.py (supersedes the old “keep it” test of the same scenario). See the next section, though - the underlying idea (an eject spot that isn’t automatically safe) turned out to be worth keeping deliberately, just not by accident and not here.

Deliberate “risky respawn” challenge (season 3 draft, not implemented)

Prompted directly by the accidental Tanzstunde version above: instead of every portal/Underworld exit always landing the player somewhere safe (the norm, and still correct for Tanzstunde’s real fix), season 3 could build a portal on purpose where the exit spot sits exactly on top of a gap or obstacle - the player free-falls (or gets pushed into the hazard) unless they steer clear immediately. The fairness condition: pair this only with an elevated exit (like Tanzstunde’s own TEACH_PLATFORM_Y, above real ground level) so there’s genuine airtime between landing and the fall actually resolving - a real reaction-time skill check, not an unavoidable cheap hit dressed up as a spawn point.

Notes for whenever this gets designed for real:

• Needs an explicit telegraph so it reads as “deliberate challenge,” not “buggy spawn” - same “mark it before it’s reachable” instinct this file already uses elsewhere (takeoffMarker in tanzstunde_s2.ts, the windsock in Above the Clouds).
• The airtime/margin needs real playtesting to tune, same discipline as the DANCE_SHOES_STEP_Y / dress-code-bypass-jump numbers already in tanzstunde_s2.ts - get it wrong and it’s either trivial or an unavoidable cheap hit, nothing in between reads as “fair.”
• Could generalize the same PortalDef.exitSide field just built for this fix rather than inventing a parallel system - e.g. a third option alongside ‘left’/‘right’ that deliberately targets a hazard, or an explicit offset.
• Should live somewhere new/purpose-built, not retrofitted onto Tanzstunde’s real exit, which just got fixed specifically to not do this.

No implementation this session - captured as a mechanics draft only, per Torsten’s own framing. This is a “figure out the design, then build it” item for season 3, same as the other sections above.

Prepper: prep items in the bag / player picks from inventory

Incident: We found a rare case where there was no energy left to finish the game - the portal to recall the dance lesson was blocked by a wind gust. We had just lost our energy (flashes) by accidentally touching evil kn00t in the clouds level. Then the thought: what if we had prepped some cola when the speed tier was full anyway? We could just open one now from our savings.

So: when the player collects a backpack item (from a trove? in season two?), we can drop it in and recall it later. Lots of stuff to build for this. Maybe the backpack opens only in the clouds level so items can only be spent there (when actually needed). Can be linked to the jetpack somehow. Just a coincidence so far. Let’s see.

Side question: what are unused items that can be collected so far but have no meaning in the game (like the dance shoes)?

Speedrun adventure

One level where the goal is not to collect items but to complete it as fast as possible. Remaining time is credits. Can be extended into speedrun mechanics.

Speedrun mechanics

A second winning tier where the goal is to reach the end as quickly as possible. One idea is to add up the remaining time per level. Other crediting possible too.

Moving platforms

A level that forces the player to jump across moving platforms or fall into lava.

Bug found that needs fixing

Reverb build-up. The audio engine in underworld caves seems not to clean up properly. Each time we re-enter, the reverb builds up one layer. After two or so, the sound becomes really unwieldy. Tried to restart the server - no chance. Only restarting the browser (TV Bro on my TV) helped. Maybe check if the reverb engine is properly cleaned on cave exit.