Unity UI Themes

What the system is for

Reusing UI prefabs in Unity sounds great until two screens want the same button to look slightly different. Then prefabs get duplicated as variants, colors are tweaked locally, fonts drift apart and the once-shared design system fragments. The same pattern shows up with UI sounds: every button picks its own click clip, until clicks sound different from screen to screen.

The UI Themes system in Serenity lets you describe the visual and audio personality of a UI as a definition asset, and share it across menus, modals and other screens.

The Unity problem

Without a theme layer, UI consistency lives in human discipline. Designers and developers have to remember to use the same color, the same font, the same hover sound. Real projects forget. Worse, when the theme needs to change, the changes have to propagate across every prefab variant by hand.

Audio feedback is the same story. Click sounds, hover sounds, submit sounds and cancel sounds appear on individual buttons, and they slowly diverge until each screen has its own audio signature, often by accident.

How Serenity approaches it

Serenity describes UI themes through IUiThemeDefinition and pairs it with two component contracts: IUiThemeComponents for visual components and IUiThemeSounds for audio components. The sound side has its own definition contract IUiThemeSoundsDefinition. Unity-specific assets such as UnityUiThemeDefinition, UnityUiThemeComponents, UnityUiThemeSounds and UnityUiThemeSoundsDefinition implement those interfaces as ScriptableObjects.

A UiThemeValidator and UnityUiThemeDefinitionEditor support the editor side. Menus reference the theme through UnityMenuThemeSoundFactory so menu UI sounds come from the theme rather than from each button.

Because the theme is a single asset, restyling the UI becomes a controlled change. You edit the definition, the consumers pick up the new values, and the prefabs themselves do not need to be touched. Multiple themes can coexist in the project, and the active one can be assigned per build or per game mode.

How it fits into Serenity

UI Themes live in the Serenity.Ui namespace. Domain interfaces define the theme contract. The Infrastructure layer provides the Unity ScriptableObject implementations. The Installation layer provides the asset configuration and the editor support, including the validator that catches missing references before runtime.

UI Themes connect to the Menu System for menu screens, to the Modal System for confirmation and prompt dialogs, to the Audio Player so UI sounds route through the same service as gameplay sounds, and to Localization when localized assets are part of the theme. Changing the active theme changes the look and feel of every consumer at once.

The split between IUiThemeComponents and IUiThemeSounds is important. It means you can change the audio identity of the UI without touching its visual one, and the other way around. Projects that ship with multiple visual themes but a single sound theme, or vice versa, do not have to duplicate everything to keep the two axes independent.

Practical workflow

1. Create a UnityUiThemeDefinition asset for the visual and audio identity you want.
2. Configure UnityUiThemeComponents with the prefabs and visual references used by menus and modals.
3. Configure UnityUiThemeSounds with the click, hover, submit and cancel sound clips.
4. Run the UiThemeValidator to catch missing references during authoring.
5. Assign the theme to the menu and modal services through their installers.
6. Swap themes by changing the assigned definition, with no prefab edits needed.

What you get

• Theme contracts IUiThemeDefinition, IUiThemeComponents and IUiThemeSounds
• Unity ScriptableObject implementations UnityUiThemeDefinition, UnityUiThemeComponents and UnityUiThemeSounds
• Sounds definition contract IUiThemeSoundsDefinition with Unity counterpart
• Theme validator UiThemeValidator for early error detection
• Editor support through UnityUiThemeDefinitionEditor
• UnityMenuThemeSoundFactory wiring menu sounds through the theme
• Integration with menus, modals, audio playback and localization
• Theme swap by replacing the assigned definition, not by editing prefabs

When to use this

• Projects with more than one UI screen that should share visuals and sound feedback.
• Teams that want to reskin the UI without touching individual prefabs.
• Games that need to support multiple themes, for example light and dark variants or per-faction styling.
• Codebases moving away from per-button sound and visual configuration.

Related systems

• Unity Menu System Declarative menus, shared UI themes and predictable navigation, configured as assets instead of hand-wired GameObjects.
• Unity Modal System Reusable confirmation, alert and prompt modals driven by typed signals and shared parameters.
• Unity Audio Player Centralized clip playback with definition assets, emitters and typed signals for UI and gameplay sounds.
• Unity Localization System Runtime language switching, separate game and voice language tracks, and localized menus and modals out of the box.