Route Planning for Roblox Progression Games: From Wave Clears to Full-Badge Runs
A route-planning method built for Be The Final Boss players: break the goal down, pick one branch per session, time the resource windows, log the run, and review what actually killed you.
Most lost runs in Be The Final Boss are not lost at the wave where your formation finally collapses. They are lost before the run starts, when the session had no plan at all: you queued up, spent Souls the moment they landed, fused shards into whichever unit happened to be selected, and called it progress. Route planning is the fix, and it is a skill rather than a trick — one that works in Be The Final Boss and transfers to almost every other Roblox progression game you touch.
Here is the method, built around the tools and data on this site.
Break the goal down until every piece has a source
A goal like "get stronger" cannot be routed. A goal like "field two Demonic carries" can, because it decomposes into inputs, and every input comes from somewhere specific:
- Souls for Summon Altar rolls — codes, kill income, and the Soul Harness node
- Fusion Shards for unit upgrades — codes, the Shard Storm window, and kill volume
- Coins for skill tree nodes and weapons — wave income, routed through the tree
Write your goal as that list of inputs, then check that each input maps to a source you can actually name. If a piece of your goal has no source, it is a wish, not a step. Our Souls farming guide and Fusion Shards guide already list every confirmed source for the two currencies most players get stuck on, and the codes page covers the zero-effort chunk of both — redeeming the active codes is the first step of almost any route.
The decomposition also exposes ordering. If your goal needs Demonic units, Souls come before shards, because there is nothing worth spending shards on until the right units exist. That single observation already sequences your next few sessions.
Pick one branch per session
Once the goal is decomposed, sessions branch. In Be The Final Boss there are three realistic branches:
- Summoning push — bank Souls, roll at the Altar, build the roster
- Upgrade push — bank shards, raise your two carry units
- Economy push — spend Coins on the skill tree so future runs earn more
Trying to advance all three at once is the most common routing error. A session that spends half its Souls, half its shards, and half its Coins moves every bar a little and finishes nothing. The better play is to declare the branch before you queue: "tonight is a shard session" means the Altar stays untouched no matter how tempting a fresh pile of Souls looks, and "tonight is an economy session" means Coins go into the skill tree instead of sitting in your balance.
Branches are not permanent. You switch when the current one stops being the bottleneck — which you will only know if you are tracking the run, covered below.
Time the resource windows
Be The Final Boss runs weather events on a fixed cycle, and two of them change the value of your currency: Cursed Moon improves what a Soul buys at the Altar, and Shard Storm improves what a kill drops. The confirmed multipliers and timings live on the events page — the routing point is what you do around them.
The pattern is bank, then spend inside the window:
- Between windows, your job is accumulation: clear waves, take the kill income, redeem nothing-expiring, touch nothing.
- When the window opens, the banked currency converts at a better rate, so that is when rolls and upgrades happen.
- When the window closes, you go back to banking — even if the session "feels" productive.
Spending outside the window is how most currency quietly disappears. A route that ignores the event cycle is not a route; it is a mood.
Log the run while it is happening
Routes fail silently when nothing is recorded. You do not need a spreadsheet — a note with four lines per run is enough:
- Wave reached, and whether it was a personal best
- What actually ended the run: damage check, tank collapse, or leaks
- Currency spent, and whether it was inside an event window
- One thing to change next run
Those notes are what turn this site's tools from trivia into routing inputs. The wave planner tells you what is coming, and your log tells you where "what is coming" beat you last time. The team builder is where the fix gets built — but only if the log says what needs fixing. "Died at wave 30" is useless. "Leaks past the tank line from wave 28, DPS fine" is a formation change.
Review the failure before you queue again
Every failed run gets a one-minute post-mortem, and the question is always the same: which subsystem failed?
- Damage check — heroes walked the whole path alive. That is a DPS or shard problem; route toward upgrades.
- Tank collapse — the front line folded and everything behind it fell. That is a tank or formation problem; route toward the team builder.
- Leaks — kills happened but too late. That is placement and travel time; route toward layout changes.
- Economy mistiming — you had currency but spent it weakly, outside a window or on the wrong unit. That is a discipline problem, and the fix is the checklist below, not more farming.
Change one variable per run. Changing three at once teaches you nothing, because when the run improves you cannot say why.
Pre-session checklist
Run this before every session:
- [ ] Goal written as inputs, each with a named source
- [ ] One branch declared for the session
- [ ] Active codes redeemed
- [ ] Event timer checked — know when the next window opens
- [ ] Currency banked and earmarked for its window
- [ ] Last run's log read, one fix chosen
- [ ] Notebook ready for this run's four lines
The method travels
Everything above is game-agnostic: decompose the goal, commit to a branch, respect the windows, log the run, review the failure. That is why route planning is worth learning once. If you also play Shred the Secrets, the same discipline has a dedicated tool — the Shred the Secrets route planner maps out routes toward that game's endings, badges, and secret goals, and the site pairs it with a run tracker and an upgrade optimizer, so the log-and-review loop above works there almost unchanged.
The games change. The method does not.