What should a regional timer store?

Start with a reference record rather than a list of rendered strings:

service: taiwan
utc_offset: +08:00
first_start: "02:00"
interval_hours: 3
entry_window_minutes: 15
evidence: official-guide
checked_at: 2026-10-07

A different service can reuse the same structure while carrying a different evidence label. Community references and player-observed custom clocks should remain visible as such instead of inheriting an “official” label from another region.

How should local-time conversion work?

Build each start as an absolute instant in the service offset, then format that instant with the browser's local time zone. This avoids manually maintaining one table for every region and keeps daylight-saving changes in the platform's time-zone implementation.

The local weekday should be rendered with the local time. Near midnight, the server date and the player's date can differ even though they refer to the same instant.

function buildStarts(firstStart: Date, intervalHours: number, count: number) {
  return Array.from({ length: count }, (_, index) =>
    new Date(firstStart.getTime() + index * intervalHours * 3_600_000)
  );
}

The countdown and daily table should consume the same generated starts. If they use separate hard-coded values, an update can fix one display while leaving the other wrong.

What can the countdown actually claim?

A schedule-based countdown can identify the next expected reference start. It cannot observe whether a portal is present, full, closed early, or changed during maintenance. During a documented entry window, the interface may show estimated time remaining, but that estimate must stay distinct from a live status signal.

This distinction changes the error handling. When the game disagrees with the timer, the game wins. The website should send the reader to troubleshooting guidance rather than insisting that a mathematically correct schedule proves a portal is available.

Why include a custom calibration mode?

When a service has no verified public anchor, asking the player for one observed opening is more honest than copying another region's clock. A custom mode can combine that observation with a UTC offset and repeat interval, save the preference locally, and generate shareable planning information without requesting a game login.

I implemented these ideas in AION 2 Rift Atlas. Its Taiwan preset cites an official-guide reference, Korea remains labeled as a community reference, and Global/custom planning starts from the user's observed clock. That evidence model is the part worth reusing: the countdown is useful because its uncertainty is visible.

The implementation I prefer starts with normalized price records and builds every comparison from that shared dataset.

Normalize rates by model, channel, and token type

One model may have an official provider route and an OpenRouter route. Store them independently:

model_id: example-model
channel: official
input_per_million: 2.50
cached_input_per_million: 0.25
output_per_million: 15.00
context_window: 1000000
source_url: https://provider.example/pricing
verified_at: 2026-10-26

The router version can use the same model ID with a different channel and source. This prevents a lower router rate from being mislabeled as the provider’s direct price.

Represent the workload explicitly

A reusable cost function should take workload values rather than a pre-computed token total:

type Workload = {
  inputTokens: number;
  outputTokens: number;
  cacheReadShare: number;
  requestsPerMonth: number;
};

Split input tokens into fresh and cached portions, price each with the stored channel rates, add output cost, and multiply by the number of requests. If the channel has no verified cache-read rate, use the full input rate and label the assumption.

Keeping the workload separate also makes comparison URLs shareable. The URL can carry model choices and workload numbers while the server-rendered page explains that stored prices should be checked against their source dates before budgeting.

Validate records at build time

A static build can reject the most dangerous data errors:

• negative prices or context windows
• a confirmed rate without a source URL
• a verification date missing from a displayed price
• duplicate model-and-channel records
• a cached-input rate greater than the fresh-input rate without an explicit note
• an “official” record sourced only from a third-party listing

These checks do not prove a price is current, but they make the update process reviewable and stop malformed values from reaching every generated page.

Show exclusions beside the estimate

Token rates do not cover every bill. Tool calls, image or audio units, long-context tiers, batch discounts, taxes, credit-purchase fees, and BYOK rules can require separate logic. When they are outside the calculator, the page should say so near the result.

I applied this pipeline to LLM API Prices, which keeps official direct and OpenRouter prices separate, links the source for each stored rate, and estimates fresh input, cached input, output, and monthly workload costs.

The result is a calculator that can be updated without rewriting every comparison page. More importantly, a reader can trace a number back to its channel, source, verification date, and workload assumptions before using it in an architecture decision.

