Coder Legion - Recent posts tagged unity3d

Aesthetic Trading Automation for Binance

Fri, 09 Oct 2026 05:01:21 +0000

I had an idea waiting up in the pipeline and finally decided to raw the cover over it. I created a trading automation tool which uses multiple trading algorithims under the hood to maximize the gains. I tested 7 different trading algorithimns in 15 different configurations across 12 coins and lab run them in a terminal. However, it turned to be super boring and tedious considering I had to run them time and again for specific intervals.

In order to make it interesting, I turned up my Unity Editor and rolled out a scene to glamour-covering it. I used my claude code to give it a cyberpunk outlook and make the main tower look like a wall street for crypto. Every single tower around the main tower represents a specific algorithim and the respective traded coin.

Note: I have used virtual currency in my project but the models are being trained on the real data. My unity project is linked with my python server through web socket and I am using 3 minute interval candle for training my algorithims.

Tech in qustion: Binance, Python, Unity 3d

using unity access to create a basic seen. What works and what still needs developing

Thu, 17 Sep 2026 06:11:07 +0000

Since development of unity access has gone so well, I have been able to have most of the basic features built. This means that I was able to begin testing it to see if it would be viable to use in the long run.
I did this by building a basic first person seen.

Building The Scene

I started with a blank unity seen and created a capsule, using the game objects menu in the menu bar.
I then used the accessible hierarchy to find the capsule.

I then renamed it to player.

Next, I added the components to the player object that will be needed for the game.

I then used the same process to add a ground and 2 walls.

overall, I found the new plugin to be much easier than using unity's editor or writing the code to create each object. However, there is still room for improvement.

what to work on next

Now that I have the basic features in place I need to work on a way for the unity access plugin to be integrated into the editor asset system. At the moment I have to move and rename assets in file explorer. This could cause reference errors if I forget to move a .meta file with the asset it is attached to.
I also want to build a material system. The alternative would be to write the code for the objects materials. However, a material system would give me added convenience when adding shaders or effects.
{% card %}
If you want to follow along with the development of Unity Access or check out the code, you can find the repository over on GitHub!
{% endcard %}

join the conversation

what problems have you faced when developing plugins for unity?
Have you done anything around accessibility?

using Codex to build unity_access. Whats worked, what hasn't and tips for building your own accessible applications with AI.

Thu, 17 Sep 2026 06:09:52 +0000

Over the past week, I have been vibe coding Unity Access, a plugin for the Unity Editor that makes the previously difficult-to-access editor more screen-reader compatible.

Unity Access uses the NVDA API alongside the Unity Editor API to create a bridge between Unity and the NVDA screen reader.

I have been using Codex for the programming, and it is for this reason that I wanted to write this post. During the development of Unity Access, I have learnt a lot about using Codex to develop an accessible application that tutorials and documentation simply do not cover.

One of the biggest lessons I have learnt is that building accessible software with AI requires considerably more than simply telling the model to "make it accessible". Accessibility needs to be expressed as specific, testable behaviour.
In this post, I will describe what worked, what did not work, how you can build your own accessible applications, and some of the things you should watch out for.

Tools and technology

Before I get into the details, I feel it is important to describe the tools and technology I use. This is because some of the results I experienced may differ from those of someone using different tools.

To write the code for this project, I used Codex running GPT-5.6 Sol with medium reasoning effort.

For my work, I found this to provide a good balance between efficiency, cost per one million tokens and quality of output. These factors are particularly important to me because I want to achieve the best possible result while keeping token costs as low as reasonably possible.

To write the Markdown specification files, I used VS Code. I chose this editor because it works extremely well with the NVDA screen reader. This means I can use it out of the box without accessibility modifications.

This is particularly important to me as a blind developer because it gives me a great deal of flexibility and independence. I can navigate the project, read and edit code, organise files and review changes without relying on inaccessible visual interfaces.

To test the plugin, I am using Unity with a sample project based on the Universal Render Pipeline (URP).

I chose Unity because I find its GameObject and component architecture easier to understand and work with. Even though Godot already has an established plugin for editor accessibility, I personally found its tree structure harder to reason about.

Finally, to read what is displayed on my screen, I use the NVDA screen reader.

I use NVDA because it is open source and therefore does not come with licensing fees. In addition, I have found its ability to read my code editor and source code to be superior to JAWS for my particular workflow.

Together, these tools allow me to understand what is happening on my computer and to develop, run and test my code independently.

Building the plugin: what worked and what doesn’t

What worked?

During my experience with different AI models, I have found that each has its own quirks and characteristics. Codex with GPT-5.6 Sol is no exception.

Here is my list of things that worked well, and continue to work well, when developing Unity Access.

Setting clear boundaries in the root AGENTS.md file.

This might seem obvious, but clear rules and boundaries make an enormous difference.

Tell the model where it is allowed to make changes, which APIs it should use, which files it should or should not modify, how large you want changes to be, what accessibility requirements apply, and what must be true before the task can be considered complete.

The more specific these rules are, the more predictable the model becomes.

This becomes particularly important when developing an accessibility-focused application or plugin.

For example, in my experience, telling the AI:

"The user must be able to navigate this menu using NVDA."

produces much better results than simply saying:

"Make this menu accessible."

The first instruction gives the AI something concrete to work towards.

You can make this even more specific by defining what navigation actually means. For example:

every interactive control must be reachable using the keyboard;
NVDA must announce the purpose of each control;
the current value or state of the control must be available to the user;
controls must be usable without a mouse; and
the user must be able to leave or return from the interface using the keyboard.

This gives the AI a measurable target rather than an abstract concept.

I have found this to be one of the biggest differences between simply asking AI to produce "accessible" software and actually getting useful accessibility behaviour.

Setting boundaries around the size of changes is also useful. If you tell the AI that you want a small, direct change, it is less likely to waste tokens modifying or refactoring an entire file when only a small section needs changing.

Standardising functions such as buttons and text boxes.

Standardising functions for things such as buttons, text boxes and other controls, and placing them in a utilities folder, has been extremely useful.

You can reference these utilities in future Markdown specification files and instruct the AI to call those specific methods. This prevents the AI from recreating the same utility every time it needs one.

More importantly for an accessibility project, it prevents subtle variations from appearing throughout the application.

For example, instead of allowing Codex to invent three different ways of creating an accessible button, I can create one accessible button utility and tell it:

Use the accessible controls located in ./utils.

That makes accessibility behaviour much more consistent throughout the project.

It also means that if I improve one of the shared accessible controls later, every part of the plugin that uses that control can benefit from the improvement.

Organise your code into related folders.

This is not just useful for the AI. It is also extremely useful for screen-reader users.

Navigating a properly organised folder tree using NVDA is considerably easier than searching through a large collection of files, particularly when files have similar names.

Because I am using a CLI, I can also set the working directory to a particular folder and instruct the AI not to add or modify code outside that directory.

This gives me another layer of protection against the AI modifying working code elsewhere in the project and potentially introducing bugs.

For a Unity project, where the complete project can contain a large number of generated and engine-related files, a properly configured .gitignore is also extremely useful.

This means I only need to commit the actual plugin and relevant project files rather than the entire Unity project.

An organised folder structure also makes relative paths easier to reference in Markdown specification files. Instead of telling the AI vaguely to find a particular file, I can tell it exactly where that file should exist.

Separating UI functionality from backend functionality in AGENTS.md files.

Separating UI requirements from backend functionality in my Markdown specification files has worked extremely well.

This is particularly useful when creating an editor plugin.

For example, I can have separate sections describing:

what the interface should contain;
how keyboard navigation should work;
what NVDA should announce;
which backend functions are required; and
which Unity Editor APIs should perform those operations.

This means that if I want to change the UI without changing the backend, I can instruct the AI to work only within the relevant section.

Likewise, if a backend function needs replacing, I can make that change without unnecessarily redesigning the interface.

It also makes the specification much easier for me to read and maintain.

If there is a particular function or UI element that I later decide to remove, it is considerably easier to find and remove when the requirements are separated rather than buried inside one enormous paragraph.

Keeping Markdown specification files concise and structured.

I found that keeping my Markdown files to the point, while adding a short description at the top explaining the purpose of the file, helps keep project requirements clear and reduces the likelihood of the AI misunderstanding what I intend.

Previously, I wrote many of my specifications almost like essays.

That did not work particularly well.

