Selected work / 01
A game prototyping concept that turns a written idea into a plan, an editable workspace, and a playable starting point.
Explore the prototypeSelect a step to explore the recorded example.
Describe the game idea and its constraints before asking the system to propose a starting plan.
The brief
A written game idea leaves mechanics and scope open to interpretation. I designed Levelyst to help small teams agree on a plan, understand how its parts connect, and try a playable direction before committing to production.
01Blueprint
The blueprint gives the user a checkpoint between a broad request and a generated scene. It brings the proposed game structure into one view, where the direction can be inspected before the next step. This matters because a quick generation is only useful if the person building the game understands what it is about to create.
02Workbench
I organized the workbench around the graph, with a panel that switches between the prompt assistant and reusable modules. A collapsible timeline leaves more room for the canvas when needed. This keeps editing tools close to the structure they affect, supporting a loop of making a change, checking its connections, and entering simulation.
Translate the initial idea into named systems and relationships, giving the builder a structure to question and refine.
Treat common game behaviors as modules, so iteration can focus on a specific part of the experience.
Keep dependencies visible on the canvas so a local edit can be considered in the context of the wider prototype.
03Design evolution
Two early layouts established the relationship between starting a project and working inside it. The final screens retain those roles while making the main workspace and its supporting tools more distinct.
Drag the divider to compare sketch and final interface.
The sketch placed the canvas between a module tray and copilot. The built interface groups the prompt and library in one panel beside the graph, leaving more space to inspect connections.
Drag the divider to compare sketch and final interface.
The dashboard separates returning to a project from starting a new one. This gives exploration a home outside the more demanding editing workspace.
04Building with Codex
I supplied the concept, layouts, direction, and feedback; Codex wrote most of the implementation. Dragging a reusable module onto the canvas is one example of that collaboration. My sketch established where the library and workspace belong. The implementation turns a drop into a node at that position and selects it for further editing. I reviewed the working interaction in the browser and guided revisions.
Explore how the design became a working interaction.
I placed reusable modules beside the workspace, keeping the available building blocks close to where they are used.
const getViewportWorldCenter = useCallback(() => {
const bounds = editorSurfaceRef.current?.getBoundingClientRect()
if (!bounds) {
return { x: WORLD_WIDTH / 2, y: WORLD_HEIGHT / 2 }
}
const width = bounds.width
const height = bounds.height
return deriveViewportWorldCenter(canvasViewport, width, height)
}, [canvasViewport])
const addNodeFromTemplate = useCallback((typeId: string, x: number, y: number) => {
if (isReadOnlyDemo) {
showReadOnlyDemoNotice()
return
}
const template = moduleTemplateMap.get(typeId)
if (!template) return
const node = createNodeFromTemplate(template, x, y)
setNodes((prev) => [...prev, node])
setSelectedNodeId(node.id)
setSelectedNodeIds([node.id])
}, [isReadOnlyDemo, showReadOnlyDemoNotice])
const autoPlaceByTypeIds = useCallback((typeIds: string[]) => {
const center = getViewportWorldCenter()
setNodes((prev) => {
const existingTypes = new Set(prev.map((node) => node.typeId))
const queuedTypeIds = typeIds.filter((typeId) => moduleTemplateMap.has(typeId) && !existingTypes.has(typeId))
const next = [...prev]
queuedTypeIds.forEach((typeId, index) => {
const template = moduleTemplateMap.get(typeId)
if (!template) return
existingTypes.add(typeId)
const { x, y } = getClusterNodePosition(index, queuedTypeIds.length, center.x, center.y)
next.push(createNodeFromTemplate(template, x, y))
})
return next
})
}, [getViewportWorldCenter])
The drop handler creates, adds, and selects a canvas node.
Source: components/editor-v2/levelyst-workbench.tsx · addNodeFromTemplate excerpt
Both modules are now on the canvas. The last drop is selected; placement alone does not connect the nodes or resolve their dependencies.
05Runtime examples
These recordings demonstrate a 2D platformer and a 3D survival FPS path. Other game families remain exploratory directions; these two examples are the basis for showing the current runtime behavior.
06Change review
The first generation is a starting point. A review step gives subsequent changes a visible place in the workflow, helping the builder follow what is being updated before returning to simulation. I kept this step connected to the existing project so the user can reason about an edit in context.
07Outcome
The prototype connects planning, modular editing, simulation, and change review. My central design learning was to make generated output inspectable, giving builders something specific to evaluate and adjust.
The recordings demonstrate particular prototype paths. They do not establish production readiness or reliable generation across every game idea.
Next, I would observe builders completing an edit, checking its dependencies, and returning to simulation to find where understanding breaks down.