World Dungeon — Your Neighborhood Is the Map, Open-Source AI Is the Dungeon Master

Sudhanshu Mani Tripathi — Sun, 11 Oct 2026 17:30:08 +0000

This is a submission for the Hacktoberfest
Open-Source AI Challenge Week 1: Touch Grass

What I Built

World Dungeon turns your real neighborhood into
a walking quest. Before you leave home, the app
reads your actual surroundings from OpenStreetMap
— the named streets, the parks, the old temples,
the unnamed alleys, the bench nobody sits on,
the wall that predates the colony — and Gemma2
generates a quest seeded entirely from what is
physically there.

Then you put your phone in your pocket and walk.

Your earbuds narrate the story in an ancient,
whispering voice. You arrive at real places.
The lore unlocks. A burnt manuscript reveals
its hidden history as you walk — each waypoint
you reach restores another section of text that
was hidden under scorched parchment. When you
finish, you get a dungeon map made from your
actual GPS trace and a quest scroll that is
yours alone.

No two quests are the same. No quest exists
without walking it.

This is not a "get outside" app with a leaderboard
bolted on. The outdoor world IS the game board.
The screen is the shortest part of the experience:

2 minutes to generate the quest before you leave
0 screen time while walking — voice narrates, GPS unlocks, you keep your eyes up
2 minutes to collect your artifact when done

Who is it for: Anyone in a city who walks
the same streets every day and has stopped
seeing them. World Dungeon makes the ordinary
feel mythic — a bench becomes a threshold,
an unnamed alley becomes a passage, an empty
plot becomes an erasure.

Demo

🌐 Live app: https://world-dungeon-smoky.vercel.app

The deployed version uses Gemma2-9b-it hosted
on Groq for live quest generation. Open it on
your phone, allow location access, and tap
Generate Quest. A real quest for your actual
location will be generated in 8-15 seconds.

To run locally with offline Gemma:

git clone https://github.com/HeythisisSud/World-dungeon.git
cd World-dungeon
cp .env.example .env.local
# Add your keys — Mapillary (free), 
# ElevenLabs (free), Groq (free)
ollama pull gemma2:2b
npm install
npm run dev
# Open http://localhost:3000
# Allow location, tap Generate Quest
# Put your phone in your pocket and walk

Code

HeythisisSud / World-dungeon

How I Built It

The Core Idea

Every "get outside" app has the same problem:
the reward is on the screen, so the screen wins.
Pokémon Go solved this by making the outdoor
world the game board — you only catch the
Pokémon if you physically go there. World Dungeon
applies the same principle to storytelling:
the lore only exists at the location, the quest
only completes if you walk it, the artifact
only unlocks if you were there.

The open-source AI stack makes this possible
without a corporate backend owning your walks.

The Stack

Inference: Gemma2 (Google open-weight model)

Gemma2-9b-it running on Groq generates all
quest narrative. The model receives real
OpenStreetMap data for the player's 1km radius
— actual place names, coordinates, landmark
types, historical tags — and produces a
structured quest JSON: title, premise, four
waypoints tied to real OSM coordinates, a
100-150 word lore fragment per waypoint, and
a final artifact description.

The prompt explicitly instructs Gemma to:

Use ONLY real places from the OSM data
Draw from Indian history — Mughal era, colonial period, partition, urban legend
Make ordinary places mythic — a bench, a wall, an unnamed crossing
Never use European fantasy tropes
Return valid JSON only, no markdown

For local/offline use, the same code runs
against Gemma2:2b via Ollama. One environment
variable switches between them:
USE_LOCAL_OLLAMA=true # offline, private USE_LOCAL_OLLAMA=false # Groq hosted Gemma2

I benchmarked both:

Model	Provider	Response time	JSON validity	Lore quality
gemma2:2b	Local Ollama	18-35s	8/10	3.8/5
gemma2-9b-it	Groq	4-8s	10/10	4.4/5
phi3:mini	Local Ollama	12-20s	7/10	3.2/5

Gemma2-9b-it on Groq wins on every metric.
The larger model produces more historically
specific lore and more reliable JSON structure.
The local 2b model is slower but proves the
offline argument — the quest generates on your
device with no internet after the initial
OSM data fetch.

Map Data: OpenStreetMap via Overpass API

The Overpass query fetches everything OSM has
tagged within 1km — not just famous monuments.
Benches. Trees. Unnamed walls. Bus stops.
Empty plots. Chai stalls. The query deliberately
casts wide:

// Fetch benches, shops, historic sites, 
// natural features, barriers, land use —
// anything physically present
node["amenity"="bench"](around:${radius},...);
node["natural"~"tree|rock|spring"](around:...);
way["barrier"~"wall|fence|gate"](around:...);
way["landuse"~"vacant|brownfield"](around:...);
// Plus named amenities, historic sites, tourism

This is what makes every quest genuinely
hyperlocal. A quest seeded from Lodi Garden
and a quest seeded from Mayur Vihar are not
just different waypoints — they are completely
different stories because the raw material is
completely different.

Street-Level Photos: Mapillary

Mapillary is an open, community-contributed
street-level photo platform. When a waypoint
unlocks, the real photo of that street location
appears — not a stock image of a famous monument,
but an actual photograph of the specific street,
corner, or alley the player is standing at.

The image reveal is timed to the encounter
animation: the player arrives, the screen
flashes gold, and the real photo of the place
fades in over the darkened encounter panel.
The photo makes the lore land differently —
you are reading about this specific cracked
wall while looking at a photograph of it.

Fallback chain when Mapillary has no coverage:

Wikipedia thumbnail via REST API
Procedurally generated dungeon-map illustration (Canvas, seeded by coords)

Voice: ElevenLabs + Web Speech API fallback

The dungeon master voice uses ElevenLabs
eleven_multilingual_v2 model. The voice
character is deliberately ancient and
whispering — like the place itself speaking.

Key design decisions:

Unlock cue spoken at high stability (0.85) — commanding, carved-in-stone quality
Lore fragment spoken at lower stability (0.45) — more variation, like a voice remembering something painful
1200ms silence between cue and lore — the silence is part of the performance
Playback rate: 0.92 — slightly slowed, heavier, more ancient

All waypoint audio is pre-generated when the
quest loads so there is zero loading delay
when the player arrives at a waypoint. The
voice fires instantly on encounter trigger.

Web Speech API is the fallback — the game
works without ElevenLabs.

Live Map: Leaflet + Stadia Stamen Toner tiles

A real interactive map shows the player's
live GPS position and all waypoint locations.
The map tiles are color-graded with CSS filters
to a dark amber dungeon aesthetic:

.leaflet-tile-pane {
  filter: invert(1) sepia(1) saturate(3) 
          hue-rotate(180deg) brightness(0.4);
}

Roads become gold lines on near-black.
The map feels like a dungeon map because
it IS a dungeon map — just one that updates
in real time as the player walks.

The Burnt Manuscript System

The quest scroll starts almost entirely hidden
under scorched parchment. As the player walks
and unlocks waypoints, the burnt overlay
retreats — SVG clip-path animation with ember
glow along the reveal edge — and the hidden
lore is restored.

This mechanic means the quest scroll is a
reward that requires walking to earn. You
cannot read the full story without completing
the full walk.

The Journey Map

A persistent progress screen shows every
completed quest as a stamp on a winding road —
Candy Crush style, but the stamps contain
real photos from the player's actual walks.
The road is generated algorithmically with
a sine-wave layout. Each stamp is a circular
polaroid of the Mapillary photo or the player's
own camera photo from that quest.

Frontend: Next.js 14, TypeScript, Tailwind

Backend: Fastify, Node.js, TypeScript, Zod

Inference: Gemma2 via Groq (hosted) or Ollama (local)

Map data: OpenStreetMap / Overpass API

Photos: Mapillary API

Voice: ElevenLabs API

Deployment: Vercel (frontend), Render (backend)

Why Does Open Innovation Matter?

This project is only possible because of open
infrastructure at every layer. That is not an
accident — it is the architecture.

Your location is private.

Every quest generation prompt contains your
precise GPS coordinates and a detailed map of
your immediate surroundings — every named place
within 1km of where you are standing. With a
closed API (GPT-4, Gemini API), that data goes
to a server you do not control, is logged, and
is potentially used for training or advertising
targeting.

With Gemma2 running locally via Ollama, the
prompt never leaves your device. The quest is
generated in your own RAM. Switch
USE_LOCAL_OLLAMA=true and your walks are
completely private.

The map belongs to everyone.

OpenStreetMap is community-built and freely
licensed under ODbL. Google Maps charges per
API call, restricts derivative use, and owns
the data. OSM data means the lore of your
neighborhood is generated from a map that
your neighbors helped build — the bench
tagged by someone who walks that park every
morning, the unnamed alley that a local
mapper added because they knew it mattered.

The photos belong to the community.

Mapillary images are contributed by real
people walking real streets. The photograph
that appears when a player unlocks a waypoint
was taken by someone who walked that exact
spot. A closed alternative (Google Street View)
would cost money at scale and send the player's
location to Google's servers on every image load.

You can swap the model.

Want darker, more literary lore? Fine-tune
Gemma on Gothic fiction. Want quests in Hindi
or Urdu? Drop in a multilingual open-weight
model. Want faster generation on a low-end
phone? Switch to a 1B quantized model. Want
to run it entirely offline on a trail with
no signal? Set USE_LOCAL_OLLAMA=true and
pull the model before you leave.

A closed API makes none of these choices yours
to make. The model is the product, not a
component you can inspect, modify, or replace.

It works without internet.

After the initial OSM data fetch and model
pull, the quest generates on your device.
On a trail, in a park with no signal, in a
neighborhood where data is expensive — the
quest still runs. The walk is yours regardless
of connectivity.

A closed alternative would cost money.

Google Places API + GPT-4 + Google Street View

a cloud TTS service would cost approximately ₹8-15 per quest generation at scale. This stack costs ₹0 per quest. That is not a minor detail for a product meant to make walking accessible to everyone — not just people with API budgets.

My Agent Session

The core engineering challenge was the prompt
that turns raw OSM data into compelling lore.
Here is the iteration that made the biggest
difference:

What failed first:
Generic fantasy tropes. Gemma kept writing
about "ancient warriors" and "mystical energies"
regardless of location. A bench in Delhi got
the same lore as a castle in Scotland.

What fixed it:
Explicit cultural grounding in the prompt:
`Do NOT use European fantasy tropes.
Draw from: Mughal court politics, the 1857
uprising, the 1947 partition, DDA housing
colony history, Delhi monsoon cycles,
auto-rickshaw culture, chai stall regulars.

The lore must reference the specific place
name at least twice.
Make the walker feel that THIS EXACT SPOT
has a story only they now know.
`

The difference in output quality was immediate
and significant. The same bench that generated
"ancient mystical energy" started generating:
"The bench was placed here in 1978 by a DDA
worker whose name appears in no other record
from that project. The colony's oldest resident
says he came back every monsoon season to
repaint it. Nobody saw him arrive. Nobody saw
him leave."

That is the version worth walking for.

The second key insight was splitting lore
into two layers — surface observation (what
you see right now) and buried history (what
happened here). The surface layer grounds the
player in the physical present. The buried
layer is revealed on tap, rewarding curiosity.
This structure came from noticing that the
best quest lore always does two things:
describes and reveals.

Field Test

Honest note: The submission deadline caught
me before I could complete a full outdoor
field test. Here is what I know from testing
the GPS system indoors and what the planned
test would have covered:

GPS system: watchPosition with maximumAge:0
fires correctly on desktop simulation. The
20-meter proximity threshold triggers the
encounter animation as expected.

Planned test location: Mayur Vihar,
East Delhi.

What I expected to find:

OSM coverage in Mayur Vihar is moderate — named roads and major amenities are well-tagged, but many unnamed alleys and street furniture may not appear
Mapillary coverage confirmed via API test — 5 images returned within 500m of my location
AQI and heat in Delhi in October means morning walks (6-9am) are the realistic use window

What I would have reported honestly:

Whether the 20m proximity threshold is too tight for urban GPS accuracy (typical urban GPS error is 10-20m)
Whether Gemma placed any waypoints inside buildings or behind gates
Whether the ElevenLabs voice narration worked through earbuds while walking with the phone in a pocket
Whether the Mapillary images matched the actual current state of the streets (images may be months or years old)

I will update this post with real field test
results within 24 hours of submission. The
code is live and the quest generation works —
the walk is next.

Prize Categories

Gemma (Google) — Featured ($200)
Gemma2-9b-it is the core inference model.
It generates all quest narrative from real
OSM data. Benchmarked against Gemma2:2b
(local) and Phi3:mini. The project is built
around the open-weight Gemma2 model family —
swappable between local and hosted with one
environment variable, demonstrating the
model-as-component argument concretely.

ElevenLabs — Partner ($100)
The dungeon master voice is the primary UI
of the walk experience. Without narration,
players look at a screen. With ElevenLabs
eleven_multilingual_v2 at tuned stability
and pitch settings, the place itself speaks.
All waypoint audio is pre-generated at quest
start so narration fires instantly on arrival
with zero loading delay. Web Speech API
provides graceful degradation when offline.

Render — Featured ($200)
Backend (Fastify + Node.js) deployed on Render.
Handles the full quest generation pipeline:
Overpass API fetch → Gemma2 prompt build →
Groq inference → Zod validation → Wikimedia
image fetch → response. Free tier instance
with environment-variable-driven configuration.

SerpApi — Partner ($100)
Optional landmark enrichment layer. When
SERPAPI_KEY is configured, the backend pulls
real-world context about each OSM landmark
before building the Gemma prompt. Recent news
or historical facts about a location are
injected as [REAL CONTEXT: "..."] into the
prompt, grounding the AI lore in verifiable
reality. Degrades gracefully when key is absent.

GitHub Copilot — Partner ($100)
GitHub Copilot assisted throughout
development — autocompleting TypeScript
types, suggesting Zod schema structures,
and accelerating the Fastify route handlers.
The entire codebase is on GitHub with a
documented commit history showing the

build progression over 3 days.

Built in 3 days for Hacktoberfest Week 1:
Touch Grass. The neighborhood has always had
stories. We just needed an open dungeon master
to read them.

— @sudhanshu_manitripathi_f

You don’t get hacked by one bad pod. You get hacked by the path between them.

Sudhanshu Mani Tripathi — Tue, 07 Apr 2026 04:31:25 +0000

Most Kubernetes security discussions I see focus on individual misconfigurations —
bad RBAC, privileged pods, exposed services, etc.
But in real-world incidents, attackers don’t stop at one mistake.
They move. Laterally. Quietly.
From:
Pod → Node
Node → IAM / Cloud
One namespace → another
That “movement” is what actually breaks clusters.
DevOps Conference & Camps
So I built something to explore that idea:
A Kubernetes Attack Path Visualizer
Instead of showing isolated issues, it maps:
How different misconfigs connect
Possible attack chains across the cluster
Where privilege escalation actually becomes possible
Example: A low-priv pod + weak RBAC + node access
→ suddenly becomes cluster takeover
Individually? Not critical.
Together? Game over.
From what I’ve seen (and even in discussions here),
people underestimate how attackers pivot:
“More real attacks come from host stuff… spreading sideways”

What I’m trying to figure out:
Do you currently think in terms of attack paths or just misconfigs?
How do you prioritize fixes when everything looks risky?
Would something like this actually help in real clusters, or is it overkill?
Not trying to sell anything — just building in public and looking for feedback.
If you’ve dealt with K8s security in production, I’d love your perspective
Npm package: https://www.npmjs.com/package/k8s-av

DEV Community: Sudhanshu Mani Tripathi