UTDX Methodology

The methodology page exists because UTDX information changes quickly. A code can expire, a unit can move in value, a map can rotate, and a YouTube guide can become outdated after one update. Naming the source type for each claim makes the site easier to repair. Rolimon's is used for game-scale metrics, code trackers are used for redeem strings, roster sources are used for unit names, and the calculator labels its assumptions.

I do not treat every source as equal. Rolimon's is useful for public game statistics such as players, visits, favorites, rating, and average playtime. It does not validate a private unit stat. A code tracker can list active strings, but it cannot prove long-term uptime. A YouTube video can reveal placement behavior, but it should not overwrite a code page. Each source answers a different question.

The calculator is intentionally simple. It multiplies base damage, attack rate, level scaling, and selected buffs. It does not pretend to model every hidden mechanic, targeting rule, or map-specific firing window. That limitation is visible because a clear model is more useful than a fake official number. Players can still compare upgrade direction without being misled about precision.

For strategy pages, I prefer decision language over absolute ranking. A recommendation should tell the player what to do next: move a tower, add control, save rerolls, test a map, or claim a code. If a paragraph cannot change a decision, it is probably filler. That rule is why the site splits codes, units, builds, waves, rerolls, maps, and beginner advice into separate pages.

When public sources disagree, the site should show the disagreement. The 30kInterestedWano example is a useful case: one tracker can keep it active while another marks it inactive. Hiding that conflict would make the page look cleaner but less useful. A watchlist note lets players test the string without confusing it with the strongest active-code set.

I also avoid cross-site portfolio transparency blocks on this UTDX site. The About page is limited to UTDX scope, author responsibility, methodology, contact path, and non-affiliation disclosure. That keeps the site focused on the game and avoids irrelevant outbound cross-link patterns.

I record the observation date because live-game metrics move quickly. A CCU number from Rolimon's is useful only if the reader knows when it was observed. The same applies to codes: a May 9 code list can be correct on May 9 and stale after the next patch.

The site also distinguishes between external source checks and direct verification. If a code is listed by PGG and Beebom, that is a strong public-source signal. It is still different from a private developer database. The wording should preserve that difference.

For generated pages, I count H2 and FAQ structure because template sameness is a quality risk. Pages with identical outlines can look large while saying the same thing. This refactor gives each major spoke a different section count, FAQ count, and editorial shape.

The refactor also checks structure mechanically. Word-count ranges prevent every spoke from landing at the same length, while H2 and FAQ targets prevent every page from sharing the same outline. Those checks are not cosmetic. They force the guide to match the depth of the topic.

For UTDX, the homepage keeps the DPS calculator near the top because it is the strongest original utility on the site. The new stats, videos, update timeline, future-code watchlist, and placement secrets support that tool instead of replacing it.

The site deliberately avoids pretending that a single source is complete. Public data, code trackers, video evidence, and calculator models each cover part of the truth. The page is strongest when those parts are labelled clearly.