Wuthering Waves is a useful example because one phase can affect several user questions at once: the current character lineup, the weapon focus, the countdown, the next-banner checkpoint, rerun planning, and pity decisions. If each page stores its own copy of the same facts, they will drift.

Build around a canonical phase record

Start with one record for the live phase:

version: "3.7"
phase: 2
starts_at: 2026-10-22
ends_at: 2026-11-11
featured_characters:
  - Suoming
  - Lucilla
  - Lynae
next_status: pending_official_reveal
snapshot_date: 2026-10-23

The homepage, current-banner page, countdown, and schedule should all read from this record. A build-time validation step can reject impossible windows, missing snapshot dates, or a confirmed next phase with no supporting source.

Generate focused pages instead of one large feed

The same dataset can support several search intents without duplicating prose:

1. Current banner answers what is live and when it ends.
2. Next banner states what is confirmed and what remains pending.
3. Countdown turns the end timestamp into a deadline view.
4. History retains completed phases for rerun research.
5. Pity and pull advice explain planning rules without rewriting the lineup.

Each page still needs original explanatory text, but shared facts come from the canonical phase record. The result is easier to audit because a date change propagates through the correct routes in one build.

Keep watchlist signals out of confirmed fields

Live-service content attracts leaks, old screenshots, and vague version mentions. Store these as separate signals:

{
  "kind": "version-mention",
  "status": "watchlist",
  "observedAt": "2026-10-23",
  "changesConfirmedLineup": false
}

The build can surface a watch page or an “official reveal pending” message while refusing to create an unsupported character lineup. Promotion from watchlist to confirmed should require an official notice, in-game Convene data, or another documented high-confidence source.

Add freshness checks to the build

A useful pipeline should fail loudly when the live record is stale. Checks can include:

• the current date is outside the stored banner window
• the snapshot date is older than an allowed threshold
• the homepage and schedule disagree on the phase number
• a history entry overlaps the live phase
• a confirmed record has no source URL

These checks are small, but they catch the errors that matter most to a player making a limited-currency decision.

I applied this structure to WuWa Banners, an independent tracker and guide hub for current and next banners, countdowns, history, rerun context, pity, and pull planning.

Static output is an advantage here. The current answer is present in crawlable HTML, the build is reproducible, and a dated snapshot makes the page’s freshness visible. The site can change often without hiding its uncertainty or depending on a client-rendered feed.

The design problem is not just how to display seven locations. It is how to preserve source confidence, help players identify a puzzle from visible evidence, and store progress without pretending the guide is connected to the game.

Model locations and puzzle rules separately

A tempting schema stores one puzzle answer inside each district record. That is compact, but it assumes the encounter is permanently fixed to the zone.

A more resilient model has two collections:

Location
- zone
- landmark
- approach notes
- source status
- reported puzzle pattern

PuzzlePattern
- visible signal
- observation method
- confirmation signal
- common mistakes

The location tells the player where to look. The pattern tells the player what evidence to watch. A reported pairing can still appear as context, but the matching logic starts with the live clue.

For example, “overhead lamps flash in a repeating rhythm” should route to the streetlight pattern regardless of which district card the player opened first. The result explains how to observe a full cycle and use the green traffic light as confirmation. It does not return a hard-coded taxi number.

Preserve conflicting source claims

Several route descriptions agree on the district while disagreeing on the final approach. Flattening both into a single coordinate would make the data look clean at the cost of accuracy.

Instead, a location record can keep a stable landmark and an array of claims:

{
  "zone": "Unknown",
  "landmark": "Evac Building on the southern island",
  "claims": [
    { "direction": "west", "source": "source-a" },
    { "direction": "north", "source": "source-b" }
  ],
  "status": "sources-disagree"
}

The UI can then show the shared landmark first and the disputed bearing second. This is more useful than a generic warning because the player still gets an actionable anchor.

Use local storage for a lightweight route log

The checklist only needs seven booleans and a schema version:

{
  "version": 1,
  "completed": {
    "downtown": true,
    "central": false
  }
}

