In the workshop game I’m designing, the most interesting car may be the one that isn’t moving.
It is ready for paint, but the booth is occupied. A repairer has finished another job. There is an empty repair bay and a new customer at reception. Starting more work looks easy. Working out whether that will help the whole workshop is the harder decision.
This fictional scene captures the idea behind a new Dynamic Apps concept: a retro 3D repair workshop game. I’m working through its rules and first playable scope. The appeal is being able to try a decision, watch its effects travel through the workshop and come back with a better plan.
Give every car a reason to move or wait
The planned route has seven stages: arrival and estimate; holding or waiting for parts; remove and repair; prep and paint; assembly; detail and quality check; then customer notification and collection.
An estimate creates the initial work plan, identifying tasks, required skills and parts. In a later version, dismantling could reveal additional work, giving the manager a reason to revise the plan.
Moving to the next stage requires the relevant tasks to be complete, the necessary parts to be available and someone with the right skills to have somewhere to work. Those conditions are what make each move a decision.
Selecting a stationary car should immediately explain its delay: “waiting for headlamp” or “no assembler available”. The player needs enough information to decide whether to resolve the blockage, change another assignment or leave that car waiting while something else progresses.
Make the workshop readable
The 3D view gives those decisions a physical home. Cars occupy space. Staff move between jobs. A queue outside a work area becomes visible before the player opens a report.
I’m picturing simple vehicles, recognisable equipment, clear colours and an angled view of the whole site. A little animation can make the place feel alive while keeping the work easy to follow.
Selecting a vehicle would reveal its stage, remaining tasks, parts status, assigned person and expected collection date. An employee view would show skills and current commitments. A bay view would show the job underway and the queue behind it.
If the holding area fills up, the player should be able to follow the blockage through the workshop and understand where it began.
Build the puzzle around people and parts
The central challenge is deciding what can productively happen next.
For the first version, an employee can have several skills but work on only one task at a time. Reassignment is a trade-off: the original job remains unfinished while another gets attention.
Move a multi-skilled employee into assembly and a car may be ready for collection sooner. Leave that person in repair and more work may enter the paint queue. The useful choice depends on what is already waiting elsewhere.
Parts add another dependency. A delivery can make one car ready for work while another remains blocked. The manager has to recognise the difference between a vehicle that has arrived and one that is ready to enter production.
This is also where starting too much work becomes interesting. If several cars finish repair together and the paint area has limited capacity, the player has created a queue. Another repair may add unfinished work without bringing the next customer collection any closer.
Let profit, quality and promises shape the score
Profit belongs in the game. My proposed model pairs revenue from completed jobs with wages, parts, materials and premises costs.
Quality checks are a required step. A vehicle becomes eligible for handover once its required work and checks are complete. A failed check sends it back to the relevant stage for correction, consuming time and capacity already needed by other jobs.
That makes rework visible across the business. The affected customer’s collection date may move, another car may wait longer and the original job’s margin may shrink. The player has to deal with those consequences together.
Collection matters too. A finished car still needs its customer notified and a pickup arranged. Until it leaves, it occupies space.
The end-of-day report would bring the financial result together with completed handovers, missed commitments, rework and unfinished jobs. Each result should be explainable through the decisions made during the day.
One site is enough to make the point
The first playable scope is one workshop, a small team and a limited set of repair types. The core actions are accepting work, reviewing estimates, assigning people and moving eligible vehicles through the stages.
A few competing demands can make that engaging: a parts delay, different skill requirements and several jobs needing the same work area. The player should be able to pause, inspect the situation and adjust the plan.
Replaying the same arrival and parts schedule would let someone compare their own decisions. What changes if they finish the nearly completed car first? What happens if they start every available job? The workshop provides the feedback.
What the player takes away
The idea has a possible longer-term connection to digital twins. NIST describes digital twins as computer models of physical systems, with uses including simulation, monitoring and decision support. An operational twin of a particular workshop would need its actual data and evidence that the model represents its behaviour reliably.
For this game, the lesson is more immediate: a decision at one bay can affect a cost, a queue or a customer commitment somewhere else.
At the end of a session, the player should be able to point to a waiting car and explain what happened. “I sent too much work into paint.” “I moved the only person who could finish assembly.” “I promised collection before I checked the parts.”
Then they can replay the day and try a better plan.