This article documents an ARC Raiders loadout-planner prototype and the engineering decisions recorded during its development. It is a retrospective, not a claim that the tool is a current or officially supported companion application.
The product question was simple: could a player compare equipment and plan a loadout using structured information rather than relying on memory?
Start by separating sourced data from estimates
The prototype began with hardcoded weapon data. That was enough to sketch an interface, but not enough to build a planner users could trust.
The data ingestion work aimed to retrieve core weapon attributes from a community API. The original implementation recorded nine core fields, including damage, fire rate, range, magazine size and handling-related values.
Not every attribute was available from the source. Some handling values were estimated by weapon class and tier. That distinction matters: an estimate must never be presented as an official game statistic.
A reliable data model should record provenance per field:
- source-provided value;
- derived value and formula;
- estimated value and its assumptions;
- missing or invalid value;
- last successful refresh and source version.
If the source returns zero or omits a field, do not silently replace it with a plausible number. Surface the gap and keep the source limitation visible.
Make ingestion repeatable
A data refresh should be deterministic and safe to rerun:
- Fetch the source response.
- Validate its structure.
- Normalise identifiers and numeric values.
- Record the source version or retrieval date.
- Compare the result with the previous dataset.
- Fail visibly when required fields are missing.
- Commit or publish only a validated dataset.
The original project included a verification command for weapon data and a separate fetch command. That separation is useful: validation should be runnable without making a network request.
Build the interface around comparison
The planner used React, TypeScript and Vite. A comparison interface should make the trade-offs visible without implying that one loadout is universally best.
Keep calculation logic outside presentation components. Unit-test derived values and edge cases independently from the UI. Label estimated attributes and let users understand which source data supports a comparison.
Test the claims the product makes
The prototype's development notes recorded 47 unit tests across four test files, along with a CI pipeline. Test counts are less important than what those tests protect.
For a data-driven companion tool, useful tests include:
- missing and zero-valued source attributes;
- unit conversions and derived statistics;
- unknown or newly introduced item identifiers;
- stale data and failed refreshes;
- deterministic sorting and comparison output;
- rendering when optional fields are unavailable.
A green test suite does not prove that the source data is accurate. Validate representative records against the source and make data freshness visible.
What this prototype demonstrates
The most reusable lesson is not a particular React component or game-specific formula. It is the need to keep source facts, estimates and presentation separate.
That discipline applies to any companion application built on community-maintained game data. Before shipping one, verify the source's terms, reliability, update cadence and permission to redistribute its data. Do not imply affiliation with the game publisher.
This is a historical engineering account. Check the project repository and current build before relying on the prototype as a live service.