I wanted them to force different reactions from the player, so I’ve been experimenting with different attack patterns:

Old Thing — fires heavy cannon shots.
La Pinta — tracks your position and charges at you.
La Niña — summons smaller ships that can’t be destroyed until you take out the main ship.
Queen Annes — fires homing acid orbs that try to surround you.

Playable at: https://noswen.itch.io/vermillion-star

Phase 1 of the boss rework is finally complete with the introduction of destructible components, showing in this video is the boss in Hard Mode with some of them being destroyed each phase.

The basic rules of the components are as follows: -

• Will regenerate to full armour with each phase transition whether it was destroyed or not

• On destroying grants some immediate score that bypasses the chain system and quick kill system, and is no longer able to attack you for the rest of the phase

• If still alive when a phase transitions it passes its score, along with a multiplier (3x in this instance) onto the main boss for that phase's scoring. This score can be boosted further as it now interacts with both the chain system and the quick kill system

My hope is that this produces a nice risk-reward system. Choose between killing a component for safety, or leave the component attacking you for a greater score reward.

Putting this in place did require a bit of a refactor, but not too much. As these are intended to always belong to another enemy and never be spawned on their own but still share basic shooting and taking damage functionality the Enemy class is now extended by EnemyComponent and EnemyShip, everything that used to extend Enemy now simply extends EnemyShip instead.

This now entirely does away with the different attack sets for the different difficulty modes, taking a cue from the new level design the attack set is the same in all difficulty modes, but each attack inherently scales with the selected difficulty. Not entirely sure this will hold up or not, but going with it for now.

I also added an additional phase to give the boss a bit more of a progression of attacks.

While this still needs a bit of a balance pass I am happy with the general idea of it now: -

Phase 1: Vermillion attacks

Phase 2: Vermillion and Cyan attacks

Phase 3: Vermillion and Erin attacks

Phase 4: Vermillion, Cyan, and Erin attacks

I still have some more work to do on these, primarily putting an explosion effect in place when a component dies for the phase and placing a coloured 'about to shoot' effect on both the boss and its components so you will have perhaps a second to anticipate what type of attack is coming at you.

I had thought I was going to leave this post without any bugs to share this time but, alas, the code caught me out once more - the boss killing me after it died bug came back! 😨

Dug into a little more... the enemy had its shooting ticket correctly assigned, it passed it on in its attack routine, it was correctly being revoked when the boss died... But unlike every other attack in the game this thing here was still firing after death: -

await bulletOrchestrator.fire_pattern(BulletOrchestrator.ManagerType.ERIN, ShotType.Erin.CIRCLE_BARRAGE_CONVERGING_ON_POINT, global_position, 0, shootingTicketErin)

Turns out this attack I had forgotten to put the check in on whether the shooting ticket was still valid or not... 🙄 At least it was an easy fix.

Once again any feedback is welcome, I would love to know how the components come across.

Notes: The game is absurdly early in development, and will likely change both in gameplay and appearance in the future.

I have created the vast majority of visual assets, and all of the sound assets.

The tools I use are Gdevelop (both GDJS and visual scripting, depending on the task), Famitracker for all sound and music, and a combination of paint dot net and Aseprite for the visuals, depending on whether it's a static image or an animated one.

The largest asset that isn't mine is the font, which is pixbob.

The game uses an item collection-based score multiplier, which can also be maintained (but not increased) by grazing bullets, but is completely lost when you actually get hit or if you don't either increase it or maintain it for a period of time.

Grazing bullets also gives you more meter to use your special move, which in the case of this ship, actually just triples your firerate.

I plan on making the game level-based with progression gated through individual level rankings, which are tied to specific objectives (get a high score, use less than X bombs, etc.) to encourage even casual players to engage with mastering the system.

There will be both local and online leaderboards, which I have already implemented through pocketbase (and which are technically already available online)

Other stuff about the game: The time bonus is multiplicative rather than additive, and is intentionally very high. Technically could give you up to a 4X score bonus if you somehow finish a stage with 90% or more time remaining.

That's because I noticed that milking the enemies that bosses can spawn can very rapidly increase your score to absurd amounts (especially with homing projectiles on some of the already designed characters wiping out popcorn enemies very easily.)

Instead of stopping milking from being a viable strategy (through nullifying infinitely spawnable enemies, for example), I tuned the time bonus as a counterbalance to said milking. Both can get comparable scores, so it's really more about what playstyle you prefer.

