DEV Community: Mario Mignemi

GLM-5.3-Flash: A Geopolitical Disruptor Hiding in an Ultra-Cheap Model

Mario Mignemi — Wed, 02 Sep 2026 12:19:42 +0000

Before the world knew it was a product of Z.ai, a massive Chinese tech player, this model was running under the secret name "Ox Alpha". It has become the most used model on OpenRouter in a single week, purely through a blind taste test. People loved it before they even knew who to thank (or blame).

Now, it’s officially out: GLM-5.3-Flash. It’s an open-source, MIT-licensed model that is aggressively cheap, runs on Chinese-made silicon, and has proven it is both a miracle and a menace

The End of Nvidia Monopoly

Most people look at AI through the lens of "Which one is the smartest?". The better question should be "Which one is the most accessible?"

GLM-5.3-Flash is disruptively cheap. We are talking $0.15 per million input tokens. To put that in perspective, I fed it a completely unfamiliar codebase (my videogame) to run small and big refactorings, and the total cost came out to just $0.10: a fraction of what you would pay for the same work using Claude Opus 4.8.

But there is a geopolitical layer here, too. This massive spike in global AI traffic isn't running on Nvidia H100s. It’s running on Chinese-made chips. The "export control" era of AI is hitting a wall: China is proving they can serve the global market at scale without Western hardware.

Can it Survive the Jovarko Incident?

I decided to put this cheap model through the ringer. I wanted to see if it could survive my game project, The Weight of One – The Jovarko Incident, which has been in development since 2013, and still is today.

I started with a tricky class decoupling to clear out direct dependencies. Many other tests followed. Without being overly technical, the most difficult one was converting a local, scene-bound component into a global, scene-unbound service. It was a high-risk refactor designed to test whether the model actually understood Unity state and runtime lifecycles, or if it would just blindly rewrite the logic and break all the classes it depended on.

I can't stress this enough: I spent several hours with the model, putting it through multi-file refactoring tests, and the entire experiment cost me around 10 cents. When I checked my billing dashboard, I couldn't believe my eyes.

Beyond Task Completion: Contextual Awareness

What surprised me wasn't just that it solved the tasks, but how it noticed things. During the first test, it proactively flagged files in the wrong place, and spotted suspicious dependencies and code smells.

GLM-5.3-Flash even reported a known bug mid-refactor and addressed it. It seems to have a "split attention" capability: it can focus on the task at hand while keeping a peripheral eye on everything else.

When I questioned its approach, asking what changes are safer than others, or why it advised against certain refactors instead of others, it didn't just output generic advice. It gave clear, solid reasoning, very specific for my codebase. Having built it myself, I already knew the right answers, and its architectural logic was spot-on.

Optimizing for Today, Ignoring Tomorrow

However, being "cheap" came with a side of "unpredictability".

