The screen takes the hit
Until now an enemy died cleanly: it disappeared, and nothing else moved. There was the explosion, of course, but I wanted to go further. I spent a few days preparing this. The screen now shakes under explosions, monsters blow apart, and a white flash appears before the screen tilts ;)
The explosion that shakes the screen
In Chaos Engine there are items that let you set off a huge explosion, killing every enemy on screen. I absolutely had to have that in my engine.
So it's done, and it's very smooth, on both STf and STe. The music doesn't glitch during the explosion, which is exactly what I had in mind.
The first thing I added is the simplest to describe: when something explodes, the whole screen is shaken. A sharp jolt, then a bounce that damps out in a fraction of a second.
There are two intensities. A monster's death gives a firm shake. A hit taken by the hero gives a more discreet shake, but enough for you to understand you have just lost health. That is actually the effect I cared about most: when you take a hit in the back while aiming elsewhere, the screen tells you before your eyes have time to check.
Handling particles
I wanted to build particle handling into the engine. You never know, particles are bound to come in useful.
I spent more time than expected on those few scraps of pixels, for a reason I hadn't anticipated. My first version sent the debris out in eight perfectly regular directions, at the same speed, over the same distance. The result looked like a geometric pattern, a sort of rosette, anything but an explosion. An explosion is disorder. As long as every fragment left in exactly the same way, no amount of tuning speed or weight changed anything.
The solution was to randomise, for each piece, its exact direction, its speed and its lifetime. And to give them different silhouettes, because a square stays a square: a stone has no right angles.
Second lesson, more amusing. I had given the debris a weight strong enough that you would see them fall back down, except that this weight crushed everything: after a few moments every fragment dived downwards whatever its starting direction. They never had time to go anywhere. I had to balance the fall against the momentum, which sounds obvious written down like this, and isn't obvious at all when you're looking at the result without understanding why it falls flat.
All of this is now configured from a single line of settings per family of effect: how many pieces, which hues, what speed, what weight, how long.
The flash, then the blast
My first attempt triggered everything at once: the white flash, the explosions, the shake. The result wasn't right.
The current version goes step by step. A white flash briefly covers the screen. Then, as the light falls away, everything blows at once.
That is something I learned by getting it wrong: how you stage an effect often matters more than the effect itself.
Without losing anything along the way
There was one constraint above all this work, and it wasn't negotiable. These effects must not cost the game an ounce of smoothness, not on the STe, and not on the STf which is by far the tighter of the two.
And my first version of the fragments did exactly that, it cost the game its smoothness. The obvious reflex would have been to remove half of them, since nobody notices eight pieces of debris rather than four whereas everybody notices a game that stutters.
Except that the real problem wasn't their number, it was the way I was drawing them. My first method noted what lay under each fragment before placing it, so it could put the scenery back on the next frame. It works, it's what the game does for the hero and the enemies, but it's expensive: you set aside and then restore an area far larger than the pebble itself, and you pay for that on every frame and for every piece.
So I took the problem from another angle. Rather than memorising the scenery under a fragment, I simply redraw it where it was, from the level map. It's a technique my engine already uses elsewhere, and it's far better suited to objects this small: nothing to hold in reserve, and four cells of scenery to repaint instead of saving and then restoring a whole area.
The result is that in the end I had nothing to sacrifice. The eight particles are there, and the game runs exactly as if there were none. I did keep eight as a ceiling, because twice that was starting to show, but it's a limit of caution and not a surrender.
It's a lesson this machine teaches me again regularly: when an effect costs too much, the right question is almost never "how many can I remove", but "am I going about this the right way".
What comes next
The next step will be light: a lantern that genuinely lights up its surroundings, in dark scenery. And that won't be a walk in the park ;)
Leave a comment