Designing a Version-Aware Game Wiki for Early Access

1. Put provenance next to the fact

For every structured record, keep at least:

• the game build or patch it was checked against;
• the source type: official note, in-game observation, or community report;
• the observation date;
• a confidence state such as verified, provisional, or disputed;
• a stable identifier that survives display-name changes.

A user should not have to trust a page because it looks complete. They should be able to see whether a coordinate came from the current build and whether another player can reproduce it.

2. Separate stable identity from mutable labels

Names, descriptions, recipes, and locations may change. Use an internal key as the identity and keep display text as versioned attributes. This prevents an item rename from creating a second logical entity or breaking every inbound link. The same rule helps with localization: English and translated labels point to one entity, while the source and verification state remain shared.

3. Model maps as evidence, not decoration

An interactive map should not be a pile of pins. A useful marker contains coordinates, category, build, evidence, verification state, and a short player-facing note. If a patch moves or removes the object, preserve the history and mark the old observation as superseded. This also makes filters honest. “Show verified markers for the current build” is a meaningful query; “show everything ever imported” is not.

4. Make guides depend on structured facts

Low-spoiler guides are easier to maintain when routes reference item and location records instead of duplicating them. When a resource moves, the dependency graph tells you which guides need review. A practical review queue can be generated after every patch:

• ingest official patch notes;
• map changed nouns to stable entity IDs;
• flag affected recipes, markers, and guides;
• verify the highest-impact facts in game;
• publish the new state while retaining the previous build.

5. Design for uncertainty

Not every fact can be verified immediately. Hiding uncertainty encourages accidental certainty. I prefer explicit labels:

• Verified: reproduced for the stated build;
• Provisional: credible but not reproduced;
• Disputed: conflicting observations exist;
• Superseded: valid in an older build, not current.

These labels are more useful than a single “last updated” date because one page can contain facts with different evidence quality.

6. Give players task-oriented entry points

Players rarely arrive wanting “the database.” They want to unblock a task: find a resource, understand a recipe, plan a vehicle route, or check whether an old guide still applies. The public navigation should therefore expose task views-map, items, blueprints, creatures, guides, updates, and FAQ-while the data layer stays normalized underneath.

As a working example, the Subnautica 2 Wiki combines those views and publishes current-build context for players. Disclosure: I maintain this independent resource; it is not an official game site.

7. Add regression checks for content

Content can break like code. Useful automated checks include:

• every current recipe references existing item IDs;
• every public marker has coordinates and a build;
• no verified current fact points only to a superseded source;
• localized pages resolve to the same canonical entity;
• guide links do not point to removed routes;
• sitemap and canonical URLs match the public information architecture.

These checks do not prove that a coordinate is correct, but they prevent many silent consistency failures.

Closing thought: The key shift is simple: build an evidence system that renders a wiki, not a collection of pages that happens to contain facts. Early Access makes uncertainty unavoidable. Good architecture makes that uncertainty visible, reviewable, and inexpensive to update.