Sandbox Demo

Why

I want to make a video game

Making games was always the goal. I built enterprise software for nine years at PayPal instead.

I have zero game development experience, but making my own game has always been a childhood dream. I found the task daunting and intimidating, and I did not know how to approach it. With the emergence of AI, I found it easier to prototype, test, fail, and iterate on game design ideas by delegating different tasks to an agent. I approached game development with AI the same way I would collaborate with a development team when building enterprise SaaS. As a Product Owner, I gathered my game requirements and created a document where I broke down features into Epics and User Stories. Then, with my experience in UI/UX design, I created a design system for my UI components and utilized NNG rules to improve the user experience.

The Drifter holds the dark Nyxblade greatsword high overhead in a ready stance, three Jellings scattered across the clearing, oaks and a weeping willow in the middle distance — The Drifter, the Nyxblade and the meadow. The tools made the assets; the decisions were mine. Click to enlarge.

The process

Same process as enterprise SaaS, different deliverable

Nothing about the method changed. Only the thing at the end of it did.

Building SaaS at work	Building the game
Product requirements doc	Game design doc
Epics	Systems: meadow, combat, creatures, progression, interface
User stories with acceptance criteria	Features and skills: each sword art, the mount, the intro card
Design system and component library	Painted UI kit: 26 chrome pieces, 16 skill icons, one brushwork style
Prototype, then usability test	Build, then playtest in the browser
QA and release notes	Test and QA each release before it goes on the site
Iterate on feedback	Iterate the models, the look and feel, the HUD

The game doc

Systems were epics. Features and skills were user stories.

Each system got an epic; each feature or skill got a story with a done-state I could test. What is in the demo today is what passed.

Epic	Example user story	Status
Meadow	As a player, I walk a painted meadow with tall grass I can cut.	In the demo
Combat	As a player, I swing the Nyxblade and use sword arts from the hotbar.	In the demo 9 of 16 arts
Creatures	As a player, I fight Jellings, tame the dragon by standing still beside it, then ride it.	In the demo
Progression	As a player, I level to 50 and spend points on STR, AGI, VIT and INT.	In the demo per session
Interface	As a player, I learn the controls from one card and can close it with Esc.	In the demo

The Drifter mid-swing with a bright cross-shaped slash flare over a Jelling beside him, willows and oaks behind, another slime watching from the left — The swing story: press, flare, hit. The server that validates it runs inside the browser tab.

The Drifter seen from behind as a slash flare fades above him, a Jelling tucked against his side, dense willow foliage on the right and a spiky white bush on the left — Attack, react and run clips are Mixamo takes retargeted onto the project's own rig.

Who did what

I designed and decided. The AI built.

Me

The game doc: epics, user stories, what counts as done
Every design decision, and the briefs for every asset
Reviewing what came back; keeping, rejecting, re-briefing
Playtesting, test and QA of each release
What shipped and what stayed gated

AI and tools

Engine code from directed coding sessions: three.js, TypeScript, the in-browser server
Meshes, painted UI chrome and skill icons: Meshy
Foliage sway sheets and the goblin horde: AutoSprite
Animation clips: Mixamo, NVIDIA MotionBricks
CC0 fills: Kenney, Quaternius

A five-by-five sprite sheet of the same painted oak tree in twenty-five slightly different poses, the canopy shifting a few pixels between frames so the tree sways when played back — The brief was “a painted oak that sways”. What came back was keyed, tiled and measured before it went in.

The top band of a goblin sprite sheet: five columns of a small green goblin in a brown tunic, the first two rows walking with a dagger, the next two winding up and swinging a sword, the last row crouching and lunging toward the viewer — A band of the sixty-frame goblin sheet, drawn and keyed in one pass.

Four painted UI chrome pieces laid out two by two: a cream parchment window panel with dark corner brackets and a dark title bar, a dark rounded title-bar strip, a long amber button with a dark outline, and a dark square inventory slot with an amber rim — The UI kit is the game's design system: 26 painted chrome pieces, one brushwork style, reused for the intro card, the hotbar and the loading screen. Click to enlarge.

Test & QA

Every release got tested before it went up

Same discipline as a SaaS release: a test pass against the stories, a QA pass on the build, then it ships, or it doesn't.

Release	What I tested	Result
Meadow slice	Controls, the intro card, the hotbar, cutting grass	Playable in the browser
Keyboard layer	Every action reachable without a mouse; key hints on screen	Shipped as a separate layer over the build
Performance	Frame rate on a 2019 laptop with an integrated GPU	20 → 60 fps, tall grass kept
Look	Pixel grid against the painted textures	600p, hard pixels, painted look kept
Loading	Input during load; the first skill after loading	Input gated until the world is built; no hitch

A game, built the way I build enterprise software.

I want to make a video game

Same process as enterprise SaaS, different deliverable

Systems were epics. Features and skills were user stories.

I designed and decided. The AI built.

Me

AI and tools

Every release got tested before it went up

Let's work together

Contact

Work