DEV Community: bingkun zhao

Why Patch Labels Belong in the Data Model of a Game Guide

bingkun zhao — Sun, 25 Oct 2026 06:17:44 +0000

Game guides have a quiet data problem: a recommendation can be correct when it is written and misleading after the next patch.

That is especially common in idle RPGs. A build may depend on a Rune effect, a stage reward, a chest table, or an event deadline. If one of those inputs changes, the headline can survive long after the reasoning underneath it has expired.

While organizing Task Bar Hero Atlas, I started treating a patch label as part of the content model rather than a decorative note.

The smallest useful record

For a build or farming route, the useful unit is not just a title and a list of items. It needs at least four pieces of context:

the game version;
the job the route is meant to solve;
the stage or progression range where it was checked;
the evidence status of the claim.

The second field matters more than it first appears. “Best build” collapses several different questions into one ranking. A player trying to clear repeated waves has a different bottleneck from a player stuck on a single boss. Another player may simply be dying before a farming loop becomes stable.

So the route should say whether it is aimed at clear speed, boss damage, or survival. That makes the recommendation testable. A player can change one route, repeat the same stage, and compare the result instead of copying an unexplained tier label.

Separate facts, observations, and plans

Patch coverage also benefits from three different states:

Confirmed: the current official notes say the feature or change is live.
Observed: a repeatable player test supports the claim, but it is not an official number.
Planned: a roadmap or announcement describes a future change.

Mixing these states creates false certainty. A relative drop improvement does not reveal the absolute drop chance. A roadmap date is not the same as a released feature. A community ranking is not a fixed property of the game.

The practical rule is simple: keep the source, version, and confidence beside the claim they qualify. Do not bury them in a general disclaimer at the bottom of the site.

Navigation should follow the next decision

I also found it more useful to organize the entry points around player intent:

choose a farming goal;
identify the current bottleneck;
select a Rune route;
check the patch label;
open the detailed source page only when needed.

This is why a small timer or route helper can be more useful on the homepage than another long encyclopedia list. The tool gives the player a next action, while the deeper pages hold the evidence and version history.

The public implementation is Task Bar Hero Atlas, an independent wiki and tool project currently tracking Ver 1.3.0. It includes the intent-based Rune helper, a local chest timer, compact reference desks, and patch-aware guide pages.

The larger lesson applies beyond one game: version labels are fields in your data model. Once you treat them that way, stale advice becomes easier to find, qualify, and replace.

How I Kept Two Different Fish Sort Games Out of One Guide

bingkun zhao — Sat, 24 Oct 2026 17:24:51 +0000

When a game title is generic, the hardest part of building a useful guide is often not writing the walkthrough. It is proving that every walkthrough belongs to the exact game and level the player has open.

I ran into this problem while organizing Fish Sort Puzzle material. The name is used by more than one game. A browser version can have different boards and numbering from a mobile app with a similar title. If those sources are merged into one library, a page can look complete while sending players to an incompatible solution.

Treat the game identity as data

The first step is to store the source game alongside every guide. A practical record can be as small as:

{
  "game": "Shycheese Android app",
  "level": 170,
  "videoId": "verified YouTube id",
  "visibleTitle": "Fish Sort Puzzle Level 170",
  "sourceChecked": true
}

The important field is not the level number. It is the combination of game identity, visible level title, and source identifier. Level 170 from one app is not automatically Level 170 from another.

For the browser game, the safest approach is to label it separately and say who distributes it. That prevents visitors from assuming that the mobile walkthrough library matches the playable web build.

Validate the mapping before publishing

For each walkthrough, I use a short checklist:

Confirm the level number appears in the source title.
Save the source video ID, not only the full URL.
Compare the opening board or visible landmarks when they are available.
Keep the game or package identity with the record.
Reject duplicate level numbers inside the same game library.

This catches the most damaging content errors: shifted numbering, duplicate videos, missing levels, and guides copied from the wrong game.

Make uncertainty visible

A guide should distinguish facts from advice. A verified source mapping is a fact about the page. A suggested opening order is strategy. Event rewards and economy values may change by version, so they need dates or version notes.

That distinction also improves maintenance. When a source changes, the affected pages can be found and reviewed without rewriting every strategy article.

Help the player verify the page