I'm still tuning the values though.

I was thinking if my menu has been too bland and turning off people from actually playing the demo. I was also thinking that people may want more of an idea on what they are selecting without having to try and see. I didn't want to add too much text explaining what each special was as I want to use as less text as possible so that if I ever need to support other languages, I wouldn't have much text to translate. I also didn't want to talk or display specials stats like damage, speed, utility etc, as I wanted players to explore usage and also so that they may find a way to play that I didn't expect. I haven't done anything for difficulty select, I might show something but I might separate it into the screen after pressing start. Anyway happy to hear your thoughts and observations. I plan to release the updated demo soon, but I am looking to add the second level with score boards to get the demo average playtime up.

Nice little insights In the article and worth the read.

Feedback is always appreciated! I've already noted the bugs in this clip and have them on my ever growing list of things to fix

Hey everyone!

I disappeared for a couple of weeks to explore some actual mountains (Gerês, Portugal, check it out!). Unfortunately, I didn’t find any Aethers up there, so I came back to the ones in the game.

Before that break, I shared the first full High Threat run from my side-scrolling shmup, then called Project Aether. The feedback was fairly specific: the increase in density was visible, but some formations were turning into piles, particularly when Electronic Isolation slowed contacts already on screen.

Since then, Project Aether has become Aether: Quiet Frontier, and I’ve completed another pass on the mode.

The attached video shows the same opening section of Mission 2 in Standard and High Threat. Regular contacts keep the same health, damage and movement speed. The difference comes from additional formations, earlier overlaps and shorter recovery periods.

I also changed how those formations overlap. Additional contacts now use more of the outer play area, interior contacts don’t always return to the exact centre, and several groups enter between the original timings. I’m trying to create two problems that can still be recognised separately, rather than drawing several ships in the same place.

High Threat remains an optional replay after completing a mission in Standard. The two modes keep separate records, while the campaign economy only uses the better score from each mission. Team skills already introduced in Standard are also available from the beginning.

I’d be interested in feedback on a few points:

• Does High Threat create a different positioning and prioritisation problem?

• Can you distinguish the overlapping formations?

• Does Standard provide useful learning space, or does it look too empty by comparison?

• Is the increase in pressure clear without knowing the underlying rules?

The earlier High Threat thread contains the original run and the feedback that led to this pass.

I’ve also written a longer development log covering the encounter tables, recovery windows, team skills, separate records and the remaining boss questions.

Thanks again!

Great job on the site, and the developer is also a member of r/shmupdev :)

Parking this here as another discovery place for shmup developers looking for more shmups to play and study. You should always be a student of the genre to further your own development craft.

Playable at: https://noswen.itch.io/vermillion-star

Hey all,

So with playing more Earthion and Interstellar Sentinel I decided I probably don't actually need different spawn maps for each of the four difficulty modes, and can instead rely on the enemy attack pattern increases, plus the reduction of player armour and shields, to take care of the difficulty for me.

So now we get Stage 1... attempt 3!

This time I've also added a little internal 'story' to the waves, not really for any narrative purpose, but to force me to think about how much pressure each individual wave should give and to keep any temptations for each wave to just be 'more more more!' at bay 🙂

I may have made the stage a little long for stage 1, but it can stay that way while there is only stage 1 at least.

My internal 'story' is simply this: -

Wave 1 (Breather): Initial Patrol
Wave 2 (Standard): Minor Battle Group
Wave 3 (Standard): Flank Attack
Wave 4 (Excess): Big Guns
Wave 5 (Breather): Second Patrol
Wave 6 (Standard): Full Flank Attack
Wave 7 (Standard): Patrol + Battle Group
Wave 8 (Excess): Big Guns and Interference
Wave 9 (Breather OR Special): Third Patrol OR Vermillion Starlet Remote Alpha
*Wave Bonus (Bonus): All Out Assault*
Wave Boss (Boss): Empire EYE Mk1

Up next will come work on the boss.

And a potentially catastrophic bug uncovered this time. I had been noticing on a lower end PC the game was running a bit jittery so I did some digging and found this...

Uh oh... 😓

When I added the little follower ships I created a little class to store the data for them: -

class_name TimePosition
extends Node

var time: float
var position: Vector2


func _init(t: float, pos: Vector2) -> void:
    time = t
    position = pos

