What the system does
IGTAP uses upgrades to connect its incremental and platforming loops. The official description says upgrades increase production, add movement abilities, open higher-income courses, and let players complete earlier routes faster. It also says clones follow optimized paths to keep progress moving. That establishes upgrade categories, but not a complete current tree or a universal best order.
Hotfix 2 changed late-game costs and scaling, moved an extra double jump earlier, and made Omni-dash optional. Any rigid tree copied from an earlier build may therefore be outdated even when its broad idea is reasonable.
When it becomes relevant
Use this guide whenever two or more visible upgrades compete for resources and the choice could change route access or production. It is most useful after a clear baseline run and before spending on several nodes at once. Read the current in-game description and dependency display; do not rely on a cost table that this page cannot verify.
If an upgrade appears missing, first check whether it depends on progression or a movement state. If an already-unlocked dash fails, use the dash troubleshooting guide rather than buying unrelated production upgrades.
Decision checklist
Classify the current bottleneck, then compare only upgrades that address it:
| Bottleneck you can observe | Evidence to collect | Upgrade category to inspect | | --- | --- | --- | | A required section is unreachable | Failed point and available movement | Movement access | | A route is finishable but inconsistent | Clean completion times and failure point | Control or movement consistency | | Runs are stable but reward rate is low | Observed reward and elapsed seconds | Production or route efficiency | | Clone output lags the active route | Separate active and clone observations | Clone-related options shown in game |
Record a baseline, change one node, repeat the same course, and compare. Use the route calculator only with observations from comparable runs. Reclassify the bottleneck after the purchase; the best next category can change immediately after movement access opens a new route.
Common mistakes
- Buying a generally strong production upgrade when movement is the actual gate.
- Valuing theoretical clone output from an unverified formula instead of what the current save displays.
- Applying a pre-Hotfix 2 cost or node order to the current build.
- Changing route, upgrade, movement toggle, and measurement window simultaneously.
- Assuming Omni-dash is a pure upgrade with no tradeoff; the official note describes a one-jump choice.
- Calling one run “optimal” without repeatable timing.
For longer farming comparisons, follow the Power farming method. If the decision concerns the first Atom, keep Atom-specific assumptions separate with the first Atom checklist.
What still needs verification
Current node names, positions, costs, prerequisites, numerical effects, rounding, and complete respec or reset behavior are not confirmed in the reviewed official sources. Exact clone scaling and the best endgame order also remain unverified.
The decision framework does not require those numbers: it asks what the save displays, records one change, and checks the observed result. A future numerical tree should not be published until it is reproduced in the current build and checked after balance patches.
Sources and verification status
Officially confirmed: upgrades affect production and movement; movement opens courses and faster paths; clones follow optimized routes. Officially confirmed: Hotfix 2 adjusted costs and scaling, moved the extra double jump, and added the Omni-dash choice.
Needs verification: the full current upgrade tree and every numerical recommendation. This page provides a repeatable decision method, not an invented build.