Unity Game Settings

What the system is for

Game settings are deceptively simple. A volume slider, a quality preset, a language choice and a graphics toggle do not look like much. Then the project grows. Settings start to depend on each other, gameplay code starts to react to changes, persistence has to be reliable across platforms, and the settings menu becomes one of the most touched pieces of UI in the project. Most teams build their own ad hoc system, hit a few of the same problems and try to patch it.

The Game Settings system in Serenity is the foundation's way of saying that settings deserve a real service. Values are typed, reads and writes go through use cases, persistence is a separate concern, and changes are observable through signals.

The Unity problem

Without a real settings layer, projects tend to drift into one of two patterns. Either every setting is a PlayerPrefs key referenced by string, scattered across the codebase, or there is a custom Settings static class that grows until no one wants to touch it. Both make it hard to add a setting safely, to test settings logic and to react to changes from gameplay code.

Persistence is the other half of the problem. Settings need to survive between sessions. They need a defined moment to be written, a defined moment to be restored and a defined way to reset to defaults. When those moments are scattered, settings either lose data or refuse to apply changes until the next launch.

How Serenity approaches it

Serenity exposes settings through IGameSettingsService with use cases SetGameSettingsValue and GetGameSettingsValue. Typed variants exist for bool, int, float and string values, both for input and output DTOs. Updates are observable through OnGameSettingsOnValueUpdatedSignal. Persistence is described through IGameSettingsPersistenceSettings and IGameSettingsRepository, and reset and persist intents are first-class signals: OnPersistGameSettingsSignal and OnResetGameSettingsToDefaultSignal.

Default values, persistence and any preloading of dependent assets live behind their own interfaces. The settings menu reads and writes through the service. Other systems subscribe to the update signal when they need to react to a change.

How it fits into Serenity

Game Settings lives in the Serenity.GameSettings namespace. Domain entities such as GameSettingsEntity and StoredSettingsPayload describe the data. The Application layer exposes the service, the typed DTOs and the update signals. Asset preloading helpers IGameSettingsAssetPreloader and IGameSettingsAssetPreloadingIntegrator coordinate any addressable assets that depend on settings.

Game Settings connects with the Sound Mixer for persistent volume categories, with Localization for the active game and voice language, with Game Mode for state-driven setting changes, with the Event Dispatcher for the update and reset signals, and with the Menu System and Modal System for the settings screen and its reset confirmation. The result is a settings layer that the rest of the foundation already speaks.

Practical workflow

1. Configure the persistent settings your game exposes through a settings definition.
2. Choose a persistence backend, for example PlayerPrefs or file-based storage, behind IGameSettingsRepository.
3. Read values through GetGameSettingsValue and write them through SetGameSettingsValue.
4. Subscribe to OnGameSettingsOnValueUpdatedSignal where you need to react to a change.
5. Dispatch OnPersistGameSettingsSignal at the moments you want to commit settings to storage.
6. Use OnResetGameSettingsToDefaultSignal to reset the settings from a menu or modal flow.

What you get

• Typed use cases SetGameSettingsValue and GetGameSettingsValue with bool, int, float and string variants
• Update signal OnGameSettingsOnValueUpdatedSignal for reactive systems
• Persistence interface IGameSettingsRepository and settings IGameSettingsPersistenceSettings
• Persist and reset signals OnPersistGameSettingsSignal and OnResetGameSettingsToDefaultSignal
• Asset preloading helpers for addressable assets that depend on settings
• Integration with Sound Mixer, Localization, Game Mode and the Event Dispatcher
• Installer that registers the service for the whole project
• Clean separation between Domain, Application and Infrastructure layers

When to use this

• Projects that expose a real settings menu with multiple categories.
• Games that need settings to persist between sessions and to reset to defaults reliably.
• Teams that want a typed, observable settings layer instead of scattered PlayerPrefs keys.
• Codebases that need other systems to react to settings changes without polling.

Related systems

• Unity Sound Mixer Per-category volume settings that drive your Unity Audio Mixer and persist through Game Settings.
• Unity Localization System Runtime language switching, separate game and voice language tracks, and localized menus and modals out of the box.
• 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.