Building a Game Wiki Hub: The Content Model Is the Hard Part

I’m Ludy, and I’m building chuppa.gg, an independent hub for game wikis, beginner guides, character and item references, builds, tier lists, and codes.

This is a content project, not a developer utility. But the engineering questions behind it are surprisingly interesting: how do you organize information that is interconnected, unevenly structured, and vulnerable to becoming outdated?

Start with relationships, not page templates

A character page, a build, and a tier list might all mention the same character. That does not make them interchangeable.

The reference describes the entity. The build recommends a configuration. The tier list compares options under some set of assumptions.

A useful conceptual model is:

Game
  -> Reference entries
  -> Beginner guides
  -> Builds
  -> Tier lists
  -> Codes

Recommendation
  -> Referenced entities
  -> Supporting sources
  -> Applicable context

This is a design sketch, not a dump of the production schema. The important distinction is between describing something and recommending something.

The stack matters less than the publishing contract

I’m keeping this post stack-neutral rather than presenting an undocumented framework, database, or hosting setup as fact.

For this kind of site, the architectural contract is the interesting part: content storage feeds validation, validation feeds rendering, and rendering produces navigable pages with useful relationships.

Whether that pipeline uses files or a database, I would want checks for broken internal references, missing source URLs, duplicate identifiers, and content attached to the wrong game.

Those checks catch problems that a perfectly healthy build can otherwise publish.

Freshness is a modeling problem

A recently edited page is not necessarily a recently verified page.

That distinction becomes especially important for codes and balance-sensitive recommendations. A typo fix should not imply that someone retested a build.

My preferred design separates editorial changes from verification events and records what was actually checked. That is a direction for the content model, not a promise of automated verification.

What I want feedback on

I’m interested in how other developers handle source relationships and update context in content-heavy applications.

Would you model a build as structured data with prose attached, or as prose with references embedded? How would you expose uncertainty without covering every page in warnings?

Take a look at chuppa.gg and tell me which relationships you would make more explicit.