Unity package · UGUI · Addressables · free and open source

Smooth, organized game UI, AI-ready

Building with AI? AI tools write a lot of code fast, and without a structure it piles up in places nobody can track. This framework gives every screen the same shape: its own Addressable scene, its own script, its own place in the state stack. Generated code always has a clear place to go, so your project stays easy to follow as it grows. Transitions animate with no flash, and an editor window writes the scripts, scenes and config for you.

Unity 2022.3 – Unity 6 Package Manager Production-ready by default Merge-friendly AI-friendly async / await MIT license
Move across to pull the screen apart–

One screen, four layers. In UI Framework every layer is its own element scene, and a state stacks them into the screen your player sees.

The Unity editor in Play mode: the Hierarchy lists the UI element scenes loaded additively, the Game view shows the showcase app, and the UI Setup Manager is docked on the right
The showcase app in Play mode in the Unity editor: each UI element is its own scene, loaded additively (Hierarchy), and the Console stays free of warnings and errors.
Package ManagerAdd by git URL, pin a version
Editor windowWindow → UI Framework → UI Setup Manager
Scenes as screensAddressable, loaded additively
UGUI nativeCanvas, Text, TMP, your components
TestedEditMode and PlayMode tests

Game UI turns into a tangle. It doesn't have to.

Almost every game starts its UI the same way, and almost every game hits the same wall a few months in. If any of this sounds familiar, the framework was made for you.

  • One giant UI scene.Every screen lives in one scene or prefab, loads at boot, and two people can't touch it at the same time without a merge conflict.
  • SetActive spaghetti.Screens switch each other on and off by hand. A popup stays open, a canvas never closes, and Back goes to the wrong place.
  • A new screen manager for every game.Each project rewrites its own, with its own bugs, and only the person who wrote it knows how it works.
  • Motion as an afterthought.Screens pop in, flash an empty frame, or move differently on every screen because each one was tuned by hand.
  • Managers and singletons everywhere.UIManager.Instance, PopupManager.Instance, GameManager.Instance: every screen reaches into a handful of singletons. It only works with all of them in the scene, start-up order starts to matter, and one null Instance breaks a screen.
  • UI logic tangled with game logic and the backend.A Buy button's OnClick checks the price, calls the server, updates the save and opens a popup. Change the backend and you are rewriting screens; test the economy and you need the UI running.
  • Setup by hand.Screens are wired with drag-and-drop references to managers in other scenes, sort orders are picked by feel, and a renamed object silently breaks a screen nobody opened today.
  • One config the whole team takes turns on.Every new screen or state edits the same registry asset, so people lock it, push it to dev, and only then can the next person start.
Bring your pointer close–

Scattered screens settle into one tree. A state stack and a single scene contract do the same to your UI.

What changes when you use it

Without itWith UI Framework
A new screenBuild a prefab, wire references, register it with a manager by handNew Element creates the script and the scene; Build Runtime UiConfig makes it Addressable and registers it
NavigationSetActive calls spread through the codeawait UiManager.ShowState<StoreUiState>()
PopupsSort-order fights and hand-written close logicPushed on top with additive: true, closed with HideUI()
Shared barsCopied into every screen, or reloaded with a flickerShared elements stay loaded and on screen while screens change
MemoryEvery screen loaded at bootScenes load on demand and unload when no state uses them
MotionTuned by hand, screen by screenTen tuned presets, chosen per element or per call
DataScreens reach into singletonsData is passed in through Populate, so every screen opens on its own
DependenciesScreens call game managers and the backend directlyScreens only show what they are given and report taps; game systems and the backend never meet the UI
SetupReferences dragged between scenes, sort orders picked by feelGenerated scenes with one contract; canvas, sorting and Addressables set per element in the editor
TeamworkOne shared config: lock it, push to dev, then the next person goesOne asset per state and one scene per element: branches add screens in parallel and merge cleanly
StructureDrifts silently until something breaksEvery scene validated, and fixed in one click

Watch a screen come together

This is the showcase app, pulled apart into the element scenes it is made of. Press Next to run each call, and the figure tells you what UiManager loaded, kept and unloaded. Point at any layer to see what it is.

Point at a layer to see what it is

State stack

Loaded scenes

UI is only the view

Scroll to pull a typical game UI apart and put every piece where it belongs.

Today

Most game UIs are one big layer.

Screens, managers and the backend client sit side by side, and every piece calls every other one. Each red line is a direct dependency: 22 of them, through six singletons. Scroll to pull it apart.

Step 1 · UI scenes

Lift the screens out.

Home, Store, Profile and the Reward popup become UI scenes. They only show what they are given and report taps, so every red line from a screen into a manager goes with them.

Step 2 · UiManager

UIManager and PopupManager become one door.

UiManager loads the scenes a state needs, hands your params to every element in Populate, animates and unloads. A popup is just another state, so PopupManager merges into it.

Step 3 · Your app

GameManager becomes your app.

One navigator decides what to show and when. It calls ShowState and HideUI with the params each screen needs, and it is the only code that talks to UiManager.

Step 4 · Game systems

The other managers become game systems.

Economy and Audio keep the rules of your game. Your app calls them; they never reference a screen, so they run and test without any UI.

Step 5 · Backend

What's left is the backend.

