This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
What if the best AI experience was one that made you close the app?
Most AI products are designed to keep you on a screen. More messages. More recommendations. More scrolling.
I wanted to build the opposite.
So I built AI Nature Quest, an open-source outdoor adventure game where AI creates a real-world quest, tells you to put your phone away, and waits for you to come back.
AI generates the adventure. You go live it.
The goal is simple: make the screen the shortest part of the experience.
Live Demo: https://ainaturequest.netlify.app/
GitHub: https://github.com/extinctsion/ainaturequest
Challenge: https://dev.to/challenges/hacktoberfest-week1-2026-10-05/
AI Nature Quest turns an ordinary walk into a small outdoor adventure.
You choose:
The AI then creates a quest with objectives such as:
Then comes the most important part.
The app tells you:
Your phone is no longer needed.
Put it away.
Go explore.
Come back when you're ready.
This is the feature I cared about most.
Once a quest starts, the interface becomes intentionally minimal. Instead of giving the user another feed to scroll, it gives them a timer and one instruction:
Put your phone away.
The timer persists, so the user can actually leave the phone in their pocket and come back later.
When the adventure is over, the user returns and submits evidence.
They can provide:
The AI evaluates the evidence, awards XP, and completes the quest.
Completed discoveries can then be saved to a private Nature Journal.
The result is a simple loop:
Generate
↓
Go outside
↓
Put phone away
↓
Explore
↓
Return
↓
Submit evidence
↓
Earn XP
↓
Discover more
That loop is the product.
I think we have a strange relationship with AI right now.
We keep asking:
"How can AI help me spend more time with technology?"
I wanted to ask the opposite question:
"How can AI help me spend less time with technology?"
Nature already has the content.
The park, street, garden, trees, birds, sounds, weather, and tiny things we normally walk past are the game world.
AI simply becomes the game master.
That distinction matters.
The goal isn't to make someone spend an hour interacting with an AI.
The goal is to spend five minutes interacting with the app and the next 55 minutes interacting with the real world.
I didn't want this to remain a browser experiment.
I shared the application with a friend and we actually went outside and tried it together.
We both used the application and competed on the generated objectives.
And there is a funny part to the story:
My friend won.
But I still considered that a win.
Because the application I built with AI assistance actually got another person outside, walking around, looking at their surroundings, and competing in the real world.
That was the most important test for me.
The application didn't need to win the game.
It needed to get us out the door.
Live demo: https://ainaturequest.netlify.app/
The public demo can be used without creating an account.
The zero-configuration demo experience uses the deterministic Demo AI provider so anyone can try the complete product without an API key.
The project also includes a real Gemma provider for open-weight AI inference.
The project is open source under the MIT License.
The application is built as a mobile-first Progressive Web App using:
The architecture separates the product experience from the model implementation.
AI Nature Quest
|
AIProvider
|
+-------------+-------------+
| |
DemoAIProvider GemmaAIProvider
| |
Deterministic AI Open-weight Gemma
for zero-config demo via local inference
The application talks to an AIProvider interface rather than directly to a particular model.
Conceptually:
interface AIProvider {
generateQuest(input: QuestRequest): Promise<Quest>;
evaluateEvidence(input: EvidenceRequest): Promise<EvidenceResult>;
}
That means the quest UI doesn't care whether the response came from the deterministic demo provider or Gemma.
It just receives a validated Quest.
The same applies to evidence evaluation.
The Demo provider exists for a practical reason.
I wanted someone to be able to clone the repository, run:
npm install
npm run dev
and immediately experience the entire product without needing an API key, GPU, model download, or external service.
It also makes the application reliable for the public hosted demo.
But the project does not stop there.
The real AI path uses Google's open-weight Gemma family.
Gemma is used as the game master for quest generation and as the naturalist evaluator for submitted evidence.
For local inference, the project can connect to Gemma through Ollama.
A local setup looks like:
ollama pull gemma3:4b
Then configure:
AI_PROVIDER=gemma
AI_MODEL=gemma3:4b
AI_API_URL=http://localhost:11434
The provider architecture keeps this separate from the rest of the application.
For evidence involving images, a multimodal Gemma model can inspect the submitted image and return a structured evaluation.
That creates a much more interesting interaction than simply asking an LLM to generate text.
The model is participating in the game loop.
I didn't want model output to directly control the UI.
Quest generation is validated into a structured schema.
For example:
{
"title": "The Hidden Naturalist",
"description": "Explore your surroundings and notice what you normally walk past.",
"durationMinutes": 30,
"difficulty": 3,
"objectives": [
{
"title": "Leaf Detective",
"description": "Find three visibly different leaf shapes.",
"evidenceType": "photo",
"xp": 50
}
],
"totalXp": 250,
"phoneAwayMinutes": 25
}
Evidence evaluation follows the same principle.
The model returns structured information such as:
{
"completed": true,
"confidence": 0.91,
"feedback": "The image appears to contain three visibly different leaf shapes.",
"xpAwarded": 50
}
The application validates the result before using it.
This makes the model replaceable and reduces the amount of model-specific logic leaking into the UI.
This project is a particularly good example of where open AI changes the product design.
If I had built this entirely around a closed API, the model would effectively become another remote service dependency.
Instead, the AI provider is replaceable.
That gives the project several important properties.
With Gemma running locally, the user can run the AI on their own machine.
That matters for an application dealing with photos of people's surroundings.
The architecture doesn't require every piece of evidence to be sent to a centralized AI service.
The product doesn't fundamentally depend on one model vendor.
Today:
Gemma
Tomorrow:
Any AI model as per preference
The product layer doesn't need to be rewritten.
Because the model layer is open and replaceable, developers can experiment with:
That is especially valuable for a project where the AI behavior is part of the game mechanics.
The project is intentionally designed around local-first storage.
There is no account requirement.
The Nature Journal is stored locally.
And with local Gemma inference, the model can also run locally instead of requiring a remote AI API.
The important point is not that open AI automatically makes everything private.
It is that open infrastructure gives the developer control over where inference happens and what happens to the user's data.
A local open-weight model can remove API costs from the development loop.
That makes it much easier to repeatedly test prompts, quest generation, evidence evaluation, and model behavior.
For an experimental project like this, that matters.
There is one metric I deliberately don't want to optimize.
Screen time.
Most consumer applications measure success by how long someone stays inside the application.
AI Nature Quest measures success by whether the user leaves it.
That creates a funny product philosophy:
The better you use the app, the less time you spend using it.
The AI creates the quest.
The human experiences it.
The phone waits.
An AI naturalist shouldn't pretend to be a scientific authority.
The application therefore avoids instructions involving:
The application also reminds users to stay on safe/public paths and respect wildlife.
The purpose is observation, not risk-taking.
AI Nature Quest does not require:
The Nature Journal and progression data are stored locally.
Demo mode does not need an external AI API.
When using local Gemma inference, AI processing can happen against the user's configured local inference endpoint.
The project is intentionally designed so that privacy is not an afterthought.
The biggest lesson wasn't about Next.js or AI APIs.
It was about product design.
When I started building this, it would have been easy to add:
Instead, I kept coming back to one question:
Does this feature help someone get outside?
If the answer was no, it probably didn't belong in the MVP.
That constraint made the product better.
It also made the AI more interesting.
The AI isn't the destination.
It is the trigger.
I built the project using Antigravity and VS Code, with AI-assisted development through the development workflow.
I also used GitHub Copilot during development.
AI-assisted coding helped me move quickly, but the product decisions remained centered around the real-world behavior I wanted to create.
The most important test wasn't:
"Can AI build the application?"
It was:
"Can the application get someone to put the phone down?"
I tested that with a real friend.
And even though my friend beat me at the quest, the experiment worked.
I am entering:
Gemma is used as the open-weight AI provider for quest generation and evidence evaluation.
GitHub Copilot was used as part of the development workflow.
There are a lot of directions this could go.
Some possibilities:
But I don't want to lose the original idea.
The application should always work toward the same outcome:
less screen, more world.
We are building increasingly powerful AI systems that can generate almost anything on a screen.
Maybe one of the most useful things an AI can generate is a reason to stop looking at that screen.
AI Nature Quest is my attempt at that.