P2K & Lumina3D / CREATIVE AI · GAME DEVELOPMENT
Directing two games, one playable moment at a time.
Two different games, one practice: set the creative direction, give AI a bounded task, then inspect what actually runs.
2 min overview · optional detail below

THE CHALLENGE
A broad game idea does not tell an AI coding partner what a good playable moment should feel like.
MY CONTRIBUTION
I directed the scope, prompts, visual choices, and review of a cozy 3D adventure and a top-down survival game.
01 / Creative direction
Two worlds, two player experiences.
Lumina3D grew into a cozy world of helpers, water routes, and story beats. P2K turned a tabletop fantasy into Kosros’s survival loop: move, aim, cast, collect, and upgrade. Each needed its own visual and interaction language.
Lumina3D: a cozy puzzle adventure

Original June public atlas image. Level Three explores water routes and environmental puzzles; this is work in progress.
Inspect screen
P2K: a top-down survival game

Original Phase 11 capture from the public P2K case. Fire effects, combat, and resource management serve a different player rhythm.
Inspect screen
02 / AI-assisted workflow
Turn the idea into a reviewable slice.
For P2K, I refined ideas with Claude into acceptance criteria, then directed Codex through locked phases with Playwright checks. Lumina used a similar small-slice rhythm: define the next playable moment, build it, inspect the scene, and record what was proven.
Human direction across AI-assisted production
- 01
Direct
Define the player moment and constraints.
- 02
Specify
Refine the brief into acceptance criteria.
- 03
Build
Give the coding partner a bounded slice.
- 04
Review
Inspect the running game and smoke checks.
03 / Iteration and integration
Generated art still has to work in the game.
P2K’s original case documents inconsistent character directions and overlapping procedural and sprite rendering. Those problems made integration a design task of its own. These two checkpoints show the project’s visual progression, not a controlled capture of either bug being fixed.
Earlier checkpoint: Phase 8

Original corruption-readability capture. This is not labeled as a failed-art screenshot in the source.
Inspect screen
Later checkpoint: Phase 11

Original Stage 3 corruption capture. The changed world treatment is visible; the run state differs from the earlier image.
Inspect screen
WHERE IT LANDED
Two game prototypes and a documented way of building.
The strongest evidence is the work itself: distinct game worlds, staged implementation, original captures, and candid notes about art and rendering failures. My contribution is the creative direction and AI-assisted production process, not a claim that I manually authored every line of code.
What I learned and would test next
An attractive generated asset can fail when it moves, changes direction, or enters the renderer. I need to review it in the actual scene before accepting it.
The next useful evidence would be observed player sessions focused on onboarding, control clarity, and difficulty.
Evidence: original P2K public case and Lumina3D field notes. Lumina includes a video demo. A separate hosted playable P2K URL was not verified.
