Building a Stat Comparator That Refuses Invalid Deltas
A technical look at developing a reliable item comparison view in games by preventing mismatched unit calculations and missing value assumptions.

Stock photo for illustration only, not from the actual event
- Comparison tables become dangerous when evaluating non-comparable data values.
- Using a Map keyed by three semantic identities prevents cross-unit data collision.
- Distinguishing between zero values and missing entries avoids false analytical conclusions.
- The implementation powers the live Gear Calculator on the Task Bar Hero Wiki.
A comparison table becomes dangerous when it produces a precise-looking answer for values that were never comparable. This challenge emerged while implementing a gear comparison view where each item exposes base stats and inherent modifiers. Values could range from flat numbers and percentages to per-second rates, and either side could omit a field entirely.
The tempting implementation was joining rows by their visible label and subtracting right from left. That approach would have allowed flat attack damage to collide with percentage attack damage while incorrectly treating missing values as zero. The safer implementation instead relies on a small Map keyed by three pieces of semantic identity.
Establishing a strict three-part semantic identity (stat identity, source, and unit) mirrors rigorous software engineering practices found in enterprise data pipelines and analytics engines. Relying on visual label matching alone often introduces silent data corruption, making explicit identity mapping essential for maintaining calculation integrity across complex datasets.
The resulting row needs to preserve more than just two numbers, as those fields form part of the comparison contract. If discarded before reaching the UI layer, careful table formatting cannot recover the original meaning. The comparison groups rows using structured composite keys like base:attack-damage:flat and inherent:attack-speed:percent to ensure only matching identities, sources, and units occupy the same comparison bucket.
This pattern extends far beyond gaming applications. Pricing tiers often feature monthly and annual amounts, analytics tools track counts alongside rates, and hardware benchmarks handle nominal versus measured values. Proper comparisons must match on semantics rather than whichever visual label appears closest.

Stock photo for illustration only, not from the actual event
Delta calculations are kept intentionally boring to avoid common false conclusions. Suppose the right item publishes an inherent +22.7% modifier while the left item lacks a matching field. Displaying a +22.7% delta would incorrectly assert that the left side is known to be zero, whereas returning null reflects the accurate data state: no compatible pair exists to subtract.
"B - A = +3 means the right record has three more units in that compatible row."
Ethan James Cole
Even when mathematical subtraction succeeds, interpretation has strict boundaries. Stating that B minus A equals three simply means the right record has three more units in that compatible row; it does not prove higher DPS or universal Best-in-Slot status. Such conclusions would require external inputs like hero scaling, skills, enemy defenses, buffs, rotations, and clear times that the comparator does not model.
This product decision keeps adjacent questions separate. Acquisition routes, drop probabilities, and duplicate-item values share item records without folding into a single score. The implementation described powers the Gear Calculator in the Task Bar Hero Wiki community reference, comparing currently published fields rather than promising universal coverage.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment