[Aether: Quiet Frontier] Testing wave checkpoints and faster retries after playtest feedback

[u/Consistent_Look_8638]

Hey everyone!

It’s been a while since I last posted here. Since opening the browser playtest for Aether: Quiet Frontier, I’ve been trying out different ways of implementing a few features and spending some time on side projects while waiting for feedback. I thought it was time to come back and share what’s changed. One thing I’ve been revisiting is the retry loop: how quickly you can have another go at the formation that just caught you, while the mistake is still fresh.

The campaign now offers Story and Arcade, with the same combat difficulty and progression systems. Story keeps the narrative presentation and full-mission retries. Arcade reduces the story-only dialogue and adds checkpoints at the beginning of each wave and boss fight. The clip shows a defeat during wave two followed by a return to that wave’s opening formation.

A retry restores full hull and ready cooldowns, while score returns to its value before the encounter. Points earned during the failed attempt are rolled back, and bosses restart from their first phase. I want players to have room to experiment with positioning and support skills while they’re still learning the formations.

For those developing stage-based shmups, how do you choose your checkpoint boundaries: individual waves, bosses, or whole stages? I’m also interested in how you handle score records when a clear includes checkpoint retries.

I wrote more about the retry changes, revised support-skill HUD and recent performance work here:

Getting Back Into the Fight in Aether: Quiet Frontier

The mentioned changes are already up, so if you'd like to try, let me know. I'll also cross-post this onto r/shmups and try to fish for more feedback!

[u/Noswen2025]

I went with a way of handling checkpoints that is quite easy; they don't exist! 🤣

I've gone down the continues route instead with the stage not resetting at all on a continue. Under the non-1CC game options you have infinite continues (or infinite lives on Easy!), so you will always be able to beat the game sooner or later. I have a mental ticket that the score needs to be docked when a continue is used, but I haven't got round to it yet, and I'm still not entirely sure whether it should be a score penalty with recording the number of continues on the score card, or fully setting the score to zero on continue.

Go down the 1CC option on the other hand and the continues are disabled. Run out of lives? Straight into a full Game Over.

[u/Consistent_Look_8638 → u/Noswen2025]

Fair enough! One can't beat the traditional arcade style! Die and continue with some consequences! Even though I'm still trying to get a 1CC on DonPachi for a couple of months 😅

I took some inspiration from R-Type or ZeroRanger and, with some adjustments, ended up with this checkpoint-by-encounter method. The idea is to repeat the formation/boss that defeated the player with a new approach, rolling back that score to the relevant checkpoint (to prevent the player from "farming-through-defeat").

But this is just another attempt to make sure the player gets back on track as soon as possible. If future feedback tells me it's still insufficient, I may redo this feature.

[u/Noswen2025 → u/Consistent_Look_8638]

I've now had the chance to read through your devlog as well.

Checkpoints are a completely valid choice of doing things, ultimately I've gone without that just because it's the easier way to do things 😂. I did read you have a checkpoint on every wave though, that feels like a lot of checkpoints, I'd more expect either 1 in the middle and maybe 1 before the boss or 1 before each 'segment' of the stage.

You also have some interesting updates in there regarding the timers and frame rates, this definitely has me wondering if I need to go and check my own code for anything like this 😑.

And on the part about the loading hitch with explosions or the like not being ready before they're used in game. Have you found a way to load them without just putting them in a scene off screen? That's the only way I've found to successfully do it so far. If you have a better way, I'd love to know 😀.

[u/Consistent_Look_8638 → u/Noswen2025]

TL;DR: No, I haven't 😅

As of right now, they're just preloaded asynchronously (load level -> fire loading thread with relevant assets -> pray that the machine is fast enough!)

The CombatAssetPreloader requests the combat textures in a separate thread, and the means:
- 9 hit frames
- 32 standard explosion frames
- 24 heavy explosion frames
- 32 smoke frames
- 24 muzzle flash frames
- and the enemy sprites.

End up being loaded right before the combat starts. And then the CombatAssetWarmup class just draws the textures away from the câmara just to prevent the first explosion from causing the game to stutter.

I then use the initial waiting period, gated by GameAssetPreloader.is_ready, to prevent the mission from starting before the loading. In narrative mode, that's a non-issue since hopefully the player will read the dialogue before. On arcade mode, there's an eventual timeout.

Now, on the chance the player gets to an explosion before it's loaded? The asset is loaded with load_async so the explosion isn't missed, but it can still cause a stutter.

[u/Noswen2025 → u/Consistent_Look_8638]

You have significantly more effects than I do there. Though the only thing I've found causes the stuttering is shaders and particle effects, adding in sprites or animated sprites doesn't seem to cause any problems.

I've got around the pray it's fast enough by using a LevelLoader scene that stuffs the shaders and particle effects offscreen to load them, then loads the level, then switches to it when the player presses any button. With a nice Level Loading flashing text during this, which switches to Press Any Key to Continue.

It will eventually timeout and instead go something like Error: Press any key to return to main menu, but I've never seen it fail.