This week’s updates brought big strides in polish and clarity for Stellar Throne. Ground combat now displays strength bars above their respective forces, making planetary invasions easier to read. Ownership now correctly updates after successful invasions, and the final phase of an invasion plays out as intended.

On the combat side, the battlefield grid now renders fully, fleets start in centered positions, and you can left-click + drag to move the map. Support ships have distinct plus-shaped icons, colony ships use circles, and troop ships have been fully renamed for clarity. Fleets with no ships are automatically cleaned up after combat, reducing clutter.

Outside battle, draggable UI panels (shipyard, diplomacy, bombardment) were unified under a new DraggablePanel base class, making the interface smoother. Loading screens are more responsive, and territory borders now update dynamically after colonization. The border system itself has been revamped with shaders, opening the door for smoother, more striking visuals.

This update brings Stellar Throne one step closer to feeling like a finished 4X experience.

🌟 What’s New

This week brings major planetary warfare upgrades with the new Orbital Bombardment and Ground Invasion systems, a redesigned Ground Combat UI, smoother combat flow, and dozens of bug fixes and performance improvements. If you’ve been waiting to crush enemy worlds in style, now’s the time.

🆕 New Features

• Orbital Bombardment System — Added comprehensive orbital bombardment mechanics with UI controls, allowing fleets to weaken planetary defenses before invasion.

• Ground Invasion — Implemented ground invasion capability integrated with bombardment UI for a seamless planet conquest workflow.

• Ground Combat UI Redesign — Enhanced battlefield visualization with army strength bars displayed above unit columns for better awareness.

⚔️ Combat Improvements

• Damage Visualization — Incremental damage application synchronized with weapon effects for more engaging combat feedback.

• Destroyed Ship Feedback — Clear visual indicators when ships are destroyed in combat.

• Ship Detail Panel — Panel now closes automatically when combat begins.

• Combat Flow — Smoother battle completion and input handling for consecutive battles.

• Auto-Resolve — Fixed to jump directly to the final combat state.

🐞 Bug Fixes

• Fixed multiple combat UI issues including scroll isolation, input handling, and grid cell highlighting.

• Resolved ship targeting bug where destroyed ships could regenerate.

• Fixed timing issues so destruction animations play at proper turn end.

• Corrected ships having zero energy capacity in combat.

• Fixed double damage and combat synchronization issues.

• Resolved input handling problems when switching between combat and starmap views.

• Fixed ground combat final screen to properly display complete phase results.

🎨 UI/UX Improvements

• Enhanced scroll wheel isolation between UI panels and galaxy view.

• Improved memory management in combat UI systems.

• Better defender priority handling for grid cell movement conflicts.

• Cleaner, modular architecture for combat UI components.

🛠 Technical Updates

• Refactored project documentation into a modular structure for better maintainability.

• Resolved SpatialGrid naming conflicts in CombatManager.

• Reduced test suite orphan count and fixed various test failures.

• Removed debug print statements and cleaned up temporary test files.

🚀 Performance & Stability

• Improved combat animation system performance.

• Enhanced memory management across UI systems.

• Better error handling for bombardment operations involving Building resources.

A couple days ago was… maddening.

I’d been wrestling with the same bug for days—the kind that sits in your code like a smug little goblin, daring you to come find it. Every time I thought I had it cornered—poof—it would slip away into another layer of logic.

The problem sounded simple enough: combat is simultaneous. Even if a ship gets destroyed, it should still get to fire its weapon that turn. But the UI shouldn’t mark it as destroyed until after all attacks are resolved.

Except in my game, ships weren’t showing their dramatic “destroyed” flair until the start of the next turn. By then, the moment was gone. It was like telling a joke and waiting five minutes for the punchline to land.

I threw everything at it:

• The “outside consultant” trick—pretending Claude was a hired expert swooping in to save the day.

• The “you’re a zookeeper” trick. (Don’t ask.)

• Breaking the workflow into phases.

• Having Claude explain the code back to me.

• Running the debugger subagent.

• Asking it to think hard… harder… ultra-think.

• Asking Claude to improve my prompt.

