← News  //  2025-11-29  //  v0.3.0

v0.3.0 - Where and when it hurts

v0.2.0 gave the game objectives and a data-driven system to describe them. v0.3.0 makes that system say more interesting things and gives the player a weapon that is not just a turret. It lands on three fronts at once: the event system grows lifecycle and location awareness, the torpedo bay arrives as the first area-of-effect weapon, and the health model underneath it all is reworked so that section-by-section damage is clean and consistent. Directional and thruster shaders got sharper on the way out. This is a smaller release than the ones that follow, but every piece of it is groundwork the later combat and scenario work stands on.

The torpedo bay and blast damage

Until now the only way to hurt something was the turret - a hitscan round that damages exactly what it touches. Aim at a section, pull the trigger, and that section takes the hit. Precise, pointed, and unforgiving of a near miss. The torpedo bay section is the game's first area-of-effect weapon, and it plays by a completely different rulebook.

A weapon that does not need a perfect hit

A torpedo does not need a pixel-perfect hit. It travels, it detonates, and it deals blast damage to everything inside its radius. That single difference changes the tactical texture of a fight completely. Turret fire stays precise and pointed, good for picking apart a specific section on a specific target. Torpedoes are about zoning: catching clustered targets, punishing fragile ones, and putting damage into a volume of space rather than onto a single point. The two weapons pull in different directions on purpose, and a build that carries both has answers to more situations.

A section like any other

The torpedo bay is not a special case bolted onto the ship. It is a section like any other, which means it mounts onto a build with the same physics and the same mounting rules as a thruster or a turret. There is no separate weapon subsystem to learn: if you know how to attach a thruster, you know how to attach a torpedo bay. It inherits mass, placement constraints, and mounting behaviour for free, which is exactly the payoff of treating every functional part of a ship as a section from the start.

A health system built for sections

Blast damage only means something if there is a consistent thing for it to damage. A weapon that hits a whole radius needs targets that can be hit individually inside that radius, or the mechanic collapses back into "the ship took some damage". So this release reworks health into a proper per-section health system.

One path for every kind of damage

Every section of a ship now carries its own health, and both flavours of damage feed into it through the same path. A turret round hits one section and subtracts from that section's health. A torpedo blast hits every section within its radius and subtracts from each of them. There is no separate hitscan health and blast health, no special code that treats the two weapons differently once the damage is computed. They converge on one shared, section-local model, which is what makes it safe to add more weapon types later without reinventing how damage is applied each time.

Damage stays local

The nice property that made destruction feel right in earlier builds carries forward: damage stays local. A torpedo that detonates on one side of a ship can shred the sections on that side while the far side survives untouched. Where a hit lands matters, not just whether it landed. That is what gives both weapons their character - the turret rewards aiming at the section you want gone, and the torpedo rewards putting the blast where the sections are densest.

Events that know where and when

The v0.2.0 modding backbone could react to things happening: an object destroyed, a variable crossing a threshold. What it could not do was react to lifecycle or to place. v0.3.0 adds both, and it adds them as more vocabulary for the same event language rather than as special-cased gameplay code.

Lifecycle: OnEnter and OnExit

OnEnter and OnExit events fire when a scenario state begins and ends. That sounds small, but it is the difference between a mission that can only respond to mid-flight events and one that can bracket a whole phase of play. On entry a state can run its setup - spawn a wave, seed variables, show a briefing - and on exit it can run its teardown, all without hand-wiring any of it into game code. A scenario author gets a clean place to hang "when this beat starts" and "when this beat ends" logic, which is exactly where most mission scripting wants to live.

Place: the zone-entry trigger

A zone-entry trigger fires an event when a ship moves into a defined region of space. This one primitive unlocks a whole class of objectives that were awkward or impossible before: "reach the nav point", "leave the debris field", "hold this area". All of them are expressed as data, flowing through the same filters-and-actions pipeline as every other event. Turning a region of space into something a scenario can react to means new scenario shapes without new engine code, which was the whole point of building the system data-driven in the first place. This is the machinery the scenario system still runs on today.

Sharper shaders

Two visual upgrades round the release out, both aimed at legibility rather than spectacle.

Directional shader

The directional shader was reworked to make a ship's forward direction far more legible at a glance. It is a small thing that matters a lot: reading which way a ship is pointed in the middle of a fight is the kind of split-second judgement that decides whether you commit to a shot or a turn, and the clearer the cue, the fewer mistakes made under pressure.

Thruster shaders

The thruster shaders were extended to support more complex shapes and animations, so exhaust plumes can be more expressive than the single cone they started as. Beyond looking better, a more articulate thruster plume is also information: a bigger, brighter burn reads as more thrust, which feeds back into how you judge another ship's acceleration and intent.

Point releases

v0.3.1 - New engine, new home for the docs

v0.3.1 is a maintenance release with no player-facing gameplay to speak of. It pulls the whole stack up to a current engine line and gives the project a proper documentation home, the groundwork that keeps the game building and makes the codebase legible to newcomers.

The headline is the jump to Bevy 0.19, which drags the physics and randomness crates along with it: avian3d 0.7, bevy_rand 0.15, bevy_enhanced_input 0.26, and rand 0.10. It is a mechanical upgrade with no behaviour change for players, but it keeps Nova on a supported engine.

The vendored bevy_common_systems copy is gone. It is now pulled in as a proper git dependency instead of living in-tree, so shared systems live in one place and stop drifting between copies. Alongside that change lands an AGENTS.md and a new docs/ folder covering architecture, the scenario system, sections, development, and migration notes - the first real home for how the project fits together, and the folder the later releases keep filling in.

On the render side, a post-processing camera component lands as the seed of a proper post-processing pass. Nothing visible hangs off it yet; it is the hook that later visual work plugs into.