Settings System

I developed a plugin that provides a flexible and reusable settings system for Unreal Engine projects.

After exploring UI best practices in Unreal Engine with my UI Framework project, I decided to apply those learnings to a more concrete problem. I chose to build a settings system: a feature that exists in most games, but is often more complex than it first appears.

The goal was to create a plugin that could be dropped into different Unreal projects and provide a solid foundation for settings menus, including authoring workflows, runtime behavior, and UX considerations.

It was also a good opportunity to learn Unreal’s Model-View-ViewModel (MVVM) pattern in a practical context.

Design Goals

A settings system does more than expose values in a menu. It needs to persist data, coordinate with runtime systems, handle dependencies or conflicts between settings, and still provide a fast and intuitive authoring workflow in the editor.

I designed the plugin to be highly flexible. It provides a foundational framework complete with the standard features and pre-made settings that most games need, but also allows teams to extend it with arbitrary settings types.

Technical Overview

Here’s a quick overview of the architecture of the plugin:

• Settings Definitions: Settings are authored in-editor as Data Assets. Each definition contains the information needed to present and manage the setting, including UI metadata, dependency rules, and custom execution logic where needed.
• Subsystem: A runtime subsystem initializes the settings, handles persistence, and acts as the source of truth for current values. Other game systems can query it directly or subscribe to setting change events.
• ViewModels: When settings are displayed, a ViewModel is created for each entry. MVVM turned out to be a strong fit here because it cleanly separates presentation concerns from runtime state and rule evaluation. The ViewModel also tracks pending changes and resolves dependency-driven UI state.
• Widgets: UI widgets are generated dynamically in a UCommonListView from the settings definitions. They reflect the state of their ViewModel and are intentionally kept simple, with no embedded logic.

Input Rebinding

I wanted input rebinding to be a core feature of the plugin. That included support for gamepad rebinding, reserved keys, conflict handling, and multiple mapping profiles.

Most modern Unreal projects use Enhanced Input, so I built the system around that. This turned out to be one of the more complex parts of the plugin, as Enhanced Input possesses its own data flow and persistence model that I had to integrate with while enforcing my own UX and validation rules.

In practice, I implemented a custom rebinding layer on top of Enhanced Input. I relied on UEnhancedInputUserSettings and player-mappable key profiles for binding persistence, while the settings subsystem coordinated rebinding flows, validation, conflict handling, and UI-facing state. In other words, the plugin owns

The result supports rebinding for arbitrary input actions, including gamepad inputs, and handles edge cases such as conflicts and reserved keys.

Other Features

Here’s a quick overview of other features I implemented as part of the plugin:

Benchmark Integration

Unreal exposes hardware benchmarking through UGameUserSettings. I wanted to use that functionality without relying directly on its default application flow, so I wrote a small subsystem dedicated to running benchmarks, interpreting the results, and applying the corresponding settings. Centralizing that logic kept the workflow easier to reason about and avoided scattering benchmark-specific code across the UI and runtime layers.

Decorator Widgets

The settings screen can also contain non-setting entries, which I refer to as decorators. These include things like section headers, spacers, and buttons that trigger arbitrary logic.

Default Values

Every setting has a defined default value. On first launch, settings are initialized from those defaults, and users can restore them later through the UI.

Transaction-Based Application

Settings may have dependencies and rules that affect their availability and behavior. I implemented a transaction-style workflow for applying settings changes, which allows the system to validate pending changes, resolve dependencies, and apply updates deterministically.

Runtime Audio Device Switching

The plugin includes support for switching audio output devices at runtime. It can also react when the active output device becomes unavailable and fall back to another valid device. This behavior is exposed through the settings UI so players can also choose an output device manually. Because audio-device behavior is heavily platform-dependent, I would treat this feature as best-effort until it has been validated on each target platform.

ImGui Debug Integration

I added integration with my ImGui-based debug tooling so the plugin’s internal state can be inspected at runtime. See ImGui Debug Tools for more details.

Tradeoffs

The plugin depends on CommonUI and MVVM. In practice, MVVM integration was relatively lightweight once the plugin was enabled, while CommonUI required more up-front project setup and has a steeper learning curve.

The plugin does not require my UI Framework plugin to function, but the two are designed to work together with very little additional setup.

Closing Thoughts

This project was a useful exercise. I have a better understanding of editor-authoring workflows and the MVVM pattern in Unreal Engine. It also integrated well with the UI framework I built, providing a concrete example of how to use it for a common game feature.