NIKITHA S

Posted on Oct 5

GetOut!

#devchallenge #weekendchallenge #hf26challenge

🚶 GetOut! — Draw Your Route, Not Just Your Steps

What I Built

GetOut! is a multiplayer walking/cycling game that turns a simple outdoor activity into a challenge.

The idea came from a very simple problem:

Sometimes you want to go outside with a friend, but you don't really know what to do once you're out there.

Instead of just tracking steps or following a predefined route, GetOut! gives both players a shape to complete.

One player creates a session and shares a short join code with their friend. Once both players join, the game generates a challenge such as a triangle, square, or other geometric shape.

Each player gets the same challenge, but it is anchored around their own starting location.

The actual walking route is generated using real-world roads, so the challenge becomes:

Start → Checkpoint A → Checkpoint B → ... → Finish

Players can see their progress, reach checkpoints, check in, and try to complete the challenge as quickly as possible.

The goal isn't to create the perfect geometric line on a map.

It's to turn:

"Let's go for a walk."

into:

"Let's see who can complete the triangle first." 🏃‍♀️

Demo

🌐 Live Demo:
https://get-out-nine.vercel.app/

The frontend is deployed on Vercel, while the multiplayer FastAPI backend runs on Render.

How to try it

Open GetOut!
Create a session.
Share the generated 6-character code with a friend.
Your friend joins using the code.
Start the challenge.
Follow the generated checkpoints.
Complete the shape and compare your time!

Code

GitHub:
https://github.com/stargalax/GetOut

The project is split into:

React + Vite frontend
FastAPI multiplayer backend
Qwen3 running locally in the browser
Valhalla / OpenStreetMap for road routing
WebSockets for real-time player communication

How I Built It

The most important part of GetOut! is that the AI isn't running on my backend.

I use Qwen3 locally in the user's browser through Hugging Face Transformers.

The architecture looks like this:

                 ┌─────────────────────┐
                 │      Player         │
                 │   React Frontend    │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │       Qwen3         │
                 │  Local Browser AI   │
                 └──────────┬──────────┘
                            │
                    Spatial Plan
                            │
                            ▼
                 ┌─────────────────────┐
                 │    FastAPI Backend  │
                 │      Render         │
                 └──────────┬──────────┘
                            │
                            ▼
                 ┌─────────────────────┐
                 │      Valhalla       │
                 │   OSM Road Routing  │
                 └─────────────────────┘

1. Qwen3 creates the challenge

When the challenge starts, Qwen3 is loaded directly in the browser.

It receives the challenge context and produces a semantic description such as:

{
  "shape": "triangle",
  "size": "large",
  "pace": "normal",
  "title": "Triangle Challenge"
}

The frontend then converts that semantic response into a structured spatial plan containing the shape, checkpoints, rotation, and target dimensions.

For example:

START
  ↓
CHECKPOINT A
  ↓
CHECKPOINT B
  ↓
START / FINISH

2. The backend handles multiplayer coordination

The FastAPI backend doesn't run the AI model.

Instead, it receives the spatial plan from the browser and handles:

session creation
join codes
player connections
WebSocket communication
player locations
challenge synchronization
route generation

Sessions are synchronized in real time using WebSockets.

3. Real roads replace impossible straight lines

A geometric triangle looks great mathematically, but you can't necessarily walk in a perfectly straight line through buildings, rivers, highways, or private property.

So instead of forcing the road network to literally draw a triangle, GetOut! treats the generated shape as a checkpoint challenge.

Valhalla then finds walkable/cyclable routes between those checkpoints.

This makes the challenge work in the real world.

4. Each player gets their own version of the challenge

This was one of my favorite parts to implement.

If two friends start several kilometers apart, they shouldn't have to travel to the same physical triangle.

Instead:

Both players get the same type of challenge, but it is generated relative to their own starting locations.

That makes the competition fair while still letting both people start from wherever they are.

Why Does Open Innovation Matter?

For me, the biggest advantage of open innovation was control.

A closed AI API could have generated the challenge description, but then the entire experience would depend on sending a user's location and prompt to an external service.

With a local open-weight model, I could experiment with running the AI directly on the user's device.

That creates some interesting possibilities:

Privacy: location-based challenge generation doesn't require sending the AI inference itself to a third-party AI API.
Lower backend cost: my server doesn't need to run an expensive model.
Offline potential: the AI component can potentially work without a separate inference server once the model is available locally.
Experimentation: I can change the prompt and challenge logic without being tied to a proprietary API.
Transparency: I can see exactly where the model's output ends and my application logic begins.

It also made the architecture more interesting.

Instead of:

User → Cloud AI → Backend → Map

I could build:

User
 ↓
Local AI
 ↓
Spatial Plan
 ↓
Backend
 ↓
Real-world route

The AI becomes part of the application itself rather than just an API call hidden behind the server.

My Agent Session

I didn't use an agent for this project, so I don't have an Agent Session to include here.

Instead, the AI component is Qwen3 running locally in the browser.

I wanted to keep the architecture intentionally simple: the model generates the semantic challenge, while deterministic application code handles the geometry, multiplayer state, and routing.

Prize Categories

🏆 Best Use of Render

GetOut!'s multiplayer backend is deployed on Render.

Render hosts the FastAPI server responsible for:

multiplayer session creation
join-code management
WebSocket connections
synchronizing the two players
receiving spatial plans
generating real-world routes

The frontend is deployed separately on Vercel, while Render acts as the real-time backend that connects the players together.

Tech Stack

Part	Technology
Frontend	React + Vite
Maps	React Leaflet
Local AI	Qwen3
AI Runtime	Hugging Face Transformers
Backend	FastAPI
Real-time communication	WebSockets
Routing	Valhalla
Map data	OpenStreetMap
Frontend hosting	Vercel
Backend hosting	Render

Final Thoughts

I started with the idea of making something that would simply encourage two people to get outside.

But while building it, I became much more interested in the boundary between AI-generated ideas and deterministic real-world systems.

Qwen doesn't need to know how to navigate a city.

Valhalla doesn't need to know what a "fun challenge" is.

The frontend doesn't need to understand how an LLM works.

Each part does one thing, and together they turn a generated idea into something you can actually walk.

And that's the whole point of GetOut!:

Don't just go for a walk. Give yourself somewhere to go. 🚶‍♀️🗺️

You can check out a sample I did with my friend here!

My friend was able to complete the challenge before me! lol

Thank you for reading my submission!

DEV Community