The AI would sometimes overlook tasks or functionality described earlier in the file and concentrate disproportionately on instructions appearing later.

Breaking the specification into properly organised headings and sections does not just make it easier for me to read with NVDA; it also appears to make it easier for the AI to understand which requirements belong together and remain within scope.

The goal is not necessarily to make specifications tiny. The goal is to make every requirement easy to find and difficult to misunderstand.

Now, this all makes it sound as though my project went well. However, here are some things that did not work and that I only found out later.

What doesn’t work

Having ChatGPT write parts of my Markdown specification files without validating them.

Having ChatGPT write parts of my Markdown specification files initially seemed like a great way to fill gaps in my own Unity knowledge.

However, I discovered that this comes with risks.

Although ChatGPT can research and write code effectively, I found that asking it to define technical requirements for parts of Unity that I did not already understand could cause problems if I accepted the output without checking it.

One example was my project_settings.md file.

Because I did not know exactly what should be included in an accessible Unity Project Settings implementation, I asked ChatGPT to help create the specification.

It not only missed a substantial number of the project settings I actually needed, but also provided Codex with outdated API references.

Codex then implemented those instructions.

The resulting errors caused Unity to enter Safe Mode, and I had to spend additional time and tokens debugging and correcting the implementation.

This does not mean that using AI to help create specification files is a bad idea. I still do it.

The lesson I learnt is:

Do not use one AI's output as unquestioned technical truth for another AI to implement.

If the AI is filling a gap in your own knowledge, that is precisely when validation becomes most important.

Proofread what it gives you, question anything that does not look right and, where possible, compare technical requirements against the current official documentation before allowing another AI agent to build from them.

Having code for buttons and text boxes scattered around the project.

Before I standardised my buttons, text boxes and other controls, UI-related code was scattered throughout the project.

This did not work particularly well.

If I did not provide Codex with a standard way of creating text boxes, buttons and menus, it would attempt to create its own variations.

Those variations did not always provide the accessibility behaviour I expected.

For accessibility, this is particularly problematic. A user should not have to experience different keyboard behaviour simply because three different interfaces were generated at different stages of development.

I found that it is much better to provide Codex with standardised subsystems that it can reuse rather than expecting it to independently understand your accessibility best practices and reproduce them consistently throughout an entire project.

Changing my model halfway through the project.

Changing my model halfway through the project turned out to be a mistake.

I switched from GPT-5.6 Sol to GPT-5.6 Lunar because of the potential cost savings.

However, for the particular work I was doing, I noticed a substantial drop in performance.

Lunar was not handling the larger project-level task as successfully as Sol. For my workflow, I found it better suited to smaller, more tightly focused tasks than something as substantial as creating an entire accessible asset viewer.

I ended up using a significant number of additional tokens trying to correct the resulting problems.

Eventually, I returned to GPT-5.6 Sol to repair the implementation. Parts of the asset viewer had to be substantially rewritten, and I also discovered that some of the accessibility requirements I had defined were no longer being followed consistently.

The lesson for me was:

The cheapest model per token is not necessarily the cheapest model for the overall task.

If a less expensive model requires several attempts, introduces bugs or requires another model to repair its work, the apparent saving can disappear very quickly.

Model selection should therefore consider the complexity of the task, not simply the advertised token price.

How to build your own accessibility-focused app or how to modify an existing app to be more accessible

When making an app, if it is intended to be accessibility-focused, it is best to start with accessibility in mind from the beginning.

There is little point building your entire UI and then discovering that screen readers or other accessibility tools cannot interact with it.

You are likely to save both tokens and development time by designing accessibility into the application from the start.

Do your research. Read the latest accessibility guidelines, but also read the documentation for the particular assistive technologies you want your application to support.

If you are using AI agents, provide them with clear accessibility requirements and best practices in the root AGENTS.md file for your project.

Do not simply write:

"Make everything accessible."

Define what accessible actually means for your project.

For example:

"All menus must be usable entirely with the keyboard and every interactive control must expose enough information for an NVDA user to understand its purpose, current state and available action."

Specific requirements give the AI something that can actually be implemented and tested.

Before implementing a custom accessibility solution, also investigate what your framework already provides.

There is little benefit in implementing an entire screen-reader-compatible UI system from scratch if the framework you are using already provides accessible controls that meet your requirements.

Using existing functionality can save considerable development time and allows you to focus on the places where custom accessibility work is actually necessary.

The same principle applies to other accessibility features: use the platform or framework's existing accessibility functionality where it is suitable, and build custom solutions where it is not.

Finally, if you are unsure whether the accessibility features you are implementing actually work for the people you are trying to support, ask them.

Find a forum, Discord community or other group containing the people your application is intended to serve and ask for feedback.

Ask what is confusing.

Ask what their screen reader announces.

Ask what takes too many keystrokes.

Ask what they cannot reach at all.

Most of the time, people will be willing to explain what works, what does not work and what could be improved.

An AI model can help implement accessibility, but it cannot replace feedback from the people who actually depend on those features.

For me, one principle has become particularly clear throughout this project:

Do not tell AI to "make it accessible". Tell it exactly what an accessible user must be able to do.

Contribute to the discussion

Have you ever used AI to make something more accessible?

If so, what worked well for you, and what mistakes or unexpected problems did you encounter?

FludeX v1.1 — Runtime Debug Platform

Tue, 26 May 2026 14:57:19 +0000

FludeX v1.1 is live.
The Console module is now available — full runtime log access directly in your Unity build, no editor connection required.

What the Console module includes:

Search across all logs
Filter by log type — errors, warnings, logs
Resizable stack trace view
Copy log to clipboard
Ring buffer storage with configurable capacity and memory usage insight

Also in this update:

Toast feedback for button actions — surfaces success, failure, and unhandled exceptions automatically
Void button overloads — Action and Func complete silently unless an exception is thrown
IConfigurableModule — modules can now expose their own settings view via a settings button in the app bar

FludeX is a modular runtime debug platform for Unity built on UIToolkit and AppUI. Available on the Unity Asset Store.

Asset Store · Documentation · WebGL Demo

REBEL HEARTS alpha demo build 0.192

Thu, 05 Mar 2026 21:53:08 +0000

alpha demo build 0.1922

This is a early playable network test for my isometric TacticalRPG concept. I plan on
iterating to build 1.0 implementing any valuable constructive feedback received during this
development cycle. This build is intended for testing connectivity, turn order, and squad
interactions! - gameplay is minimal and unfinished.

Dir: RebelHearts_demo\Win64bit_build\RHE.exe
Platform: Windows
Resolution: Fixed Fullscreen 1920×1080
Players: 1 to 2 (3 including enemy AI)

How to Connect
• Host starts the game on Windows and clicks “Host”. Host shares their public IP with the other player.
• Client launches the game and clicks “Join”, entering the host’s IP.
Additionally ensure your port: 7777 is open and that the firewall allows the prototype. That's it! Now start playing.

Good to Know'
• Player 1 Host gets priority turn first. Player 2 Remote Client can only observe the current player' actions until
their turn is over & vice versa.
• Turn over is executed only when the current player has selected 'Done' on each of their squad members 'Engange Menu'
options.
• You have 'Move', 'Attack', 'Status' and 'Done' options per squad member.
• You are NOT locked into Attacking or Moving in a particular order. However, when you select one of these two options,
you will be required to follow through with it.
• When ALL opposing player, or yourself have no more squad memebers left, the 'game' is over. You will have to hard quit
for time being (easily enough done).
• Squads are locked into spawning the same stats and equipment for now.

Conclusion
I'm looking for feedback on your network experience & other thoughts - suggestions!
Please ping me your feedback at any of the below!

Emails are not allowed
https://x.com/wildlogicgames
https://wildlogicgames.itch.io/
https://www.linkedin.com/in/ricky-wild-ab73b067/

Thanks for play testing - you are a cool person!

BUGS

build 0.1922
+Correct squad banner colours applied to Battle UI.
+Defend chance fixed - squad members - if capable of block - will now block on success roll.
+Other small quality of life fixes.

build 0.1921
+Previous issues fixed. Counter-Attack system re-written.
+Last squad standing is now winner.
-Player 2s view on other squad members sometimes loops during/for movement animations.
-Last Player to kill remaining Enemy AI squad member wins, despite other player squad remaining.

