DEV Community: Nirav Neve

I built an outdoor game that uses AI to get you off your phone

Nirav Neve — Sun, 11 Oct 2026 18:33:56 +0000

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

What if an app's most important feature was knowing when to get out of your way?

Most apps compete for your attention. They want you to open them more often, spend more time inside them, and come back tomorrow.

For this challenge, I wanted to build something with the opposite goal.

I built GrassQuest, an outdoor exploration game that uses AI to turn your actual surroundings into quests, then rewards you for putting your phone away and exploring the real world.

The interesting part isn't just that it encourages people to go outside. It's how it decides what to do outside, how difficult that activity should be, and how to verify what you discovered without uploading your photographs to a cloud server.

What I Built

GrassQuest is a location-aware outdoor quest game built around one simple loop: choose a quest, leave your screen behind, explore, and return with proof of your adventure.

Here's how it works.

Your surroundings determine your quests

GrassQuest checks local weather, sunrise and sunset times, and nearby outdoor features using Open-Meteo and OpenStreetMap data.

It uses this context to filter its quest library. A quest that requires a pond should only appear when a suitable water feature exists nearby. A sunset quest makes more sense around golden hour. When severe weather makes outdoor activities unsuitable, the game can offer gentler alternatives and protect your streak.

The application has 248 hand-written quest templates, expanded into 1,324 concrete variations. The aim is to make exploration feel relevant to your surroundings rather than repeatedly presenting the same generic checklist.

TabPFN decides how challenging your next adventure should be

Instead of showing three random quests, GrassQuest uses TabPFN to estimate completion probability and walking duration.

It presents three choices:

Easy Win: The quest with the highest predicted chance of completion.
Sweet Spot: The quest closest to a 65% predicted completion probability.
Stretch: A more challenging quest that meets a minimum predicted probability threshold.

These predictions use structured information such as weather, time of day, quest effort, distance to nearby features, and available player history. The choices are selected from different categories.

The probabilities are estimates, not guarantees. When player history is limited, the system can fall back to a heuristic rather than pretending to know more than it does.

The Ranger sends you on your way

After accepting a quest, you receive an audio briefing from The Ranger, GrassQuest's narrator.

ElevenLabs generates the voice lines, which cover different weather conditions, times of day, and quest outcomes. I pre-generated 16 audio clips instead of repeatedly generating identical lines during gameplay.

Once the briefing is over, the expedition timer and compass bearing help you get moving.

Then you put your phone in your pocket.

Gemma verifies your adventure locally

When you return, you submit a photograph as proof of your quest.

GrassQuest uses Gemma 4 Vision through Ollama to evaluate the photograph on your own computer. It can return a successful verdict, a close attempt that earns partial rewards, or an unsuccessful attempt with feedback. It can also identify plants, trees, birds, insects, animals, fungi, and interesting sky features for your Field Guide.

The photograph never needs to leave your computer. The image is processed locally, and GrassQuest's backend receives the resulting verdict data rather than the original photograph.

This does require a compatible local Ollama and Gemma setup, but it gives the player control over where their images are processed.

There is a reason to come back tomorrow

Completed quests earn XP and Seeds. XP advances your level, while Seeds can be spent on Basecamp upgrades and streak freezes.

Your Basecamp evolves as you progress, and the Field Guide becomes a collection of things you've discovered outdoors. Badges and leaderboards add milestones and friendly competition.

The point isn't to create another digital chore. It's to give people a reason to keep exploring.

Demo

Live application:

https://grass-quest-woad.vercel.app

Live demo video:

Some Images

The deployed frontend is the entry point to GrassQuest. Local vision judging requires Ollama and a compatible Gemma model on the player's computer.

Code

GitHub repository:

NotNirav / GrassQuest

🌿 GrassQuest

Tiny real-world quests that get you off the screen. Get a quest, go outside, come back with a photo, and Gemma, an open-weight model running on your own computer through Ollama, judges whether you did it. Your photo never leaves your machine.

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: "Touch Grass" (Oct 2026).

How it works

 Browser (React)                                   Your computer
 ┌───────────────────────────────┐   photo +      ┌──────────────────────────┐
 │ quest card · "go outside"     │ ── prompt ───▶ │ Ollama · Gemma 4 (vision)│
 │ proof upload · verdict · XP   │ ◀── verdict ── │  judge + narrator lines  │
 └──────────────┬────────────────┘   (JSON)       └──────────────────────────┘
                │ verdict only (no photo)
                ▼
 ┌───────────────────────────────┐        ┌──────────────────────────────────┐
 │ FastAPI on Render             │ ─────▶ │ MongoDB Atlas                    │
 │  quest picker + dedupe        │        │ users · attempts · quests        │
 │  TabPFN: P(you finish quest)  │        │ + bge-m3 embeddings (Vector      │
 │

…

View on GitHub

The repository contains the frontend, FastAPI backend, quest library, model integrations, game mechanics, and setup instructions.

The main technologies are React, Vite, Python, FastAPI, MapLibre GL, MongoDB Atlas, TabPFN, Gemma 4 through Ollama, and ElevenLabs.

How I Built It

I started with a smaller MVP containing 41 hand-written quests and basic XP mechanics. But the first version had a problem: the individual integrations existed without forming a convincing gameplay experience.

The quests didn't adequately account for the player's surroundings. XP didn't lead to much. TabPFN barely influenced the player's choices, and Gemma only returned basic pass-or-fail results.

I decided to rebuild the experience around a more coherent idea: the environment should determine what's possible, AI should help choose what's achievable, and local vision should help verify what happened.

1. Environmental context and quest selection

The FastAPI backend aggregates weather and nearby-place data from Open-Meteo and OpenStreetMap Overpass. It filters quests according to environmental requirements, weather, time of day, and distance.

I also had to deal with Overpass timeouts. I split large queries into smaller groups, added caching, and introduced background cache warming to make the context engine more resilient.

2. TabPFN-powered recommendations

TabPFN's classifier estimates the probability of completing a quest, while a regressor estimates its duration.

The backend evaluates eligible candidates and uses those predictions to produce the Easy Win, Sweet Spot, and Stretch choices. I added request limits, caching, and a heuristic fallback to avoid making the entire game dependent on model availability.

3. Local Gemma inference

My first attempt was to run the vision model directly in the browser using WebGPU and Transformers.js. Downloading a multi-gigabyte model into mobile browser tabs proved too brittle across devices.

I pivoted to Ollama on the player's computer.

The browser sends the resized photograph directly to the local Ollama service. Gemma returns structured JSON containing the verdict, confidence, feedback, and identification information. The backend receives the verdict data needed for game progression, not the photograph itself.

This added a setup requirement, but it established a much clearer privacy boundary.

4. MongoDB Atlas and semantic quest deduplication

MongoDB Atlas stores player data, quest attempts, progression, and the expanded quest library.

I also integrated Atlas Vector Search using 1,024-dimensional embeddings generated locally with bge-m3 through Ollama. The system compares new candidates against recent attempts and filters semantically similar quests, reducing repetitive recommendations.

This makes the quest library more than a collection of randomly shuffled tasks.

5. ElevenLabs and the audio-first experience

I used ElevenLabs Flash v2.5 to generate The Ranger's voice lines. Rather than spending API credits on repeated narration, I pre-rendered 16 situational clips and stored them as static audio assets.

The result is an audio layer that responds to the expedition's context without requiring a fresh voice-generation request for every interaction.

6. The game and its visual identity

The frontend uses React and Vite, with MapLibre GL for maps and a custom CSS design inspired by outdoor field guides and topographic maps.

I built the Basecamp as an evolving SVG scene, with upgrades that reflect player progression and a visual environment that changes according to the local solar phase.

The backend handles the game economy, XP, Seeds, streaks, streak freezes, badges, and leaderboard data.

The overall architecture combines local AI inference with a hosted application backend. This means the public application is accessible through a browser, while the vision model remains on the player's computer.

Why Does Open Innovation Matter?

The most important reason is privacy.

An outdoor photograph can reveal far more than the object a player is trying to identify. Sending every image to a remote AI service would introduce a data transfer that isn't necessary for the core experience.

Running Gemma locally lets GrassQuest evaluate photographs without requiring them to be uploaded to a cloud vision API. The player retains control of the original image, while the backend receives only the structured result needed to award rewards.

Open-weight models also give developers more control over their AI architecture. I could choose where inference happens, integrate the model into my own workflow, and design the application around a local privacy boundary rather than depending entirely on a hosted inference endpoint.

TabPFN demonstrates another kind of flexibility: structured predictions can directly influence product decisions rather than existing as a disconnected AI feature.

MongoDB Atlas provides persistence and semantic search, while ElevenLabs supplies the narration that makes the expedition experience more engaging. These are different technologies with different roles; I haven't tried to make every component solve the same problem.

GrassQuest does still rely on hosted services for parts of its architecture, and local Gemma inference requires compatible hardware and setup. Open innovation doesn't eliminate every trade-off.

What it makes possible is a design in which the most sensitive part of the experience — evaluating a personal photograph — can happen on the user's own machine.

For a project about spending less time on screens, that distinction matters.

I don't want AI to become another reason to stare at a screen. I want it to help people notice what's beyond it.

Prize Categories

Best Use of Gemma

Gemma 4 Vision runs locally through Ollama to evaluate outdoor quest photographs, return structured verdicts, and identify natural discoveries for the Field Guide. Its local execution also enables the application's photograph-privacy boundary.

Best Use of TabPFN

TabPFN predicts quest completion probability and estimated duration. These predictions directly influence the three quest choices, making the model part of the core gameplay rather than a cosmetic integration.

Best Use of MongoDB Atlas

MongoDB Atlas stores the quest library, player data, attempts, and progression. Atlas Vector Search also helps filter semantically repetitive quests using locally generated bge-m3 embeddings.

Best Use of ElevenLabs

ElevenLabs Flash v2.5 generates The Ranger's narration, including context-specific departure briefings and reactions to quest outcomes. Pre-generated audio clips make these interactions available without repeatedly generating the same voice lines at runtime.

Built Solo

Built for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

If you try GrassQuest, I'd love to hear what quest it gives you and what you discover along the way.

My mom spends hours every week making test papers. I built her a generator that runs offline on Gemma 4

Nirav Neve — Sun, 04 Oct 2026 16:27:09 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My mom is my first friend. She is also a Class 8 maths teacher, and for as long as I can remember, test week at our house has looked the same.

The dining table disappears under the NCERT textbook, a stack of old question papers, a folder of worksheets and one notebook with a pencil tucked in it. She picks a question from one source, changes the numbers so the class can't copy last year's answers, works it out, writes the answer key, and moves on to the next one. A 40-mark paper is an evening. If she spots one bad question at the end, the whole thing gets retyped.

When I asked how I could help, her answer was simple: "I don't need new questions from the internet. I need questions from my books, in my style, and the answers have to be right."

So I built her a test paper generator that runs on her laptop.

She fills in a short form: total marks, how many MCQs, short answers, case studies and so on, the chapters, and a line like "more word problems, keep numbers simple". She presses one button. About twenty minutes later she has two Word files: the question paper and a separate answer key with a step-by-step marking scheme.

What it does for her:

Writes new questions from her own material. It reads her textbook chapters, 9 past papers and 15 worksheets, then writes fresh questions in the same style. Different numbers, new contexts, same chapter.
Checks every numeric answer key with code before it reaches her. If a key doesn't match the working, the question is rewritten.
Balances difficulty. By default a paper is 20% easy, 60% medium and 20% hard, the split most school papers follow, and she can change it.
Lets her replace one question without touching the rest. "Too hard", "too easy", "out of syllabus", or a note of her own, and only that question is rewritten.
Hands her real Word files, with proper fractions, powers and roots as Word equations, ready for her school's header.
Never loses work. The paper is saved after every question, so closing the laptop halfway through costs nothing.
Runs offline. Her books and her school's papers never leave the laptop.

Test week: before and after

	Before (by hand)	After (the generator)
Making a 40-mark paper	An evening at the dining table	~35–40 min of laptop time, a few minutes of hers
Finding questions	Flipping through the textbook, old papers and worksheets	Searches all 13 chapters and 681 of her questions automatically
Fresh questions	Changing numbers one by one	New numbers and contexts, with a check that nothing is copied
Answer key	Solved and written by hand	Written with every step, and checked by code
Difficulty balance	By feel	20% easy / 60% medium / 20% hard by default
One bad question	Retype the paper	Press Replace, about 1.5 minutes, nothing else moves
Formatting	Typing fractions and powers into Word	Word files with real equations, ready for the school header
If she stops halfway	Start again from her notes	Saved after every question, press Resume
Cost and privacy	—	Free, offline, her books never leave the laptop

Demo

Describe the paper, press Generate. The summary turns green when the rows add up to the total marks.

Review it, download it, or replace a single question.

What lands in Word. The question paper first, then the answer key with every step. No LaTeX symbols, no cleanup.

Here's one question from a generated 20-mark paper, exactly as it came out:

Q12. A shopkeeper purchased a refrigerator for ₹ 8,000 and a washing machine for ₹ 12,000. He sold the refrigerator at a profit of 10% and the washing machine at a loss of 5%. Find the overall profit or loss percent on the entire transaction. [3]

Key: SP = 8,800 + 11,400 = ₹ 20,200, CP = ₹ 20,000, profit ₹ 200, so 1% profit.

That paper had 13 questions, and all 13 answer keys were confirmed by the code checker on the first try.

Code

NotNirav / Paper-Generation-system

Offline Test Paper Generator (Class 8 Maths)

A local tool for a Class 8 (CBSE) maths teacher. Describe a paper ("6 MCQs of 1 mark, 3 short answers of 2 marks chapters 7 to 10, more word problems") and get back a Word question paper and a separate answer key with marking schemes. Questions are new, written from the teacher's own textbooks, worksheets and past papers (RAG), and every numeric answer key is checked by code. One bad question can be replaced without touching the rest.

Everything runs on the laptop: a local open-weight model (Gemma 4 12B through Ollama). No internet, no hosting.

Quick start (teacher)

Make sure Ollama is installed (the page starts it if needed).
Double-click start.bat. A browser page opens.
New paper: title, total marks, question rows (type, count, marks each), chapters, optional instructions and difficulty split (default 20% easy / 60%…

View on GitHub

Double-click start.bat, and the page opens in the browser. When she closes the tab, the app shuts itself down.

How I Built It

The whole thing runs on a normal laptop: 16 GB RAM and an NVIDIA card with 6 GB of VRAM. The heart of it is Gemma 4 12B running locally through Ollama. What surprised me most is that one open model did three very different jobs.

Job 1: Gemma read her books
The textbooks are PDFs full of fractions and exponents. Plain text extraction turns ³⁄₂ into a "3" and a "2" on separate lines, and that would have poisoned everything downstream.

So every page with maths on it is rendered to an image and handed to Gemma 4's vision side, which writes it back as clean Markdown with LaTeX. It read tables, it read a line graph correctly (all four values, both axes), and it kept every fraction in one piece. A small checker compares the digits Gemma wrote against the raw PDF text and re-reads any page that doesn't match.

37 files went through, all on the laptop, in one overnight run. Nothing was uploaded anywhere.

Job 2: Gemma sorted the questions
Past papers don't say which chapter a question belongs to, and the generator needs that to find good examples. Gemma tagged 460 questions with a chapter, using structured output limited to the 13 chapter numbers. Not one of those calls returned broken JSON.

Later I went through all 681 questions by hand and tagged each one with its chapter, a Bloom level and a difficulty. On chapters, I agreed with Gemma 94% of the time.

Job 3: Gemma writes the questions
For each question slot, the app pulls a couple of textbook passages for that chapter and three real questions from her papers with the same marks, type and difficulty. Gemma sees them as style references and writes one new question.

A few things made Gemma really shine here:

A JSON schema per question type. An MCQ must return four options and a correct letter. An assertion-reason question returns the two statements and three true/false flags, and the code builds the standard four options from them.
A scratchpad field. The schema starts with a working field that students never see. Giving Gemma room to solve the problem first made the final answers noticeably cleaner.
Thinking off, 16K context. Fast enough to write a question in about 90 seconds at roughly 10 tokens per second, on a 6 GB card.

Code checks the answers, not the model
A wrong answer key is the one mistake a teacher can't afford. So Gemma also returns the calculation behind its answer, in a form a computer can run:

{"compute": "((8000*1.1) + (12000*0.95)) - (8000 + 12000)", "claimed": "200"}

The app evaluates that with sympy, checks it matches the claim, and checks the claimed value is really the final answer in the key, or really the correct MCQ option. If anything disagrees, the question is rewritten. If it still can't be confirmed, it stays in the paper with a "check" badge so she knows exactly where to look.

The same idea runs through the Word export. After every file is written, a checker reads it back and makes sure no LaTeX symbol slipped into the text and no number went missing on the way into Word.

Replace one question
Each question has a Replace button. Her reason ("too hard", "out of syllabus", or anything she types) goes into the prompt together with the question she rejected, the difficulty moves a step if she asked for easier or harder, and every check runs again. The other questions don't move. Every replacement is also saved to a feedback log, which is a lovely little dataset if I ever fine-tune Gemma on her taste.

The stack, all open
Gemma 4 12B and bge-m3 through Ollama, ChromaDB for search, sympy for the answer checks, pandoc for Word equations, and Streamlit for the page.

Why Does Open Innovation Matter?

For this project, open wasn't a nice-to-have. It was the only way it could exist.

Her material stays hers. Textbooks and school question papers aren't mine to upload to someone else's server. With Gemma running locally, nothing leaves the laptop.
It works with no internet. Test week doesn't wait for the Wi-Fi.
It costs nothing per paper. No subscription, no API bill, no limit on how many times she presses Replace.
I could shape the model's output exactly. Per-type JSON schemas, a hidden scratchpad, my own retry rules. Every model call goes through one small file, so swapping or upgrading the model is a one-line change.
It's gentle on resources. It runs on a laptop she already owns, with no data-center round trip for every question. Replace rewrites one question instead of a whole paper. And because answer keys are checked before anything is printed, she isn't printing draft after draft to catch mistakes.

Prize Categories

Best Use of Gemma.
Gemma 4 12B is the core of the project, and it does three separate jobs, all running locally on a 6 GB laptop GPU:

Reading: Gemma 4's vision turned every textbook, worksheet and past-paper page into clean Markdown and LaTeX.
Sorting: it tagged 460 questions by chapter with structured output.
Writing: it writes every question, answer and marking scheme.

I went in expecting to stitch together three different models. Gemma did all three, offline, with structured output I could rely on.

To the Gemma team at Google
Thank you for putting a model this capable into a size that fits on a teacher's laptop. It turned "maybe one day" into a weekend project I could hand to my mom.

This week it is going to be me and my mom enjoying tea while the test paper generator does all the hard work 😉

Voice Note From my Mom

"It generated a test paper in a few minutes, which usually took me hours. It is a great help for me, and I am really proud of my son."
— my mom, after trying it for the first time