A game wiki starts as a list of pages and turns into a mapping problem the moment players ask "where is it?" rather than "what is it?".
Here is what I learned building an interactive game map for a game database, including the parts I got wrong.
Coordinates are the easy part
Storing x/y on a page is trivial. The hard parts are:
- Zoom levels. One image does not survive 0.25x to 8x. You need tiles, or at least a few re-rendered sizes, or the map looks like a blur at the zoom players actually use.
- Marker density. Four hundred pins at once is not a map, it is a texture. Clustering by zoom level is not optional.
- Deep links. Every marker needs a URL that opens the map at that point. Players share locations far more than they share guide pages.
Deep links changed how the map gets used
Before deep links, the map was a page people visited. After, it became something people linked to — from guides, from forum answers, from Discord. That single change did more for returning visitors than any visual polish.
Filter state belongs in the URL too
If a player filters to one region and one category, that state should survive a refresh and be shareable. Doing this meant treating the URL as the source of truth and re-deriving the UI from it, rather than keeping filter state in component state and hoping nobody reloads.
What I would not do again
- Build a custom tile pipeline first. Cache the pre-rendered sizes, measure whether anyone zooms past 2x, and only then invest.
- Design the pin icons before the clustering. Clustering changes what a pin has to communicate.
- Hide the coordinate in the page data. Put it somewhere queryable from day one.
The metric that mattered
Not page views. Marker opens per session. A visitor who opens three markers is using the map; a visitor who bounces off the overview is not, and the overview is the thing I kept polishing.
Written after rebuilding the map twice. The second version was smaller, faster, and the only one players linked to.
Top comments (0)