build 0.191
-Enemy AI Idles after a counter attack from Player Turn Attack.
-Enemy AI Idles after squad member death during counter attack from Enemy AI Turn Attack.
-Player Turn idles due to blocked mouse cursor input, following from Enemy AI Turn.

build 0.190
-Player 2 Turn hard crashes during counter attack with Enemy AI AND/OR Player 1 Turn.

DevLog 20260122: Some Notes on MAUI, Unity, and Building "Map-Like" App Across Platforms

Fri, 23 Jan 2026 03:06:32 +0000

I've been meaning to write about this topic for a while.

MAUI looks great on paper. In fact, it has looked good on paper for years. Microsoft went a long way through UI and application frameworks: VBA, WinForms, MFC, WPF, Silverlight, UWP, Blazor, and now MAUI. Each iteration promises unification, abstraction, and better productivity over platform differences.

My first attempt at MAUI felt deceptively easy. I gave up shortly after.
So did the second attempt.

This time was different: I had a concrete delivery target. Giving up was no longer an option.

The Problem: A "Map-Like" Feature

The concrete requirement was simple to state but not easy to implement well: an app with a map-like feature. Not a full GIS stack, but something that looks and behaves like a map - large static textures, panning, zooming, overlays, and user interaction. No library - we are going to implement things from ground up.

My first instinct was to go cross-platform. After years of writing platform-locked GUIs that die the moment requirements change, I had no interest in repeating that mistake.

After surveying a wide range of options - inside and outside the C# ecosystem - I narrowed the choices down to:

Unity
Godot
MAUI

I tried Unity first.

Unity: Smooth Onboarding, Rough Reality

Unity deserves credit where it's due. It was the first mobile platform I ever used seriously, and I had already developed an Android game with it years ago.

Coming back with significantly more experience in C#, general software engineering, and game development, the onboarding felt excellent. The editor is mature, the documentation is decent, and the mental model is comprehensible.

Within about three days, I felt comfortable again - comfortable enough to implement the prototype. The implementation itself was straightforward (details skipped here), but the result was not.

On an actual Android device, performance was terrible. Given time pressure, I didn't fully chase down the root cause. A few hours of profiling and hypothesis testing later, I made the call to bail. Whether the issue was overdraw, batching, UI layout, or just the wrong API for the task didn't matter anymore - the risk was too high. (Oh, did I mention the build size was gigantic?)

I would have liked to include some demo code - at least the Unity version - but time didn't allow for it. That will have to wait for another post or a future amendment.

MAUI: Dry, and That's a Compliment

Rewriting the same idea in MAUI worked. Not "worked eventually" - it worked immediately and predictably. (Actually I tried Expo before MAUI, which was very smooth, then I looked at the hundreds of dependencies, and quietly reconsidered)

That forced me to rethink a long-held assumption (something I had from the CG world): engines optimized for real-time rendering should be good at texture-heavy workloads. In practice, frameworks optimized for application UIs are often better at static or semi-static content - especially when the interaction model looks more like "pan and zoom" than "render 60 FPS no matter what."

MAUI was dry. I wasn't excited to see its "mobile-like" layout on a Windows screen, and I still am not.
But dry was exactly what the project needed.

The Hidden Cost

That said, this experience didn't magically make me like MAUI - and that reminds me of Blazor.

The core issue in both cases is structural. These frameworks attempt to abstract over domains whose constraints diverge in important, non-accidental ways. The abstraction holds only as long as the application stays within a relatively narrow envelope of complexity.

MAUI Issues

Cross-platform inconsistencies are everywhere, not edge cases.
iOS AoT compilation and trimming can cause things to silently stop working.
Many behaviors that should be easily configurable (for example, disabling the Flyout) require platform-specific code.
Debugging failures caused by trimming or linker behavior is disproportionately painful.

Blazor Issues

Refactoring is far harder than it should be.
Large component trees quickly become rigid.
Abstractions that feel elegant early on tend to resist change later.

In both cases, the abstraction breaks - and when it does, you're often forced to drop down into platform-specific or framework-specific escape hatches that defeat the original promise.

These frameworks scale poorly in complexity, not because they are badly designed, but because they attempt to simplify domains that fundamentally resist unification. (Well, honestly in the case of MAUI I do think there are some design issues)

In general, MAUI is slightly better, because it's at least well encapsulated - just write platform-specific codes.

Some Takeaways

Game engines are not automatically good UI frameworks. Application frameworks may outperform engines for static, interaction-heavy visuals. In this particular case I haven't tried Godot, but I suspect the same issue wouldn't happen to Godot.
"Write once, run anywhere" really means "debug everywhere." And don't expect MAUI can save you effort because platform-specific behaviors are everywhere and it took me lots of time to back trace which seemingly trivial change many commits ago caused the entire application to break; Or, just turn off the magic MtouchUseLlvm.
MAUI is an OK choice for simple cross-platform mobile apps in C#.
Unified frameworks seem to trade short-term velocity for long-term friction. In the perfect world, I will use Swift for iOS.

In general, I wish framework developers make it clear their limitations so decision making can be made upfront.

Solo Creation: Games and the Psychology Behind Them

Fri, 16 Jan 2026 08:56:00 +0000

Hi, I'm Lucas from Poland :) I work primarily as a solo creator.
Most people know me from the technical side - building games, systems, prototypes, and shipping projects on my own.

But over the years, I’ve become just as interested in the psychological side of solo creation.

What happens when you’re alone with decisions for too long?
How motivation changes after the initial excitement fades?
Why some projects slowly die - not because of lack of skill, but because of mental friction, fatigue, or loss of meaning?

Solo game development isn’t just about tools and code. It’s a long-term mental process: identity, resilience, energy, doubt, and learning how to stay in the game long enough to finish something.

These questions now influence how I build games, how I structure my work, and how I think about creative sustainability.

I’m still making games solo. I’m just paying more attention to what’s happening inside the creator, not only inside the project.

FIGHT NIGHT ANNOUNCEMENT: The Lightweight Challenger vs. The Heavyweight Champ

Wed, 03 Dec 2025 23:20:00 +0000

In the Red Corner: Weighing in with a massive learning curve and complex boilerplate... the reigning champion of performance: Unity ECS (DOTS)!

In the Blue Corner: Weighing in at a lean 45kb... the Object-Oriented underdog: FSM_API!

We are preparing for the ultimate showdown.

THE ROAD TO THE TITLE FIGHT:

Before we step into the Unity Ring for the visual bout, we had to prove the challenger could take a punch. We put the FSM_API through "The Gauntlet"—a raw, Console-Only C# simulation involving 66,000 active agents ("Quick Brown Foxes" vs. "Lazy Sleeping Dogs").

The results were bloody. The performance was undeniable.

THE TALE OF THE TAPE (The Articles):

Round 1: The Massacre (Benchmarks)
See the breakdown of the "Silent Hordes" simulation where we maintained a stable 30 FPS under massive idle load.
Read the Benchmark:
https://coderlegion.com/8009/the-quick-brown-fox-2-the-silent-hordes

Round 2: The Training Camp (Optimization Deep Dive)
A true fighter knows their weaknesses. In this second technical breakdown, I expose the raw memory profiles. I’m embarrassed to admit how much optimization headroom is still left on the table—which is terrifying, because even unoptimized, our extrinsic benchmarks are putting us in contention with the Champ (ECS).
See the Optimization Data:
https://coderlegion.com/7988/the-control-group-benchmarking-the-dirty-version-of-my-fsm-api

COMING SOON: THE MAIN EVENT
Stay tuned for our next article, where we bring the carnage into the Unity Scene View.

Will the lightweight 45kb DLL show its raw digital power? Or will the heavyweight bloat of ECS deliver yet another TKO?

Get to know the Challenger before the bell rings:

Asset Store ($30):
https://assetstore.unity.com/packages/tools/behavior-ai/the-singularity-workshop-fsm-api-advanced-332450

GitHub (Free):
https://github.com/TrentBest/FSM_API

Coach's Advice:
"Don't step into the ring without the right gear, kid. Grab the package. It's on the house."
NuGet (Free):
https://www.nuget.org/packages/TheSingularityWorkshop.FSM_API/#supportedframeworks-body-tab

Support Our Work:

Patreon Page:
https://www.patreon.com/c/TheSingularityWorkshop

Support Us (PayPal Donation):
https://www.paypal.com/donate/?hosted_button_id=3Z7263LCQMV9J

