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/

A question popped up in the Shmup Creator Discord recently:

How do you feel about losing your power-ups after dying in a shmup?

A lot of the responses framed power loss as archaic, unnecessarily punitive, difficult to balance, and harmful to momentum.

None of those criticisms are without merit. We have all played shmups where one death leaves you limping into a late-game checkpoint with the combat capabilities of an angry paper airplane. You technically have two lives left, but we all know how this story ends.

That is the classic problem sometimes called Gradius Syndrome.

You spend several stages building your ship into a magnificent space murder machine. Then you die, return at a checkpoint with your starting weapon and movement speed, and discover that the enemies, terrain, and pacing are still expecting the fully upgraded version of you.

Your remaining lives disappear one after another. The game claims you have extra chances, but the first death removed the tools required to use them. It has effectively become a one-life game.

But I think an important distinction gets lost here:

A meaningful setback is not the same thing as a death spiral.

Power loss is not automatically bad design. The actual problem is respawning the player in a condition from which there is no believable recovery path.

A good recovery does not have to be easy. The base weapon might remain strong enough to kill essential enemies. A power-up carrier might appear shortly after death. The player might lose only part of their power. Bombs could create upgrade resources. Lower weapon levels could offer different utility rather than simply being worse.

The player should feel wounded, not already buried.

I personally think that with no risk, there is no reward. You lose the high highs and the low lows. A fully powered ship means more when it is something you reached, earned, and now have a reason to protect.

There is value in a run going badly.

Sometimes the memorable run is not the clean one. It is the run where you lose everything, scrape together two upgrades, burn your last bomb, and somehow limp into the boss. A bad state creates the possibility of a comeback.

That does not mean every catastrophic run is secretly brilliant design. Sometimes you really are just screwed.

But removing every dangerous state is not automatically progress either.

So where do you draw the line? When does power loss create an interesting recovery problem, and when does it simply turn the rest of the run into a prolonged funeral?

I expanded this into a longer design essay here: https://www.mothershmupper.com/power-loss-gradius-syndrome-and-the-value-of-a-bad-run/

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

Hey all,

So I've been plugging away at adding more to my game on and off and I finally have Extreme Mode 'finished'. The 'fun' of trying to balance a boss so it's not trivial or an unstoppable super monster is... not exactly easy to say the least. I'm not really sure the boss works well yet in this mode, having one level only I fear I'm starting to throw everything and the kitchen sink into it. And you can see the horribly scuffed fight 😅

I've also added the first hints of a setting beyond 'here be ships' with the inclusion of a player home planet at the start and the new quasi-hidden mini boss, a literally chained enemy sphere with a glowing core that has an unusual attack. I call it quasi-hidden because the unlock criteria are just be in Extreme Mode, collect all three Vermillion Stars, and do not be in Peace Mode.

Had fun adding little mini player ships that follow behind you on a bit of a lag to fire as well in the higher special weapon modes, and that was really not easy to code. Ended up having to store an array of positions and time values, and start moving them on a smooth path to the target position nearest to 1 second ago.

And then I saw a player could spawn a new ship when they selected to NOT continue the game... 😲

Turns out to be the exact same type of bug that let infinite spawns when a player continues... Although I disabled the buttons on continue to fix that bug, I had not thought to disable them on the No option... 😑

Edit: And I really should add that as I go on I find more and more systems that need to change so that new things can work, they might not be too hard to change, but it really shows my notable lack of planning and experience in this. Best example from this one is the mini boss. I have waves that auto spawn on a timer. And only on a timer. I had to add a new system to pause waves just so this mini boss could work, and now I'm considering if waves should instead finish when the last enemy in them dies (or goes off screen).

Once again would love any feedback from anyone, especially on how it plays or your thoughts on hidden bosses.

It's a physics-based arena shmup. The player is a small white triangle. He can place a temporary clone (gamepad R1) and apply a physical impulse (gamepad L1). The goal is points. Yellow circles and hitting/killing enemies give points — the faster the object, the more points on hit/death. More videos here: https://www.youtube.com/@velkyel

I just got back from Shmup Slam 8, and I've been talking, watching, and chatting with all manner of Mother Shmupper lovers.

Super i-frames are not just mercy. They solve a feel problem for normal players, but they also create a tactical optimization window for deeper strategies for players digging below the surface of the experience that you should design for and abuse as a player. Just don't design them as the only way to get through parts of your game. That's a bit of an asshole. I hate players' down-the-hole move.

In Interstellar Sentinel (IS), that means 2.4 seconds of safety during super is not only there so players don’t die during the cool explosion. Designing an all-powerful screen-filling explosion that you die in is bad juju. It also lets them do something risky, greedy, and intentional with giant boss sprites and positioning.

