An alley. A bad take. Another chance.
The first captured action–edit–retake loop, and the decisions that changed the original design.
The first day's evidence is an alley, a sequence of takes, and an editing phase between them. It is still visibly a prototype. That is useful: I can see the loop without confusing a finished-looking image with a finished game.
Getting the loop on screen
The November 12 development captures show the first action take, a failure, the director's edit phase, a second take, and a wrap. An automated alley run recorded success on take two with three kills and three edits. That gives me evidence that the tested rules can complete a loop. It does not answer whether the game feels good in a headset.
The important transition is the one after failure. Instead of resetting immediately, the scene becomes something I can reconsider. The director's tools are Cut, Move, and Restore, with a limited edit budget. A retry should feel like trying an idea, not simply repeating a mistake.
Changing the original plan
The revised design removed the walk-to-exit objective and stick locomotion. The ordinary combat scene should finish when the last enemy goes down. That keeps the focus on the action happening around the player's mark.
The revision also made the desired physical feedback much more explicit: hearts and hit feedback, hands and magnetic grabbing, gun feel, unarmed interactions, ragdolls, destruction, and the clapperboard. These were requirements to implement and test, not a checklist of things I could already call finished.
I also gave the successful take a destination: the Director's Cut. The design grew to include recording the take, placing cameras, and assembling a clip. The captured cutting-room and replay screens are early evidence of that direction, not proof of a polished export workflow.
Where the tools helped—and where they did not
The project uses C++ gameplay with editor scripting and Unreal's MCP connection for construction and iteration. Existing assets and the Fab collection give me material to work with. I still need to decide how the scene should play and check the result.
The project notes record preview-specific integration issues around particle effects, mesh import settings, and skeletal-mesh scripting. There are also editor crash reports from this day whose causes are not documented. I am not treating either a successful compile or a screenshot as evidence that those problems are all resolved.
What the pictures can tell us
The gallery below is PC development capture from November 12. It shows the prototype's state, including rough interfaces and unfinished presentation. It is not a promise of final headset visuals.
Next: continue working on physical interactions and the cutting room, then return to playtesting. A bot completing a scene is a starting point; the player still needs to enjoy performing it.