The Blender ↔ Unity Axis & Scale Problem: A Complete Technical Guide

Wed, 03 Dec 2025 21:45:56 +0000

The Blender ↔ Unity Axis & Scale Problem: A Complete Technical Guide

(and How Unit & Scale Doctor Pro Solves It Reliably)

1. Introduction — The Silent Production Killer

Every 3D developer eventually encounters the classic trap:

“It looked correct in Blender… but Unity imported it wrong.”
Rotations are flipped.
Objects appear microscopic or gigantic.
Animations distort.
Rig orientations break.
Prefabs drift or rotate 90°.
Root bones flip forward.

This is not user error—it’s the unavoidable result of two unrelated coordinate systems colliding.

Unity and Blender simply do not speak the same native “3D language.”

This article is a deep dive into:

Why scale & axis mismatches occur
The real mathematical and pipeline causes
Why attempting to ‘just apply transforms’ is unreliable
How to manually fix models in a production-safe, deterministic way
How to automate everything with Unit & Scale Doctor Pro

If you build technical art pipelines, maintain game studios' asset workflows, or run multi-DCC pipelines, this is essential knowledge.

2. The Root Cause — Two Worlds, Two Coordinate Systems

Blender uses:

Unit: Meters by default, but functionally unitless
Axis: +Z up, +Y forward
Object default scale: (1,1,1)

Unity uses:

Unit: Meters but 1 Blender meter ≠ 1 Unity meter without context
Axis: +Y up, +Z forward
FBX importer behavior: secretly compensates, inconsistently

The Fundamental Conflict

Blender’s Z-up means the “world up” vector is different.
Unity’s Y-up means the “world up” vector is different.

This leads to the classic 90° rotation offset, often around X or sometimes Z, depending on export settings.

The scale mismatch is even worse:

Blender’s grid scale ≠ the FBX exporter’s unit scale
Unity’s FBX importer applies hidden conversions
Blender’s “Apply Scale” resets object-level scaling but alters animation meaning
Armatures store rest pose matrices relative to Blender’s coordinate system

If you think this sounds messy—you’re correct.
And every studio spends hundreds of hours per year fighting it.

3. The Axis Dichotomy — Why Objects Rotate Wrong

Case 1: Blender to Unity Rotation

Blender’s +Y forward is Unity’s +Z forward.

Converting between the two requires:

Rotation = Rotate -90° around X

But this is only correct for static meshes.

For rigs, bones, animation curves, constraints, and IK solvers:

The armature object must rotate
Every bone’s roll must be corrected
Animation keyframes must be reinterpreted

If you simply “apply” the rotation:

IK chains break
Pose orientation becomes invalid
Animation curves produce different results
Bone roll becomes inconsistent (critical for weapons, fingers, mechanical rigs)

This is why the internet is full of contradictory advice—
because most of it works for simple meshes, but destroys complex rigs.

4. The Scale Dichotomy — Why Objects Import Too Small or Too Large

Key misconception:

“Blender units = meters = Unity meters.”

This is only theoretically true.

Here’s the reality:

Blender's Exporters

FBX exporter has hidden unit scaling
glTF uses meters but assumes Z-up needs conversion
OBJ has no unit semantics
CAD imports often come in cm/mm

Unity’s Importers

FBX importer has a Scale Factor (sometimes 0.01)
Legacy FBX workflows still assume Maya’s centimeter world
glTF importer assumes meters
CAD importers assume millimeters
Custom pipelines override scale silently

In practice, you see:

Assets 100× too small
Assets 1/100th expected size
Rigs where animation offsets are scaled differently
Physics collider mismatches
Prefabs with broken child offsets

Scaling is not universal.
Scaling is hierarchical, order-dependent, and context-dependent.

“Apply Scale (Ctrl+A)” solves nearly nothing reliably across a full production pipeline.

5. Why "Apply All Transforms" Is a Pipeline Trap

Applying rotation & scale at the object level seems tempting—but it is destructive:

It breaks:

Animation tracks
Rig rest pose data
IK constraints
Bone hierarchy matrices
Driver-based rigs
Constraints that assume world vs local transforms
Any rig authored for Blender’s Z-up world

Studios often apply transforms to fix one asset, but create inconsistencies with others.

This leads to asset drift, where each mesh slowly becomes different from others in the pipeline.

This is how productions collapse under their own asset inconsistency.

6. The Correct Manual Approach (If You Must Do It Manually)

Step 1 — Choose a Pipeline Convention

Examples:

Unity: Y-up, meters, 1:1 scale
Unity (Maya-style): centimeters, 0.01 scale
glTF: meters, Z-up → Y-up conversion

Step 2 — Standardize Blender Scene

World's unit scale
Scene orientation
Grid scale
Import scale adjustments

Step 3 — Fix Object Transforms Without Breaking Rigs

Convert orientation using matrix math, not rotations
Rebuild bone rolls in correct order
Resample animation curves
Normalize scale hierarchies

Step 4 — Validate

Every object must be:

Scale: (1,1,1)
Rotation: correct forward/up axes
Location: zeroed or pipeline-safe
Bone rest pose: consistent
Animations: stable after conversion

This is why studios use specialized tools—
because doing this manually for hundreds of assets is not feasible.

7. Why You Need an Automated System (Not a Manual Workflow)

A studio pipeline must guarantee:

Every asset is export-safe
Every file uses identical conventions
Transforms are mathematically correct
Rigs are preserved
No artist “accidentally breaks scale”
No asset slowly deviates from conventions over time

This is the reason tools like Unit & Scale Doctor Pro exist—
to solve a problem that is mathematically deterministic but tedious and error-prone for humans.

8. Unit & Scale Doctor Pro — What It Actually Does

Based on the README and source files in your package, the tool provides:

✔ Multi-Engine Profile System

Switch an entire Blender scene to:

Unity (meters / centimeters / millimeters workflows)
Unreal
glTF
CAD pipelines
Custom studio conventions

✔ Object, Mesh, and Armature Correction

It rewrites:

Object matrices
Mesh local → world conversions
Armature rest pose matrices
Bone roll normalization
Animation data curve remapping

✔ Non-Destructive Fixing

The tool ensures:

No rig is lost
No animation is destroyed
No mesh is warped
No parenting hierarchy breaks

✔ A Full Validation System

It detects inconsistencies such as:

Wrong scale
Hidden object scale offsets
Negative scaling
Axis flips
Bone roll inconsistencies
Meshes containing multiple transform spaces

✔ One-Click Scene Standardization

A complete “reset” that makes the entire project engine-ready.

This is exactly what large studios build internally—
but you have it packaged and production-ready.

9. How It Fixes Everything Automatically

Here’s what a typical Unit & Scale Doctor Pro pipeline does under the hood:

Step A — Scene Fingerprinting

It scans every object:

Type
Transform
Parent hierarchy
Mesh data
Armature bind poses
Animation data

Step B — Determine Required Conversions

Using the selected profile, it derives:

Required world up axis
Forward direction
Unit scale multiplier
Mesh shrinkwrap conversions
Armature remapping rules

Step C — Apply Matrix-Level Transform Fixes

It rewrites transforms directly in matrix form:

M_corrected = ConversionMatrix * M_original

This preserves:

Bone rest pose
Animation curves
Rig constraints

Step D — Clean / Bake / Normalize

Zero object scales
Fix bone rolls deterministically
Rebuild animation curves
Validate length units
Normalize mesh normals

Step E — Pipeline Safe Export

FBX-safe rotation
glTF-safe unit scale
Unity-ready hierarchy
Unreal-ready orientation

The entire process becomes deterministic and repeatable.

10. Practical Example — Blender to Unity (Correct Workflow)

Without Unit & Scale Doctor Pro

Export FBX
Import into Unity
Fix rotation manually
Fix scale manually
Fix animation drift
Fix rig orientations
Re-export when something breaks

Every asset becomes a small crisis.

With Unit & Scale Doctor Pro

Choose Unity profile
Click Fix Scene
Export FBX normally
Import into Unity and it “just works”

This eliminates rotational offsets, scale mismatches, and animation distortions.

11. Receipts for Technical Artists — Why This Matters

A good TA knows:

Scale drift kills animation pipelines
Hand-authored fixes destroy determinism
Rig rest poses must be mathematically preserved
Axis conversion is matrix math, not rotation

