Tap Tap Loot Wiki

Why This Project

Tap Tap Loot is a mobile idle-tapping game we played ourselves. The item catalog is massive - enemies, loot tables, weapons, armor, upgrades - and we wanted to build a reference for it that grows with the game.

What I Built

Tap Tap Loot Wiki is a statically generated Next.js site with a procedural data pipeline at its core. Game data isn't hand-typed into content files - it's generated by generate_wiki.js, a Node.js script that reads from the game's exported data format and produces the structured JSON that the Next.js build consumes.

Core features:

• Enemy index - every enemy with HP, drop tables, spawn locations, and weaknesses
• Item database - weapons, armor, consumables, and passive items with full stat breakdowns
• Loot tables - searchable by item name to find which enemies drop it, or by enemy to see the full drop pool
• Upgrade planner - client-side calculator for planning upgrade paths given a current item set
• Pixel-accurate rendering - sprite sheets from the game rendered at 2x and 4x with image-rendering: pixelated CSS and Next.js unoptimized flag to prevent AVIF conversion that destroys pixel art

The Data Pipeline

This is the architectural decision that separates a maintainable wiki from a liability.

generate_wiki.js is a Node.js script that takes the game's exported data (a set of CSV and JSON files that the game developer can produce from the editor) and transforms it into the wiki's internal data schema. It runs as part of the build pipeline: npm run generate && next build.

The output is validated with Zod before the build continues. If the generated data has missing required fields, wrong types, or invalid relationships (e.g., a loot table entry references an item ID that doesn't exist in the item table), the build fails. The error message tells you exactly which record failed validation and why.

This means:

• Updating the wiki for a new patch is running generate_wiki.js and pushing the output
• A bad data export from the game developer produces a clear error at build time, not a silent null value on a user-facing page
• The wiki's data schema is explicitly documented in the Zod schema - a new contributor can read it and understand what every field means

Pixel Art Rendering

Next.js aggressively optimizes images by default - it converts PNGs to WebP or AVIF and resizes them. This is exactly wrong for pixel art: modern image codecs apply lossy compression that blurs the sharp pixel boundaries that define pixel art's visual style.

The fix: unoptimized={true} on the <Image> component for all game sprites, combined with image-rendering: pixelated CSS. The sprites load at their native size (typically 16×16 or 32×32 pixels) and CSS scales them up to display size using nearest-neighbor interpolation, preserving the crisp pixel boundaries.

This is a small detail but it's the difference between a wiki that looks like it belongs in the game's universe and one that looks like a blurry screenshot from a phone.

SEO Architecture

Mobile game wikis compete with Gamepedia (now Fandom) pages that have years of authority. Winning on long-tail searches ("tap tap loot [item name]") requires technical correctness and content depth, not just domain age.

Page-per-item. Every enemy, weapon, armor piece, and consumable has its own URL with its own H1, meta description, and structured content. This means Google can index individual items and serve them directly in search results, rather than forcing users to navigate from a generic page.

GamePlayMode and ItemList schema. Item pages use Product-adjacent structured data (adapted for game items), and the main index pages use ItemList to communicate the relationship between pages to Google's crawler.

Canonical handling. Items that appear in multiple categories (e.g., a weapon that's also a boss drop) have a single canonical URL referenced from all category listings.

Internal link density. Every loot table cross-links to item pages; every item page links back to the enemies that drop it. This creates a dense graph that benefits crawl efficiency and distributes page authority across the content.

Impact

The wiki gives Tap Tap Loot's community a reference that updates with the game rather than falling behind it. The data pipeline means the developer can produce a data export after a patch and the wiki is up to date after a five-minute build - no manual content editing, no hunting through JSON files to update numbers.