Only Economy talks to the server, and nothing above it knows the server exists. Now watch a Buy tap: it travels down to the game, and the reward comes back up through UiManager.

The framework stays out of your architecture: it has no service locator, no signals and no network code, and params are plain C# classes. These layers are the structure it makes easy, and the showcase app follows it with one navigator for every call.

Why teams use it

One scene per screen

Each UI element is an Addressable scene. Artists and designers work in their own scene without merge fights, and memory follows exactly what is on screen.

A real state stack

Replace the whole UI, or push popups and overlays on top. Close them with one call. No hand-rolled screen managers, no forgotten canvases.

Shared elements stay put

A nav bar or currency header used by several screens stays loaded and on screen while the screens change underneath it. It never reloads and never re-animates.

Animated by default

Ten calm, tuned presets: fade, zoom, four slides, pops and shake. Pick one per element in the editor, or override it for a single call from code.

No flash, no empty frame

The new screen animates in while the old one animates out. Elements are prepared in their start pose before their first frame, so nothing pops.

Editor tooling

The UI Setup Manager creates element scripts and scenes, builds states, validates every scene, fixes structure in one click and generates the runtime config.

Made for teams: no config to lock

Many UI tools keep every screen in one shared registry. Adding a screen means locking that file and pushing it to dev before anyone else can add theirs. UI Framework has no such file to fight over, so the whole team adds screens and states at the same time.

Other tools

One shared registry

Two people, one shared file: someone waits, or someone resolves a conflict.

UI Framework

One file per state, one scene per element

Two people, separate files: both merge, nothing to resolve.

One file per stateA new state is a new UiStateDefinition asset. Two branches never edit the same one.
One scene per elementA new screen is new files: its scene and its script.
Shared files are generatedRuntimeUiConfig and the Addressables group are rebuilt by Build Runtime UiConfig, never merged by hand.
Set onceUiEditorConfig only holds paths and namespaces.

Four ideas, live

The whole framework rests on four ideas. Each figure below is live: move your pointer over it, or tap it on a phone.

Point up and down–

The state stack

Screens and popups stack up. Lift the frames above and the screen underneath is still there, exactly as HideUI() leaves it.

How the stack works →
Point at a tile–

Shared, counted scenes

UiManager sits at the centre. A scene links in when a state needs it and stays loaded while any state on the stack still uses it.

Shared elements →
Pick a floor–

One call between screens

ShowState takes you to any screen. The old one animates out while the new one animates in, with no empty frame in between.

What makes it feel good →
Run your pointer down–

One scene contract

Every element scene has the same shape. The editor checks them all and snaps a scene that drifted back into shape in one click.

The scene contract →

How it works, in one picture

You define states (a screen, a popup) as lists of element scenes. At runtime, UiManager loads the scenes a state needs, hands every element its data, plays the transitions and unloads what nothing uses any more.

your code ShowState<StoreUiState>() UiManager 1. find the state in UiConfig 2. load missing scenes 3. Populate(context) 4. animate out / in 5. unload unused scenes StoreUiState = three Addressable element scenes TopBarUiElement shared: stays on screen StoreUiElement loaded, populated, slides in new NavBarUiElement shared: stays on screen

As simple as it looks

Bootstrap.cs
private async void Start()
{
    try
    {
        await UiManager.InitializeAsync();
        await UiManager.ShowState<MainMenuUiState>();
    }
    catch (Exception exception)
    {
        Debug.LogError("[Bootstrap] UI failed to start: " + exception);
    }
}
Open a popup, then close it
RewardParams reward = new RewardParams();
reward.Coins = 250;

// additive: true pushes the popup on top of the current screen.
await UiManager.ShowState<RewardUiState>(reward, additive: true);

// Later, from the popup's Claim button:
await UiManager.HideUI();

The professional approach, ready on day one

Large games don't keep their UI in one scene. They split it into content the team can load, own and ship separately. A state machine drives what is on screen, data is passed in, and tooling guards the structure. UI Framework gives you that approach from the first screen. An indie team builds like a professional studio, and a prototype is production-ready by default: when the game grows, nothing gets rewritten.

1call to show any screen or popup
10tuned animation presets, per element or per call
0screen managers to write yourself
15+years of shipping games behind the design

Built for production

Ref-counted scenes

Scenes are keyed by Addressables GUID and unloaded only when no state on the stack uses them.

Resilient transitions

An exception in your Populate is logged, and the stack is cleaned up anyway.

Scene contract

Every element scene has the same shape, checked and fixed by the editor, so animation always works.

Tested

EditMode tests for the editor tools, PlayMode tests that play the animations frame by frame.

Who made it

Built from 15 years of shipping games

UI Framework is made by Mohamed Moghazi, Game Engineer at Electronic Arts, with more than 15 years of professional work on large productions, including:

Freeletics XCOM Angry Birds Evolution

Big projects teach the same lesson every time: UI that is loaded, navigated and animated by clear rules is what lets a team keep shipping. This framework puts those rules in your project from the first screen, so an indie team builds like a professional studio and every prototype is production-ready by default. Free for everyone.

UI Framework is a personal project, built and maintained independently. It is not affiliated with, sponsored or endorsed by Electronic Arts or any other company named here. Product names are trademarks of their owners and are listed as work history.