Inspiration
Modern games often grow through larger assets, larger teams, and larger hardware budgets. I wanted to explore the opposite question:
How much real gameplay can fit on a single 1.44 MB floppy disk?
That constraint forced every feature to justify its existence. Instead of shipping textures, external models, or recorded audio, LAST SECTOR generates its terrain, units, effects, interface, and sound directly from code.
The goal was not merely to create a tiny technical demo. I wanted a complete, replayable action game with construction, resource decisions, upgrades, enemy pressure, and a clear objective.
What it does
LAST SECTOR is a compact native Windows base-defense action game.
You pilot a low-altitude combat drone and defend the BOOT CORE and its power network from a 300-agent enemy swarm. Players can explore a continuous procedural battlefield, follow supply lines to ore, construct defensive infrastructure, earn salvage, and purchase BUILD or DRONE upgrades whenever they choose.
There is no separate upgrade screen interrupting combat. Building too far forward expands the economy but exposes the supply network. Staying too defensive allows enemy pressure to grow. Shooting is the immediate layer, while positioning, construction, supply management, and upgrades create the longer game.
The same seed recreates the same battlefield, making runs deterministic and testable.
How we built it
LAST SECTOR is written in C++17 using Sokol and D3D11. It builds as one native Windows executable with the static C runtime.
Shaders are compiled into offline DXBC and embedded into the executable. The game does not require a runtime shader compiler, external assets, third-party runtime DLLs, or an installer.
During OpenAI Build Week, I used Codex powered by GPT-5.6 as the primary implementation agent through a GitHub-based development workflow:
- I defined product direction, gameplay feedback, constraints, and acceptance criteria in GitHub Issues.
- Codex implemented each bounded task on a dedicated branch and opened an inspectable pull request.
- A separate Claude PM process audited the actual diff for scope, C++ safety, performance, determinism, shader correctness, dependencies, and binary size.
- Windows CI compiled the game, ran subsystem tests, verified reproducible
/Breprooutput, audited imported DLLs, and published a playable executable. - I performed the hands-on playtest and made the final fun and merge decisions.
For example, Issue #32 described a real camera-following HUD bug and restricted the solution to three files. Codex implemented the screen-space HUD fix in PR #33, and the independent audit confirmed that the implementation matched the requested scope before the human merge decision.
This separation kept implementation, review, evidence, and product judgment explicit instead of hiding them inside one AI conversation.
Challenges
The main challenge was balancing depth against an extreme binary-size budget. Every visual effect, interface element, enemy behavior, and gameplay system had to be generated efficiently without relying on conventional asset pipelines.
Determinism was another important constraint. World generation and gameplay systems use seed-based paths rather than time-based randomness so that failures can be reproduced and tested.
We also had to prevent accidental dependencies from entering the executable. The build audits imported libraries and rejects runtime shader compilation or unexpected third-party DLLs.
Finally, coordinating multiple AI roles required strict boundaries. Codex could implement, Claude could audit, CI could provide evidence, but only the human owner could decide whether the game was fun enough or merge the result.
Accomplishments
- A complete native Windows game in a 346,112-byte executable
- Less than one quarter of the 1.44 MB floppy-disk budget
- Procedural terrain, models, effects, interface, and audio
- A deterministic battlefield with a 300-agent swarm
- Construction, salvage economy, supply-network defense, and anytime upgrades
- Offline-compiled embedded shaders
- Reproducible builds and automated dependency auditing
- One file, no installer
What we learned
The strongest AI results came from treating Issues as implementation contracts rather than vague prompts. Tight scope, explicit acceptance criteria, automated evidence, and independent review made Codex much more reliable.
The floppy-disk limit also became a design tool. It encouraged reuse, procedural generation, readable silhouettes, and systems that create depth through interaction instead of asset volume.
Most importantly, the human role did not disappear. AI accelerated implementation and review, but product direction, playtesting, taste, and final responsibility remained human decisions.
What's next
The remaining floppy space will be used to deepen the game rather than broaden it carelessly: additional structures, more meaningful drone upgrade paths, new enemy behaviors, stronger audiovisual feedback, and continued player testing.
The core constraint will remain unchanged:
One executable. One floppy disk. A complete game.
Log in or sign up for Devpost to join the conversation.