The page itself should give the player enough information to reject a mismatch quickly. Useful signals include:

the exact level number;
the game or app version covered;
a visible opening-board description;
the source video title and ID;
a warning when the browser and mobile games differ.

The player should compare the first screen before copying any move. If the container count, top colors, or blocked stacks differ, the walkthrough is for another board.

Apply the same rule to downloads

Generic game names also create download risk. A guide should link to the official store or developer page and identify the developer or package. Hosting copied APK files would remove the source information that players need to verify what they are installing.

I used these rules while organizing Fish Sort Wiki, which keeps the playable YIGOT browser game separate from 156 walkthroughs mapped to the Shycheese mobile version. The useful part of the model is not the number of pages. It is the boundary that stops two similarly named games from becoming one unreliable dataset.

If you are building guides for a game with clones, regional editions, or frequent updates, store the identity and evidence first. The walkthrough text is much easier to maintain once every page can answer: “Which exact game and source does this belong to?”

Designing a Source-Labeled Wiki for an Early Access Game

bingkun zhao — Sat, 24 Oct 2026 05:47:21 +0000

Early Access game documentation has a versioning problem. A value that is correct today may change after the next patch, while an unverified player report can spread faster than an official explanation. When I started building an independent guide for Fatal Frontier 1869, the hard part was not producing more pages. It was deciding what each statement was allowed to claim.

This article describes the content model I use for the project. It is useful for any small documentation site that covers a fast-changing product.

Treat confidence as data

Every important claim belongs to one of four buckets:

Official — stated by the developer, an official FAQ, Terms page, store listing, or patch note.
Observed — reproduced in the current game build or confirmed through a repeatable check.
Reported — described by players, but not independently reproduced.
Unknown — a useful question whose answer is not yet supported.

The fourth state matters. Without it, an editor feels pressure to fill every empty field, and a guess quietly turns into documentation.

A small record can represent the idea:

{
  "claim": "The route requires a specific supply threshold",
  "status": "reported",
  "source": "community discussion",
  "checked_build": null,
  "review_after": "next patch"
}

The public page does not need to show raw JSON. It does need to expose the status in plain language. Readers should be able to tell whether they are looking at a rule, a test result, or a lead that still needs checking.

Separate durable guidance from volatile values

Exact numbers are attractive search targets, but they are also the fastest part of a guide to decay. I split content into two layers:

Durable guidance explains the decision: bring enough supplies for the return, choose one objective for a first run, and treat extraction as part of every prospecting decision.
Volatile data records a cost, timer, threshold, eligibility rule, or build-specific behavior together with its source and verification date.

This makes updates smaller. A patch may invalidate one data record without forcing a rewrite of the whole beginner guide.

Build pages around player tasks

The site architecture follows questions a player asks during a run:

What should I do on my first expedition?
Which Pioneer or system do I need to understand next?
How does extraction work?
What is known about gold, costs, eligibility, and withdrawals?
Which statements come from official material, and which remain uncertain?

Each page starts with a direct answer, then adds context, evidence, limitations, and links to the next likely task. That structure helps search discovery, but the more important result is that a player can use the page without reading the entire site.

Make uncertainty visible in the interface

Uncertainty should not be hidden in a footer. Put it next to the claim:

show the source type;
record the last check;
name the game build when it matters;
link to the primary source where possible;
avoid converting a missing answer into a confident sentence.

This is especially important when a game includes an optional real-value layer. A description of a payout route is not a promise of profit, and current eligibility rules must come from the official Terms rather than from a guide writer's assumption.

Keep the site crawlable and maintainable

For a focused guide, simple output is an advantage. Important answers should exist in the initial HTML, pages should use unique titles and descriptions, and the hierarchy should remain shallow enough that a player or crawler can reach every core guide from a hub.

I also keep the editorial system separate from the presentation layer. The site can change its design without changing what “official,” “observed,” or “reported” means.

The result

The working example is the independent Fatal Frontier 1869 Wiki. It covers beginner routes, Pioneers, survival systems, extraction, gold, costs, and evidence checks. It is not affiliated with Paydirt Games.

The main lesson is simple: for fast-changing documentation, accuracy is not only a writing quality. It is a data model. If every claim carries its level of evidence, updates become safer and readers can make better decisions even when the product is still moving.