Unit & Scale Doctor Pro fills the gap Blender never will:

A consistent, safe, automated transformation pipeline.

12. Conclusion — The Right Way to Handle Axis & Scale Forever

The Blender ↔ Unity scale/axis mismatch is unavoidable.
But the chaos surrounding it is optional.

At a high level:

Blender uses Z-up
Unity uses Y-up
Scale semantics are inconsistent
Animations and rigs magnify errors
Manual fixes are destructive
Studio pipelines require determinism

The fix:

Understand the math
Fix transforms non-destructively
Use deterministic conversion methods
Rely on a tool built specifically for this problem

This is exactly what Unit & Scale Doctor Pro provides:
A complete, automated, studio-safe solution to a 20-year-old industry headache.

Get it on Superhive Marketplace via this link: https://superhivemarket.com/products/unit--scale-doctor

FSM API (Advanced) for Unity

Mon, 27 Oct 2025 20:56:19 +0000

The Singularity Workshop is proud to announce a pivotal achievement: After months of rigorous architectural design and engineering, we have successfully released 'The Singularity Workshop - FSM API (Advanced)' on the Unity Asset Store! This is a successful milestone, and we are just getting started.

As dedicated readers of our work know, our focus is on robust software architecture, grounded in the deep theoretical understanding and powerful application of Finite State Machines (FSMs). This Unity Asset is the direct culmination of those efforts.

The Paradigm Shift is Here

Get ready to escape the chaos of Update() spaghetti and embrace a true architectural paradigm shift. Our API is engineered for decoupling and high reusability, allowing you to build complex behavior through the composition of simple, independent FSM blueprints.

As demonstrated in our work on Multi-Context FSMs, you can now apply multiple, independent FSMs to a single object's Transform simultaneously without interference, resulting in game systems that are scalable, maintainable, and profoundly robust.

Documentation as a Core Feature

We engineered this API to be universally accessible, spending as much time on learning materials as we did on the code itself. Our goal is to bring non-coders and non-C# programmers into this new paradigm.

Beyond the comprehensive user guide, you can check out our NuGet package which contains the core API and an extensive Theory Guide that dives deep into:

The fundamental mathematical models behind FSMs.
FSM types, classifications, and operational theory.

Once you understand the "What," our API documentation walks you through the "How," making the process of creating complex behavior accessible to anyone willing to learn the abstraction.

Explore the future of Unity behavior architecture today ($30 package on sale for $21 for two weeks on the Unity Asset Store!):

The Singularity Workshop - FSM API (Advanced)

Reference the Core Engine & Theory Guides:
TheSingularityWorkshop.FSM_API NuGet Package

The paradigm shift is here. We look forward to publishing deep dives into the API's advanced architecture and applications very soon!

Support Us (PayPal Donation):
https://www.paypal.com/donate/?hosted_button_id=3Z7263LCQMV9J

We'd love to hear your thoughts! Please Like this post, Love the code, and Share your feedback in the comments.

The FSM Agent Architecture: Scaling NavMesh Agents with Decoupled Logic

Wed, 15 Oct 2025 20:27:35 +0000

The FSM Agent Architecture: Scaling NavMesh Agents with Decoupled Logic

We've mastered simple oscillating motion with the FSM Context Pattern; now, we apply this powerful architectural approach to a far greater challenge: Massive NavMesh Agent AI. Instead of relying on a monolithic Update() loop, we delegate the complex logic of pathfinding, target acquisition, and state management into reusable Finite State Machine blueprints.

Our goal for this series is twofold: achieve stable, high-performance AI for hundreds of agents, and develop a system resilient to complex emergent behaviors that inevitably arise at scale.

This article introduces the two core components that make up our scalable agent system.

The Two Pillars of the FSM Agent System

Our architecture separates the agents from the environment, ensuring each component is only responsible for its own domain, which is the key to reusability and stability.

1. The Environment: `NavMeshAgentsDemo.cs` (The Orchestrator)

The NavMeshAgentsDemo class serves as the central context for the entire simulation. Its primary responsibility is orchestration and resource distribution.

Target Management: It holds the list of targets (targets list) that agents will navigate to. It includes a helper function, GetRandomTarget, which ensures agents don't immediately re-select the target they just left, promoting better distribution.
Initialization: In the main FSM's OnEnterExecuting state, the demo dynamically creates our agents. It instantiates the agentPrefab, assigns the environment reference (agentFSM.Environment = demo.Status), and gives each agent a unique color for easy visual tracking.
Scale Setup: For our first test, the NumberAgents property is set to a manageable value (e.g., a few dozen). At this scale, the system works perfectly, with agents moving smoothly between targets, proving the foundational architecture is sound.

2. The Agent: `NavMeshAgentFSM.cs` (The Decoupled AI)

This is where the magic happens. The NavMeshAgentFSM class is both a MonoBehaviour (to interface with the NavMeshAgent component and physics events) and an IStateContext that drives its own FSM instance.

The agent's logic is boiled down to a simple, three-state cycle defined in the FSM blueprint, which is created only once:

State	Role	Key Logic
Idle	Target Acquisition	The agent is stopped and contacts the `Environment` to get a new target. This is where the heavy work (target look-up) is performed.
Moving	Path Execution	The agent's `NavMeshAgent` component handles movement to the destination set during Idle. The FSM transitions out when collision with the target is detected.
Contacted	Arrival Confirmation	The agent confirms arrival (`Arrived = true`), and the physics collider is temporarily disabled to prevent it from immediately getting stuck on the target.

