Last Flag Wiki

Why This Project

Last Flag is a multiplayer capture-the-flag game we played ourselves. Guides and item data were scattered across Discord and Reddit - we wanted to build a proper reference for it.

What I Built

Last Flag Wiki is a statically generated content site built on Next.js 16 App Router with React 19 and strict TypeScript configuration. Content is written in MDX - Markdown with embedded React components - and compiled to static HTML at build time.

Core features:

• Item database - every weapon, armor piece, consumable, and upgrade documented with stats, acquisition method, and tier rating
• Map guides - tactical breakdowns of each map's flag positions, rotation paths, and power positions with annotated diagrams
• Crafting calculator - interactive component (client-side only) for planning resource combinations
• Search - client-side full-text search over the static JSON data export, no server required
• Redirect system - when map names or item names change between patches, old URLs redirect to the new canonical pages rather than 404ing

Technical Architecture

Static generation first. Every page is generated at build time. There's no server that can go down, no database that needs maintenance, no API that can become a bottleneck under load. The entire site is a collection of HTML, JS, and CSS files that can be served from a CDN or any static host.

Strict TypeScript. tsconfig.json has strict: true, noUncheckedIndexedAccess: true, and exactOptionalPropertyTypes: true. This sounds like overhead until you're maintaining item data where a missing field is a runtime bug on a user-facing page. Strict mode catches those bugs at build time.

MDX content. Game guides benefit from being written in prose, but they also need structured elements - stat tables, comparison grids, callout boxes for critical information. MDX lets the content author write Markdown for prose and use React components for structured content. No CMS UI required; the content lives in the repository next to the code.

Zero unnecessary dependencies. The dependency list is intentionally minimal: Next.js, React, Tailwind, content-collections for MDX processing, and nothing else. No heavy component libraries, no state management framework, no analytics vendor. Every dependency is a maintenance liability in a long-lived project.

Custom font handling. DM Serif Display is self-hosted via next/font/local, eliminating any dependency on Google's CDN for the site's primary display font.

SEO Decisions

Wiki content competes in a space with well-established Fandom wikis and YouTube guides. Winning on organic search requires technical correctness, not just content volume.

Heading hierarchy. Every page has a single H1 (the item or guide name), followed by a logical H2/H3 structure that matches what players are actually searching for: item names, map names, game mechanic names.

BreadcrumbList schema. Every page includes BreadcrumbList structured data so Google understands the site hierarchy and can display breadcrumbs in search results.

Canonical URLs. Item variants and patch-specific pages use canonical tags pointing to the primary entry to prevent duplicate indexing.

Internal linking. Every item mention in a guide links to the item's database page. This creates a dense internal link graph that passes equity to the most important pages and improves crawl efficiency.

Redirect handling. Game content changes between patches - items get renamed, maps get reworked. Permanent redirects (308) maintain the SEO equity of old URLs rather than losing it to 404s.

Engineering Challenges

Content schema design. The item database schema needed to be flexible enough to handle the game's heterogeneous item types (weapons have different stats than consumables) while being strict enough to catch missing or malformed data at build time. I used TypeScript discriminated unions to type each item category, with content-collections validating the MDX frontmatter against the schema.

Search without a server. Full-text search on a static site requires a different approach than a typical search backend. I generate a JSON index at build time containing all searchable text, and load it client-side on demand (lazy, only when the search input is focused). The index is kept small by stripping prose and indexing only titles, tags, and structured fields.

Impact

Last Flag Wiki provides the game's community with a permanent, searchable, SEO-indexed reference. The static architecture means it will continue working correctly as long as someone pays for the domain - no database migrations, no security patches, no runtime dependencies to update under urgency.