Price history
Recorded standalone sale prices and the latest available store price, in USD. Historical dots use the sale start date and its recorded offer price. Prices can change during a sale; this is not a daily price log. Bundle prices and upcoming offers are excluded. History covers up to the 100 most recent recorded offers.
Lowest recorded standalone price in this history: FREE. The latest store price is FREE, matching the lowest recorded price shown here.
View 2 recorded prices
| Sale start / price check | Price | Observation |
|---|---|---|
| FREE | Latest store price | |
| FREE | Unity First Price 2026-10-14 2026-10-14 |
Sale and bundle history
The 1 most recent recorded offers including this asset. Past offers may no longer be available. Bundle prices cover a package, not this asset alone.
About Settings Kit
- Tools, Systems & Learning > Development Tools & Automation
Adding a settings page to a Unity project usually means editor boilerplate, a Resources/ asset to read at runtime, and serialization wired up by hand.
Settings Kit removes all of it: you write one page class and one or more serializable settings classes, and your settings appear in the right window, are saved in the right place, reach your builds when they should, and are read with one line of code.
No asset to create, nothing to register, no Resources/ folder.
- Little to learn: a handful of public types cover every feature.
- Nothing to set up: settings classes are found automatically, saved in ProjectSettings/ or UserSettings/, and kept in sync as you add or remove them.
- Readable at runtime: build settings are loaded into the player before the first scene, so Settings.Instance returns the same values in a built game as in the editor.
FOUR KINDS OF SETTINGS
The base class of a settings class decides where it appears and whether it reaches your builds.
- Build settings (BuildSettingsEntry): Project Settings window, committed, shipped into the build, and readable at runtime.
- Per-platform settings (PlatformSettingsEntry): a build setting whose whole set of values can differ per build target, baked to the target at build time.
- Editor-project settings (EditorSettingsEntry): edited under Project Settings, committed for the team, but never shipped.
- User settings (UserSettingsEntry): per-developer, edited under Preferences, never shipped.
WHAT'S INCLUDED
- Declare once, read anywhere: one SettingsPage class plus serializable entries; read them through Settings.Instance, in the editor or at runtime.
- The right window automatically: build and editor-project entries land under Project Settings, user entries under Preferences, each window showing only its own.
- Sections, ordering, and tooltips: an optional [SettingsDisplay] attribute sets titles, tooltips, and ordering for pages and sections.
- Custom rendering: style any section with an ordinary PropertyDrawer on your settings type.
- Validation: implement IValidatedSettings for an inline help box in the window and a build-time gate that fails the build on invalid build settings.
- Migration: IVersionedSettings transforms an entry’s values forward across schema versions, and a [SettingsMigrator] method rescues data from types you deleted.
- Testing seam: Settings.OverrideForTests() substitutes what Settings.Instance returns for the life of a disposable, with no permanent “for tests” setters in the shipped API.
- Navigation: Settings.OpenPage() jumps straight to a page from your own tooling.
- A Demo folder: every feature in one place, with a Tools > Settings Kit > Demo menu.
Settings Kit removes all of it: you write one page class and one or more serializable settings classes, and your settings appear in the right window, are saved in the right place, reach your builds when they should, and are read with one line of code.
No asset to create, nothing to register, no Resources/ folder.
- Little to learn: a handful of public types cover every feature.
- Nothing to set up: settings classes are found automatically, saved in ProjectSettings/ or UserSettings/, and kept in sync as you add or remove them.
- Readable at runtime: build settings are loaded into the player before the first scene, so Settings.Instance returns the same values in a built game as in the editor.
FOUR KINDS OF SETTINGS
The base class of a settings class decides where it appears and whether it reaches your builds.
- Build settings (BuildSettingsEntry): Project Settings window, committed, shipped into the build, and readable at runtime.
- Per-platform settings (PlatformSettingsEntry): a build setting whose whole set of values can differ per build target, baked to the target at build time.
- Editor-project settings (EditorSettingsEntry): edited under Project Settings, committed for the team, but never shipped.
- User settings (UserSettingsEntry): per-developer, edited under Preferences, never shipped.
WHAT'S INCLUDED
- Declare once, read anywhere: one SettingsPage class plus serializable entries; read them through Settings.Instance, in the editor or at runtime.
- The right window automatically: build and editor-project entries land under Project Settings, user entries under Preferences, each window showing only its own.
- Sections, ordering, and tooltips: an optional [SettingsDisplay] attribute sets titles, tooltips, and ordering for pages and sections.
- Custom rendering: style any section with an ordinary PropertyDrawer on your settings type.
- Validation: implement IValidatedSettings for an inline help box in the window and a build-time gate that fails the build on invalid build settings.
- Migration: IVersionedSettings transforms an entry’s values forward across schema versions, and a [SettingsMigrator] method rescues data from types you deleted.
- Testing seam: Settings.OverrideForTests() substitutes what Settings.Instance returns for the life of a disposable, with no permanent “for tests” setters in the shipped API.
- Navigation: Settings.OpenPage() jumps straight to a page from your own tooling.
- A Demo folder: every feature in one place, with a Tools > Settings Kit > Demo menu.