• Diagramming the problem like a detective on a conspiracy board.

• Adding a ton of debug logs.

• Even pulling in ChatGPT to craft a better Claude prompt.

• Describing the issue in painstaking detail—right down to which variables changed on which frame.

Nothing. Worked.

And this wasn’t even a crash bug—the game ran fine. It was just wrong. The kind of subtle pacing flaw that players might not notice consciously, but would feel in their bones. The kind that makes everything feel just slightly “off.”

By about hour six that day, I was leaning back in my chair, staring at my code, wondering if the bug was less about the project and more about me.

Then—somewhere between frustration and surrender—I tried one more approach. Nothing special about it. No perfect galaxy-brain prompt. Just another attempt in a long line of attempts. And this time… it worked. The ships died exactly when they were supposed to, the UI updated cleanly, and the combat flow finally felt right.

I’d love to tell you it was some brilliant debugging insight or the magic words that unlocked Claude’s genius. But it wasn’t. It was just the luck of the dice—one more roll, one more try, and this time it came up in my favor.

When I first started experimenting with AI-assisted game development, I saw something that changed the way I think about making games: you don’t need to be a programmer to bring your ideas to life anymore.

With the right tools and the right guidance, artists, designers, and dreamers can skip years of technical roadblocks and just start building.

ClaudeCraft is my way of opening that door.

1. Because Non-Coders Can Make Games Now

Game development used to feel locked behind walls of code, syntax, and complex tools.
AI is tearing those walls down. With tools like Claude, you can describe what you want, refine it through conversation, and watch your game take shape—no CS degree required.

2. Because I Want to Empower Artists, Designers, and Hobbyists

I’ve met so many creative people with incredible game ideas… who never got the chance to make them because the technical barrier was too high.
ClaudeCraft is designed for them—for you—so you can stop saying “I wish I could make a game” and start saying “I’m making one right now.”

3. Because Teaching Makes Me Better Too

They say the best way to learn something is to teach it.
By building ClaudeCraft, I’m deepening my own understanding of Agentic Game Development—the process of using AI not as a mere assistant, but as a creative collaborator. Every lesson I create sharpens my own skills.

4. Because AI is the Future of Creativity

From art to music to storytelling, AI is becoming part of the creative process everywhere.
I believe the future belongs to those who know how to work with AI instead of against it—and ClaudeCraft is my way of helping people step into that future with confidence.

The Goal

By the end of ClaudeCraft, you won’t just have learned how to make a game with AI—you’ll have actually made one.
And more importantly, you’ll know how to keep going, creating the worlds you’ve always imagined.

If you want to be part of that journey, stay tuned. ClaudeCraft is coming soon.

Waitlist at ClaudeCraft.com

Today was a tale of two projects — one in the depths of space, the other in the heart of the classroom.

Stellar Throne – The Bug War

Work on Stellar Throne felt like navigating an asteroid field with a faulty nav computer. The main nemesis? The Combat UI’s combat log, which decided to also control the battlefield zoom. Imagine trying to scroll through battle events and suddenly you’re looking at the galaxy from light-years away.

The fix meant tearing apart the screen infrastructure, carefully reassembling it without losing functionality. Once the battlefield stopped “breathing” under my mouse wheel, I ported the same fix to the main starmap. Smooth scrolling across the board now.

Other combat encounters:

• Mysterious spontaneous ship damage (bug or stealth weapon… to be determined).

• Mouse clicks going on strike after combat.

• Destroyed ships clinging to life visually.

It’s not glamorous work, but it’s the kind of quiet victory that makes the rest of the game shine.

ClaudeCraft – Building the Blueprint

Meanwhile, on the teaching front, I made big strides with ClaudeCraft, my upcoming course on AI-assisted game development. Modules 7–10 got their teaching guides, the course outline got tightened to stay laser-focused on Claude workflows (no drifting into generic gamedev land), and I even expanded it to 11 modules with some bonus content for extra punch.

I also whipped up a shiny roadmap image and, in the process, felt the course concept click into place — a clear path from AI novice to confident AI-powered game creator.

