Product Engineering

Project Kappa

A location-based territory strategy game where running changes a shared world.

Every run captures, defends, or loses territory, transforming exercise into a persistent multiplayer strategy experience.

A spatial engineering story about making movement change shared territory.

Spatial Systems: territory, ownership, contested regions
Movement Evidence: GPS traces, route validation, physical loops
Game Simulation: capture state, defense, persistence

Status: draft
Year: 2026
Role: Founder · Product Designer · Full-Stack Engineer
Duration: In progress
Focus: Spatial systems, anti-cheat logic, synchronization, and long-term world simulation

Flutter
Python
SQLite
GPS
Riverpod
Dio

SECTION 01

Overview

Project Kappa is a location-based territory strategy game where running changes a shared world. The core loop is simple in public: a runner moves through real space, captures territory, defends routes, loses ground, and has a reason to return.

The engineering work is less about making a map look alive and more about making the loop honest. Location data has to be validated. Offline runs have to recover. Territory ownership cannot depend on a toy coordinate system forever. The product has to survive actual pockets, phones, parks, and people.

What makes it interesting is that it is not a fitness tracker. It builds a persistent game world driven by real movement, which means the product has to reason about spatial boundaries, anti-cheat signals, synchronization, and long-term simulation without making the runner feel like they are debugging a system.

SECTION 02

Problem

Kappa came from a product question: can running become more durable if the route has memory?

The idea depends on emotion, not just tracking. A normal run log records what happened. Kappa asks whether ownership, decay, and loss can make the next run feel necessary. That is why the early work focused on the territory loop, route validation, offline reliability, and privacy boundaries before broader product expansion.

SECTION 03

Why Existing Solutions Weren't Enough

Fitness apps already track movement, but they usually end when the workout ends. Strategy games create persistent worlds, but the movement is usually virtual.

Kappa sits between those models. The interesting problem is not recording a run; it is translating noisy physical movement into a shared game state that still feels fair tomorrow.

SECTION 04

Architecture

The core architecture is a loop from mobile run capture to local validation, territory resolution, and world synchronization.

Flutter records run sessions and keeps the interface responsive during movement.
GPS samples are normalized into route evidence instead of treated as perfect truth.
SQLite preserves local run state so interrupted sessions can recover.
Territory resolution converts movement into capture, defense, and loss events.

The proof artifact is the territory map: route path, contested cells, capture state, and evidence flags shown together.

SECTION 05

Interesting Engineering Decisions

The main decision was to treat location as evidence rather than authority. A coordinate point can be wrong, delayed, or spoofed; a route has to earn trust through consistency, timing, and surrounding context.

That pushed the system toward explicit validation steps: segment runs, score movement quality, flag suspicious jumps, and only then mutate territory.

SECTION 06

Challenges

The central challenge is that the product has to be validated in the real world.

The current foundation includes a simple backend, SQLite persistence, server-side validation, offline queueing, session recovery, and privacy concepts. But the hard parts are still physical: background GPS on Android, reliable run capture, tile ownership that maps cleanly to real geography, and validation with actual runners.

The existing grid model is useful for proving the loop, but it is not the final geography model. A real product needs a hex-based spatial layer and a validation model that agrees in real-world units, not just simulated grid coordinates.

SECTION 07

Tradeoffs

More validation makes the world fairer, but too much friction makes the runner feel punished by the system. The product has to explain questionable runs without turning every workout into an audit.

The current bias is conservative: protect the shared world first, then make dispute and recovery flows clear enough that honest users still trust the game.

SECTION 08

Evidence

What can be inspected

How does a run become trustworthy territory state?

Territory grid
Capture path
Contested region
Ownership state

Route evidence

GPS samples, pace continuity, and anomaly checks.

Sync model

Local recovery before shared-world reconciliation.

Current evidence focuses on the territory loop rather than finished multiplayer scale.

Territory map: captured, contested, and defended cells.
Capture flow: how route evidence becomes a world-state update.
Anti-cheat signals: GPS jumps, speed anomalies, and confidence scoring.
Synchronization model: local recovery, queued updates, and shared-state reconciliation.

SECTION 09

Outcome

Kappa now has a clear product and systems direction: persistent territory driven by real movement, with anti-cheat, synchronization, and long-term world simulation as the credibility layer.

The next proof point is an instrumented field build that shows capture flow, run recovery, and contested territory updates under real GPS noise.

SECTION 10

Lessons Learned

Kappa made the gap between software correctness and product truth very visible.

A simulation can pass tests while the product still fails outside. A route can validate on the server while a phone drops samples in a pocket. A territory mechanic can look clear in a prototype while feeling wrong to the runner.

The design changed because of that gap. The next engineering loop has to start with field evidence, not more interface surface. One runner using the product every week is more valuable than a larger roadmap built on assumed behavior.

SECTION 11

Future

The next honest step is not more product surface. It is field validation.

Kappa needs one runner, one park, and a small group test before larger city or community ideas matter. The technical path is also clear: migrate from the prototype grid to a real spatial index, harden Android background tracking, and make notification and territory decay behavior reliable enough to support the retention loop.