top of page
Scene_001_demo_00.png

AceLand Unity Packages

Center of System and Architecture Design.

Designs of AceLand Unity Packages

I started building AceLand packages back in 2020. Unity is powerful precisely because it is so open and unopinionated, but that same freedom turns long-term projects into a maintenance nightmare, where every team ends up reinventing the same plumbing in slightly incompatible ways. My answer was to stop rebuilding the foundation on every project and instead package it once, properly. That is why the core of AceLand is not flashy features but framework and background services, things like Event-Driven messaging and State management, together with agent services such as Task Utils and Web Request that quietly do the heavy lifting underneath the game.

​

These packages were never written in isolation. I built and hardened them on real production work, and as I used them day to day, more focused library and tooling packages grew out of genuine needs, including Curve, Command History, and Kalman Filter. Each one exists because I hit the problem myself and wanted to solve it once, cleanly, and never again. The result is a toolkit that lets me finish tasks with high efficiency and high quality, because the difficult, error-prone parts are already solved, tested, and reusable.

​

In 2026, as Unity moves toward CoreCLR, I decided to take this further. AceLand packages are being rebuilt around the modern runtime, with no reliance on domain reload, and released under a model I call "Open Core, Paid Editor Tools": the runtime that ships inside your game stays open source and free forever, while the development-time editor tooling that makes the packages easier to inspect, verify, and optimize is offered under a paid license. The sections below explain how this model works in practice and what it means for you.

What is Open Core, Paid Editor Tool

"Open Core, Paid Editor Tools" is simple: everything that runs inside your game is open source and free forever, so your shipped product never depends on a license and never gets gated. What you pay for is the development-time experience, the editor tooling that inspects, validates, traces, and profiles the packages while you build. In short, the runtime is free, and the tools that make working with it faster and safer are paid.

​

Full Article: [Gitbook]

Why New Core Packages

The current new Core Packages are Injection and Lifecycle, and more of the older packages will be upgraded to this new Core stage over time. Take DI and Lifecycle as the clearest example of why a redesign is necessary: the classic frameworks were built around domain reload and reflection-heavy resolution, assumptions modern Unity no longer holds. With no-domain-reload and CoreCLR, static state survives between play sessions and reflection cost is increasingly out of place, so rebuilding these foundations is not polish, it is a requirement to stay correct and fast on modern Unity.

 

Full Article: [Gitbook]

Upgrades of Old Packages

More existing packages, such as Event-Driven, will be upgraded into Core Packages. Beyond the runtime rebuild for the modern player loop, each upgraded package gains a complete editor monitor window, so you can debug live state, validate configuration before it ships, and trace back to the source object and script that raised or handled a given event. The goal is that nothing important stays hidden behind a black box.

 

See the Announcements: [GitBook]

New Editor Tools

Alongside the package upgrades, more pure editor tools are being developed, standalone utilities built to make everyday work in the Unity Editor more flexible and efficient. These are not tied to a single package; they are quality-of-life and productivity tools meant to speed up the parts of Unity development that normally slow you down.

 

See the Announcements: [GitBook]

©2023 by Parsue Choi - AceLand Workshop

bottom of page