Upgrade Planning Guide
A cautious upgrade workbench for Shell abilities and weapon investment.
Separate fact from preview
Official pages confirm deep weapon upgrades and innate Shell abilities. Exact costs and balance can shift across launch patches.
Read current item and skill descriptions before copying a numerical build from an older video.
One-variable testing
Keep Shell, weapon and route fixed, then change one upgrade. Run a normal enemy, group and elite to see whether it changes a decision you make.
A rare effect that appears once is less useful than a modest improvement to recovery, posture or survival.
Material discipline
The beta reset currencies, weapons, Shells, collectibles and other items at launch. That warning shows why beta economy advice is not permanent fact.
Spend common resources to learn the system and hold rare-looking materials until the current interface reveals their scope and replacement rate.
Record the purpose
Write the role of each upgrade: opening safety, posture, ranged control or recovery. A list of names cannot be repaired when a patch changes one part.
After an update, retest the affected decision rather than rebuilding everything.
Upgrade decision ledger
Record the current description, material cost, intended combat job and one repeatable test before purchasing. After the test, write whether the change improved opening safety, posture pressure, range control or recovery instead of merely noting that damage felt higher.
This ledger exposes an upgrade that duplicates an existing strength or depends on a rare situation. It also makes later patch reviews focused and reversible.
Respec-risk boundary
Do not assume materials are refundable or infinitely farmable until the current launch interface proves it. Use common resources for learning, but pause before rare commitments when acquisition and replacement are still unclear.
Beta progression resets already show why preview economy advice cannot be permanent. Verify costs and availability in the release build before publishing an exact route.
Post-purchase audit
After buying an upgrade, rerun the exact pre-purchase encounter and compare the intended job, not only completion time. If the decision does not become safer or more repeatable, stop the branch and preserve remaining materials until the current economy and replacement path are understood.
Sources & visual context
Version note: open-beta behavior is never treated as permanent launch fact. Interface labels, balance, triggers and performance can change after the August 2026 release.
Upgrade Planning Guide FAQ
Did beta progress carry over?
The beta warning states that most currency, weapons, Shells, collectibles, and related progress would reset for launch. That makes beta economy routes temporary evidence rather than permanent advice. Verify current costs and ownership in the release interface before following an older spending plan.
What should I upgrade first?
Upgrade a component that improves an action you already perform safely. A dependable recovery, posture sequence, or survival tool is more valuable than an impressive effect with no repeatable setup. State the intended job before spending so the purchase can be evaluated afterward.
How do I test fairly?
Change exactly one variable while keeping the Shell, weapon, route, and encounter as stable as possible. Run the same normal enemy, group, and elite before and after the purchase. Compare the intended decision rather than relying only on completion time or visual spectacle.
When should I spend rare materials?
Hold rare-looking materials until the current build explains the effect, scope, and replacement source. Common resources can teach the system, but an irreversible purchase should answer a known build problem. If replenishment remains unknown, postpone the branch and keep testing alternatives.
Will patches invalidate builds?
Patches can invalidate numerical breakpoints, costs, or individual effects, but they do not erase a clearly recorded build purpose. Note whether each choice provides opening safety, posture pressure, ranged control, or recovery. Retest the affected decision after an update instead of rebuilding blindly.