As weird as it can sound, the model is sometimes overly proactive. During one big refactor, it deleted several Assembly Definition files (C# way of grouping code) simply because their folders were empty: an unprompted "cleanup" I've never asked for. The problem? Those empty folders and assembly definitions were placed there for upcoming features. In trying to be helpful, it wiped out intended structure.

The breaking point was the FSM Incident. One of my packages had a dependency on a complex Finite State Machine (FSM) implementation. The model looked at it, judged the dependency as overkill, and simply deleted it to write its own minimal, "optimized" version.

The model seems to optimize for today without considering that I might need that complexity tomorrow. It’s a reminder that while the model is logical, it lacks the long-term strategic vision of a lead developer.

AI for the Rest of Us

For anyone watching the hardware market over the last two years, the trend is impossible to miss. The silicon that once flowed toward desktop GPUs is now being vacuumed up by data centers. This isn't just a temporary pricing fluctuation. It's a fundamental shift in who the industry serves, and who it is leaving behind.

I feel this shift every time I attempt to run a model locally. I currently own a 4060 Ti with 16GB of VRAM, and running models locally constantly forces me into a lose-lose trade-off.

The smart model route: I get good capabilities, but the heavy VRAM footprint leaves me with a tiny context window to barely host a single source file plus some working memory.
The small model route: I get a huge context window, but the model is too dumb to actually use it without degrading into nonsense.

This is why the push toward miniaturizing models like GLM-5.3-Flash is so vital. We consumers don't need frontier models that require a nuclear power plant to run. We need good models that can run on the hardware we already own.

Looking for a New Equilibrium

Maybe it’s time to change how I work entirely. I’ve spent a long time trying to force local models to do more than my hardware allows. The trade-offs are simply too stark for me. Even with the move to capable remote models, I’m still grappling with the problem of "delegation overhead".

In my current workflow, there is a sweet spot for AI: it is incredibly efficient when I can delegate large, complex systems, where the time saved outweighs the time spent reviewing the output. Unfortunately, there are no such tasks in The Weight of One: The Jovarko Incident. The bulk of the systems are already implemented, and only granular, smaller tasks remain. The time required to prompt, review and test generated code often exceeds the time it would take me to just write it myself.

Therefore, my focus for this next phase is to find a way to bridge this gap.

Have you experimented with the newer "Flash" class models? Do you prefer the "smart but expensive" approach, or are you betting on the "cheap and slightly chaotic" route?

My Game's Links:
The Weight of One - Official Channel
The Weight of One - Itch.io Page

My Socials:
My Linkedin
My Personal Channel

You can find my Dev Vlogs in both Youtube channels!

#gamedev

Mario Mignemi — Tue, 25 Aug 2026 05:52:02 +0000

How Dyslexia Taught Me to Write Idiot-Proof Docs

Mario Mignemi — Mon, 24 Aug 2026 20:52:48 +0000

There is a strange dichotomy in my professional life.

When I'm staring at a codebase, things make sense. Logic flows, structures are clear, and I can navigate complex systems with ease. But the moment I shift from writing code to writing long-form prose — whether it's a development article or a chapter of my novel — the world changes.

I'm neurodivergent and have dyslexia. While I genuinely enjoy the act of storytelling and sharing knowledge, writing isn't my "natural" mode of output. For me, the cognitive load of structuring thoughts into flowing sentences is immense.

Ironically, this struggle has become a professional superpower. Because I have to fight so hard to be clear, clarity has become something I pay close attention to. Over time, this has made me exceptionally good at writing idiot-proof technical documentation. I know exactly where a reader is likely to get lost because those are the same places I get stuck while writing.

The Quest for a Better Bridge

Because of this gap, I've spent a long time searching for a way to bridge the distance between the ideas in my head and the words on the page. Naturally, I turned to the tools that already help me in my coding workflow: Large Language Models (LLMs).

However, I quickly discovered a frustrating irony. These tools are incredible at generating clean, functional code, but they often fall apart the moment you ask them to write a cohesive article.

I tested the heavy hitters — Gemini, Grok, ChatGPT, and Claude — and the results were consistently disappointing. Most of them suffer from "repetition loops" where they repeat the same concept, in the same paragraph, in three different ways, burying the actual point in linguistic fluff.

Claude was perhaps the best at this. It produces a structure that looks correct at a glance, but the content is empty, meaningless. The sentences are technically correct but painfully long-winded, requiring multiple reads just to parse the meaning. They aren't writing. They're simulating the sound of writing.

Going Local: Quality Over Speed

As a last resort, I decided to step away from the polished corporate chatbots and move toward local AI via LM Studio. I wanted to see if a specialized model could handle nuance better than these "jack-of-all-trades" giants.

The biggest model I've tested was Gemma 4 31B (Q4_K_M), a 20GB beast. My 4060 Ti only has 16GB of VRAM, so I had to offload part of the model to system RAM, which made the process agonizingly slow. A 3-to-5-minute read took nearly an hour to generate.

I didn't mind the wait because the result was fundamentally different. In that instance, the local model produced a high-quality draft on the first try. However, it revealed a critical truth: when using local AI, the quality of your notes is everything. If your input is vague or misspelled, the model can hallucinates wildly. To make it work, you have to be a rigorous "director", providing precise guidance and structured data.

Gemma 4 26B A4B QAT (Q4_0) told a different story. At roughly 14GB, it fit comfortably in VRAM. The difference was night and day. It took 15 seconds to finish, roughly 240 times faster. Finally fast enough to feel like a tool rather than a test of patience.

The output quality came surprisingly close to the larger models, though I want to stress-test it further before drawing firm conclusions.

The Modern Workflow

This experimentation led me to a workflow that actually works for my brain. It isn't a "Generate" button; it's an iterative loop:

The Brain Dump: I start with unordered, chaotic notes of every point I want to cover.
The Structuring Pass: I hand these raw notes to Claude and ask it to organize them into something readable without changing the meaning. I then check the result to make sure nothing got twisted or lost.
The Style Guide: I maintain a separate reference document defining my voice, structure and language preferences.
The Draft: I feed the notes and the style guide into the local AI to create a good scaffolding.
The Refinement: This is where the real labor happens. I spend 2 to 4 hours reading, editing, discarding nonsense, and refining the prose until the article not only sounds like me, but it's in fact me.

The Stigma of the "Shortcut"

This process, which still takes several hours, recently became a point of contention.

A loved one, who works in communications and social media, asked if I used AI to write my articles. When I told her that I use it as an assistant, she laughed. In her field, the use of AI is often seen as unprofessional, a shortcut that signals a lack of effort or authenticity. She suggested that, while it might be "fine" for developers to do that, it was still essentially cheating.

Her perspective highlights a genuine tension between industries. In communications, AI is often viewed as a replacement for the human voice. But in tech, the tide is shifting. Job postings now frequently list "experience with AI tools" as a requirement, signaling that companies view AI as a tool for augmentation, not as a way to avoid work.

The Invisible Labor

I'll be honest: being laughed in the face irritated me a lot. The frustration I felt in that moment didn't stem from her opinion on AI, but from the assumption that "AI-assisted" is synonymous with "effortless".

Equating AI-assisted writing with purely automated output undermines the 2 to 4 hours spend reading, thinking and editing every single line.

As a neurodivergent writer with dyslexia, AI doesn't do the work for me. It cuts through the "mechanical drag", so I can focus on what really matters: making sure my ideas actually reach the reader.

What about you? Where does AI fit into your creative process? Are you using it for game dev, content creation, or life admin — or are you still holding off? Let me know your favorite use cases (or biggest gripes) below!

My Game's Links:
The Weight of One - Official Channel
The Weight of One - Itch.io Page

My Socials:
My Linkedin
My Personal Channel

You can find my Dev Vlogs in both Youtube channels!

Your Unity Tests Are Lying To You (Here's Why)

Mario Mignemi — Sun, 23 Aug 2026 20:02:12 +0000

There is nothing more gaslighting than a test that passes on Monday and fails on Tuesday, without you changing a single line of code.

Today, I’ve been diving deep into Unity integration testing for my Selection System. If you read my last post On the Illusion of Architectural Choice in Unity, you know I decided to lean into a ScriptableObject-based architecture. It felt elegant. It felt decoupled.

Then I tried to test it. And that’s when I realized that while ScriptableObjects are great for architecture, they can be absolute nightmare for testing if you don't know the "hidden" rules of it.

The "Shared State" Trap (Again)

Remember how I mentioned in my last article that SOs are assets and their state persists? Well, that architectural quirk becomes a lethal bug when writing tests.

I wrote a test: Select a unit → Verify it's selected. Pass.

I wrote a second test: Deselect all units → Verify nothing is selected. Pass.

But run them in a different order and they started failing. Why? Because the context was dirty.

Loading a fresh scene before each test should have given me a clean slate, but the unit from Test A was still selected when Test B started. (Turns out scene loading had its own secrets, but that's a problem for later in this post).

The Lesson: Even in PlayMode tests, ScriptableObjects do not magically wipe themselves clean between tests. You have to manually reset your runtime state using the attribute [UnitySetUp].

[UnitySetUp]
public IEnumerator SetUp()
{
    ...
    ClearSelection(); // Clearing the list containing the selected units
}

The Frame I Forgot to Wait For

Once I fixed the SO state, I hit a second, sneakier problem: I thought I was loading a clean scene before every test. I wasn't.

My first attempt was simple: call SceneManager.LoadScene(scenePath) in my setup, then immediately go find the GameObject I needed. But it was null.

I stared at that NullReferenceException for way longer than I'd like to admit. The object was right there in the scene. I could see it in the Editor. Why couldn't my code find it?

The answer was buried in a line of the Unity docs: LoadScene is semi-asynchronous. Calling it doesn't load the scene right away. It queues the load for the next frame. My setup code wasn't waiting for that frame.

The Fix: Stop treating scene loading as instant and actually wait for it to finish:

[UnitySetUp]
public IEnumerator SetUp()
{
    yield return LoadTestScene();
    ClearSelection();
}

private static IEnumerator LoadTestScene()
{
    var loadOperation = EditorSceneManager.LoadSceneAsyncInPlayMode(
        ScenePath,
        new LoadSceneParameters(LoadSceneMode.Single));

    while (!loadOperation.isDone)
    {
        yield return null;
    }

    yield return null; // one extra frame for safety
}

Was it worth the pain?

Here's the thing: none of this was new to me conceptually. I've spent 7-8 years writing Java/Spring Boot integration tests, so "isolate your state" and "don't trust a dirty context" weren't foreign ideas. I saw these problems coming before I'd even written my first test class. After all, that's just what integration testing demands, regardless of framework.

What I wasn't prepared for was how Unity-specific the actual mechanics turned out to be. But that's the price of admission: you learn the framework's quirks by tripping over them. And it was worth it.

Finally, I have a robust suite of tests for my Selection System, and I can sell the asset knowing that any future change won't quietly break it.

What about you? Do you actually write integration tests in Unity, or do you rely on the "Play button and pray" method? Let me know in the comments!

My Game's Links:
The Weight of One - Official Channel
The Weight of One - Itch.io Page

My Socials:
My Linkedin
My Personal Channel

You can find my Dev Vlogs in both Youtube channels!

On the Illusion of Architectural Choice in Unity

Mario Mignemi — Sat, 22 Aug 2026 20:25:50 +0000

I was staring at my SelectionSystem class a few days ago and realized that the public interface was completely stateless, something that immediately raised a design question I hadn't considered.

It was just a collection of logic handling lists. It didn't care about the frame rate, it didn't care about the scene hierarchy, and it didn't actually "live" anywhere. It just took a unit to select and that was it.

At that moment, I hit a wall. If the system is stateless, where the hell should it actually reside?

Now, for a bit of context: I’m building this system in a separate repository as a "test of skill" to master ScriptableObject (SO) architecture. My long-term goal is to package this up and sell it for cheap to help other developers, especially juniors, get a robust selection system without the typical "I just put everything in a singleton" headache. But to make it as easy to use as I wanted, I had to figure out the "entry point" problem.

Here is the mess I went through trying to decide where the SelectionSystem should live.

The "Comfort Zone": The MonoBehaviour Route

The instinctive move in Unity — the one we all do when we're tired or in a rush — is to just slap a MonoBehaviour on a GameObject, call it SelectionManager, and call it a day.

The Appeal: It’s comfy. You can drag and drop references in the Inspector, and you can see the system sitting right there in your Hierarchy. If your selection system is something like an RTS-style box selection, it feels natural for it to be "scene-owned" because it needs the active camera and Physics.Raycast to figure out what the player is clicking on.

The Problem: The moment you do this, you’ve basically built a prison for your logic. The system is now coupled to the scene. If you want to use this to a different scene, you have to set this up as a prefab. Also, other systems now have to find this specific instance (hello, FindObjectOfType<T>() or the dreaded Singleton pattern), and your logic is now tangled up with Unity's scene lifecycle despite not using any of its methods.

It’s great for a weekend prototype, but for a reusable package? Maybe not my cup of tea.

The "Architect's Dream": The ScriptableObject Route

Since I'm leaning heavily into SO architecture, the next logical step was to make the SelectionSystem an injectable ScriptableObject service.

The Appeal: This is where things start feeling elegant. The selection rules live in an asset. You can inject that asset into whatever needs it. The logic becomes scene-independent; you can call SelectUnit(unit) from a UI button, a custom input handler, or a debug tool without needing a reference to a specific GameObject in the scene. It plays beautifully with modular asmdef designs, keeping the orchestration separate from the scene components.

The Problem: It's a potential "Shared State" Trap. Here is where it can get weird for some junior developers. ScriptableObjects are assets. If you store runtime state — like who is currently selected — directly inside the SO asset, that state persists across scenes. You stop the game, and the unit is still "selected" in the editor. Unless it was destroyed, of course. In that case, your list now contains a null element, ready to bite back at runtime.

And then there's the lifecycle. SOs don't have an Update loop. If your selection system needs to do something, even for a single frame, you're back to needing a MonoBehaviour .

The Epiphany: "But wait... what about Split-Screen?"

While debating MB vs. SO, I hit the real wall: Instance Scalability.

I started asking myself:

What if the game is split-screen?
Suddenly, one global SelectionSystem asset isn't enough. You need two. One for Player 1, one for Player 2. If the system is a single SO asset, Player 1 selecting a unit would accidentally select it for Player 2 as well. Total chaos.

What if the AI uses the selection system to target units?
Does every single AI agent need their own SelectionSystem asset? If you have 100 of them, are you really going to create 100 SO assets in your project folder? No way.

Also, this all assumes we know the number of players/AIs ahead of time, and that's not always the case. So the question isn't just "how many SelectionSystem do I need?" anymore. It's "how do I create one on demand?"

Now, someone will (rightly) point out: "You can just call ScriptableObject.CreateInstance<SelectionSystem>() at runtime. Problem solved."

True. That API exists precisely for this. But ask yourself what you're actually getting when you do that.

The entire reason to reach for a ScriptableObject in the first place is because it's an asset. If you're using that method, you might as well use a plain C# class instead of inheriting all the overhead of aUnityEngine.Object.

The Pure C# Detour

I briefly considered going full "Clean Architecture" and making the system a pure C# domain service.

The Appeal: Maximum flexibility and testability. In theory, I don't even need the Unity Editor. No dependencies, no scene overhead, just pure logic.

The Problem: Integration friction. Pure C# might be a bit of a pain for junior developers to integrate because there's no "drag and drop" in the Inspector. You need some manual bootstrapping code to get it running in Unity.

The Solution: The Hybrid Approach

I realized that the "entry point" shouldn't be the "system" itself. The system should be the logic, and the entry point should be an adapter.

That's why "which one is better?" doesn't really hold up as a question. It's not an either/or choice. You can offer all of them.

Why I'm sticking with SO (for now)

Going through this exercise, I realized the "correct" answer is probably the hybrid approach, and let each developer decide what's best for their project.

But here's the thing: this system is a "test of skill" to master ScriptableObject (SO) architecture. Sure, this approach has real problems, but they're not problems I have right now, and limitations can be documented. Building the fully decoupled version today would be solving for a scale I don't need yet.

So I'm keeping the SO-based version as-is and rather focus on flexibility and extensibility. If one of those use cases show up for real, which is very unlikely for my game, at least I know exactly where the seams are.

What about you? Do you prefer the "everything is a MonoBehaviour" simplicity, or have you fallen down the ScriptableObject rabbit hole too? Let me know in the comments!

My Game's Links:
The Weight of One - Official Channel
The Weight of One - Itch.io Page

My Socials:
My Linkedin
My Personal Channel

You can find my Dev Vlogs in both Youtube channels!

When Rider Forgets How to Write Assembly Definitions: My Day-Long Fight With UnityAtoms

Mario Mignemi — Tue, 18 Aug 2026 05:08:47 +0000

Yesterday, adding a dependency in Jetbrains Rider was a non-event: type the class name, hit Alt+Enter, keep coding. Today, the exact same shortcut quietly stopped writing anything to my .asmdef file and it took me a full day to even understand what was going on, let alone fix it.

For context: right now, I'm working on a flexible selection system for my game The Weight of One: The Jovarko Incident, a tactical space-combat game. The project is split into several modules, each with its own Assembly Definition: Core.asmdef, Systems.asmdef, UI.asmdef, Data.asmdef, and so on. I recently added UnityAtoms through the Package Manager, and I wanted to use types like AtomEvent and AtomValueList from the Data module. Simple stuff. Except it wasn't, and here's the story of it.

The Ghost Import

The first sign something was wrong was almost funny. I'd type AtomEvent, the name would show up red (unresolved), I'd hit Alt+Enter → Reference and import, and the red would disappear. Great, dependency resolved, right?

Then I'd switch focus to the Unity Editor window to check something in the Inspector. The moment I clicked back into Rider, the exact same symbol was red again. Same file, same line, nothing touched in between.

It felt like Rider had briefly pretended to fix the problem and then changed its mind the second I looked away.

What `Reference and Import` Is Actually Supposed to Do

To be clear on what should happen: when you add a dependency through the Unity Package Manager, and you click Alt+Enter on an unresolved type that exist in an external assembly, Rider is supposed to add a reference in your .asmdef file. In my case, Data.asmdef should end up depending on UnityAtoms.UnityAtomsCore.Runtime. That's the whole mechanism that makes cross-module code work cleanly with Assembly Definitions instead of forcing everything into one giant assembly.
Except my Data.asmdef never actually gained that reference. The autocomplete looked like it worked. But the underlying file wasn’t changed, which meant the result was only cosmetic. The Rider’s syntax highlighter got a brief nap before Unity's next domain reload reminded it that, structurally, nothing had actually been connected.

The Troubleshooting Rabbit Hole

At this point, I did what anyone would do: assumed it was something dumb on my end and started working through the usual checklist.
• Invalidate Caches / Restart
• Regenerate project files from Unity
• Fully close Unity, delete the .csproj / .sln files, reopen and let them regenerate
• Clean out the Library/ folder
• Update both Rider and the JetBrains Rider Editor package
• Toggle Git packages and Built-in packages under Unity's External Tools preferences.

None of it stuck. By the end of the day, I had tried basically every standard fix in the book and I was exactly as blocked as when I started.

The Almost-Fix

Here's the one thing that worked, sort of: opening the asmdef file directly inside Rider's own editor and adding the reference by hand. Mind you, not through Unity's Assembly Definition Inspector. Through the raw file directly. That would sometimes get the symbols to resolve and stay resolved.

Sometimes. Not always. And I still haven't figured out what actually triggers it to break again. It's not tied to a specific action I can reproduce on demand, which is the most frustrating kind of bug: the kind where your "fix" is really just a temporary appeasement ritual and nothing else.

Why This Bugs Me More Than a Normal Bug

Well, it turns out I wasn't the only one blindsided by this either. A bit of digging turned up RIDER-94834 on JetBrains' YouTrack, a closely related report of asmdef references not being persisted correctly.

And what gets under my skin isn't that the bug exists — software breaks, that's just how things go. It's how it fails. Nothing about the UI hinted that the import hadn't actually landed on disk. That distinction matters to me.

If package-sourced assemblies are a known blind spot for Rider, that's fine. It's a limitation, and limitations are forgivable. What isn't forgivable is showing that everything is ok when something silently fails. If Rider doesn’t support this type of import, say so: a warning banner, a tooltip, a line in the changelog. Anything beats finding out, after a wasted day, that it’s a visual bug.

I'm not saying this to pile on. I pay for Rider, and it earns that money close to 100% of the time, which is exactly why this one stings. The bar is set high, and watching a core part of the Unity workflow quietly fail with zero warning felt genuinely out of character.

What's Next

I've since opened a thread on the Rider support forum.

If this problem sounds familiar to you, don't just quietly work around it, please. Go upvote and comment on both the thread and the YouTrack issue. A pile of "me too" moves the needle.

For now, I'm sticking with the manual-edit workaround and treating every successful Alt+Enter import with deep suspicion until I've actually reopened the file to confirm the reference stuck. Not a great long-term workflow, but it's hopefully unblocking me for the moment.

Has anyone else seen asmdef references silently drop the moment you switch focus between Unity and Rider? If you've found a workaround that actually holds, not just "sometimes" but reliably, I'd really like to hear it in the comments.

My Game's Links:
The Weight of One - Official Channel
The Weight of One - Itch.io Page

My Socials:
My Linkedin
My Personal Channel

You can find my Dev Vlogs in both Youtube channels!

How a Broken Button Forced Me to Rebuild My Entire Architecture

Mario Mignemi — Sat, 15 Aug 2026 16:53:48 +0000

A few weeks ago, I hit a deadlock that took me an embarrassingly long time to fix: I couldn't have a shuttle without a button, and I couldn't have a button without a shuttle.

Here's why. My four-year-old button system required a live GameObject reference to be valid: no reference, and the button would self-destroy. Fine for a button that operates on a ship already sitting in the scene. Not fine for a boarding shuttle, which doesn't exist until a button spawns it. So the button needed the shuttle to exist to avoid self-destruction, and the shuttle needed a button to exist to spawn. Neither one could go first.

The bug wasn't in the shuttle. It was in a button that was four years old.

I'm building The Weight of One: The Jovarko Incident, a tactical space-combat game where you command a capital ship and its subsystems. The shuttle in question is a small craft you launch from your own hangar to either forcibly dock an enemy ship from the outside, or peacefully move into the hangar of a neutral or allied ship. Simple concept. It broke everything I had.

This post isn't really about the shuttle, though. It's about the module structure I ended up building because of it, and whether drawing hard boundaries — before writing a single line of code — was worth the friction it's currently causing me.

Every button in my prototype came with a spaceship stapled to it

My original UI code, written during early prototyping, made buttons stateful. A ButtonModel held a direct reference to the ship it operated on, and if that reference wasn't there, another script would destroy the button on the spot:


    // Pseudo-Code
    public class ButtonModel : MonoBehaviour
    {
        public Transform linkedShip;
    }

    public class SelfDestructOnDestroyedObject : MonoBehaviour
    {

        private ButtonModel model;

        ...

        private IEnumerator OnLostReferenceDestroySelf()
        {
            ...
                    Destroy(gameObject);
            ...

That's fine when the ship already exists in the scene before the button does, which has been the case so far. However, for a shuttle, it's exactly backwards: the button is what's supposed to trigger the creation of the gameobject. The classic Mexican standoff.

I don't blame past-me for this. It was prototype code from 2021-2022, and it did its job for years, until it didn't in 2026. But I'm not the type to bolt on a special case just for shuttles and move on. If I have the feeling that the design is wrong, I want to know why and fix it.

Making the button stop caring whose ship it was

The fix felt obvious once I named the actual problem: the button shouldn't hold a reference at all. It should announce an intent and let something else figure out the target.

Stateless buttons break the deadlock cleanly. The catch: something still needs to track which button maps to which ship. There’s no getting around it. That something is basically a lookup — conceptually a Map<Button, Spaceship> — and I didn't want a bare dictionary sitting inside a MonoBehaviour pretending to be a service, and six months later nobody remembers what it's for.

Down the ScriptableObject rabbit hole

I had used ScriptableObjects for exactly one thing before this story: configuration data. Stat blocks, balance numbers, that kind of thing. Looking into how larger studios structure decoupled systems, I found a much bigger use of SOs: as runtime variables, event channels, and typed runtime sets that replace both generic EventBuses, which I've been using so far, and direct references.

It solved my mapping problem cleanly.

What it didn't solve was a bigger question: full rewrite, or hybrid architecture? I have no problem resetting and rebuilding systems, that's genuinely part of why I enjoy programming. However, a full architectural rewrite of a project that's somewhere between a prototype and an actual demo is a different bet than restructuring one feature. So I picked a feature that didn't exist at all — a flexible mission system — and decided to build it entirely with a ScriptableObject architecture in a separate project, as a real test.

Drawing five boxes before writing any mission code

Before touching the mission system, I made one decision on purpose: assembly definitions, not just folder conventions, would decide where files were allowed to live. In fact, almost everything I came across about SO architecture — articles, videos, you name it — flagged a common problem: every variable, event channel, and runtime set is its own small asset, and that adds up fast.

A feature that used to be two files in the old EventBus system could easily turn into five or six files. Left unorganized, that adds up into a mess fast, so I wanted the boundaries locked in from day one.

Five main modules, five assemblies:

Core: Generic, game-agnostic primitives — base SO wrappers, generic interfaces, extensions
UI: Draws to Canvas/Screen, captures interface input, raises intent events
Data: SO Variables, Event Channels, Runtime Sets, and config schemas — no Update() loop
Gameplay: Moment-to-moment entity behavior like movement, combat, mission triggers.
Systems: Global, cross-scene infrastructure, like save/load, scene transitions, campaign progress.

Dependency graph:

The one rule that makes the other five make sense

None of this is exotic on its own. Assembly definitions weren't new to me, but I’ve never actually reached for them. Game development isn't my day job, so they just weren't on my radar until now.

This is the part that maps directly back to the shuttle deadlock. The old ButtonModel was a compile-time UI-to-Gameplay dependency wearing a MonoBehaviour costume. The new rule makes that specific mistake impossible to write by accident. The assembly definition simply won't allow it.

Where the shuttle actually landed

Here's the part I want other people to take away from this. Understanding ScriptableObject architecture hasn't stopped me from placing files where I think they belong, only to have the assembly definition reject them.

At first, this was annoying. Then I noticed a pattern: every one of those errors was telling me one of two things. Either the file is genuinely misplaced, or the code design underneath it is wrong: future tech debt I hadn't noticed yet, because nothing was preventing me from writing it that way.

Is it paying off?

Honestly, provisionally, yes! But I'm not going to pretend the trade-off is free: having a ScriptableObject architecture and five modules means more files, which adds real ceremony for a solo dev before any feature ships. There's no dodging that.

I picked the mission system specifically because it was new territory: a contained way to test the architecture before betting the rest of the game on it. I'm treating that as a deliberate validation step. I want to see it hold up across a few more features before I call it the standard.

On the plus side, what I didn't expect was how much the friction itself became useful information. Every misplaced file is a small, cheap lesson about my own design, delivered immediately instead of six months later as an unmaintainable spaghetti mess.

If you're staring down a similar dilemma, the one thing I want you to take from this “happy accident” is: don't draw module boundaries as folders, draw them as dependency "permissions". Enforce them with assembly definitions, and let the compiler be blunt with you.

This whole approach is a sharp departure from the generic EventBus pattern I used to lean on, which is a big enough topic to deserve its own post. For now: I'll keep building the mission system and report back on whether five assemblies still feel right once the feature list grows.

Developers unite! Let me know how you've drawn your own lines.

Useful Links:
The Weight of One - Official Channel
The Weight of One - Itch.io Page
My Personal Channel

You can find my Dev Vlogs in all channels!

DEV Community: Mario Mignemi

GLM-5.3-Flash: A Geopolitical Disruptor Hiding in an Ultra-Cheap Model

The End of Nvidia Monopoly

Can it Survive the Jovarko Incident?

Beyond Task Completion: Contextual Awareness

Optimizing for Today, Ignoring Tomorrow

AI for the Rest of Us

Looking for a New Equilibrium

#gamedev

How Dyslexia Taught Me to Write Idiot-Proof Docs

The Quest for a Better Bridge

Going Local: Quality Over Speed

The Modern Workflow

The Stigma of the "Shortcut"

The Invisible Labor

Your Unity Tests Are Lying To You (Here's Why)

The "Shared State" Trap (Again)

The Frame I Forgot to Wait For

Was it worth the pain?

On the Illusion of Architectural Choice in Unity

The "Comfort Zone": The MonoBehaviour Route

The "Architect's Dream": The ScriptableObject Route

The Epiphany: "But wait... what about Split-Screen?"

The Pure C# Detour

The Solution: The Hybrid Approach

Why I'm sticking with SO (for now)

When Rider Forgets How to Write Assembly Definitions: My Day-Long Fight With UnityAtoms

The Ghost Import

What Reference and Import Is Actually Supposed to Do

The Troubleshooting Rabbit Hole

The Almost-Fix

Why This Bugs Me More Than a Normal Bug

What's Next

How a Broken Button Forced Me to Rebuild My Entire Architecture

Every button in my prototype came with a spaceship stapled to it

Making the button stop caring whose ship it was

Down the ScriptableObject rabbit hole

Drawing five boxes before writing any mission code

The one rule that makes the other five make sense

Where the shuttle actually landed

Is it paying off?

What `Reference and Import` Is Actually Supposed to Do