From Rug Pull to Runtime: Why I’m Open for Business and Building the Future of UGC
To the Coder Legion community,
On Friday, my out-of-state contract was suddenly canceled.
The reason? A failed drug screening because I live in Washington State and legally use cannabis—something that has been my primary tool for managing life and functionality since my service in the Navy.
I was told earlier that if I didn’t pass the corporate screening, we would still find a way to keep working together. Instead, the rug was pulled out from under me, right when a long-anticipated full-time conversion was on the table. For a veteran trying to finally plant roots in the software development industry after a lifelong climb, it’s a jarring reminder that corporate policy can override human judgment.
I'm not here to throw a pity party. Sob stories are a dime a dozen. Wallowing doesn't write code, build systems, or pay bills. So I'm going to do what I know how to do: Build. And right now, I'm looking for the next place where I can put that ability to work.
What I Actually Bring to the Table
If you've only seen my recent work, you may know me primarily through FSM_API. That's fair—but it's only one piece of a much larger body of work.
I've spent years working at the intersection of software architecture, automation, BIM/AEC systems, visualization, game technology, state-driven systems, developer tooling, and increasingly AI-assisted creation. The common thread isn't a particular programming language or industry. It's taking complicated systems and figuring out how to make them composable, understandable, and useful.
FSM_API — State Shouldn't Be a Mess
My current public project is the FSM_API NuGet package: a pure C# Finite State Machine system designed to provide deterministic, decoupled, runtime-safe state management without tying the architecture to a particular engine or framework. It supports processing groups, runtime redefinition, deferred mutation, contextual state logic, diagnostics, throttled updates, and compositional state-driven behavior.
More importantly, it is becoming an ecosystem. I've built Unity integration around it, explored state-driven 3D visualization through FSM_Helix, experimented with FSM-driven multiplayer/P2P architecture (GitHackforFun), and developed additional layers for serialization, generics, dependency injection, project templates, and package management. The goal has never been "another FSM"—it's creating a reliable architectural primitive that disappears underneath larger systems to make them easier to reason about.
A much larger part of my current direction lives inside TheForge. It is my experimental development environment and architectural foundation for Unity, exploring a Micro Package architecture where systems can be independently described, registered, composed, and instantiated.
It includes a central Workshop Hub, code-driven GUI construction, builder contracts, experience manifests, FSM integration, and tools intended to make complicated systems accessible through structured visual interfaces. This is where my thinking about user-generated content (UGC) becomes concrete: moving beyond the idea that creating sophisticated digital experiences requires learning an entire programming stack. What if the architecture itself could become the tool?
BIM / AEC — Where a Lot of This Thinking Started
Before this push into game technology and UGC, a significant portion of my career was spent solving difficult problems in BIM and AEC technology. That work includes Revit automation, Dynamo tooling, data management, family manipulation, UI systems, and breaking down fragmented construction data (visible across projects like NormalBIM, FTI_BIM, ZeroTouchFTI, RevitFamilyManagerBuilders, and DynamoNodes).
The interesting part isn't simply that these are BIM tools; it's the architectural problems underneath them:
- Moving data between systems without losing meaning.
- Automating workflows that normally require hundreds of manual operations.
- Separating domain logic from presentation.
- Building interfaces dynamically instead of hard-coding every screen.
Visualization, Games, and Distributed Systems
I've also applied these ideas in experimental directions, such as GitHackforFun (exploring a peer-to-peer game loop with distributed round-robin authority) and FSM_Helix (state-driven architecture for 3D visualization and rendering in WPF). Alongside bots, procedural architecture tooling, and various prototypes, I'm deeply interested in systems—not just job titles.
I've built tooling around diagrams, publishing, web applications (including the Blazor WebAssembly publishing infrastructure for The Singularity Workshop), automation, and package management. A massive portion of my work remains private, experimental, or client-specific. If you look at my public GitHub and think, "That's quite a bit of code," you're still not seeing everything.
The Bigger Idea
All of these projects may look unrelated at first glance—FSMs, BIM, Revit, Unity, 3D visualization, P2P systems, developer tools, automation, UGC, and AI. But to me, they're all variations of the same problem: How do we take something complicated and give a human being a better way to control it?
That's what I want to keep building. And that's why I'm particularly interested in teams working on developer platforms, AI tooling, game technology, simulation, visualization, automation, BIM/AEC technology, or systems that empower non-technical users to create things that previously required specialized engineering knowledge.
Open for Business
I am looking for immediate employment, contract work, consulting, or collaborative engineering.
- A startup that needs someone who can walk into a complicated problem and start building.
- A team that needs an architect who is still willing to write the code.
- An ambitious project where the requirements aren't completely figured out yet.
I'm not looking for a job where I can sit quietly inside a predefined box. I'm looking for a problem worth solving.
If you have one, let's talk. You can start with the public FSM_API project, but don't stop there. The repositories are only the visible edge of a much larger body of work.
I'm open for business. Let's turn the ash into momentum.
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
Please Like this post, Love the code, and Share your experience in the comments.