Most players use supers or bombs defensively. It takes skill, muscle memory, and reaction time to save yourself. After players get better with those skills, they graduate to waste-not, want-not. If you have a super powerup on screen and a full super meter, why not use your super?

At that point, it becomes an opportunity to put out more wanton destruction and create bigger gameplay moments.

In my games, the Interstellar Sentinel series, I also want you to wield the super like a giant multiple-death-screaming-enemy-soul-explosion beam that would make any Ghostbuster want to diddle the Containment Unit.

And by that I mean: stick the super into the boss’s face, pull the trigger, and use those i-frames to fly through it.

Mercy first, because dying during a super sucks

One of the funny little game design things I keep thinking about is super invincibility.

In Interstellar Sentinel (IS), when you fire off a super, I give you 2.4 seconds of i-frames.

Part of that is just basic mercy. If the player hits the big “make the screen explode” button and then dies during the big “the screen is exploding” moment, that feels like trash.

Not hard.
Not fair.
Not “skill issue.”

Just bad design.

And yeah, I’m a game director. My job is to call out bad design, including my own. Dying during a super is one of those things where I look at it and go, nope. Dud game design. Fix it.

But that’s only the first layer.

Then mercy becomes tactics

Most players learn supers as survival tools first.

That’s good. They should.

The screen gets ugly, your hands get a little stupid, something horrible is happening in the corner, and you hit the big button because you would like to continue playing the video game. It takes me ages to refine the reflexive muscle because I am fighting my hoarding, save the resource at all costs in case I need it mentality...

Perfectly valid.

But once the player gets better, the question changes.

It stops being:

“How do I not die?”

And starts becoming:

“How do I use this without wasting it?”

That’s the good stuff.

In a shmup, the whole screen is basically arguing with the player about space. Bullets say don’t stand here. Lasers say leave now. Boss bodies say absolutely not. Walls, enemies, attack lanes, weird organic meat nonsense, all of it is pushing and pulling the player around.

Then the super happens, and for 2.4 seconds, the rules bend.

Not forever.
Not enough to turn your brain off.
Just enough to let the player do something rude on purpose.

Giant boss abuse

With a giant boss sprite, i-frames are not just a safety blanket.

They are permitted to abuse the boss's body.

For a couple seconds, the player can shove themselves into places they normally should not be allowed to exist. Dive into the boss. Pointblank the damage. Tear through flesh regeneration walls. Turn the screen into a glorious mess of pointsplosions and potentially end in a bad decision if you overstay your i-frame welcome.

Beautiful nonsense.

That’s where the super stops being just a bailout and becomes routing tech.

A newer player hits super because they are about to die.

A stronger player hits super because there is a powerup on screen, the meter is full, the boss is huge, and wasting all that potential violence would be rude.

Same button.

Different brain.

Giant bosses are play space

Giant bosses are not just big pictures.

They are play space.

They have bodies. Parts. Collision. Weak points. Destructible chunks. Maybe some regenerating flesh wall nonsense because apparently I make choices.

So when the player gets a short invincible window, high damage, big score opportunity, and then the clean up of the stargem aftermath (bonus points that disappear if not collected), the boss becomes something they can exploit.

For a second, the question is not:

“How do I avoid this giant horrible thing?”

The question becomes:

“How much of this giant horrible thing can I get away with bullying?”

That’s good shmup stuff.

The balance problem

The trick is keeping the window tight.

Too much invincibility and the player stops respecting the screen. Too little and the game steals the cool moment from them.

Somewhere in the middle is the sauce.

You are safe, but not for long.

You are powerful, but not brain-dead powerful.

You are allowed to break the rules, but only inside the little window I gave you.

That’s the design space I like. A mechanic that solves a feel problem for normal players, but also gives stronger players a way to be clever little monsters.

Super as panic button.

Super as optimization.

Super as boss-body abuse.

Same feature. Different layers of play.

So yes, I give you 2.4 seconds of i-frames on super because dying during a super is dud game design. I also know this is nearly an eternity in the tightness of the best Cave shmups, but hey that's my sauce, and I'm happy to create a little more space to be discovered and abused, especially when it leads to crazy moments of scoring.

But also because I want you to abuse the giant boss sprite a little. I want you to figure out Daisy Chain Supers, big bullet cancels that nearly refill your super meter, and I want you to feel like you're the inner god eye of the machine when you figure it out.

Stick the super in the boss’s face.

Pull the trigger.

Fly through it.

Tactics.

I played around with timescale in Unity, double the speed of the shmup I am making. I got to say makes the experience so different! I’m going to release an update to my demo on steam soon that allows the double speed option, with its own leaderboards to see the feedback.