Systems architecture, product decisions, visual direction, testing and scope all have to survive contact with one another.
01 / How it is built
Three overlapping disciplines.
Systems
State has to hold.
A game is a system under load. State, timing and transactions have to stay coherent when the player does something unexpected.
Production
Scope has to survive.
One person cannot build a whole world at once. The useful move is shrinking the unit of work until the real constraint is visible.
Product
The picture has to decide.
Art direction is not decoration. If the shot does not read, the product decision is not finished — keep, change or kill from evidence.
02 / The game
A game, built under constraint.
Too much world, then a smaller unit of work, then a failed picture, then a structural correction. The next move came from what the frame actually showed.
The first world
01
The first world asked for too much.
The first prototype generated a large 3D world. It proved the idea, then asked one person for environment, animation, navigation, collision, lighting and testing all at once.
Wrong unit of work
02
The whole world was the wrong unit of work.
A staged 2.5D approach kept the main machine realtime 3D and used layered scenery for depth. That was the right reduction. The first framed shot still failed: machine, route and background merged into one dark mass.
Readability
The shot still did not read.
The layers had to be visible as layers before the picture could carry meaning.
Silhouette
Before adding materials, the silhouette had to work.
Shape and scale first. Finish later.
Evidence
The next decision came from the evidence.
Keep, change or kill from what the frame actually shows.
The same habit applies to operational systems: shrink the work until the constraint is visible, then build around it.
03 / Continue
The game is one practice. The work is broader.
Current professional work lives in the Pavilion. LinkedIn is the direct route.