Development record · solo 48-hour build
Artemis Lost
What can 48 hours produce alone? Artemis Lost is the answer in repository form: a playable lunar mission assembled during PantherHacks 2026, with a history that moves from a basic AI game loop through crew mechanics, persistent state, deterministic outcomes, and deployment.
Development record
What can 48 hours produce alone?
The repository history moves from a componentized UI and session saves through autonomous turns, role mechanics, mission outcomes, tests, deployment, and post-hackathon provider work.
- Componentized interface, crew creation, and session saves
- Role mechanics, autonomous turns, handoffs, and outcomes
- Tests, deployment configuration, and provider support
Context
Artemis Lost started as a hackathon project: a stranded lunar crew, a mission director, and a game that had to feel like more than a chat window. The team dropped within the first hour, leaving 48 hours and a repository that had to carry the remaining design, frontend, backend, AI integration, and deployment work.
The problem was making AI playable
A generic model wrapper could produce atmospheric prose, but it could not by itself provide a stable game. The mission needed roles, turn flow, crew coordination, saves, pressure, and an ending that did not depend on the model remembering every rule.
The architecture had to be survivable. The frontend, backend, model integration, and local gameplay rules were split so each could be built and checked independently.
Presented after the hackathon
After PantherHacks ended, Artemis Lost was presented at a meeting on May 20, 2026. The presentation framed it as a role-playing game where an AI agent plays the Dungeon Master: generated narration inside a game with explicit rules.
Project timeline
Selected checkpoints from the public Artemis Lost repository. The sequence follows the hackathon build and the small amount of post-event maintenance that followed.
-
Establish the game loop
The interface was split into components, character creation and session saves landed, autonomous turns were added, and the mission-director integration moved to OpenAI.
Result: the project had a playable loop to build against instead of a single undifferentiated screen.
-
Turn features into rules
Launch sequence, role mechanics, and role-aware turn effects landed; mission effects were refactored into a data-driven system.
Result: the game could express crew differences through repeatable mechanics rather than prompt flavor alone.
-
Make it shippable
The built client was served for deployment, the initial test suite was added, and win/loss conditions gained dedicated resolution screens and ending animations.
Result: the project crossed from prototype mechanics into a testable, deployable game.
-
Close the multiplayer gaps
The mission required at least one human player, supported bot-first crews, and corrected handoff logic so the small-group experience could still reach a complete mission.
Result: setup and control rules matched the way the game was actually meant to be played.
-
Polish the surface and freeze the event build
Session-based save slots, performance work, stylesheet refactoring, and the post-hackathon documentation checkpoint tightened the shipped surface.
Result: the visual polish stayed attached to a game whose state and outcome rules were already explicit.
-
Keep the provider boundary open
Post-hackathon commits added Claude API access and merged the Anthropic provider work without changing the local game-state authority.
Current state: a public playable build with a provider boundary that can evolve independently of the rules engine.
System
A hybrid turn pipeline
- React and Vite handle crew creation, launch flow, the live mission interface, and resolution screens.
- Node and Express assemble mission context and handle the mission-director request.
- OpenAI Responses API or Anthropic Messages API returns narration plus a partial structured state delta.
- The client validates and merges the delta, then applies local role mechanics, mission mechanics, coordination, and outcome rules.
- Browser-scoped slots persist sessions, with Postgres available for durable deployed storage.
The model is part of the experience, but it is not the authority over the world. That boundary lets the game stay interesting without making every bad response a state-corruption bug.
Role-based control
Character creation starts with the player claiming one role. The remaining crew are generated around that choice, and each seat can be human-controlled or autonomous. Role-aware guidance, handoff windows, and crew coordination make the four seats matter after setup instead of treating the roster as decoration.
The same action path serves human and autonomous turns. That kept the feature surface coherent while still allowing a smaller group to run a complete mission.
Failure boundaries
The system records commands and typed event-log entries locally, advances the mission clock, and preserves the session even when the DM request fails. The model can still be unavailable or surprising; the important boundary is that its failure does not erase the rest of the game.
Interface Evidence
These screenshots show the project as a playable interface rather than only a codebase: save slots, crew assembly, launch, live mission state, and mission resolution.
Current state
A shipped game with a narrow AI boundary
Artemis Lost shipped as a playable mission-control game and received Entertainment Track Runner-Up recognition at PantherHacks 2026. The public result demonstrates full-stack implementation, game design, model integration, persistence, and interface work under severe time pressure.
What the repository shows
The model handles narration and structured consequences; local systems decide what actually happened. That division kept expressive behavior inside a game with explicit state, persistence, and outcomes.
That does not make model behavior deterministic. It makes the failure boundary visible and keeps the playable system from depending on a perfect response.
Artifacts