DEV Community

华灵庚
华灵庚

Posted on • Originally published at guildrunguide.wiki

How I Built a Data-Driven Game Wiki with Next.js — Hero DB, Pipeline, and Static Export

#nextjs #webdev #gamedev #tutorial

I just shipped a data-heavy game wiki for Guildrun (a roguelite auto-battler on Steam) and wanted to share the architecture because it's a pattern that works well for any structured game data site.

The Problem

Most game wikis are either Fandom pages (slow, ad-heavy) or markdown files on GitHub (not indexable). I wanted something that could handle 25 heroes × 13 stats each, 162 items, and 295 relics — all with source provenance tracking — while rendering as fast static HTML.

The Stack

  • Next.js 14 with App Router, static export (output: "export")
  • Tailwind CSS for styling
  • Vercel for deployment + Cloudflare DNS
  • Data pipeline: raw markdown files → build-time parser → typed TypeScript objects → static pages

The Data Pipeline

The key insight was keeping content and code separate. All game data lives in content-input/pages/ as structured markdown files with a custom frontmatter format:

slug: beginner-guide
title: Guildrun Beginner Guide
contentStatus: ready
versionContext: Steam demo build (app/3669200)
Enter fullscreen mode Exit fullscreen mode

Each page has a directAnswer section (for Google featured snippets), structured sections with evidenceType tags, and a quickFacts table. The build script parses these into typed records and generates one static page per guide.

Source Provenance

Because this is a demo-phase game, accuracy matters more than completeness. Every data block has an evidence level:

  • confirmed-fact — verified in demo game files
  • community-report — Discord/Reddit consensus
  • editorial-recommendation — strategy opinion
  • uncertainty — explicitly flagged as "might change"

This ships to the frontend as a small badge on each section. Readers know exactly how reliable each claim is.

Static Export & Performance

Full static export means every page is pre-rendered HTML. No database queries at request time. Total build time is under 2 minutes for 9 content pages plus the hero/item/relic database routes. Lighthouse scores are 95+ across the board.

What I'd Do Differently

  • Start with a smaller indexable surface: we shipped the full data set at once, but phasing in pages gradually would give Google more time to evaluate each one
  • Add a data diff system earlier: when the full game launches and stats change, we need to show what changed from the demo build

The live site is at guildrunguide.wiki if you want to see the result. Happy to answer questions about the pipeline or the content architecture.

Top comments (0)