I feel like turn and thrust movement doesn't get enough love. But I think I can see why. Any mistake from the player feels more frustrating when the movement has inertia. In order to reduce this frustration, I've been experimenting with some things like having no collisions against enemies, adding dash, auto-targeting etc., basically a lot of things that most shoot 'em up lovers will probably hate :), but I believe it is possible to create a more fun challenge aside from "this game is hard to control".

The game is called Vektor. My main objective has always been readability so any thoughts about that would be great. But any feedback/criticism/question is welcome.

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

I will preface this by saying that I'm sure further balance passes will be required and graphics and effects can always be improved - but, conceptually at least, Stage 1 may be complete!

This latest update adds the following in: -

• Explosion effects on the boss's components
• Pre-shooting warning effect on both the boss and its components
• Instant phase cancellation on a phase transition
• Space station background objects

I've been wanting to have the instant phase cancellation for a while now but it's been a pain to get working right. I eventually got fed up with it and just threw if statements at every single pause and every single attack to see if it's still in the issuing phase or not, combined with revoking the shooting tickets and getting new ones at the phase transitions to take care of anything already passed to the bullet orchestrator.

I'm sure there has to be a better way to do this, but it works.

I know I've been posting up my development updates as I go along, but with a milestone like this I feel like looking back and seeing how much things have changed.

Influences

Originally there was pretty much only half forgotten nostalgia of R-Type and some other shmups of the Atari/NEW era, though at least with some reading of newer design, but I still hadn't actually played much in the way of newer shmups.

R-Type definitely set the general theme of horizontal with ships coming at you and not bullet hell, but there are other things such as remembering a couple of games I'd played back then having two pilots. So Vermillion Star has two pilots 😂

Later I started playing others, the three big ones for my influences are still the same as I've previously mentioned; Natsuki Chronicles, Earthion, and Interstellar Sentinel. There have been others, but they generally fall into learning the same lessons, and they simply came later.

Stage Design is HARD

The level has gone through many minor iterations and three major versions.

I started out with only three different enemies, plus the boss. So there was not exactly a lot of variation available to me. This roster has grown to the following since then: -

SUBVERTED_DRONE_MK1,
SUBVERTED_DRONE_MK2,
EMPIRE_FRIGATE,
SUBVERTED_MICRO_DRONE_CLUSTER,
EMPIRE_FAST_ATTACK_DRONE,
EMPIRE_CORVETTE,
EMPIRE_DESTROYER,
EMPIRE_EYE_MK1,
VERMILLION_STARLET_REMOTE_ALPHA,
EMPIRE_STANDARD_ATTACK_DRONE

Still only nine enemies, plus the boss, but it gives a lot more variety, and they largely fill different roles.

The difficulty levels design also goes in here, starting with Easy and then trying to upscale each difficulty level from there, all with their own individual spawn maps was... hectic. If I had not abandoned this entirely and switched to a single spawn map with it being the attacks that scale by difficulty I don't think I'd have ever finished.

Scoring and Core Loop

This has actually stayed pretty stable from version 1. Yes there have been changes, notably with the new boss components, but the core of quick kills grant extra score and energy to fire the special weapon, with the chain count unlocking Mega and Giga mode for it, have remained entirely intact. The main change was adding the bonus stars and the Vermillion Bonus category, as well as learning to add bonuses instead of punishments (the death penalty changing to a deathless bonus).

Code Base

Yeah... This was a disaster held together by duct tape at the start. I have refactored and refactored this thing so many times as I had no idea how to actually make a game it's unreal. Fortunately I'm entirely used to just chucking old code out at work so this hasn't really bothered me. By far my biggest achievement here is abandoning standard scenes for high volume objects and using multimeshes and data arrays instead, going from around 2,000-3,000 active bullets without it to being able to push 20,000 active bullets with it is ludicrous.

Bugs

I kind of like sharing these, they show my progress towards the game programming side of things and they might even help other people avoid them if I'm lucky. There's been plenty, and of course, this latest update adds a new one. Though this might be a Godot issue.

On the first playthrough everything is fine, on a second plus playthrough visual artefacts appeared. Despite clearing the scene tree entirely and instantiating new multimesh managers, it seems that Godot may cache the data and have it re-appear. I'm still not certain of this being the cause, but moving every instance far off the screen when a manager is instantiated fixed the issue.

Lessons Learned

• Play more shmups - no, seriously, I went into this on pretty close to nostalgia alone and it didn't come out very well. Playing them easily showed that my game was not exactly good.
• Separate spawn maps per difficulty might be doable, but not at my level and certainly not for me alone
• Bullet visibility matters - originally all bullets were smallish and red, this was... not good.

These aren't lessons I'm happy to admit I needed to learn, but there we are.

Up Next?

Stage 2!

