Perform the Demo, Don't Assemble It
Instead of setting up states in code and filming them, the promo script walks through the product and reads the screen. It became a free integration test.
HappyBirthTown needed four short promo clips. Scenes inside the pixel town: a character picks up a candle and sets it on the cake, a photo appears. A person could record those by hand, but the same scenes would be re-shot many times, so a script was the right tool.
There are two ways to script a scene. One is easy and one is slow. I took the slow one, and it left me with something besides the footage.
An assembled video is only a claim
The easy way is assembly. Set up the state you want in code — a candle already in hand, a photo already on screen — capture the frames, and join them. It is fast, it never fails, and the picture comes out identical. From the video alone there is no telling the difference.
But what that video says is "the product can look like this." Whether it really does when a guest takes those steps in that order is something nobody has watched. Whoever set the state up skipped the road that leads to it.
Promotional material is a promise the product makes. If the basis of the promise is "I was able to make it look that way," then the first person to find out whether it is true is the guest who saw the video.
Real keys, real screen
So the tool performs. It presses real keys and reads the real screen. To pick up a candle it walks to the tile the candle is on. To place it, it keeps walking until "Place candle" appears on screen. If the prompt never appears, it cannot move on.
It was slow. And it got it wrong three times. It picked the wrong spot and walked past the cake with a candle in hand: the row it walked along was not a row that touches the cake. Assembly would never have had that failure. In an assembled scene, a character stands in front of the cake because you wrote that it does.
Those failures were a cost, but they were also information. A place where the script loses its way is a place where a first-time guest can lose theirs. An assembled demo never passes through such places at all.
Placing it while already standing there
Along the way a bug turned up that nobody knew about. Beside the cake is a sign that says how many candles have been placed. The script placed a candle, and the sign kept showing the old number.
The cause was simple. The sign was drawn once, on approach. Walk up from a distance and it shows the right count. But place a candle while already standing beside it and there is no approach, so nothing draws it again.
Setting states up in code would never have shown this. An assembled scene has no "while already standing there." Build the state with the candle placed, build the state with the sign drawn, and the two always agree. The mismatch exists only in the crossing from one state to the other, and guests always make the crossing.
A test whose priorities are already set
When the script that makes marketing material walks in through the product's front door, it becomes an integration test you got for free. And a good kind. There is no deciding what to cover. The scenes chosen for promotion are the ones you most want a guest to see first, which makes them the steps a guest will actually take first. The priorities are already set.
An assembled demo drifts further from the product the more it is used. The product changes and the staged states do not. And the last person to learn about the gap is the one who made it: a guest knows the moment their screen differs from the video, while the maker finds out the next time the video is re-shot.
A performed demo passes through the product every time it is re-shot. If it cannot get through, there is no video. Promotional material that cannot run ahead of the product is what the slow road paid for.