I’m still chewing on the challenge of reaching the right audience, but the bones of the course are solid and the waitlist is live at ClaudeCraft.com.

Today felt like juggling two galaxies at once — on one side, Stellar Throne’s combat UI, and on the other, my brand-new course, ClaudeCraft.

🚀 Stellar Throne

The combat UI turned into a tricky beast today. Fleets are moving again, but I hit a real gremlin: scrolling the combat log was also zooming the battlefield map. Not exactly the immersive tactical experience I was going for.

The fix? A complete rebuild of the screen infrastructure — from the ground up. I'm still carefully untangle the input handling so nothing else brakes in the process. Let’s just say it was one of those moments where I briefly missed the raw, direct control Zig gave me.

On the bright side, the redesign feels cleaner, more modular, and less likely to explode the next time I touch it. The test harness is moving into Phases 6–7, and I also gave CLAUDE.md some love while fine-tuning my AI agents to run on models better suited to their roles (no more “Opus for everything” just because it sounds fancy).

🎓 ClaudeCraft

Meanwhile, I decided to lean into an idea that’s been bouncing around my head for a while — teaching AI-assisted game development. The result is ClaudeCraft, a 10-week program on building games with Claude, even if you’ve never written a line of code.

I locked in the name, hooks, and the transformation outcome, mapped out the full module breakdown (plus bonus content), and built the waitlist site: ClaudeCraft.com.

The teaching guides are already in progress — Modules 1–7 are done — and I’ve started collecting a big list of concepts I want to weave in. This one’s shaping up to be just as ambitious as Stellar Throne… just with fewer fleets firing at each other.

Today was a deep dive into two critical fronts: refining the Combat UI and strengthening the testing pipeline.

On the combat side, I addressed several issues in turn flow, UI behavior, and ship logic — including a bug where only the defender was firing and the End Turn button did nothing. The combat log now displays (but is empty), and its minimize function is still broken. The ship details panel also lacks cooldown indicators, which I’ve flagged for follow-up.

Testing revealed a deeper issue: Claude was reporting successful test runs, even when GUT (Godot Unit Test) was throwing warnings and memory leaks in-editor. The culprit? Autoloads behave differently in headless testing versus the editor. That discovery forced a rethink of the workflow. I'll have to start running tests manually.

To address this, I created two new Claude agents:

• Godot Developer Agent — for context-aware game development tasks, a coder
• Quality Control Reviewer — focused on identifying inconsistencies and code quality issues

Both were drafted with ChatGPT, then refined via Claude. While the test suite still needs cleanup — failing tests, memory leaks, and noisy logs — the pipeline is improving.

In parallel, I started building a Zig-based test harness to simulate full game runs via a TCP server embedded in Godot. This system will allow me to run batches of games and collect real gameplay data — offering better insights into balance, exploit detection, and rough edges that might be invisible during manual testing.

Today I upgraded Stellar Throne to run on Opus 4.1 and completed a full code audit to ensure compatibility. One surprising discovery: Claude was reporting passing unit tests that were, in fact, producing errors and warnings. To fix this blind spot, I fully migrated the project to Godot Unit Test (GUT) — now I have better visibility and cleaner reporting.

I also explored six different Combat UI layouts, selected the strongest version, and wired it up to the logic layer. It’s already starting to feel more readable and engaging — and being built on a clean, modular HUD structure means it’ll be easier to evolve over time.

Tomorrow I’ll keep iterating on combat polish and look for regressions now that the new UI is in place.

https://mrphilgames.substack.com/p/why-im-switching-stellar-throne-to?r=ifm45

Today I made the jump to Godot 4.3 alongside the release of Claude Opus 4.1. The upgrade went smoothly, and the new version feels like a solid step forward — snappier performance and better tooling all around.

After migrating, I performed a full codebase audit to ensure everything plays nicely with the new engine version. There were a few compatibility tweaks needed, but overall it was a seamless transition.

Combat UI continues to be the major focus. While parity hasn’t been fully restored yet, fleet layout, interaction, and stat visibility are improving each day.

Tomorrow I’ll resume debugging the remaining combat issues and continue polishing the overall experience now that the base engine is stable again.