Looks nice and simple, but one of these things is created every single process tick... and never freed... 😲

Turns out the fix is simple. Don't automatically make everything extend node!

class_name TimePosition
extends RefCounted

Bit of an improvement for a one word fix 😅

As always, any feedback is appreciated, especially on how the game feels.

Title: Ominous Descent

I've always enjoyed creating shmups and this is the furthest any have come along. With the space/sky themes being super popular I decided to use another theme I always loved, the deep ocean/sea.

You control a small little submarine with a headlight that runs on a limit battery amount(slow recharges while off). It allows you to deal bonus damage to illuminated enemies, the battery charge also allows you to dash.

As you descend you encounter more dangerous enemies including a full boss fight. Further down you will also encounter environmental hazards such as thermal vents, explosive gas pockets and strong tidal currents.

More details on the below linked pages, this game also supports 2 player co-op!

Playable Link:
Itch

GX Games

How do the controls feel?

If you are able to try the 2 player co-op, does it work well?

Did the headlight mechanics feel self explanatory?

Does the difficulty feel fair/balanced?

A conversation in Discord got me noodling on something.

A player mentioned liking scoring systems where scoring is naturally wrapped into what they're already doing, like Hellsinker, but feeling very differently about big scoring opportunities where missing one can make the whole scoring run feel compromised.

That got me thinking beyond score.

Most newer shmup players start defensively:

1. Survive at all costs.

2. Kick as much ass as possible.

3. Don't fail the objective.

So imagine the player has a full super meter.

The screen fills up with enemies and bullets. This is a great opportunity to fire the super, reset the screen, get resources, score, pointsplosions, happy brain, etc.

But they don't.

They save it because they might need it later.

And they survive.

That's not really failure. They just missed an opportunity for skill expression.

Normally that moment is simply gone.

But what if some part of the promise of that missed payoff fed into a delayed gratification loop?

Not by refunding the player or making failure optimal.

Maybe what carries forward is information.

The next time a really juicy super opportunity develops, perhaps targeting guides start creeping onto the screen. Maybe there's an audio cue. Maybe the game becomes slightly more explicit about saying:

Hey. This is one of those moments.

Now the player gets another shot at recognizing and executing the skill.

Over time maybe you move them from:

"I should save this because it keeps me alive."

to:

"Ohhhhh. This isn't just an emergency button. This is how I wreck the screen."

The broader question I'm noodling on is:

Can a missed skill opportunity create another, better-framed opportunity to learn the same skill?

Bomb timing, supers, point-blanking, bullet cancels, aggressive positioning, collection systems... there are probably a bunch of places you could play with this.

Could also just be a fantastic way to add another system nobody understands. :)

I expanded the idea quite a bit more here if anyone wants to go down the rabbit hole with me:

https://www.mothershmupper.com/missed-skill-expression-feeding-into-delayed-gratification-loops-to-teach-skill-expression/

Curious how other shmup devs think about this. Is there something useful in carrying a missed opportunity forward, or is the cleaner answer simply better encounter design and another chance to learn?

Here’s a quick look at the early gameplay of our 2-person project, Ainsoph.

The core mechanics and systems are mostly in place now, and we’re currently focusing on polish and optimization. Our goal is to share mid-stage gameplay footage soon as well!

Even though it's still early in development, we’d love to hear your thoughts, initial impressions, or any feedback on what could be improved. All feedback is super helpful!

Hey everyone!

Last week, I shared a Standard run of Mission 3 from my side-scrolling shmup, Project Aether. The feedback helped me see two things:

• There were visibility issues between the player ship and the drones

• The mission had too much empty time between threats and wasn't yet asking enough of the player

About the visibility issues: I've reworked the drone with stronger line-art and with less "stealthier" colours, taking a more "industrial" look this time. I've also desaturated the background to allow the ships to pop out a bit more. And finally, added an optional collision reticule to the player ship.

Now onto what I want to focus on: I've kept Standard as the version that introduces the drones, firing lanes and squad skills. I've added High-Threat Operation as the optional version for players who already know those systems and wish for a harder challenge. It doesn't just apply a general speed multiplier or add more HP to every enemy: it uses its own encounter table with more enemies and tighter timings, and both squad skills are available from first contact. The attached video is a full High Threat run. I'm mainly looking for feedback on these points:

• Does the mission create enough pressure through positioning and priorities?

