itch.io

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.

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.

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?

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.

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.