The interface writes the record only after the player marks a Threshold complete. A reset action clears the same key. No account, cloud database, or game API is required.

This architecture is intentionally modest. It supports the player’s session without implying synchronized game progress. The page should state that boundary directly: progress stays in this browser only.

Make the first screen answer the current question

The route page has three common entry states:

1. “Where is the next taxi?”
2. “Which puzzle am I looking at?”
3. “Which locations have I already completed?”

Those states map cleanly to three interface blocks: location cards, a clue matcher, and a route log. Long-form explanation remains available below them, but the tools answer the immediate question first.

I used this structure in Resonant Field Guide, an independent CONTROL Resonant guide covering the seven reported locations, six visible puzzle patterns, and a local completion log.

The general lesson applies beyond games. If a guide combines uncertain sources, repeated rules, and personal progress, separate those concerns in the data model. Store disagreement instead of erasing it, match on observable evidence, and keep local state within the boundary you can truthfully support.

That sounds obvious, but many small guide sites begin with categories such as “articles,” “news,” and “database.” Those labels describe how the site stores content. They do not describe what a player is trying to do.

For Task Bar Hero Atlas, I used a decision-first structure built around four questions:

1. What resource am I trying to farm?
2. What is stopping the current run?
3. Which route or build should I test next?
4. Is this information current for the game version I am playing?

Model the bottleneck before the recommendation

An idle RPG build is not useful without a goal. Clear speed, boss damage, and survival can point to different Rune priorities even at the same stage.

That led to a small content model for route pages:

route
  goal
  progression_context
  patch_version
  evidence_status
  recommended_next_test

The last field is deliberate. A guide should leave the player with something they can compare. “Try this route on the same stage and watch whether the run fails earlier or later” is more actionable than an unsupported “S-tier” label.

Keep tools small and local

The homepage includes a chest timer, but the tool does not pretend to know a server-side chest state. It is a simple local reminder for the player's own session.

That boundary is useful in product design. A local timer can be reliable without collecting account data or inventing live game telemetry. The page states what the tool does, gives quick presets, and links to the deeper chest notes for context.

The same pattern works for the Rune helper. It asks for the player's current goal, returns a first priority to test, and sends the user to the detailed Rune desk for the reasoning. The small interaction handles routing; the reference page handles evidence.

Attach version context to every volatile claim

Patch-sensitive content should carry its own version and confidence state. For example:

• an official release note can confirm that a feature exists;
• a repeated player test can support an observation;
• a roadmap can describe a plan;
• none of these automatically proves an absolute drop rate or a universal best build.

This separation prevents a common maintenance failure: a future announcement gets copied into a current guide, then survives after the release changes.

Build the homepage as a routing layer

The resulting homepage is not a compressed copy of every guide. It is a routing layer with three fast paths: find a farm, pick a build, or check a drop. It also shows the tracked patch, the current coverage boundary, and the tools that can be used immediately.

You can see the working structure at Task Bar Hero Atlas. The project is an independent guide for Task Bar Hero, currently tracking Ver 1.3.0, with 20 public pages covering Rune routes, builds, farming, stages, drops, pets, patch notes, and local tools.

For a small knowledge site, this structure keeps both readers and maintainers oriented: the player starts from a decision, and every volatile answer carries the context needed to revisit it later.

The fix is to treat content verification like a small data-quality pipeline.

Define a minimal walkthrough record

Each walkthrough should have a stable set of fields:

type Walkthrough = {
  gameId: string;
  levelNumber: number;
  sourceUrl: string;
  sourceVideoId: string;
  visibleSourceTitle: string;
  checkedAt: string;
  boardNotes?: string;
};

gameId matters because generic titles are ambiguous. A web game and a mobile app may both be called Fish Sort Puzzle while using different boards and level numbering.

Run collection-level checks

Page-level validation is not enough. The full collection should also satisfy rules such as:

• one record per (gameId, levelNumber) pair;
• one intended source video per level;
• level numbers within the supported range;
• no empty source titles or video IDs;
• no accidental gaps unless the missing levels are documented;
• all canonical URLs generated from the same route rule.