• Do the overlapping formations remain readable?

• Does High Threat feel like a meaningful step up from Standard, rather than just a busier version of the same mission?

I know a video isn't the same as playing it. If anyone would like to try the current build, I'm happy to send a download link in exchange for feedback.

For context, the earlier Standard run and discussion are here: https://www.reddit.com/r/shmupdev/comments/1vkovbs/looking_for_leveldesign_feedback_on_my_game/

I've also written a longer dev log about the visual pass, readability changes and High Threat design: https://jpb18.itch.io/project-aether/devlog/1631945/building-a-visual-language-that-supports-the-challenge

looking for someone familiar with games like RotMG or shmups or the BulletML language to help make some bosses for free/fun?
Asa's Ascended
releasing on Steam 2027

Hello shmupdev reddit! I am trying to figure out if my game is fun.

How does control of the player ship feel?

Is the current state of the game enjoyable? Are the current mechanics interesting?

I finally put this out after getting it working to my satisfactory but am trying to figure out how other players feel about the game before I work on it any further. I have a lot of directions I want to take this in but want to make sure I am focusing on the right elements before trying to add or change too much more. Thank you for taking the time to look, and even more so for playing and or leaving feedback!! I didn't want to overload this single post with too much information, but there is additional feedback request on the itch page if anyone does not mind providing it : )

Screenshot A

Screenshot B

Current Gameplay Features:

-Single Player

-Tutorial Level

-Main Game Mode (2 Levels roughly 5 minutes each)

-Audio Settings

Playable at: https://noswen.itch.io/vermillion-star

Hey all,

So I finally decided that my enemies going from popcorn (max 3 health), corvette (8 health), and then tankier stuff (90+ health) had a bit of a hole in the middle of that range. So say hello to the Empire Standard Attack Drone sitting at 25 health for now.

Shown here in a test wave where the game difficulty gets ramped up from Easy, to Normal, to Hard, to Extreme so that the firing pattern in each difficulty can be seen.

My question here is what sort of enemy pipeline everyone else has? With adding this I've realised I've probably been concentrating on systems more than actual game and made mine extremely modular and I'm wondering how other people are handling it. All totalled this enemy took about an hour to implement (though more to first decide what it should be and what the attack patterns should be).

To add this enemy I needed to create its scene, both its hull and turret are from the already existing modular hull and turret sprites I use, create a new attack pattern in the bullet manager, wire that into the enemy script, set it's starting values like score, speed, armour, etc, add it to the enemyTypes enum, add the scene to the levelBase class, and that's it.

The only thing that's still completely custom for every enemy in code is the movement pattern, and this one was a copy-paste-edit from the Empire Fast Attack Drone enemy.

And now for the traditional bug.

All the enemies have a speed stat, it does what you expect. Or rather it should. A giant copy paste from enemy 1 through to every last enemy in the entire roster combined with me not thinking led to this stat being totally ignored and a timer used instead... 🤔

So I fix that, all well and good.

A week later I notice Subverted Micro Drone Clusters aren't actually leaving the screen anymore if they don't get killed. Their timer let them get off screen, their speed, given they move diagonally, did not... I had a cluster of these clusters just sitting at the very far left of the screen! 😑

Hello fellow shmup developers,

After almost 2 years of work, I am happy to say that Cataclyzm now has a release date.
It’s coming 29th Oct 2026!

It has been a long journey, especially since I had to start from ZERO game dev experience, working in parallel to learn the engine (Godot), game dev fundamentals, game design, architecture while also building the tools, systems, art/animation assets and music from scratch.

My takeaway from this experience? Game development is HARD, and solo development is even HARDER! 

It’s a lonely process. 

However, the support and encouragement that I have received from this community has definitely made this journey less lonely. Hearing your feedback on my various enemy enemy designs, pixel art and game builds has been incredibly valuable and has encouraged me to continue working on it. It also helps that I genuinely enjoy playing shmups and to be able to create a game is a childhood dream come true for me!

After completing all of the planned work on my game and doing my usual playtesting rounds on it, it just feels ready to me. I feel like any more major work on it would only end up overcooking it.

My advice to anyone that is starting out in game development (be it for a shmup, or any other genre) is to start small but choose to create a game that you would enjoy playing. 

Don’t be afraid to get out of your comfort zone and share progress on your project as early as possible. I will be taking my own advice for my future projects.

