Hello everyone,

I’m currently developing Project Aether, a mission-based 2D shooter for Android inspired partly by the Flash games I played growing up.

The prototype began with a simple question: can a shooter make the decision not to fire as meaningful as pulling the trigger?

Combat is still central to the game, but some encounters can be resolved through observation, restraint or the correct use of mission intelligence. Decisions made during a mission may affect its debriefing, the information available to the team and later events.

The current prototype contains four connected missions. They are being used to test:

• Mobile movement and shooting controls.
• Mission briefings and debriefings.
• Optional objectives and alternative solutions.
• Intelligence gathered between missions.
• Consequences that persist across the campaign.

Most of the current presentation is deliberately temporary. The visuals consist mainly of line art and shapes drawn by the engine, while the audio uses simple 8-bit-style effects and synthetic placeholder voices. My priority at this stage is validating the mechanics, mission structure and narrative systems.

I recently published a longer development log covering the original concept, the proof of concept, early feedback and the development of the first four missions:

Building a 2D Shooter Where Shooting Is Not Always the Best Solution

I’m now preparing a limited Android playtest.

One of the questions I’m currently considering is how clearly the game should signal that an encounter has a non-destructive solution. Should the possibility be communicated explicitly in the briefing, suggested through intelligence, or left for the player to discover?

I’ll use this thread to share future progress and playtest findings.

I received useful feedback after posting the encounter elsewhere, particularly the suggestion to present the alternative resolution through the existing combat HUD.

The platform now receives a cyan “STABILIZER TARGET” reticle once its required subsystems are disabled. The HUD confirms “STABILIZER TARGET ACQUIRED”, Ravi’s skill changes to “RAVI // SAFE MODE”, and the game reports whether the stabilizer is within range and whether containment is progressing.

Players can still complete the encounter by continuing to fire, though this results in the forced-disable outcome. The goal was to make the safe-mode path visible during combat, while leaving the decision with the player.

I also published a longer dev log covering this change, the removal of temporary character voices, and the latest visual and audio feedback pass:

When Working Mechanics Are Not Enough: Improving Through Player Feedback in Project Aether

The next step is to test whether players notice the safe-mode option and understand it without my explanation.

Hey there!

Since the previous update, I have been working on the structure between missions.

The current build now includes an Operations Map that shows mission availability, completion and best scores. Those scores generate Operational Data that can be invested in ship equipment before the next deployment. Only an improved best score provides additional resources, so repeating the same operation with an equal or lower result does not create a farming loop.

I also returned to Mission 3 after receiving feedback that its enemy formations appeared slow and simple for a third stage. Rather than increasing enemy health or projectile density, I added choreographed formations with different entry directions, firing windows, repositioning and intentional withdrawals. The comparison below shows the same section before and after that pass:

The existing deterministic patterns remain in the mission. The new formations occupy some of the gaps between them and are still being adjusted through playtesting.  This pass also introduces new visual assets for the player aircraft, enemy drones, bosses and environments, alongside clearer outlines, stronger separation from the background and a visible reticle matching the aircraft’s actual projectile hitbox.

I published a longer development log covering how the map, scores and equipment now connect individual missions into a campaign:

Building a Campaign Layer Without Turning a Shmup Into a Grind

For a mission-based shmup, does using each mission’s best score as an equipment resource sound like a useful reason to replay earlier stages, or would it risk making score improvement feel mandatory?

Since the previous update, I've completed a wider visual and difficulty pass for Mission 3.

The visual work combines original aircraft and drone sprites with openly licensed environment assets. More importantly, it responds to feedback that some of the earlier enemies were blending into the mountain background. The revised drones use a warmer industrial treatment, clearer outlines and stronger contrast, while the active combat area of the background is less saturated.

I also revisited the mission's difficulty. Standard still introduces the drone roles, firing lanes and squad skills at a measured pace. High Threat is an optional version for players who already know those systems. It uses a separate encounter table rather than simply increasing every enemy's health or speed: formations overlap, armed contacts arrive while earlier groups are still active, and the recovery windows between waves are shorter.

The clip below compares the third wave in both versions:

I'd particularly like to know whether High Threat creates a different kind of pressure, or whether it only looks busier. Do the overlapping formations remain readable? And does the visual pass make it easier to understand why a hit happened?

I've written a longer development log about the asset selection, readability changes and High Threat design here:

https://jpb18.itch.io/project-aether/devlog/1631945/building-a-visual-language-t...

If you have experience with shmups and would like to try the current build, let me know. I'm happy to send an individual download link in exchange for feedback.

Since the previous update, the project has a new public name: Aether: Quiet Frontier.

While checking the project’s public presence on itch.io, I searched for Project Aether and found several unrelated projects using the same name. The prototype, FRS-07 and its four connected missions remain unchanged. I kept Aether because it still belongs to the setting, and added Quiet Frontier because it better describes a game where observation, restraint and protection can matter as much as firing.

