Character - Stealzmi
Character - The Saif Guy
Character - Burgl AR
Home interface
AI difficulty and statistical comparisons (previous rounds VS current round)
Game Interface and Map
Character - The Arif-Nator

How Time Heist came to be

“Time Heist: the vault is only as safe as the last loop.”

The idea that started it

We first imagined a tool to help emergency service vehicles transport patients more efficiently. It would use traffic and weather forecasts, along with a patient’s vital signs, to help decide the best route.

We realized that building something reliable would be a much bigger challenge than we could tackle in a hackathon. Existing services already handle parts of the problem, and meaningfully improving them would require dependable APIs, data, and expertise that we didn’t have.

So we kept the central question and looked for a way to demonstrate it:

How can data from the past help us make a better decision about what to do next?

From a big vision to a playable game

Our first vision for Time Heist was also ambitious. One or two thieves would try to steal valuable data from a futuristic vault while an AI security system learned their behavior. We imagined players hacking security, setting decoys, sabotaging or betraying one another—and an AI that could choose where to send guards, place traps, or add protection.

But we had so many ideas that the foundations of the game weren’t clear at the start. Instead of trying to build every feature at once, we focused on getting the core experience working: the map, players, guards, and game assets needed to work together properly. Once players could move through the facility and guards could respond, we had a stable base to build on.

We narrowed the first version to a clear loop: players have 60 seconds to explore the facility, collect points, grab the data core, and escape. The game records where they go and what happens. After a loop, that history can inform the guards’ patrol in the next one.

How we built it

We built Time Heist iteratively with Gemini and Delta, a collaborative agentic AI platform. We used them to generate ideas, explore game mechanics, and help create and revise code. Instead of trying to build the whole original vision at once, we focused the tools and our effort on the core version we could make work.

We worked with the code in VS Code, editing and integrating the files so the map, players, guards, and game assets worked together. As the project took shape, we used Git to track the changes and pushed the code to GitHub so the project could be shared and continued. The AI tools helped us move faster, but we still had to make the design choices, keep the scope focused, and check that the pieces worked together.

How the data changes the game

The first loop uses a fixed guard patrol. The game records events such as which areas players visit, whether they collect the core, and whether they escape or get caught. With completed routes as evidence, a simple, explainable predictor estimates which area players may visit next. When there’s useful evidence, the game can use that prediction to adjust the guards’ patrol.

That’s the main idea in action: gameplay creates data; data supports a prediction; the prediction changes a decision; and the next loop shows what happened. Players can change their route and try to outsmart the guards.

The current game focuses on adapting patrols. Ideas like hacking, sabotage, betrayal, traps, and extra protection were part of the broader vision, but aren’t all features of the current version.

What challenged us—and what we learned

We had to narrow our scope and establish the basic game before adding more ideas. We also needed the map, players, guards, and assets to work together reliably. That taught us to build and test the core experience first, then add complexity.

We also learned that using data well means more than collecting it: events need to be recorded consistently and connected to the right loop. And we need to be honest about what the results show. The game’s comparison summary reports observed outcomes; it doesn’t prove that adaptive guards always make the game harder or that the predictor is always correct.

To make the first comparison fairer, loops one and two use the same map: the first has the fixed patrol, and the next can use an adaptive one. Later loops get new randomized maps to keep the game fresh. The predictor itself is a simple statistical approach, not an advanced model that knows the future.

What we gained—and what comes next

We gained experience turning a broad idea into a focused, working prototype—and learned how to connect gameplay data to predictions and decisions in a way players can see.

Our next-step ideas include more maps and challenges. The slide also suggests exploring the SmartSpectra SDK to monitor signals such as heart rate, breathing rate, and facial expressions through a webcam. That is a future idea, not a feature in the current game; it would require careful attention to consent, privacy, and how those signals are interpreted.

Time Heist grew from a question about better decisions into a game where each loop leaves evidence behind—and the next loop puts that evidence to the test.