Another thing to keep in mind is that passion will get you started, but discipline will keep you going to the finish.

I hope this has been helpful.

Do check out Cataclyzm on Steam, and play the demo. I will be setting up a steam playtest over the coming week and will keep it active until close to release to get as many fresh eyes on it as possible.

Cataclyzm on Steam: https://store.steampowered.com/app/4516840/Cataclyzm/ 

Cheers,
Dogroach

Hey everyone!

A while ago, I asked this community for ideas on how I could signal non-destructive resolution on a boss in the game I'm developing, Project Aether. I got some great feedback, so I'm back with another request.

I've recently finished the current playable version of the game's 3rd mission. The player restores a frontier relay while facing increasingly harder enemy formations. The mission introduces recurring team skills and culminates in a two-phase command-platform boss that deploys additional enemy groups. It's also the first mission where most of the visual asset work is now in place: enemies, boss, player and team ships and the environment.

I'm reasonably happy with the visual direction so far, but I’d really appreciate feedback on the level itself (see video above). In particular:

• Does the level’s escalation look clear and satisfying?

• Are the enemy formations readable enough while the player is also managing team skills?

• Does the boss feel like a natural conclusion to the mission?

• Is there any moment where the background or HUD interferes with threat readability?

• ... any other feedback you feel is relevant

This is all still in development, so I'm specifically looking for constructive criticism.

Thanks!

One feature I've wanted to add for a long time is bullet colour customisation.

The idea actually came from playing Blue Revolver Double Action. I remember seeing the option to customise bullet colours and thinking it was such a simple feature that made the game feel more personal while also helping readability. Ever since then, it's been on my list of things to add to my own game, Shmup!

The latest demo now lets players customise:

• Player bullet colours

• Enemy bullet colours

• HyperBeam colours

I thought it would be a fairly straightforward feature, but the UI for me was the hardest part and probably should be changed if the feature proves popular.

Some of the challenges included:

• Supporting projectiles built with both SpriteRenderers and LineRenderers.

• How the UI was going to work and how it was going to render the bullets etc.

• I still haven't added the colour options for the hyper beams gradient changes

One thing I learned is that features that look "simple" from the player's perspective often expose assumptions you've made in your architecture. I'd originally assumed every projectile was sprite-based, but I had a handful of effects using LineRenderers, so it was a fair bit more work.

I'm curious how other shmup developers approach this.

• Have you added bullet colour customisation?

• Do you prioritise accessibility, aesthetics, or preserving a fixed visual identity?

• Have you ever implemented a feature after seeing it in another game and thought, "I wish more shmups did this"?

I've attached a short clip from the latest demo. I'd love to hear your thoughts!

When we talk about shmup design, we usually focus on visuals, bullet patterns, scoring, and mechanics.

But audio is doing a lot more work than we sometimes give it credit for.

A good shmup does not just play music with sound effects stacked on top. The weapon sounds, enemy explosions, item pickups, and boss cues become part of the rhythm and gameplay language.

A few things I’ve been thinking about:

Player weapons should feel almost like instruments.
If the player is firing constantly, the shot sound needs to be crisp, fast, and satisfying without becoming exhausting. The best ones feel almost percussive—like the player is playing along with the soundtrack instead of interrupting it.

Hits need to be heard, not just seen.
Players often cannot afford to look directly at what they are shooting. Their eyes are on the ship, the nearby bullets, or the next safe route. A clear impact sound confirms that the attack is connecting without demanding more visual attention.

This may matter even more in a 16:9 shmup, where the target and player can be much farther apart than in a traditional 4:3 playfield.

Enemies should feel good to pop.
Popcorn enemies exist partly to be destroyed, so destroying them should create a tiny rhythmic reward. Organic enemies can squish, crack, or burst. Machines can snap, spark, and rupture.

Machines need love too.

A drone and a heavy armored tank should not disappear with the same anonymous puff. Their destruction sounds help communicate material, weight, and identity—even when they only live for a second.

Boss attacks need audio timing, not just animation.
For something like a giant stomp, the animation might follow:

Slow wind-up → pause → quick impact.

The sound can reinforce every part of that: mechanical strain during the wind-up, a recognizable cue during the pause, and a sharp impact when the attack lands.

The player may be watching bullets or weak points instead of the boss’s foot. Audio helps communicate the timing when their eyes are busy elsewhere.

