Compare · Builds
Desktop aligns full columns. Mobile keeps each build as a readable card instead of squeezing a wide table.
Tiel
A forgiving acquisition order for players who prefer mobility.
Gragu
A heavy setup assembled in the same order that the completion route reaches its pieces.
This comparison uses only captured acquisition facts and attributed recommendations. It does not invent DPS, tiers or “best” rankings.
Begin with the goal column. A build designed to avoid early detours answers a different question from one assembled around mobility or heavy equipment, so there is no meaningful universal score. Next compare the acquisition order: identify which pieces the current route has already reached, which step requires an optional trip, and which recommendation depends on a source that still needs release-version review. The shortest list is not automatically the cheapest if its pieces are unavailable in the current run.
Read strengths together with limitations. A stated strength explains why the authored route uses the setup; it is not a measured damage, defense, or speed result. A limitation shows what the source or model cannot prove. When a column omits a statistic, do not infer a zero or fill the gap from another build. Open the dedicated page and attributed source before using an unverified comparison as a spending decision.
Choose one question at a time: which loadout can be assembled next, which route preserves scarce upgrades, or which moveset the player wants to test. Compare every selected build against that same question. Changing criteria halfway through makes a visually aligned table misleading. Record unknowns explicitly and prefer a reversible test in the game before spending a limited resource.
After selecting a route, confirm each Shell, weapon, and sidearm in its source record and current game build. The comparison tool does not inspect inventory, calculate DPS, or simulate an encounter. It presents authored goals, acquisition steps, strengths, and limitations side by side. A local profile should reflect pieces actually obtained, while a planned piece remains open until the game confirms it.
Return to the table when the route reaches a new branch or the preferred moveset changes. Switching builds is a new acquisition decision, not evidence that the earlier recommendation was false. Preserve already confirmed targets, avoid checking future pieces, and keep the source date visible when a patch could change availability or behavior.
Write the selected question and rejected alternative into the route note before closing the comparison. Name the build chosen, the first piece still missing, the evidence date checked, and the limitation that affected the decision. If two columns remain equally suitable, leave both open and test the cheapest reversible step rather than inventing a tie-break score. This receipt makes a later switch explainable: the player can see whether new inventory, a changed preference, or updated source evidence caused the decision to change.