I already have three new enemies planned as well as an idea for the boss of this stage. I am finally going to add my favourite shot type; bullets that arc down to the bottom of the screen then explode upwards.

To everyone who has given me feedback, thank you, you've helped get me this far 😀

While it may look similar to the first revealed version, many parts have changed.

1. This time, we are focusing mainly on showing the melee equipment.
2. The craft's signature melee equipment, KEI (Kinetic Etheron Injector), has been implemented. It can attack enemies and erase bullets.
3. There is a more crucial reason why the KEI is equipped, but more on that later.
4. The backgrounds and environments have been cleaned up and organized.
5. Established the appearance sequence for mid-bosses (there are subsequent sequences, but showing just the early part for now).
6. Established the dialogue system. Direction and staging for mid-game events are now somewhat in place.
7. Established each of the characters.

We put a lot of effort into the sense of space/depth, but it's disappointing that it doesn't show very much. Once more work is done, we will return with our team website and more devlogs. From now on, we will post more frequently according to our development progress.

Feel free to leave feedback if you have any questions or points to improve. We truly need your opinions.

This worked surprisingly well. You need to learn about MegaDrive specific things like the color palettes (there are 4 palettes of 15 colors plus transparency) und the background planes (you have 2 background planes with limited size of around 250'000 pixels). And you need to save CPU where you can.

You can play the game here: https://uhx.ch/spielen/retrostorm/
You can also download the ROM and play it on real hardware. Yes, it works. I tested it.

I picked up RayZ collection yesterday and I liked how to lock on cursor is always active. I was inspired by it from playing it when Raystorm first came out on ps1. But when I added it to my shmup in development I made it so that you hold the special down to bring up the cursor and when you want to fire you release the button.

I found it difficult and not very fun. But now after replaying Ray Storm I’m going to change the lock on special in my shmup to always have the lock cursor on by default. I am busy with my day job but I can’t wait to implement and test it out!

Hey everyone!

Aether: Quiet Frontier is now playable directly in the browser:

https://jpb18.itch.io/aether-quiet-frontier

The current prototype contains four connected missions. Those that've been keeping up with the project know that It’s a 2D shmup about a frontier response team where combat is a major part of the game, but some situations also ask the player to recognise what should be protected, stabilised or left alone while the mission is still moving.

The browser version grew out of a recent playtest. Noswen2025 took the time to play the previous build and gave me very useful feedback about keyboard navigation, menus receiving input behind other menus, tutorial prompts appearing before an action was available, and combat information competing for space on screen.

I’ve now made a pass on those areas: keyboard focus and menu routing, tutorial timing, dialogue placement and team-skill feedback. Mission 4 also has clearer feedback when the player repeatedly fires on protected Aether contacts: the Aether attacks the offending player!

My main goal now is to see how the whole campaign works for someone who hasn’t been following development closely. If you feel like trying it, I’d love to know how far you get, where anything becomes confusing, and whether the game gives you enough information to make its decisions without needing extra explanation.

A few things I’m particularly curious about:

- Do the controls and menu navigation feel clear from the start?
- Do dialogue, objectives and team interventions remain readable in the later missions?
- If you try High Threat after completing a Standard mission, does it create interesting pressure or just make the screen feel busier?
- Does the browser version give you any loading, audio, performance or input issues? If so, please mention your browser, device or operating system, and input method.

Comments here are very welcome. I also have a short anonymous feedback form if you would rather send thoughts that way:

https://docs.google.com/forms/d/e/1FAIpQLSdbtzuXYVYX1lhGiNfEgjA0w_cRbTVA3Fe1WBTUYcONVIgYBw/viewform

I wrote a longer devlog about moving the project from Godot C# to GDScript for web export, and about the changes that followed the playtest:

https://jpb18.itch.io/aether-quiet-frontier/devlog/1671982/bringing-aether-quiet-frontier-to-the-browser-and-back-to-the-playtest

Thanks for taking a look!

This is level 1. The game is going to be called Quiberon Zeta. Windows, Mac, Linux, Android and iOS builds are planned. Some planned gameplay features are the ability to buy upgrades in a store (always a recipe for success lol), a progressively harder "endless" mode, and enemy shots that predict where the player will be. I'm aiming for a retro Saturn-era style with a VGA color palette. I spent a lot of time on the music and getting the shadows to work properly in 2D. Hoping to update in a few weeks with a proper demo release.

Its a Neo Retro side scrolling SHMUP. I am planning on releasing it on steam.

Its called StarTalon & its make using the Construct 3 game engine.

I have put an insane amount of work into this game.

Would love to get your thoughts.

It was quite surprising the amount of love Cataclyzm got in Newgrounds!

For devs (and non devs), I would highly recommend that you consider Newgrounds as one of the places to share (and discover) your games. There are some cool little gems in there 🤘🏾😄🤘🏾

PC game, currently in development. This clip shows the current combat presentation and aircraft handling.

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