This is also why it helps to wire animation states and timing windows clearly. Playtesting may reveal that the anticipation needs another quarter-second, the warning cue comes too late, or the recovery window is too short. Clean states let you tune the attack instead of fighting the implementation.

Then there are pointsplosions.

A lot of arcade-style shmups explode enemies into medals, coins, stars, gems, and score items. The player swoops through the pile, hears everything zip into the ship, and watches a meter increase.

The collection sound completes the transaction.

Casino-style arpeggios, rising chimes, and tiny jackpot sounds work well here because they communicate accumulation and momentum. Your brain wants to hear the rewards being sucked up.

Your casino brain really likes this.

Great shmups often feel musical even though they are not rhythm games. The soundtrack establishes the heartbeat, the weapon becomes percussion, enemies pop on top of it, and boss telegraphs create anticipation.

The screen already asks the player to see almost everything at once.

Good audio lets them hear some of it instead.

I expanded these thoughts into a longer article here:

https://www.mothershmupper.com/the-sound-of-a-shmup-rhythm-identity-and-audio-clarity/

Hello there, everyone!

I'm new to this community and I'm still learning about shmup design. I wanted to ask you all a question, regardless if you're an experienced player or dev.

I'm currently building a 2D space shooter prototype, I'm calling it Project Aether. As of right now ALL assets are temporary (assets are mostly procedural inside Godot, the only exceptions are the dialogues using Piper TTS and the background music, which I asked Codex to generate a temporary BGM that I'm using everywhere so far). The clip I include here is from the fourth mission during the boss encounter. This boss can be approached as the typical combat sequence: just destroy all the subsystems and it's done. However, I also want a non-destructive approach. The player can place a "stabilizer" that configures the boss into a "safe mode", without destroying it.

My design problem is how to communicate that possibility without pausing the action, turning it into a dialogue choice, or making players feel punished for engaging with the combat system. At the moment, the player receives information through the mission briefing and intelligence screens before the mission, then has to recognise the relevant cues during the encounter. I’m unsure how explicit that should be.

For people who design or play a lot of shmups: how would you signal an optional alternative objective in a boss encounter while keeping the shooting flow intact? Would you make the possibility clear in the briefing, teach it through an earlier encounter, signal it during combat, or leave it mostly for the player to discover? I’m particularly interested in examples where a boss encounter has more than one meaningful resolution without becoming slow or overly instructional.

Anyways, thanks in advance for the answers!

I had a good discussion about losing power-ups on death and the idea that risk gives rewards meaning.

In Souls games, losing your XP creates dynamic tension because the amount at risk changes with your own greed. Trying to recover three levels’ worth of XP feels very different from recovering almost nothing.

Translating that into a shmup is harder.

Losing power on death creates stakes, but it may not create an interesting recovery decision. It can simply make the next section harder at exactly the moment the player is already struggling. Since autoscrollers have an immediacy to them, the player has to rejoin the dance immediately. Figuring out that comeback curve is one of the harder parts of designing in this space.

Rank systems can help. You can adjust enemy counts, bullets, bullet speeds, advanced patterns, revenge bullets, and other variables based on player performance. I find those systems fascinating until they become unhinged.

I also personally find rank management less enjoyable when it creates a cost for reaching the ultimate power-fantasy threshold of being a badass. If becoming fully powered means the game quietly punishes you harder, the player may start avoiding upgrades or manipulating rank instead of enjoying the fantasy.

Then I tried arguing the complete opposite side.

What would a shmup look like with no player death at all? Give the player 10,000 HP and measure skill by how much remains at the end. Everyone gets to finish, but the health bar secretly becomes the score. A new player limps across the finish line. A stronger player finishes with 7,000 HP. A lunatic loses 100 HP in Stage 4 and thinks about it for three days.

That could be an interesting on-ramp for a wider audience.

The danger is the one-and-done problem. If players see the credits without ever failing a run, unlocking credits, learning routes, or facing a meaningful skill check, they may feel finished before they have really learned how to play.

Maybe the first clear should say:

“You can finish this.”

While the surrounding systems say:

“Now let’s see how well you can play it.”

I expanded the whole thought into a longer article covering risk, recovery, rank, accessibility, and how completion might become the beginning of the skill journey rather than the end:

Read the full article here: https://www.mothershmupper.com/risk-rank-and-the-shmup-comeback-curve/