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.

Today was all about chasing down elusive bugs and bringing Stellar Throne’s combat system back online. I made progress aligning fleet behavior, restoring engagement triggers, and fixing visual/UI issues — including a very stubborn notification bug. I also optimized the loading screen to prevent a short freeze, got the test runner compiling cleanly again, and did a full quality control pass of recent commits. There’s still work to do on the combat UI, but it’s coming together.

Today I focused on reviewing and improving the modularity of my Godot codebase using Claude. I experimented with deeper AI-assisted refactors, but noticed that some of the changes subtly altered functionality — a reminder that even “smart” tools need clear boundaries.

On the feature side, I added a proper loading screen for galaxy generation and restored key parity features:

• Build buttons are now back in the planet and star detail panels

• Ships no longer appear instantly when queued for construction

It’s steady progress toward visual polish and parity — but it’s also clear that Claude needs tighter prompt rules when it comes to refactoring logic. I’ll be updating my CLAUDE.md guidelines accordingly.

Today was all about closing the gap between the original Zig build and the Godot port. I tackled a wide range of bugs and visual polish tasks: fog of war is back, the background star field is in place, and the main menu, game setup screen, and star map all got a visual lift. I also adjusted the zoom level so you can now see the entire galaxy at once, and finally got animated notifications working — a deceptively tricky task.

I also pulled all the notification code into its own system, refactored how buildings are handled, and fixed a bunch of UI interaction bugs (like clicks passing through panels to the map). ChatGPT gave CLAUDE.md a 9.5/10 after a full audit, and a code quality review helped clean up some lingering issues — replacing unsupported typed arrays and cleaning up debug output.

Claude is starting to really shine inside Godot now that the environment is more stable. Tomorrow, I’ll continue hunting bugs and pushing toward feature parity.