STARGAZER · DAY 64
StarGazer is a single-player 3D space combat game where you command massive capital warships through procedural roguelike runs — broadsides, voxel hull damage, deterministic simulation, built solo with AI assistants.
Started May 21, 2026 · last activity 7d ago
Activity & Beats
Composite of commits, decisions, and posts per day. Click a bar to filter the timeline below.
Select voxel proxy faces from camera position
Large stations stay whole at the edge of view instead of breaking into disconnected slabs.
Store access and trade as bounded faction state
The game now remembers who may enter, who trades with whom, what each side gains, and what breaks when the link fails.
Make faction choices bounded, sourced, and replayable
Factions now choose from a fixed budget, say why, keep the evidence, and make the same choice after a save.
Split system fleet capacity by hull tier
A system can now hold large fleets and hundreds of working small craft without letting capital ships crowd them out.
Compose small-craft roles with faction doctrine
A faction ship keeps both who it serves and what job it does.
Scale ordered faction outcomes for full system fleets
Bigger fleets can create more political facts without losing or reordering them.
Make the ship the player
The player needs a clear heroic identity and power source while factions remain dangerous through fleets, territory, and rare apex threats rather than ordinary ships matching the hero one for one.
Make faction access and trade concrete
Relations need visible local effects and useful strategic risks. A treaty should change where ships can go, what services work, and what both sides stand to lose.
Make faction intent visible before consequences
Drama is readable when the player can connect intent, evidence, choice, and consequence. Silent fallback makes a faction look arbitrary, especially when a failed diplomatic offer turns into aggression.
Put faction drama where the player can meet it
Drama is useful when the player can see its cause, enter it locally, and trust that travel, saves, and hidden intel do not rewrite the story.
Let doctrine create identity without adding a second faction AI
Combat identity should be visible and data-driven without creating a parallel AI, hidden action budget, or public strategy leak.
Give small craft jobs, not new physics classes
A ship's job should change its shape and behavior without duplicating movement rules. Factions can now show their economy and local control through the craft around them.
The Lights in the Dark Have Names Now
I wanted every distant station to feel worth crossing the dark for, with a purpose, a flag, and wounds that wait for your return.
The Galaxy Learned to Say No
I wanted the galaxy beyond the bow to stop feeling like a field of dots, and tonight one distant star told my capital ship it was not welcome.
I Gave Three Small Ships a Reason to Cross the Dark
From the command chair, I wanted every distant light to mean something: ore coming home, cargo moving, or a patrol keeping watch.
Keep travel's mutation lease until rollback ends
A jump now finishes or rolls back fully before another mode can replace the battle.
Capture submitted frames before swap
Screenshots now save the complete frame the game is about to show. The map no longer draws hidden UI behind itself.
Failed travel stays locked until restoration is proven
A broken jump cannot return to unsafe play, and the map tells the truth about what the player can do.
Sync-main auto-rebases unless a major conflict appears
I made sync cleanup automatic unless the branch is truly conflicted.
Make VFX content failure visible before expansion
I built a repeatable visual proof so every effect must exist, render, and identify itself before the library grows.
Make weapon VFX lifecycle data authoritative
Every weapon can now carry its own flash, impact, interception, and expiry look without special-case rendering code.
Run VFX as fixed timed recipes
Explosions, trails, and electrical failures can now unfold in clear stages while staying repeatable.
Reserve VFX capacity by visual importance
Important blasts and hit cues now stay visible in large battles, while smoke layers hold together as the view moves.
Treat flash accessibility as an effect policy
Flash controls now soften the whole effect while keeping the information needed to follow a fight.
Keep wound history outside voxel authority
Fresh breaches now spark, vent, and cool over time while always staying tied to the damage that is really present on that ship.
Scale collision effects from contact severity
Light scrapes now throw a restrained spark fan, while hard rams add a brighter flash, fragments, and dust without hiding the fight.
Tint VFX from authored faction identity
The same weapon effect now reads cyan for the player, coral for the legacy hostile fleet, and violet for the Scourge without becoming brighter or changing shape.
Drive warp VFX from ship lifecycle edges
Arriving ships open a restrained warp wake at their aft face. Departing ships leave from their last real position.
Map planet profiles to VFX through strict data
The planet generator says which world this is. VFX data says how that world's weather looks.
Render planet weather from stable profile seeds
Gas giants, rocky worlds, and alien worlds now choose different weather recipes from data.
Keep planet terrain covered during LOD changes
Planet detail changes without opening cracks in the world.
Keep Metal body lighting in fragment slot zero
The voxel shader keeps data that changes per ship in one stable Metal buffer.
Drive space weather from generated world profiles
Each system now surrounds its worlds with distinct dust, charged filaments, flares, and coronal debris.
Use pipeline linear depth for soft particles
Smoke now fades into ship surfaces instead of cutting across them as a hard card. Sparks and hot points keep their sharp edges.
Structure state and targets use stable simulation identity
Stations now stay damaged, react to attacks, and remain the same target even as the surrounding battle changes.
Give weapon verbs distinct render geometry
Missile swarms now travel as compact groups, while electrical weapons snap across space in a changing zigzag.
Keep faction diplomacy bounded and transaction ordered
Factions can now make deals, answer calls for help, press claims, wage limited wars, and negotiate peace for reasons the game can remember.
Encounter markers show owned instances, not guesses
Spawn requests can be delayed, refused, killed, or reuse slots. A signal or ship scan cannot reconstruct the authoritative pending and active counts. Persistent instances make the marker truthful and replayable.
Jumps pause the bubble but keep the map live
Advancing the old bubble would make travel results depend on machine speed. Freezing the whole window hides progress and removes cancel. This split keeps deterministic sim time while the player still has a responsive screen.
Make fun evaluation explicit and evidence-backed
Build, determinism, asset, and visual checks prove the game works, but they do not ask whether the player makes a clear choice, reads the consequence, and wants another try.
Give every space structure a job before a shape
A station chosen from one global table cannot say why ships are present or make capture, damage, and faction identity legible. Separate data lets a harbor, refinery, listener, yard, bastion, and gate change local traffic without duplicating geometry.
Raids attack exposed infrastructure before the harbor core
I want a raid on a listener, refinery, relay, or yard to create a readable local loss. Repeated attacks on an already dead site or the safest central beacon do not.
Factions remember causes, not one score
One symmetric reputation value cannot express love, fear, need, betrayal, duty, or a shared enemy. Separate causes let factions act differently and let the player see why.
Space structures change local behavior, not only scenery
A purpose label has no value if traffic, defense, repair, intel, and incidents behave the same. Local consequences make each station explain what ships are doing and what the player changed.
Structure effects stay local and weapons obey physical blockers
A disabled relay must not shut down an unrelated shipyard. A warning service must change time, not only text. A station must obey the same physical weapon rules as a ship.
Generated structures inherit local builders and castable conflict
A generated station must belong to the place around it. A raid or opening scene must create real local actors, not a label with no possible cast.
Active structures belong to the factions present and operating them
A local station cannot support a castable story if its active faction is absent, its raid target is friendly, or its guns follow a former owner's doctrine.
Structure activity must name both ends and obey live authority
A station story is only believable when ships visibly travel between places and current control changes who visits, attacks, responds, and appears locally.
Make faction conflict limited, caused, and endable
I want betrayal and cooperation to create readable consequences without turning every refusal into permanent total war.
Destination fleets cook in parallel
The long jump wait was ship building. I split that work across four workers without changing fleet order.
Jump directly from the Strategic Table
This completes navigation without deciding whether the wider game becomes strategy-first, a campaign, or a roguelike.
The game is the only ship visual authority
Its static Three result had drifted from the voxel-native game and gave a false picture of the current art.
My Living World Was Counting Its Dead as Alive
Yesterday my star system passed its own health check. Today I caught it counting corpses as crew, and the honest fix finally taught the world to measure itself without lying.
THE PLANET IS AN UNREACHABLE VOXEL BACKDROP AT ACTUAL PLANET SCALE
Descending to a planet surface was a spectacular tech demo but not the game — StarGazer is capital-ship combat. As pure scenery the planet needs none of the approach/surface machinery (governors, horizon camera rigs, VFX depth bands), and dropping them collapses three fragile depth regimes into one exact partition. Meanwhile "actual planet scale" is what makes the backdrop read as a WORLD: at theatrical scale (14k) the planet was ~93 ship-lengths of radius — a moonlet; at 500k it's a wall of world behind every battle.
Planetfall Phase 3h — the hover sits LEVEL over the surface (+ richer terrain)
The 3g arrival worked but the ship kept the tilt it flew in with, which looked like it had stalled mid-turn rather than arrived. A capital holding station over a planet should sit flat to that planet's horizon — that one change is what makes the hover read as "arrived and parked" instead of "paused." The taller terrain gives the coastline more drama at the scale you view it from.
Planetfall Phase 3i — a broad voxel landscape, not a small patch
The 3g/3h arrival worked, but the view only reached a short distance, so the voxel land felt like a little island rather than a world. Letting the camera see much farther (and growing the voxel ground to match) is what makes it read as a real planet surface you're flying over — the difference between "a patch below me" and "a landscape to the horizon." It's the payoff of the whole planetfall being a place, not a prop.
Planetfall Phase 3j — planetfall is now NORMAL PLAY (the G cruise flies you there)
Up to now the whole planetfall lived behind a launch flag — a demo, not a feature. The point of the ask was "can I actually go to the planet and it's voxel" — and "actually" means in the game you play, by pressing the key you already use to set course, not by relaunching with a flag. Wiring the cruise to land you on the voxel surface (and keeping the terrain invisible until you're there, so combat is untouched) is what turns it from a showcase into a place the game takes you. It's the difference between "I built a planetfall mode" and "the planet is somewhere you go."
Cruise key moved G → J (G was already the shipyard toggle)
A double-bound key is a bug — the shipyard binding is the established one, so the newer cruise binding is the one that moves. (Reported in play: "G is colliding with the shipyard.")
Planetfall Phase 3k — the transition is a joke; NMS research + a from-the-surface SKY
The research's headline lesson is that atmospheric scattering is ONE continuous effect — the limb you see from orbit is the sky you see from the ground (O'Neil GPU Gems 2 / Hillaire). Our atmosphere was limb-only shells that vanish once the camera is inside them (exactly the arrival case), so the surface had literally no sky. A sky is the fastest, highest-leverage step from "green slab in the void" to "standing in a world's atmosphere" — and it's what the ask literally named ("into the atmosphere"). Shrinking the patch matters because a flat finite slab, seen from low altitude, juts ABOVE the true horizon and occludes the whole sky — the smaller it is, the more world + sky show beyond it.
Planetfall Phase 3k.2 — the LOCAL-HORIZON camera (the arrival finally reads as a world)
This was THE thing hiding all the other work. The sky dome and the smaller patch were both there, but the camera was looking straight down at the ship against the ground with a tilted horizon, so you never saw the sky or the curve of the world. A planet has a local "up" (straight away from its centre) that is nothing like the game-world "up" once you're tens of thousands of units out; the camera has to know that to frame a horizon. Aligning the rig to the local horizon is what turns "top-down at a ship over a floor" into "banking over a world."
Weapon mounts were comically oversized — bulk re-trim of the ×3 voxel-scale re-author
The re-author's floor (armament ≥ ~4-8 voxels so it survives the cook) is correct, but ×3 made a "large" drum on a capital a ~3u barrel-less box that dwarfed the hull, and the casemate a ~1.9u cube whose thin barrels vanished against it — reading as shipping crates, not guns. The fix is proportion, not floor: shrink the housings toward the gun and let the barrels carry the read. Verified across four fresh capital seeds (12345, 88, 424, 7777) at real viewing scale — mounts now read as proportionate turrets with visible barrels.
Broadside guns were too LONG — stubby re-trim (reverses the fix-1 barrel lengthening)
The player literally named these "broadside turrets" in the prior report, and the only barrel I'd just made *longer* was the broadside pair — so "so long" maps straight to that change. Stubby is short-and-thick, so the fix is both axes: cut the length hard and fatten the barrel so it still reads as a gun deck rather than a bristle.
FLYABLE PLANET Phase A — the surface is a STREAMED cube-sphere voxel planet
A fixed patch (however broad/curved) can only be a hover backdrop — you'd fly off its edge. A cube-sphere gives every surface tile a STABLE global id, so chunks generate once, stream, and LOD independently, covering the whole sphere (poles included) — the real planetary-terrain substrate (Outerra OSC / the NMS research), not a re-centering hack. Built on the marcher's existing multi-volume API (register/unregister/prune, per-frame poses, front-to-back depth cull) — the AsteroidField already runs many volumes, so this is the same proven path at planet scale.
LOGARITHMIC DEPTH BUFFER — the planet is now VOXEL from orbit (P0 unblocked)
The reverted Phase B.2 proved the smooth mesh could only be a far-LOD because the voxel chunks span too large a depth range for a standard 1/z buffer (clipped past the far plane, z-fighting with a wide one). The log-depth buffer is the *only* clean fix (the research's P0), and now that it's in, the "fully voxel, no shortcuts" planet is real — voxel from space down to the surface.
Log-depth GATED to the approach band — surface VFX stay consistent
The log-depth buffer only *needs* to span the huge range during the approach (a rock in front of the ship + a chunk 27km out). At the surface everything's within the standard far plane, so classic depth is sufficient AND it's what the VFX already write — gating there gets correct plume compositing for free, deferring the full VFX→log-depth conversion to when it actually matters (the brief high-speed cruise). No new mismatch: the only frames with a plume/terrain depth disagreement are the ~5-tick cruise, mostly hidden by cruise speed.
Atmosphere halo CONTINUOUS across the mesh→voxel boundary
The vanishing halo was the most jarring part of the descent pop and was an artifact of the BodyHidden early-return (it dropped the shells too), not inherent to the LOD architecture — so it's a seam to close, not a fundamental limit. A full mesh→voxel silhouette crossfade (geomorph/impostor) remains the hard, deferred piece; halo continuity is the cheap high-impact 80%.
Crisper planet from orbit — finer terrain voxels (CellsPerChunk 32→64)
Blockiness from orbit was purely the voxel SIZE, and the marcher profiled as coverage-bound with ~11ms of headroom under the 16.6ms/60fps budget — so buying 2× the detail for ~0ms of steady GPU cost is the obvious lever. Chose finer cells over more chunks (higher baseRes) precisely because it adds detail without multiplying draw calls.
Galaxy backdrop structure (Skysphere/Starfield/NebulaClouds) — render-only, hash-neutral
The code that paints the sky at startup now draws a structured galaxy — a banded core with dust lanes — instead of an even haze, and the stars cluster along that band. None of it runs per frame or touches the game simulation, so nothing about the game's determinism changed.
Far-layer rendering + world-positioned terrestrial planet (Phase 2a/2b) — render-only
Added a way to draw very distant things (like a planet tens of thousands of units away) that the normal camera would clip away, and gave the planet an Earth-like surface generated from the same kind of noise the real terrain will use later. None of it runs in the game simulation.
Planet-approach cruise governor (Phase 2c) — sim-side autopilot, hash-neutral
New sim code flies the player's ship to the planet on command, slowing smoothly as it arrives. It only runs when the player chooses it, so the game's fights and its automated tests behave exactly as before.
Shared PlanetHeightField + displaced terrain mesh (Phase 3a) — render-only
Added one shared, exactly-reproducible "how tall is the land here" function, and used it to push the planet's surface out into real hills and coastlines. It doesn't touch the game simulation yet.
Voxel terrain patch renderer (Phase 3b) — render-only
New render-only code turns a patch of the planet's surface into blocky voxel cubes read from the same height map the orbital planet uses, flat-shaded by the sun like the ships. It doesn't touch the game simulation.
Voxel terrain migrated to the GPU marcher (Phase 3c) — render-only
The planet ground is now drawn by the same voxel engine as the ships — same lighting, same detail-reduction, same destructible material — instead of a separate stand-in that painted its own light. It still doesn't touch the game simulation.
Destructible voxel terrain (Phase 3d) — render-side Direct overlay, render-only
New render-only code carves craters into the voxel ground so it shows real holes — the same hole-rendering ships and asteroids use. It doesn't touch the game simulation.
Surface-arrival mode (Phase 3e) — render-only, env-gated
New render-only code lays the voxel terrain out as a ground plane under the ship and frames the shot, so you see your capital hovering over the planet surface. It doesn't touch the game simulation.
Surface descent (Phase 3f) — governor retarget + level attitude, hash-neutral
The ship now flies itself down onto the voxel surface, staying level like a big ship should. It reuses the existing "fly to the planet" autopilot aimed at a point under the ground; the only new sim behavior (staying level in a steep descent) never runs in the automated tests, so the game's determinism is unchanged.
Point defense is a recharging burst, and missiles now saturate it
The old pass granted PD its full capacity EVERY tick, so crossing the 200-unit intercept sphere (~20 ticks) multiplied PD strength twenty-fold: a healthy capital provably shot down every missile ever fired at it, which is exactly what play felt like ("they get shot down pretty fast"). The AI's own volley math already assumed the salvo-minus-K model; now the sim agrees with it. My first cut used fixed tick-windows and the new gate arm immediately caught volleys straddling a window boundary facing double budget, which is why it became a rolling bucket.
Collapse the dev command stack behind one small toggle
The dev buttons were always on screen and dominated the right third of the view, which made the game read like a debug tool instead of a game. They are still one click away, and every one of them still has its keyboard shortcut, so nothing got less reachable.
Showcase reels roll a fresh ship, reproducible by seed
A marketing or demo reel that always shows the same ship hides the whole point of the game (every ship is procedurally generated and different). The seed is the reproducibility answer: variety by default, exact repeat on demand, without falling back to a boring fixed ship.
Fix the two dead cinematic beats (shear + head-to-head)
The trailer's self-check had been failing on these two beats since before this session (I confirmed it against an older build) because the game's combat and damage systems moved on while the beat scripts didn't. A trailer scene that stages no combat or checks for a deleted effect is worse than useless. This is exactly the silent drift that rots a vibe-coded project.
Planetfall research — adopt DeepSpaceEngine techniques at theatrical scale, techniques only
The engine is an unknown (zero stars) but genuinely good reference: it proves the whole seamless orbit-to-surface pipeline runs in C# on weaker GPU features than ours, and its design docs record the lessons (precision first, per-seed determinism, geomorph + fractional octaves for pop-free LOD, worker-pool baking). The scoping insight that makes descent affordable for us is that its hardest subsystem — true-scale coordinates — is the one part a single-arena combat game does not need. The backdrop gap, meanwhile, turned out to be composition rather than technology: our sky is a uniform nebula wash, theirs is a structured galaxy; our existing procedural bake infrastructure can produce their look by changing what it bakes.
DeepSpaceEngine owner granted permission to use parts of the code
The whole planetfall proposal keyed its legal framing off DSE having no license file (all-rights-reserved by default). Direct permission removes that constraint for the parts that port cleanly as C#, which meaningfully speeds up Phase 2-3 (adapt a proven, tested noise/quadtree implementation rather than rebuild it from prose). Recording it matters because "why is there DSE-derived code in the tree, and under what right" is exactly the provenance question a future contributor — or a storefront's legal review — will ask; a verbal okay that isn't written down is the kind of thing that rots.
Capital ships now frame big — size-adaptive camera distance
The old default framed every ship at the same fixed distance regardless of size, so a capital read like a desktop model and a fresh fighter was a distant speck. Framing by size is what makes a big ship actually feel big — the complaint that started this.
Planetfall Phase 1 — the sky becomes an edge-on galaxy
The user liked how the reference engine renders its stars and background, and the gap turned out to be composition, not technology — our procedural sky bake already had the machinery, it just baked a flat smear. Adding band structure + a bright core + a dark rift is what makes a sky read as a real galaxy edge-on. Keeping the core aimed at the default camera means the improvement shows on "run the game," not only when you turn to look (default run is the showcase). I pulled the core brightness back a notch so the deep-black void contrast the middle-ground baseline wants is preserved.
Planetfall Phase 2 (render foundation) — the planet becomes a destination
The load-bearing problem the review flagged is that a planet parked that far out is far past the camera's far plane and simply would not render. Solving that (a far-layer with its own wide projection, drawn behind the arena) is what turns the planet from unreachable-backdrop into a body the game can actually place at destination scale. Making it terrestrial (baked from the same seeded height field a future terrain would use) both reads as a place you'd land on and de-risks Phase 3 — if the continents look good painted on the sphere, the terrain will. Keeping it world-fixed is the difference between "a bigger backdrop" and "a destination."
Planetfall Phase 2 — you can now fly to the planet (approach cruise)
The ship's normal top speed is tiny (tuned for close-range capital combat), so the planet was effectively an hour away at combat speed — a beautiful backdrop you couldn't reach. And simply letting the ship go faster would have broken combat (the player could sprint at hundreds of times combat speed around the arena). A separate, opt-in cruise autopilot is the clean answer: it makes the destination reachable and the arrival cinematic, while leaving combat speeds and feel exactly as they were. The eased, self-slowing approach (fast then gentle) is what makes arriving feel like settling into orbit rather than slamming to a halt.
Planetfall Phase 2 polish — cruise turns nose-first, toggles, and arrives on its own
The raw mechanic worked but read rough — a capital ship crabbing sideways toward a planet looks broken, holding a key for a ~20-second flight is tedious, and a travel mode that doesn't tell you when you've arrived leaves you fighting the autopilot. Turning nose-first, toggling, and auto-arriving are what make it feel like a deliberate "set course for the planet" command instead of a debug hold. The turn is a smooth swing (not a snap), so engaging cruise looks like the ship banking onto its heading.
Planetfall Phase 3 (start) — the planet becomes a real 3D world
This is the load-bearing, always-needed foundation for any version of "descend to a surface": one deterministic height map, and the mesh pipeline that turns it into visible relief. Getting that in — and proving the terrain renders (relief in the silhouette, a flyable coastline) — de-risks everything downstream and is a real visual leap (a world, not a marble). It's honestly limited without the next piece, though: from orbit the relief is too small to see (it looks like the Phase-2 textured planet), and up close the fixed-resolution surface is soft and blocky. Both are fixed by the quadtree level-of-detail system (fine surface only where the camera is close) — the multi-session heart of Phase 3, which is the natural next decision point now that there's a 3D world to look at.
Planetfall Phase 3b — the planet surface is voxels too
Everything in StarGazer is voxels — the ships you fly, the asteroids you shoot, the wreckage. A smooth painted-mesh planet surface would be the one thing that ISN'T, and dropping onto it would break the whole aesthetic the moment you got close. Proving the surface can be built as on-brand voxel cubes from the shared height map — and that it reads as a real coastline with biomes and per-face sun shading — is the load-bearing "does the look work" answer before I invest in the streaming/level-of-detail machinery that makes a whole planet of it. Doing it as a simple cube patch first (rather than jumping straight to the destructible GPU version) got that answer cheaply.
Planetfall Phase 3c — the planet surface runs on the real voxel engine
Everything in StarGazer is drawn by one voxel engine — the ships, the wreckage, the asteroids. Having the planet surface drawn by a SEPARATE stand-in renderer with its own hand-painted lighting was the seam that would always look slightly "off" next to a ship parked on it, and it was a dead end: the stand-in couldn't be shot, couldn't share the ships' destruction, couldn't share their detail-reduction. Putting the surface on the real engine is what makes it a first-class part of the world — the lighting matches the ships automatically, and it's now the exact same destructible voxel material, so weapon damage to the ground is a wiring job on top of what's already there rather than a whole new system. The stand-in did its job (it proved the look); this retires it.
Planetfall Phase 3d — you can blow holes in the ground
"Everything is made of destructible voxels" is the promise of the whole game; the ground being the one indestructible thing would break it. Proving the surface actually craters — with the same look as ship/asteroid damage — closes that gap and confirms the marcher-migration payoff (the ground is real destructible material, not a decorative skin). Doing it as a scripted carve first is the honest increment: it demonstrates the capability now, on the exact rendering path the live version will use, without pretending the surface is reachable by weapons yet (that needs the orbit→surface descent).
Planetfall Phase 3e — the capital ship at the planet surface
The arc so far built each piece — a galaxy sky, a planet to fly to, the cruise to reach it, the surface turned to voxels, put on the real engine, made destructible — but never showed the one image that makes it all land: your ship over that surface. Staging it now proves the surface reads as a place a capital ship belongs over, at the right scale, with the space horizon selling "this is a planet, and I'm above it." It's the emotional close of the loop even though the *mechanical* descent (flying continuously from orbit down onto it) is still ahead — worth having the destination view now so the descent has an obvious target.
Planetfall Phase 3f — flying the ship DOWN onto the surface
Phase 3e showed the ship AT the surface; this is the motion that gets it there, which is the verb in "bring my capital ship DOWN to a planet." Reusing the existing cruise autopilot (just aimed at a point below the ground) meant the descent came almost for free — the same self-easing travel that solved "the planet is too far to reach" also solves "come down gently onto it." The one thing that needed fixing was attitude: the autopilot turns to face where it's going, which for a straight-down descent pointed the nose at the ground (a capital standing on its nose — wrong). Making it hold its deck level for steep descents is what turns an awkward plunge into a proper warship settling onto a world.
Planetfall Phase 3g — you can actually FLY to the planet and it's voxel
This is the actual thing that was asked for — "go to the planet and have it be properly voxel, hover 5000 ft up." The big worry (a planet parked tens of thousands of units away can't be drawn as voxels from that far) turned out not to block it: because the SHIP flies there too, once you arrive the voxel ground is right next to the camera, and the numbers stay precise enough at that distance (sub-centimetre) to draw it cleanly — so no elaborate "re-center the universe" machinery was needed, just placing the voxels on the real surface and flying there. Lighting the approach side (it's the planet's night side by geometry) is what turns a dim arrival into a bright green voxel coast.
Weapons are data: def catalog, pack bindings, declared visuals
Every weapon in the game, from its damage numbers to the color and shape of its shots, now lives in small data files instead of buried code, so a new weapon is a short recipe file rather than a programming session.
Armory phases 6-8: live tuning, loadout defs, material seam
Tuning a weapon, changing the player's build presets, and deciding how armor resists each damage type are now all edits to small data files, and a running game can be tuned live and save those tweaks back to the files itself.
Coarse cook keeps the largest component, then seats the core
Some randomly generated ships were secretly hollow to the physics engine because a floating crumb of hull stole the ship's heart during baking, and the game crashed when they tried to fly; now the bake always keeps the real ship and the crumbs are swept away.
Projectile velocities quantize to a 1/32-voxel lattice
Plasma shots were snapping to a coarse direction grid at launch and could miss where you were aiming by a wide margin; the grid is now 32 times finer, so shots fly where the crosshair points and a test keeps it that way.
Gunnery review hardening: floor, faction guard, archetype re-check
I had the new weapon system reviewed and hardened the rough edges: a shot can never round down to doing literally nothing, the systems-disruptor beam won't knock out your own ships, and a mistyped build can't quietly load the wrong gun.
Weapon-arch cleanup executed: one owner per stat, one copy per rule
I had the weapon code audited for tangled wiring, then rewired it so every number has exactly one home and every rule is written exactly once, which also fixed the build presets so their stat bonuses actually apply when you play.
The player flies a freshly generated ship every launch
Every session should open on a ship you have never seen before - the generator is the game's content engine, and the launch moment is where that variety should show.
The whole battle is freshly generated every launch
The generator IS the content engine; a roster of eight hand-kept ships was a placeholder cast. Every battle should be a fleet nobody has ever fought.
Weapon machinery scales with the hull, not the class floor
The 0.75 floor exists so hull greebles stay readable, but weapon banks clamped UP dwarf a short hull: the owner's 9.2u ship carried side turrets sized for a 13.5u hull, 47 percent oversized, spanning the full flank height. Machinery must read as hardware ON the ship, never rival the ship.
The Gunnery: player gun system expansion proposed
The audit showed the bottleneck is not tech, it is roster: salvo/pattern fields and the whole EMP system are implemented but unused, and the player literally cannot pick a different gun, only tune the fixed one.
Swarm missiles: vertical tube launch, ripple, arc onto the lock
Missile volleys that pour out vertically and curve onto the target are the single most iconic sci-fi combat read, and the ordnance group was dead weight: it had NO launch trigger in mouse-aim mode at all.
The Gunnery A1+A2: builds pick guns, five new player weapons
The audit showed the real gap was not tech but roster and selection: the player literally could not swap a gun. A1 unlocks that with a small keystone; A2 fills the roster with data only, no new code.
The Gunnery A3: armor now matters (damage-material matrix awake)
The audit's biggest sleeping lever was the per-cell material table, shipped neutral so the plumbing risk landed separately from the balance decision. Waking it makes a ship's armor placement tactical reading and gives HE its identity as the mount-stripper.
The Gunnery B4: player HE spall (the mount-stripper)
The spall resolver existed but nothing the player fired reached it, and A3 had just given HE a material identity worth exploiting. A distinct projectile kind isolates the change so nothing existing moved.
The Gunnery B2: the EMP beam (arc-projector, the tech-killer)
The whole EMP disable system was implemented (it powers the spinal disruptor) but no player weapon delivered it. A hitscan beam is the cleanest EMP delivery, and it slots straight into the primary picker.
Allies are immune to all friendly fire
Friendly fire was a latent gap the weapon review surfaced (the EMP beam, and every existing hitscan, would carve a teammate in any ally scenario); with the arsenal expanding it is time to make allies safe by rule rather than by luck of positioning.
Middle-mouse target lock (and the T double-bind fix)
Gunner mode freed the left button for firing and lost click-to-lock, leaving Tab-cycling as the only designation path — awkward mid-fight. A dedicated mouse button makes locking a flick.
All player weapons live on the hotbar, one trigger fires them
I kept catching dedicated fire hotkeys sneaking in (T for missiles was the second). One trigger plus an arm/disarm loadout bar is the model: the bar shows everything you can fire, keys stay scarce, and arming finite ammo is a deliberate act instead of a fat-finger.
The target-lock reticle is player HUD, not a debug visual
Screenshots lied by construction: capture frames force the debug overlay on, so every verification screenshot showed brackets while live play showed none. The fix ships with a catalog case (mmb-lock-reticle) that stages the live-parity frame (lock scripted, debug lines hidden) so the regression cannot re-hide. The same pass surfaced that the scripted-input branch dropped the lock stamp entirely (third instance of the scripted-branch-must-mirror-the-live-stamp class); both scripted returns now carry it.
Transient dynamic lights: combat flashes cast onto hulls (8-slot, render-tier)
When something explodes next to a warship, the warship now catches the flash — bright on the facing side, falling off around the hull, cooling from white-hot through orange toward the arcane violet as the blast dies.
StarUI foundations + settings graphics tab (one arc, gallery canary, settings proof)
The game now has real menu building blocks — rows, cyclers, one keyboard-focus system, one look — and its first real settings screen built from them, where changing an option takes effect instantly, saves itself, and can never silently fight the developer test switches.
Settings fast-follows: controls-tab rebind UX + device rows (display/vsync/render-scale)
You can now rebind every flight key in the menu — the game warns you when a key is stolen from another action and shows exactly what's still bound where — and drop the 3D resolution to 75% or 50% for frame rate without the menus or HUD getting blurry or tiny.
Sprint architecture audit: 28 confirmed findings, one crash fixed, work list in UI-WEAPONS-ARCH-AUDIT
We had thirty-three reviewers comb through everything shipped today; the features themselves are solid, but the places where new code gets bolted on are wearing out, and there is now a ranked to-do list for reinforcing them — plus one crash that could only happen on machines missing shader files, fixed on the spot.
core_rating is pack data: the re-knit gate and rate come from the sidecar, not a player-index check
Each ship's data now says how good its magical heart is at re-growing lost hull; every enemy ships with an ordinary heart that cannot, and the player's unique one still can, so nothing changes in play — but a future boss that heals is now just a number in its file.
The Core RE-KNITS: carve damage heals after disengaging; severed matter is spent forever
Degradation without recovery is a death spiral and made every fight pure grind-down; the two-tier economy (chips heal, severs cripple) makes sever-hunting the decisive layer and creates the disengage-to-heal rhythm, exactly where the ship-class review pointed.
Canon amendment: ONLY the player's Core re-knits — everyone else's cores are lesser
It puts the player's Core at the literal center of the power fantasy — the one artifact in the sky that can undo violence — and it keeps fights convergent: the player can attrit an enemy across passes without it healing back, so patience is always rewarded.
THE WEAVE: channeling the Core is a held stance with a cost, and its onset is an event
Passive-only regen is a timer, not a decision; routing the accelerated weave through the reactor makes disengaging-to-heal an ACTIVE choice with a visible cost and a dramatic beginning, in the same resource language as every other player expenditure.
Damage-control UX: focus the weave, see your envelope, read ADRIFT on the target
The physics arc made damage REAL but invisible and unsteerable — the player could lose authority without seeing it, and the weave healed in an arbitrary order nobody could direct; this pass turns the recovery loop into decisions a player can read and make (engines first when adrift is THE beat).
The target lock gets teeth: lock-gated plasma homing + a lead pip
The lock panel was excellent intel bolted to a ritual — Tab did nothing your weapons could feel; homing-on-lock plus the lead pip makes designating a target a real tactical verb that pays off in landed volleys.
One trigger fires the loadout (supersedes the 2026-07-01 split-trigger model)
The split-trigger model shipped 2026-07-01 read as broken in play — the owner armed plasma+laser, held the fire button, and nothing visibly changed ("i turned on plasma and laser but its not shooting"). A toggle that arms a weapon the trigger then ignores is a lie in the UI; one trigger + a loadout hotbar matches the ARPG framing the kit was designed around (enable your kit, hold the button, manage the reactor).
The showcase must exercise every weapon: class-interleaved AI pool + a legible hotbar
"Default run is the showcase" is a tenet — a default encounter that cannot exercise a third of the player's kit is a broken showcase, and a toggle state the owner cannot read in the heat of a fight is not a state indicator.
Visible weapon mounts on the player ship: turrets that track your crosshair
The mounts existed only as data and baked voxels — the player could never SEE their broadside face the enemy or their turrets swing onto a target; tracking heads turn the crosshair into something the ship visibly obeys, which is the whole capital-gunnery fantasy.
Armament is voxels in the pack: gunmetal finish + voxel-scale guns + capital main battery, render bolt-on removed
Ships ARE their cooked voxel packs; a runtime overlay is a parallel geometry system that damage, mass, and per-pack binding can never see. And the voxel grid imposes a minimum feature size: geometry authored below one voxel does not exist after the cook, no matter what color it is — armament must be authored AT voxel scale, in dark steel, or a warship reads as an unarmed liner.
Auto-turrets harass everything (supersedes decision-6's fighters-ONLY gate)
With the fighters-only gate, an armed AUTO slot in a big-ship fight was dead weight — indistinguishable from broken (the exact confusion that opened today's UX thread). Constant low-grade harassment keeps the hull visibly alive and the slot's firing pulse honest, at zero cost to the kill economy because the ballistics never mattered against armor.
Plasma gets its own body: compact violet ball, stubby wake (VFX identity)
A weapon named plasma that draws as a kinetic shell is a broken promise — and the long tail + big head made the player's own secondary read as incoming enemy fire in a furball. Violet also rhymes with the Core's arcane identity (the magic canon's color) without colliding with the enemy-warm or player-cyan lanes.
AI reacts to crippled ships: finish the helpless, go weapons-platform when it is you
The flight-dynamics arc made maneuvering authority real, degradable, and recoverable — but the AI ignored it: pilots thrashed dead controls chasing orbits they could not fly and kept respectful standoff rings around helpless wrecks. Both read as broken the moment a player notices.
The Guns Are Real Now, and the Hull Knows How to Mend
My ship finally wears guns you could shoot clean off her spine, and when I limp clear of the fight and hold the weave, her heart drinks the reactor dry to knit the wounds closed in violet light.
Live mass properties: ShipMassTracker follows damage (flight-dynamics P1)
A ship now keeps honest books on its own remaining matter, so a hull that loses a flank collides and strains like the lighter, lopsided thing it has become.
Damage now reshapes handling: live maneuver-static rebuild (flight-dynamics P2)
Battle damage now changes how a ship flies: lose a flank and it turns lopsided around its new balance point, while a lighter, shot-up hull answers its surviving engines more eagerly — and an undamaged ship flies exactly as it always did.
Flight dynamics direction: handling derives from working RCS, thrusters, and live mass
The model is already half force-based (thruster positions and forces, a torque Jacobian, per-thruster alive fractions, a real anisotropic tensor in collision response), but mass properties freeze at load and authored rate caps mask the physics, so damage never reads in the player's hands. Closing those gaps is an upgrade, not a rewrite.
Canon: the Core is magic; hull matter is woven and can be re-knit (sci-fi meets magic)
One fiction rule now explains and stabilizes a set of previously separate decisions (severed pieces dissolving, core death as total dissolve, the hot-to-arcane color journey, the VFX tech-vs-arcane split, the repair economy in FLIGHT-DYNAMICS-PLAN), and it constrains future features cheaply instead of demanding a magic subsystem.
The Fleet Finally Glows on PC
For weeks PC players could see everything except the ships. Tonight the whole fleet finally drew, and then it caught fire with light.
Solo agents may self-merge worktree→main; the gate is *concurrency*, not worktrees
The rule was written for the parallelizable-by-design case (multiple Agent(isolation: "worktree", …) running at once; the human reconciles to avoid clobbering). It was being mis-applied to *solo* worktree work, forcing a pointless human merge step on a single developer who only used a worktree for isolation — exactly the completion-blocking friction the 2026-06-21 skills audit set out to remove. A lone agent has no one to collide with, so hand-merging its branch is ceremony, not safety.
The Day the Ship Became Mine to Shape, Then Stood Trial
This morning the answer was no. By night you could stand on your own bridge and rebuild your warship in the dark, watch it tear itself down and become yours. Then a panel of pitiless reviewers tore the whole thing open and found twelve wounds I had been quietly taping over.
Ship-ship collision damage — impacts crater + shed chunks, "dramatic but survivable" (owner request; v1 of universal collision)
Collisions were inert — ships bounced as rigid boxes with ZERO damage (the Collision damage type existed but was never emitted). That is both undramatic and tactically dead. Real ships now take a proportionate crater (a 985k-voxel hull shrugs off a ~1.3k-voxel ram-dent at 99.9% hull yet sheds visible chunks; a small/fragile hull can be gutted by a hard ram), which turns ramming + positioning into a real tactic.
VoxelType catalog is the cross-stack material registry (P2a foundation, hash-neutral)
the alternative (a fixed ≤16-row role enum in a single palette byte) right-sized the visual scope but under-modelled the owner's "hundreds-to-thousands of variants + per-ship aggregate stats, no future rewrite" requirement; a 32-bit catalog id costs the same per-voxel (zero) and never needs a format bump to grow. Building the registry FIRST as the contract makes armor/interior/resistance/glow all "assign an id, read its row" instead of N ad-hoc special cases — the strongest answer to silent cross-stack drift.
Armor exterior = hull paint + metallic gleam, steel only on the cut edge (owner decision)
At the fleet's cook resolution the armor rind is the whole 1-cell exterior skin (K=1), so tinting Armor strongly toward gunmetal (the prior pass's RoleTintStrength Armor=0.82) repainted every cooked ship gunmetal and erased its signature hull color — a kestrel no longer read blue. The owner's call: the SIGNATURE COLOR is load-bearing (ship identity at a glance), so it must survive on the unbreached hull; the "this is armored" read comes from the gloss, and the "you can see the plating at the wound" read comes from steel on the cut edge — both without touching the paint. This keeps the cross-section informative (the cake interior already provides breach contrast) AND keeps the fleet recognizable.
A Million Blocks Deep
For months my capital ships were gorgeous hollow shells that faked every wound. This week I deleted the last of them and rebuilt the whole fleet out of solid matter, so now when you punch a hole in one, you are staring straight into its guts.
Pack format v2 + SceneIR→SDF cook contract (P0 of GLB retirement)
I wrote the new ship-file contract and its tamper-evident checksum chain down on paper before touching code, so the migration off the old mesh format has one exact target and the simulation's answer key is allowed to change exactly once, with my sign-off.
GLB retired: ships are voxel-native end to end
the voxel volume is already the render and damage truth; a triangle artifact surviving as cook input, hash anchor, and fallback renderer is a second source of truth I pay to keep in sync on every change. Honest drift I am signing up for at the flag-day: all 10 packs' voxel sets re-source (SDF is not bit-for-bit SAT), the suite baseline moves exactly once with my acknowledgment, and ship radius/mass shift by at most 0.4%/1.1%.
Voxel-render Phase 0 — share FNA3D's SDL_GPU device (the engine fork) + fix a latent FNA3D rebuild bug
Taught the engine to hand our new voxel renderer direct access to the GPU so it can draw ships as true voxel volumes — and fixed a hidden bug that stopped the engine from being rebuilt at all on a current system.
Voxel-render Phase 1 — GPU ray-march proven in the live frame (THE gate, passed)
The game can now draw true ray-marched voxel objects inside the normal scene — they correctly hide behind ships, ships hide behind them, and weapon beams pass in front and behind them properly. The door to Teardown-style voxel ships is open.
Voxel-render Phase 2 — solid materialized 1M-voxel brick volumes per pack (additive, zero sim drift)
Every ship now has a million-voxel solid version of itself, colored exactly as the ship designer painted it — cooked, verified, and stored compactly — ready for the GPU to draw, without touching any of the game's existing simulation guarantees.
Voxel-render Phase 3 — the player ship IS ray-marched voxels (848k-voxel brick volume, GLB parity verified)
The player's capital ship is now drawn as nearly a million tiny cubes, ray-traced live on the GPU — and it looks like the same ship in the same colors, just made of voxels, exactly the Teardown-style goal.
Voxel-render Phase 4 — the whole fleet is ray-marched voxels, and it's FASTER than the mesh path
Every ship in a hundred-ship battle is now made of a million voxels each, drawn by tracing rays — and the game runs at 60 fps, slightly faster than the old way of drawing ships.
Voxel-render Phase 5 — the SceneLighting rig + voxel corner AO + sun-shadow march in the marcher
Voxel ships are now lit by the same sun and studio lights as everything else, every little cube corner self-shades realistically, and the ship's own structure casts soft shadows on itself — the flat toy look is gone.
Voxel-render Phase 6 — REAL destruction: sim damage punches holes through to the cooked interior
Shoot a ship and the cubes are really gone — you see the dark guts of the ship inside the hole, exactly like Teardown. The old fake-dent system can't drift out of sync anymore because there's nothing to keep in sync.
Voxel-render Phase 7 — the flip: ray-marched voxel ships are the DEFAULT showcase
From now on, just running the game gives you the voxel ships — a million cubes each, real holes when shot — with the old renderer kept as a safety net you can switch back to with one setting.
Damage perf-on-hit — baked-distance field + per-vertex 2-pass build + rebuild throttle (render-only)
Getting hit used to freeze the game for a moment while the torn-up hull was rebuilt; now that rebuild is ~6-10x faster and happens far less often, so combat stays smooth.
Readable battle-damage deformation — coherent shared-basin bowl + wall-shading normals (render-only)
Damaged hull now visibly caves in around a breach — a dented bowl of plating that catches light — instead of looking like a flat wall with a clean hole punched through it.
Kill grazing-angle residual see-through — plug the carve↔interior mouth-ring gap (render-only)
from a glancing angle you could still catch a sliver of space through the very edge of a breach; the breach's inner cavity now plugs the opening edge-to-edge and flares inward, so there's always solid dark structure behind the hole.
High-res capture override + see-through verified at 3200×1800 (the "peek-through" was silhouette, not a leak)
Added a way to take much higher-resolution screenshots, used it to zoom way in on the battle-damage breaches, and confirmed you can't actually see through the hull — the bit of background near a breach is just the edge of the ship, not a hole.
Documentation + skill drift sweep — audited all CLAUDE / MCP / charter / schema docs + 23 skills against the live repo (two-workflow audit→fix)
Swept every project doc and skill file for claims that had gone stale as the code changed underneath them — references to a build server that doesn't exist, renamed folders, deleted features still written up as live, out-of-date counts — and fixed 124 of them so the instructions match the actual repo again.
Ship rendering becomes GPU ray-marched voxels (voxels as the single source of truth)
Today a ship has TWO representations — a GLB triangle mesh it renders through, and a separate sim voxel grid that drives gameplay — kept in uneasy sync, with damage *faked* by deforming the triangle mesh to approximate voxel destruction (the recurring see-through / boxy-breach damage bugs are exactly this gap surfacing). Collapsing both onto one voxel representation makes destruction REAL (a hole exists because the voxels are gone, with solid interior behind it, not because triangles were dropped), unifies the pipeline, and unlocks the volumetric look. Teardown proves per-object voxel volumes + in-shader ray-march hold 60 fps on modest hardware; ESVO supplies the hierarchical empty-space-skip and attribute-averaging-for-LOD ideas (we take those, not its octree encoding).
Federation ship family in the generator (family-gated, non-invasive)
Added Star Trek Federation ships to the generator without changing any existing ship — all the new code only runs for the "federation" family.
Federation hardening — fix core zone + RCS, add excelsior variant, completeness test
The first Federation ship looked right but had a mis-placed reactor and thrusters firing the wrong way — the tests caught it, and I reshaped the hull so both the cruiser and the new big explorer pass every check.
Wound heat — fresh breaches glow molten, old scars cool to charcoal (render-only)
Fresh hull breaches now glow hot like just-cut metal and cool to dark charcoal over a few seconds, so you can tell a ship that was just hit from one carrying old wounds.
Debris chunks — fresh impacts knock tumbling wreckage off the hull (render-only)
When a ship takes a hit, chunks of burnt hull now break off and tumble away into space.
Fix textureless damaged hull — wound-heat floor + lighter heat-bleach (render-only)
Badly damaged ships were turning into flat grey blobs; now they stay charred metal that keeps the ship's colour.
Damage proving harness + see-through invariant (tear/deform/stretch gated to a backed interior)
Badly damaged ships had holes you could see space straight through. Now a hole is only ever opened where there's solid interior behind it; everywhere else the plating stays whole and just chars.
Federation (Starfleet) ship family — saucer + warp-nacelle hull type
The fleet was all original wedge / spine / dreadnought silhouettes; a recognizable real-world archetype adds instant-read variety. The "Federation" read lives in the SILHOUETTE (saucer + nacelles), so it survives the project's vibrant-color rule — the hull is a saturated Starfleet azure that clears the HULL_COLOR vibrancy floor rather than the canonical desaturated grey (which the floor would resample to a random vibrant colour).
The Ship I Grew Up Wanting to Command
The silhouette everyone knows now flies in my fleet: a broad saucer, a slim body behind it, two nacelles swept high and glowing blue. I finally built the ship I sat too close to the TV for.
Claude-only consolidation — AGENTS promoted into CLAUDE, agent-agnostic file removed
The project only uses Claude now, so the old generic "AGENTS" instruction files are gone and their contents live directly in the "CLAUDE" files Claude already reads. Nothing about the rules changed — they just live under one name. Old diary/history entries still say "AGENTS" on purpose, because that's what the file was called when they were written.
Dark-end color floor — kill near-black structural albedo on ships
Ship sidepods, vents, fairings and other structure used to be painted nearly pure black, which looked harsh against the bright hull. They're now a readable dark grey-blue instead. Only the paint changed — the ship shapes are byte-for-byte identical, so the game's determinism checks are untouched. The deep shadows tucked between the tiny surface details are still dark, but that's real 3D shadow, not paint.
Wound smoke — lighter + PS1 screen-door dither (see-through, tasteful)
Battle smoke used to be a thick grey cloud that covered the ship. Now it's a light, retro dot-stipple haze (PS1-style) you can see the ship through.
The Fleet Got Its Colors
For weeks my whole fleet was the same grey smear. Then I went loud, and a battle line of rival houses came up out of the fog: steel blue, deep violet, and a dreadnought the color of old blood.
Voxel-driven mesh-deformation damage renderer (per-cluster wounds, render-only)
Battle damage is now built by bending and tearing the ship's actual surface around where it lost material, with each separate hit becoming its own torn, charred, glowing wound, instead of stamping square holes on a grid.
Ship battle damage tears the hull open (epic capital-ship wounds)
the prior attempts read as cheap because the torn edges snapped to the ship's blocky internal grid (square holes); I had my agents drive the wound shape off the visible hull surface instead, with the internals only deciding where and how big. Damage finally looks like a wound, not a missing-block bug.
The Hull Tears Open
For weeks my ships died on the inside while the outside stayed perfect. Tonight the armor finally tears open where the shot lands, glowing at the rim, the ship's bones showing through the dark.
Performance & Scale pass — 100 ships as the comfortable case (caps, pooling, registries, LOD, perf gate)
I measured first and found the game already runs 100 ships smoothly — so instead of chasing speed I fixed the things that quietly broke or got messy AT scale: every ship now has thrusters (not just the first 32), big battles show many beams (not 8), the asteroid belt and turret-aim stop wasting work, loading 100 unique ships allocates 396MB less, distant ships use a cheaper body that looks identical, and adding new systems/renderers is now a one-line register. A new automated gate guards the speed numbers so they can't quietly regress, and I re-checked the determinism hashes and the on-screen pixels myself after every step.
Upgrade FNA and StarGazer to.NET 10 LTS
I updated the game engine and its build tools to run on the latest long-term support version of the software framework.
Harden docs against two verification gotchas (voxel-suite cwd, launchctl env-strip)
I wrote down two easy-to-trip traps so future-me (or an agent) doesn't fall into them again: always run the determinism test from inside the game/ folder (a crash there means wrong folder, not a missing file — don't "fix" it by regenerating the file), and remember that the game launcher drops any custom env switch you didn't explicitly wire through.
Visual verification is a ship requirement — catalogued visual-test suite, equal weight to determinism
I built a proper test area for "does it look right on screen". For each visual feature there's now a saved test that puts a single ship in a fixed camera view and triggers the feature (e.g. fire each thruster direction), takes a labelled screenshot, and writes down exactly what to check. The feature isn't "done" until someone has actually looked at that screenshot and confirmed it — the same bar the determinism hash checks already hold.
Input layer plus the camera-mirror fix for inverted controls
The ship was steering backwards because the camera sits behind it and flips left and right on screen, while the controls had been set up for the opposite view. I proved which way each control really turns the ship, corrected them, and rebuilt the control system so keys and a gamepad both run through one place that decides direction, with a test that fails if anyone ever flips it again.
FNA fix #1 — SpriteBatch delivers MatrixTransform to custom effects
A long-standing engine-side bug silently dropped sprite-pipeline shaders we wrote ourselves: the rendering library only handed the screen-mapping math to its built-in shader, so a custom shader saw zeros and quietly drew nothing. I fixed the library so it now hands the same math to a custom shader too, and proved it with a deliberate magenta test that was invisible before the fix and floods the whole screen after.
FNA campaign foundation — build-fna3d + first locally-rebuilt libFNA3D.0.dylib
Up to today our shipped FNA3D binary came from an upstream CI farm. Now we have a one-command script that rebuilds the same binary locally from our own source tree, plus a doc explaining how to do it on each operating system. I ran it to prove it works, replaced the old binary with the new one, and confirmed the game still launches cleanly on macOS. The two FNA C-level fixes left in the campaign are now unblocked.
FNA fix #3 prep — Metal fp16 sceneTarget bug NO LONGER REPRODUCES on M4 (H1 disproven, FNA3D edit not landed)
I added a one-line switch so I can flip the in-game render into a higher-quality color space and look for an old rendering bug. When I tested it on my current Mac the bug did not happen, even on the exact same rendering library that originally hit it months ago. So I am not changing the rendering library yet, because there is no live bug for the change to fix. The switch stays in case the bug shows up again.
Debug HUD overlay refactored into a lower-right collapsible widget
I moved the live debug stats panel into a small collapsible tab pinned to the lower-right corner. The default view is now uncluttered, just a single tiny toggle button. Click it (or press the tilde key) and the stats grow upward from the corner so they don't fight the gameplay area. Saved screenshots still carry the stats automatically for analysis.
A heavy camera for a heavy ship (decouple position from aim)
the current camera is a pure function of the current frame (it snaps every tick with no memory), so every cue of mass is structurally impossible and a 100m warship reads as a 1m toy. Making the camera a spring the ship's motion drives is the one change that unlocks scale, heft, and power at once.
The Day I Lit the Whole Sky
For weeks my ship sailed through a darkness it carried with it, until one switch finally lit the whole sky and the hull became something worth flying.
Five Days in the Chair: The Bridge Starts to Feel Real
Five nights of work in the captain's chair: the ship learns to wheel in three dimensions, the guns trade a cheat-beam for honest steel, and the cockpit finally looks like an instrument I trust.
Whole-pipeline scaling audit — the per-voxel component-kind spine is dead; standardize on geometric footprints instead
The shipyard is great at adding new looks but was quietly broken at adding new *functions*. The code that's supposed to notice "this ship's guns are shot up, stop firing" never actually runs, because the information about which blocks are guns gets thrown away when a ship loads. The steering jets don't have this problem — they figure out their blocks by location instead. The proposal is to make everything work the way the jets already do, which also makes adding brand-new systems (sensors, shields) cheap and means we never have to rebuild old ships when we add a new kind.
Scaling-audit NOW follow-through — prow dedup, coverage/parity gates, longbow bridge + fleet completeness gate
Added automatic checks that catch a few ways the ship factory could quietly break — a menu option with nothing behind it, two copies of the same list drifting apart, or a saved ship missing a required part. Also gave the longbow a bridge (it didn't have one) and made the fleet health-check run every time, not just when asked.
Weapons Phase 7 — 3D AI spatial tactics (PitchReacquire / PlaneBreak / BowBias) default-disabled in the live sim
New AI behaviors landed — diving above or below the enemy's heavy-gun plane, attacking the stern blind spot, and pointing the bow at the target if the ship has a spinal cannon — but they're all OFF in the normal game so saved fights play identically. You turn each one on with a command-line flag for testing. The behaviors plug into the existing turning controller instead of growing a new one, so future-us has one place to tune steering, not three.
Spatial-combat layer — 3D firing arcs, computed hull-wide coverage, and roll-to-tank fresh-face armor
the fight is mathematically 3D but plays flat, every procedural ship covers every face identically, and a wounded capital ship has no way to turn its scars away — the exact 2D-collapse the research catalogues. The voxel hull makes face-tanking *mechanically real* (damage is location-specific) rather than cosmetic, which is a StarGazer-native differentiator.
Kill the center-to-center laser; replace it with a projectile-based capital-ship arsenal
The laser fails every pillar at once — no WEIGHT (instant, no lead/dodge/telegraph), damage is a shape-blind blob not a SYSTEMIC story, every hotbar slot is the same non-DECISION, and center-to-center fire ignores muzzle geometry so THE SHIP ISN'T THE CHARACTER. It's also the performance villain: the radius-2 cube destroys ~125 voxels and triggers a full-ship topology BFS per damage tick. Projectile travel-time is the single precondition for nearly all the counterplay (leading, dodging, interception, bearing-prediction) that eight research domains — naval doctrine, hard-sci-fi sims, capital RTS/4X, ship-builders, space-sim damage triangles, sci-fi fiction, weapon-variety design theory, voxel-damage mechanics — independently converge on. The energy fantasy survives louder in three earned places (EMP disruptor set-piece, torpedo drive trail, muzzle-charge telegraph): the laser fantasy was never the beam, it was light crossing space and meaning something when it arrives.
3D AI spatial tactics — diving the plane, attacking the stern, and presenting the bow
the broadside/spinal weapon redesign promised a fight where positioning was a real decision — attacker wants bow-on, defender wants side-on, the incompatibility *is* the gameplay. Without these tactics the AI plays both roles flat: a broadside ship has no reason to fear vertical evasion, and a (future) spinal ship would orbit broadside-on like a normal ship and never present its bow. Three behaviors close the gap at the cheapest possible price: each adds one verb the existing controller already had a setpoint for, no new control surface.
A Hundred-Meter Ship, Wheeling In The Dark
It used to fake its turns. Now the ship fires real jets against its own weight, vents cold gas you can read, and you can shoot those jets to pin it.
Remove the visual damage system (Phase 0 of the rebuild)
I stripped out the old visible battle-damage system entirely so I could rebuild it fresh, which for now means ships take hits without yet showing the wounds.
Maneuvering thrusters: full deterministic force/torque rigid-body model
I chose the most believable approach for ship movement: thrusters pushing against a ship's real mass, so the drama of a crippled ship spinning or losing control comes naturally from the physics rather than being faked.
Maneuvering thrusters Phase 1: clean unified thruster record + committed fleet manifest + full re-export
I cleaned up how every ship's jets are described into one tidy, consistent format and wrote down each ship's recipe in one place, so the fleet stops drifting out of sync as the game grows.
Maneuvering thrusters Phase 2: load-time thruster derivation (footprint, jacobian, inertia/COM)
I taught the game to work out each ship's balance point, weight, and where its jets push from the moment it loads, laying the groundwork for the new weighty, physics-driven steering.
Regenerate _test_materials fixture; user-approved voxel-suite baseline bump
I fixed a broken internal test that had been crashing on startup and silently skipped for two updates, so the safety checks that confirm ships behave consistently are running again and all of them pass.
Maneuvering thrusters Phase 3: force/torque integrator, capability gating, AI PD retune
Ships now move by firing real jets that push against their own weight, so when battle damage knocks out part of a ship its handling drifts and degrades on its own instead of following a script.
Maneuvering thrusters Phase 4: thruster VFX fire on command, not on speed
A ship's steering jets now light up the moment they fire, even when it is turning in place or starting from a standstill, so what you see on screen matches what the ship is actually doing.
Thruster plume size by role (not strength) + emissive hot core
The little steering jets were drawing as big as the main engines; now each jet is sized to the thruster it comes from (small for steering, large for the main drive) and glows with a hot bright centre so even the small ones read as real thrusters.
Maneuvering thrusters Phase 5: dramatic plume (glow + vent particles + onset punch + shimmer)
Firing a thruster now glows, vents a puff of gas, and punches bright on a fresh maneuver, so a hard turn or a main-drive burn looks like a ship lighting its engines.
Thruster VFX fixes: roll-plume X-bridge + main drive tracks the throttle setpoint
The steering jets now light on the correct side when you roll, and the main engines glow as bright as the throttle is set, easing off as you ease the throttle down.
Coordinate unification — one right-handed +X-starboard ship frame (root-cause fix for the mirrored-jet bug class)
The ship models were being built mirror-image of the way the physics thought about them, and the code papered over the difference axis-by-axis — getting yaw right but roll wrong, so rolling fired the wrong thrusters. Now the models and the physics agree on left and right, so the steering jets always fire on the side that matches the turn, and that whole family of left/right bugs simply can't happen again.
Full 6-DOF RCS thrusters + completeness gate + A/D-turn rebind
Every ship was missing half its little steering jets — it could slide right but not left, drop but not rise, and couldn't back up. Now each thruster pod has a full set of nozzles facing all six ways, so ships can move and turn freely in every direction, and a new automatic check fails the build if any ship is ever missing a direction again.
Maneuvering feel — flip yaw/strafe input signs + reverse retro plume at full intensity
Turning and strafing left/right were backwards on screen, and the reverse jets were firing so faintly you couldn't see them. Now the left/right keys match the screen and reversing lights the front jets brightly.
Ship-completeness fuzz suite — 100 generated ships vs the minimum-parts contract every run
Instead of checking only the eight ships we keep around, this builds a hundred brand-new random ships every time it runs and makes sure each one actually has everything a warship needs — steering jets that can push it every direction, weapons that are properly mounted, a bridge, and a solid single-piece hull with one core in a sensible spot. It deliberately also builds a couple of broken ships to prove the test can still tell when something's missing.
Strip the visual damage system to rebuild it fresh (Phase 0)
The iterative wound visuals (beveled cut cross-sections, molten rims, layered interior detail) had grown into a complex render path that still wasn't landing the look I wanted, and each tweak fought the existing geometry. It's cheaper to delete it wholesale and design the next system against a pristine codebase than to keep patching. This is Phase 0 — clean ground before the rebuild.
Neutral "NASA/ISS footage" lighting baseline
The player wants a neutral, non-stylized foundation matching real spacecraft footage to build the next visual era on. The old colored 3-point rig + colorful nebula/galaxy vista read as space opera, not NASA footage. A neutral baseline is a stable starting point; stylization can be layered back per-scene later.
Grey procedural asteroid field (clustered belt)
The old field read as colorful random rocks (ice/copper/gold + amber/cyan beacon glows) lit by the pre-neutral colored 3-light rig — out of step with the new NASA/ISS baseline and the player's ask for grey, asteroid-ish rocks that are "far and distributed like asteroid fields, not just random rocks in space."
Maneuvering thrusters: destructible 6-DOF RCS that physically drives turning
I want capital ships to feel like a mass you conduct, where you read an enemy's next move from the puffs blooming along its hull and "shoot its thrusters to pin it" is a real tactic, not a stat tweak.
Tighten 10 skills with mandatory proof artifacts or ask-user fallbacks
I tightened my own development checklists so that every step which used to rest on just eyeballing the result now demands real proof, guarding against bugs slipping through unnoticed.
Split Game1 (1689 LOC god-class) into StarGazerGame partial-class file map
I broke up one enormous tangled chunk of the game's core into clearly named, bite-sized pieces, so it is far easier to find and fix the part that controls any given behavior.
Partial fix to skill-tightening: relax visual-eval verbatim-quote, standardize ask-user wording
I loosened some of my own self-imposed review rules that were demanding busywork for tiny changes, so the checks I keep stay focused on catching real problems instead of producing empty paperwork.
Add verify-fleet one-command end-to-end fleet verification
I built a single command that runs every check on the fleet of ships at once and writes up a clean report, turning what used to be ten minutes of poking around into a quick glance to confirm nothing broke.
Extract StarGazerGame.Scenario partial, single owner for scenario reset cluster
I reorganized the behind-the-scenes wiring that resets a battle scenario into one tidy place, so changing how a fight restarts stays simple and predictable as the game grows.
Phase 2 of 6-DOF refactor, swap ShipControlState to quaternion + ship-local angular velocity (baseline drift [hash] → [hash], benign FP noise)
I rebuilt how a ship's orientation is stored under the hood so it can later turn freely in all directions without the math breaking, and confirmed the change does not alter how anything actually plays.
Phase 3 of 6-DOF refactor — wire PitchAxis + ToggleFlightAssist; direct quaternion integration (determinism baseline unchanged)
Ships can now pitch their nose up and down as a true third turning direction, so you can fly and aim freely in full three dimensions without the controls locking up when looking straight up or down.
On-screen ACES tonemap fixed + enabled by default via fullscreen-triangle + sRGB-decode composite ("cheap path"); full linear-HDR pipeline shelved
I got the cinematic film-style color grading working and turned it on by default after it had quietly been doing nothing, giving the whole game a richer, more filmic look without having to redo every scene's lighting.
Damage shell binds per-primitive PBR materials (one indexed draw run per material)
A damaged ship's surviving hull now keeps its original surface look instead of turning into one flat dull color, so a battered ship still looks like itself where it has not been hit.
Damage rebuild — ship Phase A+B; defer wound-aesthetic phases to interactive/MCP verification
I brought visible battle scars back to ships and added a glowing-breach foundation, then deliberately stopped short of the fancier torn-edge and debris effects because I could not reliably confirm they looked right yet, and I refuse to ship visuals I have not actually seen working.
Re-enable visible battle damage by default
The player asked for capital-ship battle damage back. It was disabled 2026-05-25 only because the damage shell looked muted; now that the shell binds per-primitive PBR materials, a damaged ship's surviving hull matches its pristine self, so re-enabling no longer regresses the showcase.
I Lost A Morning To A See-Through Ship
From the back, my warship was a ghost. Engines hanging in the dark with nothing behind them. Three wrong fixes later, the real culprit was hiding where I never thought to look.
Skills migrated from to; lint script enforces the path
I moved my collection of helper guides into the folder where they get picked up automatically, so they are always available to assist instead of sometimes going unseen.
The Day I Could Finally Whisper To The Living Ship
Tuning the ship used to mean stopping the world, changing one number, and waiting to see it again. Now I reach into the ship while it is still flying, turn the dial, and watch it answer in the same breath.
Diverged-main sync policy: rebase the trivial cases, surface the messy ones
I set rules for safely merging my work when two copies of the project have drifted apart: the obvious cases get reconciled automatically, while the risky tangled ones stop and wait for me, so no work gets destroyed.
Add stargazer-verify-determinism skill +.gitattributes LF-pin for hash-bound fixtures + defer stargazer-schema-contract
I fixed a Windows quirk that was silently corrupting ship data files and added an automatic guard that flags any unintended change to how ships are shaped, before it can sneak into the game.
Ship pipeline phases L→F→G: shipyard cooks voxels, game stops cooking at load
I moved the heavy work of turning a ship's 3D model into its solid blocky form out of game startup and into the build step, so ships load noticeably faster and look the same on every platform.
Ship pipeline Phase I followup: multi-stage shipyard.Dockerfile + digest-pinned cook-base + cross-platform byte-determinism verified
I proved that ships now come out byte-for-byte identical whether they are built on a Mac or on a Windows machine, so every player sees exactly the same ship no matter the computer it was made on.
Close out 3 deferred ship-pipeline items: schema canonical-cook CI gate + oracle threshold calibration +.last-hash Mac bump
I locked down the ship-building pipeline so that any change to how ships are shaped from their models has to be deliberately acknowledged, preventing quiet drift in the final result.
Skill overhaul: fix daily-blog, add data/asset/combat verification skills, add [flag]/[flag], extend determinism gate to physics
I expanded my toolkit of automatic checks to cover the ship numbers, combat, and physics that were previously unguarded, catching the kind of silent breakage that once shipped a glaringly pink ship without anyone noticing.
Unified capital-ship reactor core (Singularity Forge)
The previous quantum_sphere focal was undersized (around 0.6m on a 72m ship), the four-style split meant no ship felt iconic, and the connectivity-slide pass kept burying it inside the hull. The replacement lands at 1.05m on an 18m gunship and 4m on a 72m dreadnought, and the spine yoke gives the shell guaranteed OBB-overlap with the rib frames so connectivity is satisfied without any sliding. The anchor leaves around 78 percent of the surface exposed above the hull silhouette, which supports the "the core is your exposed kill target, defend it" fantasy. The validator passes 8 out of 8 randomized ships at 82 to 100 percent exposure (it was failing-by-burial on most before).
Singularity Forge v2: midline-centred, 20% cap, hex+multi-band
v1 floated above the hull instead of sitting in the gap, had no diameter ceiling (I was seeing 8m orbs on 72m dreadnoughts), and read as a saturated white emissive ball with no surface structure. With v2 I inverted the contrast strategy to bright shell with dark cladding, so the hex pattern and the bands read as silhouette structure at every zoom. I directed a multi-agent parallel review across 30 renders (6 ship families across 5 angles), and it confirmed that v2-iter3 reads as "a contained hex-panelled reactor cell on the centreline" on every family.
I Wanted Every Ship To Share One Heart
Every capital ship now carries the same glowing core at its centerline. One shape to learn, every hull. The day I gave the whole fleet one heart.
Phase 5b kinematic chain: 3-phase render-side aim path
A ship's turrets now physically swivel to track the nearest enemy within their real swing limits, instead of being painted on, so the ship visibly looks alive and aimed in battle.
StarUI Zero-Allocation Responsive UI Framework
I built a custom interface system for the heads-up display that never stops to clean up memory mid-frame, which is what keeps the game running smoothly even on a handheld.
Wound clusterer: O(n²) all-pairs → O(n) cell-indexed BFS
I rewrote how the game groups a cluster of damage into a single wound so it stays fast even when a weapon carves out a large area, keeping the frame rate steady in sustained fights.
DamageVisualHistory skips clean chunks instead of full 21k-voxel walk
When a ship takes a hit, the game now only re-examines the small region that was actually damaged instead of rechecking the whole hull, cutting a big chunk of wasted work during heavy combat.
KinematicAimSystem.BuildDeltaLookup reuses caller-owned Dictionary
I stopped the game from throwing away and rebuilding a chunk of memory for every ship on every frame, which keeps the action smooth even with lots of ships on screen.
Gameplay loop phase 2: 9-slot hotbar UI + scenario keys move to F1/F2/F3
I added a row of nine numbered ability slots along the bottom of the screen, the place where the player's powers will live, and moved the battle-scenario shortcuts up to the function keys to make room.
Enforce voxel core placement zone and exposure constraints
Every ship is now checked to make sure its vulnerable core sits in a sensible spot and stays exposed enough to actually be shot, so the targeting-the-weak-point fight always works as intended.
StarUI Responsive HUD Button Panel and Command Routing
Decoupled, addressable UI trees make every UI feature reachable visually AND programmatically. That meets my tenet that external AI agents can query UI state via JSON dumps and execute path-addressable button triggers (e.g. /hud/buttonpanel/reset-battle), which keeps test automation fast and direct.
Majestic Dawn Logo Color Swap
I wanted a gold background with navy lines and details for a high-contrast, vibrant look.
Update Native Game Icons with Refined Logo
I wanted the refined Majestic Dawn logo in the game shell too. Updating the raw SVG and the compiled binaries together ensures the executable shows the gold-background, navy-lines branding on Windows and macOS windows, the dock, and the file explorer.
Require core visibility and longitudinal zoning on ship hulls
I want every ship to have a core that is visible, accessible, and shootable. Targeting the core is a primary combat mechanic, so if the core can hide buried in the middle of the hull, the whole tactical loop collapses. The three longitudinal zones also help players read silhouettes quickly.
Monorepo: four-stack + standard library, one repo
I'm a solo dev, and polyrepo discipline was costing me time without buying anything. A shared schema/ subdir plus CI cross-validation kills the silent contract drift that motivated the integration plan in the first place.
Two Quiet Calls About Where the Work Lives
I decided the guns point themselves where you can see them, and the menu never begs for more memory mid-fight. Both calls protect one thing: a big ship running on a small machine.
Share interactive combat launch defaults
I tidied up the default fight you drop into so the ships actually square off and trade laser fire, with longer, more visible beam pulses, instead of drifting out of range before anything happens.
Default Program camera to Orbit
Launching the game now drops you straight into an orbiting camera that circles the action, so a normal play session and a captured snapshot start from the same vantage point.
Default Program voxel view to mesh damage
When a ship gets hit, you now actually see the hull tear open by default, and I shrank the size of each hit so battles chip away at a ship instead of blowing huge chunks off too fast.
Keep default render systems enabled
The game now switches on all its stable visual effects (like the glowing energy shields around ships) by default, so a normal launch shows the game at its best unless something is deliberately turned off.
Tune beam damage as direct hits plus splash
I retuned weapon beams so a hit destroys the spot it strikes and only lightly chips the surrounding area, fixing a problem where ships were being blown almost completely apart and vanishing after just a few shots.
Run live apphost as one-shot LaunchAgent
I changed how the game launches in the background during automated testing so it reliably starts once and stays up, instead of either being killed early or stubbornly relaunching itself after I close it.
Keep broadside orbit steering in AiPilotSystem
The logic that makes enemy ships circle and align for broadside attacks now lives squarely with the rest of the combat behavior, keeping their orbiting and aiming consistent and easy to find.
Default voxel debug to translucent overlay
I set the default debugging view to show ship damage as a see-through overlay so the visible hull, the underlying structure, and the width of incoming beams all line up correctly when checking how a battle looks.
Plan damage rendering as derived render meshes
I decided detailed ship damage would be handled purely as a visual layer built on top of the simulation, so the wounds can look rich and cinematic without ever changing what the game considers truly destroyed.
Add retained wound history to damage plan
The damage system now remembers a wound's shape even after the shattered pieces drift away, so a dramatic gash keeps its torn edges, interior decks, smoke, and sparks instead of healing over once the debris is gone.
Build first retained damage renderer slice
I built the first version of the system that renders battle damage as layered wreckage you can see into, while the underlying simulation still treats the ship's structure as the single source of truth for what is actually destroyed.
Aggregate damage wound across chunks, cull interior-poking GLB
Battle wounds now form as one clean carved-open breach instead of a blocky grid of dark squares, and stray bits of the ship can no longer poke through the hole from the inside, giving each wound a deliberately crafted look.
Remove energy shields from the universe
I removed energy shields from the game entirely, because a glowing protective bubble would hide the very battle scars the game is built to show off, so combat reads purely through armor wear and ships physically breaking apart.
Gate full structural wound on cluster size; tiny hits scorch only
Now only real, sizeable hits tear open a ship's hull with a proper jagged cavity, while tiny grazing shots just leave a hot scorch mark, fixing an earlier glitch where small hits sprouted floating black squares instead of believable damage.
Default launch is an AI-vs-AI RTS battle with damage on the selected ship
Launching the game now drops you straight into a six-ship computer-versus-computer fleet brawl seen from a high overhead view, with one ship shown in full battle-damaged detail, so the default experience is a watchable showcase of ships tearing each other apart.
In-game HUD buttons for reset + runtime scenario switching
I added a clickable button panel in the corner of the screen so you can restart a battle, flip through ships and camera angles, switch between fight scenarios, and toggle damage effects on the fly, without having to quit and relaunch the game with different settings.
Voxel state is the truth for visual feedback, not the physics OBB
Set a firm rule that anything a player sees touching a ship (a beam's end, an impact spot) is placed at the true point on the hull, so weapon glows land flush against the ship instead of floating in empty space beside it.
Ship contact normal + point routed through voxel raycast
When two ships collide, the game now figures out the exact spot on the hull where they touched rather than guessing the rough center, so contact effects land where the ships actually meet.
Coalesce shell triangle draws into one per-ship buffer
Rebuilt how a damaged ship's surface is drawn so the whole hull goes to the screen in one efficient pass instead of thousands of tiny ones, restoring a smooth sixty frames per second during fights with several ships on screen.
Defer voxel topology BFS to end-of-batch
Reworked how the game recalculates a ship breaking apart after a hit, doing the heavy check once per volley instead of once per shattered chunk, which keeps the game smooth at sixty frames per second even mid-battle instead of stuttering with each beam strike.
Honor glTF PBR materials on ship draw
Ships now keep the colors, metal sheen, and glowing accents their artist gave them when they appear in the game, so a custom ship looks like itself instead of being repainted a single flat faction color.
Read KHR_materials_emissive_strength from raw GLB JSON chunk
Now reads how strongly a ship's lights and engine glows should shine from the standard place any 3D art tool writes it, so glowing parts keep their intended intensity instead of dimming to a flat default.
Revert emissive strength to material.extras["strength"]
Switched to reading the brightness of a ship's glowing parts (like engine flares) from a simpler, reliably written value, so authored glow intensity comes through correctly with less fragile machinery behind it.
DamageableGlbMeshAsset multi-primitive, retains node identity
The system that builds a damageable ship can now read a ship made of many separate pieces instead of just one, so the detailed new ships hold together and show their full shape rather than appearing as a single stray sliver.
GlbVoxelTriangle carries NodeName
Ships now carry the original name of each part of their body (engine, weapon, and so on) through the building process, so the game can later treat a thruster as a thruster and a gun mount as a gun mount based on what the artist actually labeled it, instead of guessing from shape.
Automated frame sequence capture and GIF compiler pipeline
I added a way to automatically record a smooth run of gameplay and stitch it into a short clip, so highlight reels like explosions and maneuvers can be captured for the dev blog without manual screen recording.
Default launch is single-ship Dreadnought-style + hull binds GLB material
I made the game open straight into a close-up duel between your capital ship and one enemy, and removed a color tint that had been masking each ship's true paint, so ships now show their real materials and tell friend from foe through the interface instead.
ShipPackSidecarReader implements the ninja-blender ship-pack v1.0 contract
The game now reads the new richer ship files and refuses to load any that have been tampered with or half-written, so a corrupted ship is caught immediately rather than glitching later.
Migrate default ship path to
I switched the default ship over to the new, far more detailed version built by my ship-maker tool, while still falling back to the old plain one if the new files are missing.
Start the default run in combat
The current playable slice is about proving voxel and GLB combat, so the first window should show enemy engagement without requiring hidden scenario flags or perfect timing.
Make run launch orbit combat
My "run" loop should land me directly in the playable test surface, not force me to remember hidden flags or press Tab before camera input works.
Show voxel damage through the GLB by default
Voxels are intentionally invisible gameplay truth, but the normal playtest view has to show their effects, otherwise combat looks like lasers hitting an indestructible model.
Treat default run as the showcase
My run loop is the product review surface. Hiding effects behind flags makes features look broken or absent when I (or anyone else) glance at the game.
Make lasers scar before they sever
Capital ship damage should read as progressive hull punishment. When the ship just disappears after a few hits it feels like a render bug, even when the voxel topology is technically obeying core ownership.
Make enemy broadsides orbit the player
Moving the firing origin spreads laser hits across the voxel and GLB damage surface, and it makes the encounter feel like two capital ships maneuvering around each other.
Show voxel truth over the GLB in default combat
To playtest the voxel damage cornerstone I need the authored ship and the underlying damage grid visible together. The oversized lasers were making hits look wider than the damage they were applying.
Replace triangle deletion with authored wound rendering
Capital-ship damage needs to expose structure and battle scars, not look like missing GLB triangles. The full reviewed plan is in SHIP-DAMAGE-RENDERING-PLAN.
Treat breaches as capital-ship interiors
A capital ship breach should read as a huge layered vessel being torn open, not as a GLB shell with missing faces or flat caps.
Use layered wreckage as the damage bar
I want the damage cornerstone to feel like a huge ship being gutted, not like a debug mesh disappearing. The working art bible is DAMAGE-VFX-ART-BIBLE.
Honor glTF PBR materials by mapping onto BasicEffect (v1, no custom shader)
I need external authors (ninja-blender) to author per-part colors, metallic distribution, roughness, and emissive engine glows, and have the in-game ship match the source preview's color identity. The renderer was throwing every material away and re-tinting per faction (cool steel for the player, warm copper for the AI), so two visually-distinct authored ships read the same in-game. The "color identity matches" plus "engines glow" goals only require per-part color, per-part specular character, and per-part emissive, none of which need a custom shader.
Tonemap target: ACES filmic at exposure 1.0
The ninja-blender web preview uses THREE.ACESFilmicToneMapping with exposure 1.0. Matching the tonemap end-to-end means the per-part baseColor and emissive values authored in Blender will read the **same shade** in StarGazer as in the source preview. Without it, a red-orange engine glow can read pink-white because the shoulder curve differs. Tonemap choice has more visible impact on "does this ship look like its preview" than BRDF choice does, so picking the matching one closes the biggest source-of-truth gap.
Tonemap target: AGX (supersedes ACES choice)
AGX preserves bright chromatic edges around stars and thrusters better than ACES, and that matters for a space-combat game where every visible HDR source (engines, beams, suns) sits over a dark background and the tonemap shoulder decides whether they "bloom and bleed" or "clip to a flat hot ring." That was the original analysis in the render architecture entry. The brief deviation toward ACES was driven by ninja-blender's preview using ACES, but matching the planned architecture beats matching one external preview.
v1 IBL stand-in: asymptotic raise-the-blacks emissive lift
Bare PBR through BasicEffect renders the literal product of baseColor * directLighting, and for a baseColor authored to expect environment-map bounce (which is what every modern ship tool does, including ninja-blender's Three studio HDRI), the missing bounce leaves dark hulls reading pure black. My first reaction on dotnet run was "why is the ship so dark?", and the math confirmed it is authored that dark on purpose, expecting IBL to lift it. The (1 - baseColor) * k curve is the "raise the blacks" component of any HDR or tonemap workflow, max lift to surfaces with minimum direct-light response, zero lift to already-bright ones. That matches the qualitative behavior of an IBL irradiance map without requiring the cubemap or the shader pipeline.
Trust contrast: tiny IBL floor + brighter key lights (supersedes the k=0.25 lift)
The k=0.25 lift was the wrong knob. For ninja-blender's baseColor (linear ~0.014), a 0.25 emissive add is roughly a 17x boost, which paints near-grey over near-black and erases the "dark hull" identity. The right principle, per the feedback I got, is "accept that dark materials render dark in shadow, raise the key-light intensity, trust the contrast." With the bright key, lit faces read at 30 to 35 percent sRGB (dark but structured), shadow faces read at around 5 percent (truly dark, matches SceneIR), and metallic spec hot spots punch at around 60 percent because they reflect the bright key and fill, not the dark base.
Configure interactive combat launch defaults and broadside AI behavior
Grouping the combat parameters under a central defaults registry gives me consistent, predictable scenario initialization. The broadside-hold pilot keeps weapon alignment for high-fidelity combat feedback.
Guts And Glow
The first day damage stopped looking like deletion and started looking like a wound. Armor peels, ribs show, and the enemy has learned to circle.
I Decided Damage Should Open The Hull, Not Erase It
When a beam lands on a capital ship, the cheap thing is for the wound to vanish. The right thing is for the ship to come open. Today it came open.
Canonicalize agent skills and split solo-main from worktree-branch commits
I gave my helper assistants one clear home for their instructions and kept my own solo work separate from work running in parallel, so different streams of effort no longer step on each other.
Add world grid and scripted thrust for movement captures
I added a fixed grid in space and a way to drive a ship along a set path automatically, so I can capture the exact same movement shot every time and judge whether motion looks right.
Camera is lightweight render-side state with CLI modes
I kept the camera as a light, easy-to-script viewing tool separate from the simulation, with a default follow mode and exact preset shots, so I can frame screenshots quickly without complicating the game's core or adding heavy machinery.
Orbit camera remains render-side and scriptable
The orbit-around-a-ship inspection view lives purely on the viewing side, steered by keyboard or gamepad and repeatable from exact angles, so studying a ship never disturbs the actual simulation.
Camera default far clip keeps 10x space headroom
I pushed the camera's view distance ten times farther by default so it won't clip away ships and scenery while I orbit around to inspect them, giving the wide open feel that space scenes need.
Engine systems use findable ownership boundaries
I broke the game's inner workings into clearly named pieces by job, so it's easy to find and grow the camera, controls, visuals, or flight without behavior leaking messily across everything.
Ship visual forward is world +Z
Until ships could rotate, I locked in which way counts as forward and right for the default ship so the movement keys actually push it the way it looks like it should go, fixing controls that had felt backward.
Ship motion starts as assisted Newtonian velocity
Ships drift with real space-like momentum: thrust builds up speed, there's a top speed, they coast freely when you let off, and a brake assist helps you stop, giving flight weight without going full orbital-physics.
Make thrust follow ship yaw
Thrust now pushes in whatever direction the ship's nose is pointing, so its momentum follows where the bow faces instead of always shoving in a fixed world direction.
Keep vertical thrust on Shift
I set the controls so holding Shift thrusts the ship upward and Space acts as a brake, which feels more natural since Space reads like a deliberate stop and Shift is easy to hold alongside the movement keys.
Add target dummy instrumentation before weapons
Before adding real weapons I gave ships a practice target plus on-screen guide lines showing heading, speed, distance, and direction to the mark, so I could fine-tune how flying and lining up a shot feels.
Kill stale game instances before launching
I made it a rule to always shut down any leftover copies of the game before starting a fresh one, so stray hidden windows can't pile up and muddy my testing.
Roll joins ship-local orientation
Ships can now roll, banking around the line their nose points down, and that roll actually affects how they thrust and fight rather than just tilting the picture.
Ship physics has a named sim system
I gathered everything about how a ship moves, turns, and slows into one clear home, so tuning the feel of flight is a single obvious place to work instead of scattered through the whole simulation.
Roll basis matches rendered ship roll
When a ship rolls, the invisible guides I use for its weapons and steering now tilt the same way the ship visibly does, so what I see and what the game thinks are happening finally agree.
Coordinate conventions get a project skill
I set a standing rule that any work touching how ships are aimed, turned, positioned, or how the camera sees them has to first sort out which way is up, so the game's directions stop drifting into a tangle of opposite-facing fixes.
Keep AGENTS as the instruction source
I settled on a single master instruction file for the project, with everything else just pointing back to it, so the guidance my various helpers follow never drifts out of sync.
Plan BEPU-backed body physics
I wrote down the plan for handling large numbers of colliding space objects with a real physics engine, kept walled off behind my own code so the game stays organized and runs well everywhere.
Extend physics plan for modules and constraints
I expanded the physics plan to treat solid ship bodies, breakable modules, and hinged connections as distinct problems, each with its own performance targets, so capital ships can lose pieces and link up without hurting performance across computers and consoles.
Headless sim scenarios start physics migration
I recorded how ships currently fly (thrust, turning, rolling, braking, and firing) as fast windowless test runs, so the big physics rework can be checked against them and never quietly change how a ship feels to pilot.
Benchmark body iteration before BEPU
I added a quick stress test that runs a crowd of moving objects with repeatable results and timing, giving me a cheap baseline to compare against before the bigger physics overhaul lands.
Ship pose snapshots become the read model
I had the simulation start broadcasting each ship's position and orientation in a single shared form, so the parts of the game that draw and inspect ships can move onto the new physics one at a time instead of all at once.
Validate physics assets before runtime bodies
I made every ship's physical properties (its shape, weight, and how it reacts to forces) start life as checked, readable data, so problems show up as clear differences before they ever reach the live game.
Keep BEPU behind StarGazer physics handles
I tucked the new physics engine behind a clean wall of my own so the rest of the game never talks to it directly, keeping the borrowed engine swappable and the game's code tidy.
Start collision slice headless
I built the first slice of collision handling as a windowless test that proves objects spawn, get scanned for hits, and report events in a reliable order before any of it is shown on screen.
Render physics debug from collision slice data
I made the on-screen physics debugging view draw straight from the same verified data the underlying simulation uses, so what I see while debugging is the real state and not a separate guess.
Prove compound detach before articulated joints
I proved that big ships can break apart cleanly, with detached pieces carrying their momentum away, before wiring up the more delicate physics of hinged and jointed parts.
Set first physics performance gates
I set concrete speed targets the physics has to hit, including a profile for the lower-powered handheld console, so performance is measured against real limits as the simulation grows more complex.
Harden physics runtime API
I gave the physics layer a proper toolkit for spawning, destroying, and tracking objects safely, so the game can handle many different kinds of moving things instead of a handful of one-off test pieces.
Add a BEPU runtime benchmark gate
I built a tool that measures how fast the game's collision and motion math runs on its own, so I can see exactly where the time goes before adding heavier physics.
Support static physics bodies behind BodyRef
I taught the physics engine to handle immovable things like stations, beacons, and obstacles through the same simple interface it uses for ships, so non-moving objects don't need their own separate plumbing.
Name physics runtime velocity units
I renamed the speed values in the physics engine to clearly mark which ones are measured per second versus the older per-frame ones, so the two timekeeping styles that coexist during this transition can't get confused.
Keep BEPU shape ownership inside PhysicsWorld
I made the physics engine quietly clean up after every object it creates and destroys as ships come and go, so spawning and removing things doesn't slowly leak clutter behind the scenes.
Serialize dotnet commands per worktree
I made it a rule never to build or run two copies of the game at once from the same folder, because doing so causes false errors from the two builds stepping on each other's files.
Route runtime queries through collision channels
I made the game decide what can collide with what using the same rulebook the ships themselves are built with, so hits and near-misses behave consistently everywhere instead of each feature inventing its own rules.
Make runtime query hits self-describing
I made every detected hit carry its own details, like what it struck and how it should react, so the game can resolve a collision instantly without having to go look the answer up afterward.
Make playable physics consume PhysicsWorld
I moved the real game (your ship, the target, and weapon fire) onto the proper physics engine instead of leaving it confined to behind-the-scenes test runs, so everything you see and shoot now obeys the same real physical rules.
Wake controlled physics bodies on motion
I fixed a bug where a ship left sitting at the start would refuse to move forward (the engine had quietly put it to sleep), so a ship always responds the instant you give it a push.
Separate chase and orbit camera ownership
I gave the default camera its own follow-behind mode anchored to the ship and clearly separated it from the orbit and fixed views, so a ship sliding sideways now actually looks like it is moving instead of just spinning.
Harden live physics review gaps
I tightened up how the physics engine tracks which objects are touching and rejects bad data, so as the fleet grows it stays fast and never gets fed nonsense numbers that would corrupt the simulation.
Use raw runtime icon assets
I set up the game's window icon so the program automatically finds and shows it on Windows and Mac without extra fuss.
Deterministic AI pilot emits movement intent only
I taught the computer-controlled ships to simply decide where they want to go (like wandering or charging) and let the shared movement system carry that out, so their behavior replays identically every time and they stay unarmed for now.
Promote ships into a dense control store
I gathered every ship, yours and the computer's, into one shared registry that feeds them through a single steering pathway, so growing from one ship to a whole fleet stays organized and the ships still bump and collide believably.
Add real-ship scale and determinism gates
I built a way to run whole fleets of ships through the game's movement and combat logic without any visuals, so I can prove the ships behave the same way every time and measure how they hold up at scale before trusting it.
Measure live frame metrics in the render HUD
I added a live readout of how smoothly the game is drawing, so I can spot stutters in real time while flying around as I push the number of ships and the intensity of combat higher.
Draw selected ship vectors from sim snapshots
I made the on-screen debug arrows for a selected ship (which way it faces, where it's heading, where its computer pilot is aiming) come straight from the same source the actual gameplay uses, so what I see while debugging matches what the ship truly does.
Split ship scale profiles and benchmark phases
I added different ways to lay out test fleets, from ships spread thinly across space to crowds deliberately packed together to collide, so I can tell exactly which part of the game is slow when the action gets heavy.
Plan voxel ships as deterministic state over coarse physics bodies
I decided each destructible ship would be a single solid body for movement with a detailed damage map laid over it, rather than thousands of separate physics objects, so battles can scale to enormous fleets without grinding to a halt.
Harden voxel plan around chunked and pooled performance paths
I rewrote the destructible-ship plan to demand the fast approach from day one, avoiding shortcuts that would look fine on a single ship but crawl once hundreds or thousands fill the screen at once.
Define voxel construction, destruction, debris, and performance test gates
I wrote out a full test plan for destructible ships, listing every sneaky way the system could break (a severed chunk still acting alive, ships splitting wrong) so those flaws get caught automatically instead of slipping past a screenshot.
Add synthetic voxel validation, split scenarios, and benchmark gates
I delivered the first working slice of destructible ships: test shapes that break apart correctly, pieces that drift off as wreckage when severed, and speed tests to make sure all of it stays fast.
Add CPU GLB voxel cook slice
I got the game to take a real 3D spaceship and slice it into its damage blocks for the first time, turning a detailed ship into roughly twelve hundred destructible cells, proving the pipeline works on an actual model and not just made-up test shapes.
Add aggregate voxel test suite gate
I built one single command that runs the whole gauntlet of ship-damage tests at once, from ships breaking into floating pieces to a real spaceship being chopped into its damage blocks, so I can catch broken battle behavior before it ever reaches you.
Record core-death hull as voxel debris
When a ship's core is destroyed, all of its remaining intact pieces instantly become drifting wreckage in one clean stroke, so a dead ship can no longer keep fighting or be targeted as if alive.
Hash voxel suite results by stable evidence
I changed how the game double-checks that battles play out identically every time, basing that check on what actually happened (which parts lived or died) rather than on stopwatch timings that naturally wobble run to run.
Harden voxel headless gates before runtime integration
I tightened the automatic safety checks around how ships are carved into their tiny damage blocks, so the system refuses to choke or quietly lie about being reliable when ships get very large or very numerous.
Attach voxel state to runtime ships
Every ship, whether you or a computer opponent flies it, now carries a living record of damage to each part of its body, hit and torn apart in a strict, repeatable order, so a wreck always falls apart the same way.
Add selected-ship voxel debug overlay
I added a way to peek under a chosen ship's skin during play, showing its damage in little building-block chunks and counting how many are still alive, dead, or knocked loose, so I can prove the damage is real before building bigger battle features on it.
Plan FNA-native HDR forward rendering pipeline
I laid out the full plan for a modern, cinematic look for the game: rich lighting that holds bright and dark detail at once, soft glows around hot light, crisp edges, film-grade color, and realistic shadows, all tuned to run smoothly even on a handheld.
Fold Git LFS upload into the committed pre-push hook
I fixed how my project uploads its large screenshot files so that pushing my work no longer leaves the heavy images stranded on my machine, which had been causing fresh copies of the project to fail to download.
Render voxel debug cells at cooked GLB density
The debug view that shows a ship's building-block structure now displays it at the true, fine density the ship was built with, so when I inspect it the framework looks as detailed as it really is instead of a coarse stand-in.
Route beam hits through ship-local voxel DDA
Weapon beams now do their damage by tracing the actual shot through a ship's blocks and striking the first solid one it reaches, so hits land where the beam really goes instead of from hand-picked spots, all kept fast and exact.
Prove sparse voxel DDA crosses empty cells without allocation
I proved that a beam can travel through long stretches of empty space inside a ship's frame and find the first solid block to hit without ever bogging the game down, which matters because capital ships are mostly hollow and beams cross a lot of nothing.
Add aggregate voxel state slots with promotion on demand
Far-off ships can now sit as lightweight summaries that cost almost nothing, and a ship only blossoms into full block-by-block detail the moment it actually takes damage, so the game can hold hundreds or thousands of ships at once while nearby combat still looks fully detailed.
Add detailed voxel state scale ladder
I added a test that builds 1, then 10, then 100 ships all tracked in full block-by-block detail and damages each once, confirming every one registers its hit cleanly before I push battles to heavier fire.
Report detailed voxel caps in sim scenarios
Test runs now print exactly how many ships are being tracked in full detail versus kept as cheap summaries, and you can cap that number, giving a clear honest readout that the fleet's detail-saving system is really working in the live game.
Apply voxel damage by sorted command runs
I rewrote how a wave of incoming hits is processed so the game handles them in tidy groups by which ship was struck, letting a thousand-ship battle's damage scale with the number of volleys rather than ballooning out of control.
Resolve same-tick voxel detaches inside command runs
When a chunk of a ship breaks off during a single burst of hits, later hits in that same instant correctly pass through the now-floating debris instead of pretending it is still part of the living ship.
Report real voxel topology and LOD benchmark metrics
I taught the performance test to report honest, real numbers about how ship hulls are broken into pieces and how much work each tick does, so a slowdown at large fleet scale can't hide behind tidy fake totals.
Guard aggregate voxel ships against invalid promotion
I made sure that a shot which misses or doesn't really count against a distant ship no longer accidentally jolts that ship into expensive full-detail tracking, which is what keeps huge fleets affordable to simulate.
Read aggregate voxel core ids without promotion
When something just needs to peek at which block sits at a distant ship's core, the game can now glance at it cheaply instead of waking the whole ship into full detail, so far-off ships only get spun up when damage actually lands on them.
Test killed voxel ships through runtime control systems
I added tests that fly destroyed ships through the game's real steering and computer-pilot logic to confirm a ship with its heart blown out goes truly dead and stops trying to move, instead of only checking that on stand-in stand-alone wrecks.
Extract render pipeline scaffold from Game1.Draw
I reorganized the behind-the-scenes drawing code into one tidy pipeline, clearing the way for the richer lighting and visual polish I plan to layer on next.
Mark detached voxel debris without drawing dead hull
When a chunk of a ship breaks off, the lost piece vanishes from the hull and gets its own marker showing exactly where it tore away, so a ship splitting apart is easy to follow.
Use apphost launcher for live game runs
I changed how the game gets launched so the running game stays alive on its own and does not get killed when I close my work session, making testing far more reliable.
Add live voxel damage demo
I built a small live demo that plays out damage over time, breaking a structure apart piece by piece, so I can actually watch how destruction unfolds rather than just inspecting frozen snapshots.
Render voxel debug cells as filled blocks
I switched the damage view from thin wireframe outlines to solid filled blocks, so torn hull, dead sections, and floating debris all read clearly instead of looking like a see-through cage.
Cache voxel debug rendering by dirty chunks
I made the game redraw only the parts of a ship that just took damage rather than rebuilding the whole hull every frame, keeping things fast even as the cornerstone damage system runs.
Drive GLB mesh damage from voxel state
Damage now eats away the ship's actual sculpted surface where it was hit, so a wounded ship keeps its real shape and loses recognizable chunks of hull instead of turning into crude blocks.
Add programmatic GLB breach demo
I added a quick way to drop straight into a scene showing a fresh breach blown into the top of a ship's hull, making it easy to look at battle damage on demand.
Share GLB breach damage patterns with tests
I set up an automatic check that confirms a blast through a ship's hull always carves a proper hole without instantly killing the ship, so the damage stays believable as I tune how it looks.
Route ship lasers through voxel damage
Ship laser fire is now wired straight into real hull damage: a beam that lands burns away part of the enemy and drains its health, so what you see hitting the ship is what actually hurts it.
First weapon is a broadside beam gate
Capital ships should reward bearing and positioning before twitch aim. The beam gives me immediate feedback while the weapon art and damage rules are still fluid.
Make prototype thrust visibly readable
The physics-backed ship was technically moving, but the motion was too subtle against the follow camera and the large grid for me to trust the controls during live playtesting.
Default flight view is ship-local chase
Translational motion needs to stay readable during live playtesting. A visual-center follow camera can hide movement on a capital ship because rotation changes the camera's target.
First AI gameplay slice is no-combat flight
I want to prove ownership, control, collision, camera framing, and the debug surfaces before I layer fighting, targeting, damage, or fleet behaviors on top.
Compact runtime HUD around performance first
The previous debug readout exposed useful values but behaved like an unstructured dump. I need performance visible while playtesting at scale, and I want the rest scannable without covering the playfield.
Ship selection is keyboard and CLI addressable
Fleet-scale debugging needs a stable way to inspect one ship at a time without mouse-only picking. Keeping chase player-owned preserves the flying camera while orbit becomes the inspection camera.
Capital ships become core-rooted damageable voxel structures
Damageable capital ships are a cornerstone fantasy for me. Positioning and weapon impacts should matter spatially, not just subtract from a single health bar. A core-rooted graph gives readable rules, supports future "real ship systems", and keeps disconnected wreckage behavior deterministic for the first slice.
Detached voxel islands become debris, not ship
Capital-ship damage needs to feel physical without letting severed pieces keep acting like the player ship. This gives the sim a crisp ownership boundary for future salvage, collision debris, visual wreckage, and system detachment.
Core death sheds remaining hull ownership
Core death is the same ownership boundary as bridge severing. Once the root is gone, no surviving hull piece should keep behaving like the ship.
Adopt cinematic space-opera aesthetic
The "modern beautiful space game" target needs a single aesthetic compass so I stop relitigating per-effect technique choices. Cinematic space-opera fits capital-ship combat's slow tactical pacing, gives every system biome a strong identity, and survives the FNA SM3 rendering ceiling without compute-required modern looks.
Tune flight around capital-ship commitment
Capital ships should feel massive because repositioning is a decision with momentum, not because the top speed is tiny.
Put primary turning on A/D
For capital-ship handling, left and right on the home cluster should command heading commitment first. Strafe is secondary maneuvering thrust, it deserves the secondary keys.
Use voxels as invisible damage truth
Capital ships need authored silhouettes and readable art direction. Voxels give me spatial damage and scaling, but showing raw blocks as the main ship would undercut the fantasy.
Make lasers the first live voxel combat proof
It proves the cornerstone loop in actual play (weapons, ship ownership, voxel damage, life, debris, GLB mesh removal) without waiting for turrets, reactors, armor types, or full combat AI.
The Ship Coasts Now
I gave the ship drift, broadside arcs, and a quiet foundation strong enough to hold a debris field. Today it stopped being a toy.
Three Calls I Made About How The Ship Should Feel
Does the ship dart or does it drift? I want it to drift. Three decisions in a row, all serving that one feeling.
Vendor FNA instead of MonoGame NuGet
I copied the game's core engine directly into the project so I fully own it and can change it freely whenever the game needs it, rather than depending on an outside package.
Target.NET 8
I built the game on the current long-term-supported version of its programming platform, which runs natively across Windows and Mac (including Apple's own chips).
SDL3, not SDL2, as the FNA platform layer
I built the game on the modern version of its underlying platform layer, which brings better controller and high-resolution display support that matters for gamepad play and Mac.
Native libs laid out as runtimes/<rid>/native/
I organized the game's platform-specific support pieces into the standard layout so the correct ones get bundled automatically for Windows or Mac when I build for each.
Use SharpGLTF.Core via NuGet for GLB loading
I adopted a well-maintained, widely trusted tool for reading the 3D ship files the game uses, so loading ship models is reliable and I am not maintaining that plumbing myself.
Main-only git workflow with auto commit + push
Working alone, I save and back up my progress automatically at every finished step, which keeps the game always in a working state and gives me easy points to roll back to.
Adopt DOC/ decision-log discipline
I started keeping a running journal of every meaningful design and technical choice and the reasoning behind it, so when I return to the game after a break I can remember why things are the way they are.
Defer text rendering library choice; "Hello World" via window title only
For the very first milestone I just put the greeting in the window's title bar and held off on picking a text system until I actually knew what the game's on-screen writing would need.
Adopt FontStashSharp.PlatformAgnostic + custom FNA renderer for text
I chose a text-drawing approach that lets me load and swap fonts at any time without a rebuild, so on-screen writing renders cleanly and stays easy to restyle later.
In-process screenshot via RenderTarget2D + --screenshot CLI flag
I built the game so it can take its own screenshots from any moment with a single command, giving me a consistent way to capture how things look across every computer without any outside tools.
First ship renders: GLB loader extended for normals + BasicEffect render path
I got the first real ship model showing on screen with simple built-in lighting and an automatic camera that frames any ship, so the game finally renders a lit, three-dimensional vessel instead of just placeholder text.
Cull clockwise, not counter-clockwise, for glTF + FNA right-handed projection
I corrected which side of each surface the game treats as facing outward, so ships now show their proper outer hull instead of looking turned inside-out with their interior walls exposed.
Roguelike structure (procedural runs, not scripted campaign)
It fits my solo indie scope: replay value scales with procedural systems while content authoring stays manageable, and the roguelike loop fits "one more run" sessions, which is how I actually play games while traveling.
3D space combat centered on capital ships
This has been the game concept since I started. Capital ships afford strategic-feel combat (positioning, broadside arcs, subsystem targeting) over twitch reflexes, which aligns with the roguelike "tactical decision" loop more than with a flight-sim arcade loop.
GLB as the ship model format
It's a modern open format, widely supported in DCC tools (Blender, etc.). It avoids the dead XNA-era.fbx to.xnb Content Pipeline. And runtime loading lets me do data-driven ship variants without a rebuild.
Target PC + Mac desktop
Mac coverage lets me keep working on a Mac during travel, and the FNA plus SDL3 stack covers both desktop targets cleanly (better controller and HiDPI support along the way).
Programmatic control of every game state is a core tenet
Four compounding reasons. AI-driven verification needs programmatic state access for automated screenshots and scenario runs. My dev velocity collapses if reproducing a bug takes 90 seconds of menu-clicking instead of a --scenario flag. The same affordances let players write mods, replay, and speedrun tools later. And forcing programmatic reach makes the sim explicitly expose its state transitions (easier to test, more predictable). Retrofitting onto a finished UI is a multi-week refactor, menu state machines, animation skippers, save and load headless paths all have to be threaded through every screen. Designing it in from feature one is essentially free.
Determinism in the simulation layer is a core tenet
Replay unlocks bug-repro-by-file (a player sends a 200-byte replay, I reproduce locally), automated scenario regression (replay then diff every Nth frame), AI-agent verification loops, and modding and speedrun infrastructure, and all of those compound forever on top of a deterministic sim. The retrofit cost is brutal (every system touching randomness, time, or IO would have to be audited and rewritten), so adopting the discipline now while the sim code is empty is essentially free. The cost gap between "do this from day 1" and "add this in year 2" is multiple orders of magnitude.
Parallelizable by design, multi-agent, multi-instance from day 1
I want multiple Claude Code agents running in parallel (for example, one in worktree A and another in worktree B with screenshot diffs comparing them). That only works if the codebase has no hidden contention surface: no shared file someone forgot about, no global cache that gets corrupted, no log file two agents fight over. Building this in from day 1 costs me nothing. Bolting it on after the first global-state bug is brutal, I'd find them one race at a time over months.
Asset pipeline: raw files at runtime, no packing until shipped game needs it
My projected asset footprint is modest: a small fleet of ship GLBs, modest textures, conventional SFX and music, low hundreds of MB at ship. At that size class, the iteration-speed benefits of raw files (no build latency, trivial future hot-reload, every agent can write any asset in any worktree without tooling, dev environment matches ship) outweigh the distribution-size and cold-start benefits of packing. Stating "no packing" as a principle now prevents drift into "just add a small manifest" creep that compounds into a pipeline rewrite a year in.
Determinism tenet refinements after expert review
I had my determinism specialist reviewer pass on the original 7 rules (2026-05-21), and they named these as the 30 percent the original list missed, the parts that actually break in shipped lockstep games. It's cheap to add them to the tenet text now while the sim code is still empty.
Run shape: short FTL-style runs, hard perma-death, procedural fleets + sectors, no meta-progression
Short runs plus hard perma-death gives me the "one more run" loop that fits travel-on-Mac sessions, matches my solo-dev scope (no meta-DB to maintain), and lets each run carry real stakes. Procedural-fleet-on-a-fixed-roster keeps the content authoring tractable.
First Transmissions: One Ship, One Window, Day One
All I wanted on the first day was a window, a ship, a grid for scale, and a camera that follows. Four small proofs that the dream is real.
Day One: I Decided To Owe Nobody
Two calls I made before any of the game existed. One about the machine that runs the ship. One about the words on the screen. Both about owing nobody.