• 

• 

• 

• 

• 

• 

@ -0,0 +1,76 @@

Artemis Lost Devpost Draft

Inspiration

Artemis Lost started from a very particular kind of frustration. I love systems that feel alive under pressure, but a lot of AI-heavy interactive projects still feel either shapeless or too polite. I wanted something that felt like an actual incident: a crew in trouble, a situation that keeps changing, and decisions that carry weight even when nobody is fully in control.

I also wanted it to feel memorable in a room full of demos. Not only visually, though that mattered too, but structurally. I wanted the project to feel legible enough to play, dramatic enough to hold attention, and specific enough that people would remember it after the room had moved on.

This was originally entered as a team project, but the team dropped within the first hour of the hackathon, so everything after that point was designed, built, debugged, deployed, and polished by me solo.

What it does

Artemis Lost is a turn-based lunar incident simulator. The player claims one crew role, generates the rest of the crew, chooses a mission profile, and launches into an unfolding emergency on or around the Moon.

During play:

• the player can directly control one crew member while the others can run autonomously
• an OpenAI-powered mission director narrates the consequences of each turn
• the game tracks world-state changes like O2, power, comms, navigation, crew health, and anomaly pressure
• crew roles matter mechanically, so commanders, engineers, scientists, and specialists have different strengths
• handoffs and crew relationships affect who should act next and how effective those actions will be
• each mission can end in victory or defeat, with different cinematic resolution screens

The result is part strategy game, part narrative simulator, and part mission-control problem.

How we built it

I built Artemis Lost as a full-stack web app.

Once the team dropped, the project became a solo sprint. That changed the shape of the work immediately. I had to be careful about what was worth building, what needed to be legible first, and what could not be allowed to collapse into a pile of clever but unstable systems.

• Frontend: React with Vite
• Backend: Node/Express
• Model integration: OpenAI Responses API
• Persistence: browser-scoped save slots with Postgres support for durable cloud saves
• Testing: Vitest plus Testing Library

On the frontend, I built a multi-screen flow with a main menu, player-first crew assembly, a launch sequence, the live gameplay interface, and separate win/loss resolution screens. I also added shared animated telemetry backdrops and a panel system that keeps the screen active without burying the important information.

On the gameplay side, I split the simulation into modular systems for role semantics, crew coordination, mission mechanics, mission outcomes, UI-derived state, and turn runtime resolution. That mattered because I did not want the game to rely on AI narration alone. I wanted the roles, handoffs, and outcomes to have real structure underneath them.

On the backend, I built an API layer that passes world state and action history to the OpenAI-powered mission director, receives structured deltas and narration back, and persists the evolving mission cleanly.

Challenges we ran into

One big challenge was balancing flavor against usability. It was tempting to make every label and every line of copy fully in-universe, but that kept pushing the interface away from readability. I had to keep asking the same question: does this sound good, or does it actually help the player understand what is happening?

Another challenge was getting the simulation to feel coherent instead of random. It is easy to bolt AI narration onto a game loop. It is much harder to make the crew roles, handoffs, suggested actions, and initiative order all point in the same direction. A lot of the work went into making sure the underlying systems and the model prompts reinforced each other.

I also ran into practical deployment issues. Durable saves on a hackathon budget meant I needed something cheaper than paid persistent disks, so I adapted the save layer to work cleanly with Postgres and browser-scoped session ownership.

On top of that, losing the team early meant I had to cover design, frontend, backend, deployment, testing, and presentation at once. That forced a kind of discipline on the project. Not every idea could stay. The ones that survived had to justify themselves.

Accomplishments that we're proud of

• Building a full playable loop from crew creation to launch to mission resolution
• Making AI narration feel grounded by tying it to structured world-state updates
• Creating meaningful role differences instead of just cosmetic class labels
• Adding evolving crew trust, follow-through windows, and handoff-driven initiative
• Shipping launch, victory, and defeat sequences that give the project a real sense of transition and consequence
• Deploying the project live with durable save support
• Turning the crew generator into a socially specific easter egg without letting it break the rest of the game

What we learned

I learned that AI-heavy interactive projects work much better when the model is only one part of the system. The best results came from surrounding the model with strong game rules, visible state, and UI affordances that help the player understand what matters.

I also learned how much polish matters for trust. Small things like clearer copy, matched panel layouts, dynamic telemetry, or better end-state animations changed how real the project felt. Even when the core logic was already working, those presentation choices changed whether the system felt readable and worth trusting.

Finally, I learned that hackathon scope gets much easier to manage when systems are refactored early. Splitting large files and separating persistence, turn runtime, and coordination logic made it much easier to keep adding features without the project collapsing into chaos.

What's next for Artemis Lost

The next step is to make missions feel even more distinct from one another. Right now the core loop is strong, but I want each mission seed to introduce more specific mechanics, pressures, and decision patterns.

I also want to expand the end-of-mission experience with better recap screens and more shareable outcomes, so players can walk away with a cleaner story of what happened to their crew. Beyond that, I want to deepen the crew simulation, grow the mission set, and keep pushing Artemis Lost toward something more durable than a one-off demo.

Built With

• javascript
• neon
• react
• render