Inspiration
I wanted to create a living-room game that gives people a reason to discuss difficult decisions before pressing a button.
The Last Light turns that idea into a space rescue mission. Saving people now can leave less power for the journey home, and a promise made to obtain help can become a difficult obligation later.
Players must consider not only whether a plan works, but also what it costs and what consequences it creates.
What it does
The Last Light is a cooperative decision-making game designed for a shared television screen.
Six people are stranded aboard a space station. A rescue tug with two crew members must bring all eight people home.
The ship begins with 12 power, 3 hull, one emergency module, and six passenger seats.
Players navigate dangerous routes, manage limited resources, negotiate rescue agreements, and make decisions that affect the outcome.
Two-player mode: One player controls engineering decisions while the other handles navigation and rescue choices. Both share the same screen and can take turns using one remote. Each role must approve the combined plan before it executes. Changing a choice invalidates previous approvals.
Solo mode: The player chooses one role while a clearly labelled local-strategy teammate handles the other. An optional "Ask AI teammate" action can request live online advice, but the human player retains final approval.
Consequential negotiation: Players can propose rescue terms, pledge equipment, defer payments, and manage obligations. Promises are tracked and can affect future choices. Breaking an agreement has consequences.
Multiple outcomes: Resource exhaustion can cause mission failure. Success requires managing both survival and outstanding commitments.
The game also supports English and Chinese, persistent saves, Continue functionality, and television remote navigation.
How we built it
The backend uses Java 21, Spring Boot, and H2.
Java controls game rules, legal actions, resources, agreements, approvals, and outcomes. Request identifiers and version checks help prevent duplicate settlement when network responses are lost or retried.
The frontend uses HTML, CSS, and JavaScript, shared between desktop browsers and an Android Java/WebView television client.
The Android TV application includes a television launcher entry, landscape layout, D-pad/OK/Back input handling, and a native Retry screen for connection failures.
The game runs with a local backend. Reviewers can use an Android TV emulator connected through ADB reverse forwarding.
Optional online AI uses the FrostFox Responses gateway. The model can interpret supported negotiation proposals and suggest teammate actions, but it cannot directly change game state. The Java backend validates all proposed terms, and required player approvals determine when actions execute.
A fully playable local mode is available without paid AI services.
Codex assisted with development, testing, verification, and documentation.
Challenges we ran into
One major challenge was adapting browser interactions for television remote controls.
Repeated OK events initially risked approving both player roles. We corrected this behavior and tested gameplay with native D-pad, OK, and Back input.
Another challenge was ensuring that negotiations had meaningful consequences.
A proposal, an explanation, an approval, and an executed agreement must represent different states. We implemented backend validation and persistence to ensure AI-generated text cannot silently spend resources or rewrite commitments.
We also encountered difficulties with online model integration. Earlier Amazon Bedrock attempts returned validation errors and did not produce successful inference. The working online interactions in this submission use FrostFox instead.
Finally, fresh-clone testing exposed missing default initialization resources. We improved first-run startup so the normal Java main entry can initialize absent default databases and usage-ledger files without overwriting existing data.
Accomplishments that we're proud of
On October 18, we recorded gameplay running in an Android TV emulator with native remote input.
The completed two-player voyage included three successful online NPC negotiation requests.
All eight people returned safely, with 1 power and 2 hull remaining. Both the rescue debt and escort obligation were fulfilled.
A separate solo demonstration showed the local-strategy teammate, switching between English and Chinese, resuming a saved voyage, and confirming an action that changed the ship's resources.
The resulting English demonstration video is 2 minutes and 58 seconds long.
Independent source verification passed 471 Java tests and 192 JavaScript tests. Subsequent startup testing also confirmed successful optional online teammate advice and state preservation across a normal restart.
The latest verified fixes were committed and pushed to the project's GitHub repository.
What we learned
AI is more useful in a decision-making game when its suggestions operate within explicit rules.
Players should understand what a proposal means, what it costs, and when it becomes binding.
Separating generated advice from authoritative backend state helps keep gameplay predictable, testable, and recoverable.
We also learned that television interfaces require dedicated focus management and input testing. A feature that works with a mouse may still be difficult to use with a remote.
What's next
Next steps include testing with real pairs of players, evaluating the game on physical Fire TV hardware, improving remote navigation and language controls, and investigating device-specific speech capabilities.
We also plan to improve reviewer onboarding and continue evaluating how optional AI can make negotiation more meaningful without taking control away from players.
The current submission demonstrates an Android TV emulator implementation, not physical Fire TV hardware testing or an Appstore release.
Log in or sign up for Devpost to join the conversation.