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.
Top comments (0)