The power here is delegation: the FSM defines when the agent decides (Idle) and when it confirms arrival (Contacted), while the NavMeshAgent component (outside the FSM's Update loop) handles the complex movement how.

The Early Success (Small Batch)

When we run the simulation with a small number of agents (e.g., 20–50), the system is seamless.

The FSM Context Pattern successfully replaces the traditional Update() based AI:

Instead of constantly checking if if (target != null && distance < threshold), the system waits in the Moving state and is triggered only by the OnCollisionEnter physics event, which flips the Arrived flag.
The Idle state automatically handles the transition out to Moving once a target is assigned, using the AssignedTarget predicate check (return agent.Target != null).

The foundation is solid, proving that the FSM Context Pattern is highly effective for managing AI state.

Next, we push to a high agent count, but this is where the new architectural challenge arises...

In the next article, we will reveal the performance optimization that allows us to run over 1,000 agents and introduce the subtle, yet critical, emergent behavior known as Agent Gridlock.

Support the Vision and See the Code!

If this pattern has helped clean up your Update() loop, please consider supporting our development! Your support ensures we can continue to provide advanced, architectural solutions for cleaner game development.

Resources & Code:

The FSM Package (Unity Asset Store):
https://assetstore.unity.com/packages/slug/332450

NuGet Package (Non-Unity Core):
https://www.nuget.org/packages/TheSingularityWorkshop.FSM_API

GitHub Repository:
https://github.com/TrentBest/FSM_API

Support Our Work:

Patreon Page:
https://www.patreon.com/c/TheSingularityWorkshop

Support Us (PayPal Donation):
https://www.paypal.com/donate/?hosted_button_id=3Z7263LCQMV9J

We'd love to hear your thoughts! Please Like this post, Love the code, and Share your feedback in the comments.

The Grand Finale: Orchestrating Complex Motion with Multi-Context FSMs

Wed, 15 Oct 2025 19:35:04 +0000

We've successfully established a reusable architectural pattern by isolating the data (Context) from the logic flow (Finite State Machine) for the three primitive motions: Rotation, Scaling, and Translation. We created three distinct, independent blueprints—"RotationFSM," "ScalarFSM," and "TranslationFSM"—each driving separate objects on various axes.

Now, for the grand finale: we will demonstrate the true power of this decoupled architecture by applying all three FSM blueprints simultaneously to the same three objects, achieving a perfectly synchronized, multi-dimensional motion effect.

This isn't about creating a new FSM; it's about proving the flexibility and reusability of the existing ones. We will show that one object can be driven by multiple, independently managed FSM contexts, eliminating the need for a monolithic, complex state machine.

The Power of Decoupled Contexts

The core principle remains the same: the FSM definition is the reusable logic (the how), and the Context is the unique data (the what).

In our previous demos, we created one Context per object. In the Combined Motion Demo, we create three Contexts per object.

Object	Rotation Demo	Scalar Demo	Translation Demo	Combined Demo
X-axis Cube	RotationContext	ScaleContext	TranslationContext	RotationFSM, ScalarFSM, TranslationFSM
Y-axis Cube	RotationContext	ScaleContext	TranslationContext	RotationFSM, ScalarFSM, TranslationFSM
Z-axis Cube	RotationContext	ScaleContext	TranslationContext	RotationFSM, ScalarFSM, TranslationFSM

The FSM framework handles each Context instance completely independently. When the Unity Update() loop runs, it executes the update for all nine individual FSM instances (three contexts * three objects), resulting in the compound motion.

The Entry Point: SimpleRotationScalarTranslationDemo.cs

The SimpleRotationScalarTranslationDemo.cs file is the orchestrator, instantiating the nine required Contexts in its main FSM's OnEnterExecuting method.

Instantiation Logic: Three-in-One

The code combines the instantiation logic from all three previous demos. For the XaxisCube, we instantiate a ScaleContext, a TranslationContext, and a RotationContext, all referencing the same demo.XaxisCube Transform.

private void OnEnterExecuting(IStateContext context)
{
    if (context is SimpleRotationScalarTranslationDemo demo)
    {
        // === X-AXIS CUBE ===
        // 1. Scale FSM (Uses ScaleContext/ScalarFSM)
        ScaleContext scX = new ScaleContext(demo.XaxisCube, new Vector3(1, 0, 0), 0.5f, 3f, 0.5f);
        // 2. Translation FSM (Uses TranslationContext/TranslationFSM)
        TranslationContext tcX = new TranslationContext(demo.XaxisCube, new Vector3(1, 0, 0), 1f, 2f, -2f);
        // 3. Rotation FSM (Uses RotationContext/RotationFSM)
        RotationContext rcX = new RotationContext(demo.XaxisCube, new Vector3(1, 0, 0), 90f, 45f, -45f);
       
        // === Y-AXIS CUBE ===
        // ... (Similar instantiation for Y-axis cube, using (0, 1, 0) for the axis)
        ScaleContext scY = new ScaleContext(demo.YaxisCube, new Vector3(0, 1, 0), 0.5f, 3f, 0.5f);
        TranslationContext tcY = new TranslationContext(demo.YaxisCube, new Vector3(0, 1, 0), 1f, 2f, -2f);
        RotationContext rcY = new RotationContext(demo.YaxisCube, new Vector3(0, 1, 0), 90f, 45f, -45f);
       
        // === Z-AXIS CUBE (Note: Scale is multi-axis for visual flair) ===
        // ... (Similar instantiation for Z-axis cube, using various axes)
        ScaleContext scZ = new ScaleContext(demo.ZaxisCube, new Vector3(1, 1, 0), 0.5f, 3f, 0.5f);
        TranslationContext tcZ = new TranslationContext(demo.ZaxisCube, new Vector3(0, 0, 1), 1f, 2f, -2f);
        RotationContext rcZ = new RotationContext(demo.ZaxisCube, new Vector3(0, 0, 1), 90f, 45f, -45f);
    }
}

The Decoupled FSMs in Action

Because each Context is an independent data container, the FSM framework executes them separately, resulting in simultaneous, non-interfering motion:

The RotationContext drives the TransformHandle.localRotation.
The ScaleContext drives the TransformHandle.localScale.
The TranslationContext drives the TransformHandle.localPosition.

Each FSM instance has its own independent state and transitions, yet they all operate on the same object's Transform. The result is a fascinating display: the Z-axis Cube, for instance, oscillates along the Z-axis (Translation), pulses in size along the X and Y axes (Scaling), and swings around the Z-axis (Rotation).

Conclusion: True Architectural Victory

This Combined Motion Demo is the ultimate proof of the FSM Context Pattern's power:

Separation of Concerns: We fully separated the primitive operations. Modifying the boundary check for rotation, for instance, has zero impact on the translation or scaling logic.
High Reusability: We did not write a single new state machine definition for this complex demo. We simply reused the "RotationFSM," "ScalarFSM," and "TranslationFSM" blueprints.
Scalable Complexity: An object's behavior is now a composition of independent FSM-driven movements. If we need to add a "Color Modulation FSM," we simply instantiate a fourth context for each object.

This decoupled architecture provides the foundation for robust, maintainable, and highly extensible game systems. You've escaped Update() spaghetti and unlocked the ability to compose complex behaviors from simple, reusable, and independent parts.

See it in action on YouTube (Don't forget to like and subscribe!):

https://youtu.be/1lKBINkTtYM

Support the Vision and See the Code!

If this pattern has helped clean up your Update() loop, please consider supporting our development! Your support ensures we can continue to provide advanced, architectural solutions for cleaner game development.

Resources & Code:

The FSM Package (Unity Asset Store):
https://assetstore.unity.com/packages/slug/332450

NuGet Package (Non-Unity Core):
https://www.nuget.org/packages/TheSingularityWorkshop.FSM_API

GitHub Repository:
https://github.com/TrentBest/FSM_API

Support Our Work:

Patreon Page:
https://www.patreon.com/c/TheSingularityWorkshop

Support Us (PayPal Donation):
https://www.paypal.com/donate/?hosted_button_id=3Z7263LCQMV9J

We'd love to hear your thoughts! Please Like this post, Love the code, and Share your feedback in the comments.

Completing the Motion Trilogy: The Reusable TranslationFSM

Tue, 14 Oct 2025 22:23:29 +0000

Completing the Motion Trilogy: The Reusable TranslationFSM

We've conquered Rotation and streamlined Scaling using our FSM Context Pattern. In this article, we tackle the final primitive motion—Translation (linear movement)—to complete our core motion trilogy.

The biggest takeaway here is the demonstration of true architectural reuse. We define a new Context class and a new FSM, but the logic flow remains 100% identical to the Rotation and Scaling demos.

1. The Context: Swapping Scale for Position Parameters

We isolate the specific data required for linear position change into the TranslationContext class.

The primary conceptual difference from the Scale/Rotation demos lies in how boundaries are established: Translation must calculate its absolute boundaries relative to the object's starting local position (OriginalPosition). This ensures the oscillation is centered around the object's initial placement.

Previous Context Parameters	Translation Context Parameters	Purpose
ScaleSpeed (float)	MoveSpeed (float)	Linear speed of position change.
ScaleAxis (Vector3)	MoveAxis (Vector3)	The axis (or axes) to apply the movement along.
MaxScale / MinScale	MaxPosition / MinPosition	The absolute position bounds, calculated from `OriginalPosition`.

TranslationContext.cs: Absolute Boundary Calculation

The TranslationContext calculates the precise MaxPosition and MinPosition by using the dot product to find the object's starting coordinate along the movement axis, and then adding/subtracting the desired displacement.

public class TranslationContext : IStateContext
{
    // The new parameters that define linear movement
    public float MoveSpeed = 1.0f;
    public float MaxPosition = 5.0f;
    public float MinPosition = -5.0f;
    
    public Vector3 MoveAxis;
    public Vector3 OriginalPosition = Vector3.zero;

    // ... Constructor logic
    // 2. Calculate the absolute Max/Min boundaries:
    this.MaxPosition = initialCoord + maxPos;
    this.MinPosition = initialCoord + minPos;
    // ...
}

2. The FSM Definition: The Same Engine, New States

The Finite State Machine flow is identical to the Rotation and Scalar demos (Move $\rightarrow$ Max $\rightarrow$ Move Back $\rightarrow$ Min). The blueprint name is now "TranslationFSM".

Scalar FSM	Translation FSM (Change)
States: ScalingUp	States: MovingForward
States: ScalingDown	States: MovingBackward
Predicate: Apex	Predicate: MaxReached
Predicate: Root	Predicate: MinReached

The Core Logic (Simple Vector Math)

The state updates are handled by direct vector math applied to localPosition using Time.deltaTime for smooth, framerate-independent movement.

// The OnUpdateMovingForward function within TranslationContext.cs
private void OnUpdateMovingForward(IStateContext context)
{
    if (context is TranslationContext tc)
    {
        // Add the movement vector based on speed and time
        tc.TransformHandle.localPosition += tc.MoveAxis * (tc.MoveSpeed * Time.deltaTime);
    }
}

The transition predicates, MaxReached and MinReached, use the Dot Product to extract the object's current coordinate along the axis, comparing it to the absolute MaxPosition/MinPosition boundary values calculated earlier.

3. The Entry Point: Final Proof of Reusability

The SimpleTranslationDemo.cs handles the instantiation. We simply provide three different MoveAxis vectors to three unique TranslationContext instances, all utilizing the same "TranslationFSM" definition.

private void OnEnterExecuting(IStateContext context)
{
    if (context is SimpleTranslationDemo std)
    {
        float moveSpeed = 1.0f;
        float maxDisplacement = 2.0f;
        float minDisplacement = -2.0f;
        
        // 1. X-axis: MoveAxis (1, 0, 0)
        TranslationContext xAxisContext = new TranslationContext(std.Xaxis, new Vector3(1, 0, 0), moveSpeed, maxDisplacement, minDisplacement);
        std.XaxisHandle = xAxisContext.Status; 

        // 2. Y-axis: MoveAxis (0, 1, 0)
        TranslationContext yAxisContext = new TranslationContext(std.Yaxis, new Vector3(0, 1, 0), moveSpeed, maxDisplacement, minDisplacement);
        std.YaxisHandle = yAxisContext.Status; 

        // 3. Z-axis: MoveAxis (0, 0, 1)
        TranslationContext zAxisContext = new TranslationContext(std.Zaxis, new Vector3(0, 0, 1), moveSpeed, maxDisplacement, minDisplacement);
        std.ZaxisHandle = zAxisContext.Status;
    }
}

Conclusion: Architectural Reusability Confirmed

With the implementation of the TranslationFSM, we have successfully completed our core motion trilogy, elegantly managing Rotation, Scaling, and Translation using a single, unified architectural approach.

The key takeaway is the profound level of architectural reuse we achieved. By isolating the unique data (the what) into the Context class and retaining the generic logic flow (the how) within the FSM blueprint, we were able to build three distinct motion systems with virtually identical FSM definitions. This pattern has proven its ability to handle different primitive operations—be it altering localRotation, localScale, or localPosition—simply by swapping out the specialized context. This kind of separation of concerns leads to robust, maintainable, and highly reusable code.

The final proof of concept in SimpleTranslationDemo.cs, simultaneously orchestrating three separate translation contexts with one FSM blueprint, underscores the pattern's efficiency and flexibility.

Up Next: The Grand Finale

We've mastered the primitives. In the final article of this series, we'll connect the three systems—RotationFSM, ScalingFSM, and TranslationFSM—to a single object. Get ready for the Combined Motion Demo, where we'll show an object spinning, pulsing, and oscillating all at once, driven by multiple, independently managed FSM contexts. This is where the true power of this decoupled architecture shines! Keep an eye out for the final installment.

See the demo in action:
YouTube Channel Video

Support the Vision and See the Code!

Resources & Code:

The FSM Package (Unity Asset Store):
https://assetstore.unity.com/packages/slug/332450

NuGet Package (Non-Unity Core):
https://www.nuget.org/packages/TheSingularityWorkshop.FSM_API

GitHub Repository:
https://github.com/TrentBest/FSM_API

Support Our Work:

Patreon Page:
https://www.patreon.com/c/TheSingularityWorkshop

Support Us (PayPal Donation):
https://www.paypal.com/donate/?hosted_button_id=3Z7263LCQMV9J

We'd love to hear your thoughts! Please Like this post, Love the code, and Share your feedback in the comments.

Applying the FSM Context Pattern to Scaling: The Reusable ScalarFSM

Tue, 14 Oct 2025 21:23:15 +0000

Applying the FSM Context Pattern to Scaling: The Reusable ScalarFSM

In our previous article, we demonstrated how to eliminate Update() spaghetti by applying the FSM Context Pattern to complex Rotation logic. The result was a single, reusable blueprint ("RotationFSM") that drove three objects on different axes.

Here, we prove the true versatility of this pattern by applying it to Scale motion. The vast majority of the logic remains the same—only the Context data and the specific Unity functions change.

1. The Context: Swapping Angular for Linear Parameters

The core philosophy remains: isolate the specific data required for the motion. We move from the RotationContext to the ScaleContext.

Rotation Context Parameters	Scale Context Parameters	Purpose
RotationSpeed (float)	ScaleSpeed (float)	Linear speed of scale change.
RotationAxis (Vector3)	ScaleAxis (Vector3)	The axis (or axes) to apply the scale along.
MaxAngle / MinAngle	MaxScale / MinScale	The absolute min and max bounds for the object's local scale.

ScaleContext.cs: Data Encapsulation

The ScaleContext holds the new parameters and is what ultimately manipulates the TransformHandle.localScale.

public class ScaleContext : IStateContext
{
    // The new parameters that define scaling motion
    public float ScaleSpeed = 0.5f;
    public float MaxScale = 3.0f;
    public float MinScale = 0.5f;

    public Vector3 ScaleAxis;
    public Vector3 OriginalScale = Vector3.one;

    public Transform TransformHandle;
    // ...
}

2. The FSM Definition: Same Flow, New Names

The Finite State Machine flow is identical to the rotation demo (Move $\rightarrow$ Max $\rightarrow$ Move Back $\rightarrow$ Min) but uses domain-appropriate terminology.

The blueprint name changes from "RotationFSM" to "ScalarFSM".

Rotation FSM	Scalar FSM (Change)
States: RotatingForward	States: ScalingUp
States: RotatingBackward	States: ScalingDown
Predicate: MaxReached	Predicate: Apex
Predicate: MinReached	Predicate: Root

The Core Logic (The Only Update)

Instead of applying a Quaternion update using Quaternion.AngleAxis, the state update logic now directly modifies the localScale vector using the ScaleAxis vector stored in the Context.

// The OnUpdateScalingUp function within ScaleContext.cs
private void OnUpdateScalingUp(IStateContext context)
{
    if (context is ScaleContext sc)
    {
        // Linearly increase the scale along the specified axis(es)
        Vector3 scaleDelta = sc.ScaleAxis * (sc.ScaleSpeed * Time.deltaTime);
        sc.TransformHandle.localScale += scaleDelta; // The only movement line!
    }
}

The elegance here is that the state engine (the FSM) required zero changes. We only updated the specific motion logic inside the state functions of the new ScaleContext.

3. The Entry Point: Demonstrating Multi-Axis Motion

The SimpleScalarDemoFSM.cs acts as the entry point. This demo highlights a capability easily solved with scaling that was slightly more complex with rotation: multi-axis movement.

Notice how the third instance utilizes a ScaleAxis vector with multiple components set to 1 to drive a single FSM instance to scale along both the X and Y axes simultaneously.

private void OnEnterExecuting(IStateContext context)
{
    if (context is SimpleScalarDemoFSM ssd)
    {
        float speed = 0.5f;
        float maxScale = 3f;
        float minScale = 0.5f;
        
        // 1. X-axis Scale
        ScaleContext xAxisContext = new ScaleContext(ssd.Xaxis, new Vector3(1, 0, 0), speed, maxScale, minScale);
        
        // 2. Y-axis Scale
        ScaleContext yAxisContext = new ScaleContext(ssd.Yaxis, new Vector3(0, 1, 0), speed, maxScale, minScale);
        
        // 3. XY-axis Scale: Scales on X and Y using the *same* FSM definition
        ScaleContext xyAxisContext = new ScaleContext(ssd.XYaxis, new Vector3(1, 1, 0), speed, maxScale, minScale);
        
        // ... Instantiate all handles and transition to start state
    }
}

This demo proves that the FSM Context Pattern is an engine-agnostic architectural solution. Once you define the pattern, reusing it for any kind of movement—Rotation, Scale, or Translation (coming next!)—is as simple as defining a new Context class.

See the demo in action:
YouTube Channel Video

Support the Vision and See the Code!

Resources & Code:

The FSM Package (Unity Asset Store):
https://assetstore.unity.com/packages/slug/332450

NuGet Package (Non-Unity Core):
https://www.nuget.org/packages/TheSingularityWorkshop.FSM_API

GitHub Repository:
https://github.com/TrentBest/FSM_API

Support Our Work:

Patreon Page:
https://www.patreon.com/c/TheSingularityWorkshop

Support Us (PayPal Donation):
https://www.paypal.com/donate/?hosted_button_id=3Z7263LCQMV9J

We'd love to hear your thoughts! Please Like this post, Love the code, and Share your feedback in the comments.

Building a Reusable State Machine for Oscillating Rotation in Unity

Tue, 14 Oct 2025 20:05:21 +0000

Escaping Update() Spaghetti: Reusable Oscillation with FSM & Context in Unity

If you’ve ever built a Unity object that needs to move or rotate between two points—like a swinging pendulum, a turret oscillating for patrol, or a security camera scanning an area—you’ve likely ended up with a tangle of booleans and if/else statements in your Update() loop.

// The typical mess you want to avoid
void Update()
{
    if (isMovingForward)
    {
        // Move Forward Logic
        if (transform.rotation.z > MaxAngle)
        {
            isMovingForward = false;
        }
    }
    else // isMovingBackward
    {
        // Move Backward Logic
        if (transform.rotation.z < MinAngle)
        {
            isMovingForward = true;
        }
    }
}

By leveraging the Finite State Machine (FSM) pattern with a distinct Context object (using the FSM_UnityIntegrationAdvanced package), we can create a single, clean definition for oscillating rotation that can be instantly reused across any number of objects and axes.

The Heart of the Demo: The FSM Context

The core idea is to separate the object's data (where it is, how fast it moves) from the logic (how it behaves). This is done via the RotationContext class, which acts as the data structure for each rotating object.

RotationContext.cs: Data Encapsulation

By implementing IStateContext, this class holds everything the FSM needs to operate on the specific object:

public class RotationContext : IStateContext
{
    // Object and parameters for THIS instance
    public Transform TransformHandle;
    public Vector3 RotationAxis;
    public float RotationSpeed;
    public float MaxAngle;
    public float MinAngle;
    // ... other data
}

The Universal FSM Definition

The beauty of this approach is that the Finite State Machine itself ("RotationFSM") is defined only once inside the RotationContext constructor, making it a reusable blueprint.

State Name	Logic (Update)
RotatingForward	Apply positive rotation to `TransformHandle`
RotatingBackward	Apply negative rotation to `TransformHandle`

Transition (What decides the change)	Condition (Predicate)
`RotatingForward` → `RotatingBackward`	`MaxReached()`: Checks if the current angle ≥ `MaxAngle`
`RotatingBackward` → `RotatingForward`	`MinReached()`: Checks if the current angle ≤ `MinAngle`

The logic in OnUpdateRotatingForward and OnUpdateRotatingBackward simply drives the object, relying entirely on the MaxReached and MinReached predicates to decide when the object's behavior must change.

The Entry Point: Instantiating Reusable Logic

The SimpleRotationDemo.cs is a standard Unity MonoBehaviour whose sole job is to kick off the system in its Awake() or OnEnterExecuting method.

Instead of writing three separate components (one for X, one for Y, one for Z), we instantiate three unique Context objects, each feeding the same shared FSM definition ("RotationFSM") with different parameters.

private void OnEnterExecuting(IStateContext context)
{
    if (context is SimpleRotationDemo srd)
    {
        float speed = 90.0f;
        float maxAngle = 45.0f;
        float minAngle = -45.0f;

        // 1. X-axis Rotation: Unique context, shared FSM logic
        RotationContext xAxisContext = new RotationContext(srd.Xaxis, new Vector3(1, 0, 0), speed, maxAngle, minAngle);
        srd.XaxisHandle = xAxisContext.Status;

        // 2. Y-axis Rotation: Same FSM logic, different object/axis
        RotationContext yAxisContext = new RotationContext(srd.Yaxis, new Vector3(0, 1, 0), speed, maxAngle, minAngle);
        srd.YaxisHandle = yAxisContext.Status;

        // 3. Z-axis Rotation: Same FSM logic, different object/axis
        RotationContext zAxisContext = new RotationContext(srd.Zaxis, new Vector3(0, 0, 1), speed, maxAngle, minAngle);
        srd.ZaxisHandle = zAxisContext.Status;
    }
}

The Result: Scalable Advanced Integration

With minimal setup, we achieve perfectly synchronized, bounded rotation across three distinct objects, all driven by a single, well-defined state machine. This pattern easily extends to more advanced scenarios:

Reusability: The same RotationFSM can be used to drive dozens of turrets, doors, or fans.
Maintainability: If you need to change the rotation logic (e.g., adding easing), you change one piece of code (OnUpdateRotatingForward), not three.
Extensibility: This blueprint instantly adapts to your Translation, Scale, or NavMeshAgentsDemo logic—simply define a new FSM and Context for those specific concerns.

This demo proves that advanced FSM integration doesn't mean complex setup, but rather intelligent architectural separation to keep your Unity code clean and highly reusable.

Coder Legion - Recent posts tagged unity3d

Aesthetic Trading Automation for Binance

using unity access to create a basic seen. What works and what still needs developing

Building The Scene

what to work on next

join the conversation

using Codex to build unity_access. Whats worked, what hasn't and tips for building your own accessible applications with AI.

Tools and technology

Building the plugin: what worked and what doesn’t

What worked?

What doesn’t work

How to build your own accessibility-focused app or how to modify an existing app to be more accessible

Contribute to the discussion

FludeX v1.1 — Runtime Debug Platform

REBEL HEARTS alpha demo build 0.192

DevLog 20260122: Some Notes on MAUI, Unity, and Building "Map-Like" App Across Platforms

The Problem: A "Map-Like" Feature

Unity: Smooth Onboarding, Rough Reality

MAUI: Dry, and That's a Compliment

The Hidden Cost

Some Takeaways

Solo Creation: Games and the Psychology Behind Them

FIGHT NIGHT ANNOUNCEMENT: The Lightweight Challenger vs. The Heavyweight Champ

The Blender ↔ Unity Axis & Scale Problem: A Complete Technical Guide

The Blender ↔ Unity Axis & Scale Problem: A Complete Technical Guide

1. Introduction — The Silent Production Killer

2. The Root Cause — Two Worlds, Two Coordinate Systems

Blender uses:

Unity uses:

The Fundamental Conflict

3. The Axis Dichotomy — Why Objects Rotate Wrong

Case 1: Blender to Unity Rotation

4. The Scale Dichotomy — Why Objects Import Too Small or Too Large

Key misconception:

Blender's Exporters

Unity’s Importers

5. Why "Apply All Transforms" Is a Pipeline Trap

It breaks:

6. The Correct Manual Approach (If You Must Do It Manually)

Step 1 — Choose a Pipeline Convention

Step 2 — Standardize Blender Scene

Step 3 — Fix Object Transforms Without Breaking Rigs

Step 4 — Validate

7. Why You Need an Automated System (Not a Manual Workflow)

8. Unit & Scale Doctor Pro — What It Actually Does

✔ Multi-Engine Profile System

✔ Object, Mesh, and Armature Correction

✔ Non-Destructive Fixing

✔ A Full Validation System

✔ One-Click Scene Standardization

9. How It Fixes Everything Automatically

Step A — Scene Fingerprinting

Step B — Determine Required Conversions

Step C — Apply Matrix-Level Transform Fixes

Step D — Clean / Bake / Normalize

Step E — Pipeline Safe Export

10. Practical Example — Blender to Unity (Correct Workflow)

Without Unit & Scale Doctor Pro

With Unit & Scale Doctor Pro

11. Receipts for Technical Artists — Why This Matters

12. Conclusion — The Right Way to Handle Axis & Scale Forever

At a high level:

The fix:

FSM API (Advanced) for Unity

The Paradigm Shift is Here

Documentation as a Core Feature

The FSM Agent Architecture: Scaling NavMesh Agents with Decoupled Logic

The FSM Agent Architecture: Scaling NavMesh Agents with Decoupled Logic

The Two Pillars of the FSM Agent System

1. The Environment: NavMeshAgentsDemo.cs (The Orchestrator)

2. The Agent: NavMeshAgentFSM.cs (The Decoupled AI)

The Early Success (Small Batch)

The Grand Finale: Orchestrating Complex Motion with Multi-Context FSMs

The Power of Decoupled Contexts

The Entry Point: SimpleRotationScalarTranslationDemo.cs

Instantiation Logic: Three-in-One

The Decoupled FSMs in Action

Conclusion: True Architectural Victory

https://youtu.be/1lKBINkTtYM

Support the Vision and See the Code!

1. The Environment: `NavMeshAgentsDemo.cs` (The Orchestrator)

2. The Agent: `NavMeshAgentFSM.cs` (The Decoupled AI)