The project page now uses the new branding, and I wrote a longer explanation here:

From Project Aether to Aether: Quiet Frontier

The next update will return to Mission 4 and recent feedback about visual readability.

Hey there!

Since the previous update, I’ve been working on Mission 4, Mountain Response, with a focus on how the game communicates competing responsibilities during combat.

The latest pass covers:

• earlier warnings for environmental hazards and crossing contacts;
• clearer team intervention cards for FRS-07;
• shorter combat communications during active play;
• more distinct visual and audio cues for hazards, equipment and team activations.

I’ve written a longer development log about the current direction and the questions that remain open:

https://jpb18.itch.io/aether-quiet-frontier/devlog/1641354/making-restraint-read...

The build is still experimental. If anyone would like to try the current prototype, send me a message, and I’ll share a download link

Hey there!

Since the previous update, Aether: Quiet Frontier is now playable in the browser.

The four-mission prototype can be launched directly from game page. The purpose of the web version is to make complete playtests easier to arrange: a new player can start a campaign without downloading, extracting or installing a build first.

I’m particularly interested in complete runs through the campaign: starting Mission 1, following the briefings and debriefings, using the Operations Map and preparation screens between missions, and reaching the final debrief. Partial runs are useful too. If you stop early, knowing where and why is valuable feedback.

The current playtest is looking at:

• objectives and alternative outcomes are understood without explanation;
• keyboard, controller and menu navigation behave consistently; 
• dialogue, team interventions and combat information remain readable through the later missions;
•  the browser version performs reliably across devices, browsers and narrower screens.

If you try it, you can leave a comment here or use this anonymous 

I also published a development log about moving the project from Godot C# to GDScript for web export, and about the changes made after a recent external playtest:

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

I’d especially like to know: does the browser version make the first step into the game easier, or do you encounter friction before the first mission begins?

Hey there!

It’s been a while since I opened the browser playtest. While waiting for feedback, I’ve been experimenting with alternative implementations of a few systems and working on some side projects. I’ve now written up the latest changes to Aether, focusing on how players get into the action and try again after a defeat.

The campaign now offers Story and Arcade. Story keeps the full narrative presentation, while Arcade skips story-only dialogue and starts directly with the combat missions. Both keep the essential instructions, equipment and progression systems. Standard and High Threat remain separate difficulty choices.

Arcade also introduces wave and boss checkpoints. Getting caught halfway through wave two now returns you to the beginning of that wave, with full hull, ready cooldowns and your score restored to its value before the encounter. Story keeps the full mission retry. I wanted players to be able to practise a troublesome formation while the mistake was still fresh:

I’ve also revised the support skill HUD so buttons describe their effects more clearly, reduced unnecessary UI updates and fixed a firing timer that made the cannon shoot less often at lower frame rates. The longer dev log covers those changes, the checkpoint behaviour and the performance measurements:

Getting Back Into the Fight in Aether: Quiet Frontier

For a mission-based shmup, do you find wave checkpoints useful while learning the formations, or do you prefer building familiarity through full-stage attempts?

Hey there!

Since the last update, I went back to a question this thread raised earlier: can you tell what's hostile at a glance?

In earlier builds, enemy rounds were amber, the same family as the hulls, HUD labels, and the player's cannon fire. I'd kept amber because it seemed the most realistic colour for a projectile, but on a crowded screen it made hits hard to trace back to anything you'd seen.

The current build uses one rule: magenta means it can hurt you. Hostile rounds are magenta with an outline, a halo and a fading trail; enemies get a thin magenta rim, and amber stays with the player's side and the tools. Enemy muzzles also glow before they fire (0.15 s for single shots, longer for burst and heavy patterns), and the hitbox reticle has a dark backing stroke so it reads over the pale hull.

The two clips aren't time-aligned: the earlier build is from 21 October, and its sprites and wave tempo have changed since, so this compares how the rounds look, not how the wave plays. I also haven't had a new player go through High Threat with these changes yet.

I'm comfortable with the demo as a representation of the game, so I'm treating it as closed and moving on to the post-demo missions. I'll only publish about it again if there's an issue to resolve. There's also a demo trailer now: 

The longer write-up is on the dev log: https://jpb18.itch.io/aether-quiet-frontier/devlog/1732922/reading-the-screen-gi...

A few things I'd like to know:

• In High Threat, can you separate hostile rounds from hulls and from your own fire without slowing down?
• Is the muzzle glow enough warning, or only enough to notice?
• Does the magenta rim make the hulls noisy when many share the screen? And if you have a colour-vision difference, does the magenta/amber split hold up for you?

Thanks for playing and for the feedback so far.