A duplicate check catches copy-and-paste mistakes. A range check catches a page labeled 170 that still points to Level 169. A gap report gives editors a concrete work queue instead of relying on memory.

Keep source evidence separate from strategy

Source metadata and editorial advice change at different speeds. The video mapping may remain valid while the written strategy improves. Event rewards or economy values may change with a game update.

Keeping those layers separate makes reviews smaller:

1. Verify identity and source mapping.
2. Describe the opening board and the important blockers.
3. Add strategy notes and checkpoints.
4. Date any version-sensitive facts.

This structure also makes corrections safer because a source fix does not require rewriting unrelated strategy content.

Give readers a mismatch test

A verified mapping still needs a human-readable check. Before following a walkthrough, the player should compare the opening board:

• Does the number of containers match?
• Are the same colors visible at the top?
• Are blocked or hidden stacks in the same positions?
• Is the walkthrough for the same app, not merely the same title?

If those signals differ, the user should stop. Replaying an incompatible solution is more frustrating than being told that the board has not been mapped yet.

Publish the distinction prominently

The homepage, level pages, and download page should all repeat the source boundary in plain language. Structured metadata is useful for maintenance, but users need the distinction before they invest time in a guide.

I applied this model to Fish Sort Wiki. The site offers a YIGOT browser game and a separate library of 156 mobile walkthroughs mapped to the Shycheese version by visible title and video ID. It also keeps downloads on official store links rather than hosting APK files.

For any large guide library, the strongest quality feature is not page count. It is the ability to prove that each page belongs to the correct product, version, level, and source.

While building an independent Fatal Frontier 1869 guide, I adopted a small content model that separates the claim, its evidence, and its lifespan.

Start with the claim, not the page

A page is a presentation. The maintainable unit is the claim behind it. For each update-sensitive statement, record:

type EvidenceState = "official" | "observed" | "reported" | "unknown";

type GuideClaim = {
  statement: string;
  state: EvidenceState;
  sourceUrl?: string;
  checkedAt?: string;
  checkedBuild?: string;
  reviewTrigger?: "patch" | "terms-change" | "manual";
};

This is a conceptual model rather than a required stack. It works in a CMS, Markdown front matter, JSON, or a relational database. The important part is that evidence state is explicit.

Give unknowns a first-class state

Many content systems allow published or draft, but not “the question is valid and the answer is unknown.” That gap encourages accidental fabrication.

An unknown record lets the public page say exactly what is missing. It also creates a useful research queue: look for an official source, reproduce the behavior, or keep the answer marked as unresolved.

Attach review triggers

Dates alone do not explain why a statement should be checked again. I use review triggers:

• patch for mechanics and numeric values;
• terms-change for eligibility, purchases, withdrawals, or other real-value rules;
• manual for durable explanations that change only when the whole system is redesigned.

This reduces unnecessary rewrites. A new patch can invalidate a movement threshold while leaving the first-run decision framework intact.

Render evidence close to the answer

A source list at the bottom is useful, but it does not show which citation supports which sentence. The page should place a small evidence label, date, or source link near a volatile claim. The interface can stay quiet; the relationship just has to remain visible.

For search pages, I still lead with a concise answer. The evidence and limitations follow immediately, so a search snippet or AI extraction is less likely to detach a number from its conditions.

Organize routes by intent

The navigation should reflect real tasks rather than the internal database:

• first expedition;
• supplies and survival;
• Pioneers and game systems;
• extraction;
• gold, costs, and current official rules;
• evidence and update status.

One claim may appear in several routes. Keeping it structured makes those appearances consistent while allowing each page to explain the decision in its own context.

A concrete example

The approach is visible in the independent Fatal Frontier 1869 Wiki. The site covers beginner routes and systems while keeping official statements, repeatable observations, player reports, and unresolved details distinct. It is an unofficial project and is not affiliated with the game's developer.

The broader pattern applies to any fast-moving knowledge base: store certainty and freshness with the content, render them near the answer, and let update events target the smallest affected unit. That turns maintenance from a full-site rewrite into a bounded review.