Quick answer: When a game loses settings after restarting, the settings aren't being persisted or restored correctly: they may not be saved when changed, saved to a location that doesn't persist (or fails to write), or saved but not loaded and applied at startup. Check the full round trip, settings written on change, to a persistent location, then loaded and applied on launch, and fix wherever the chain breaks.

Losing settings on restart is a small but genuinely annoying bug, players re-configure their controls, audio, and graphics, and have to do it again every launch. It's a persistence problem, the settings round trip from 'changed' to 'saved' to 'restored on next launch' is broken somewhere, and fixing it is a matter of checking each step of that round trip.

Why Settings Don't Persist

Settings persistence is a round trip: when changed, settings should be written to persistent storage; on launch, they should be loaded from storage and applied. Losing settings means a break in this round trip. The breaks: not saved, the setting change isn't written to storage at all (it only lives in memory and is lost on exit). Saved wrong, written to a non-persistent location, or the write fails (permissions, path) silently. Not loaded, the settings are saved but the game doesn't read them on startup (or reads them but doesn't apply them, so they default). Or load-order issues, settings load but are overwritten by defaults applied later in startup.

Each break leaves settings at their defaults after restart. Which one you have depends on where the round trip fails, on the save side (not written/written wrong) or the load side (not read/not applied/overwritten).

How to Diagnose It

Test the round trip directly. Change a setting, then check whether it's actually written to persistent storage (does the settings file/store get the new value?). If not, the save side is broken (not saving on change, or write failing). If it is saved, restart and check whether the game reads it and applies it, if the saved value is there but the game still uses the default, the load side is broken (not loading, not applying, or overwriting with defaults). This pinpoints which half of the round trip fails.

Settings-loss reports are common and easy for players to describe ('it forgets my settings every time'), and they may cluster by platform if it's a storage/permissions issue specific to one. Capturing these reports (Bugnet collects player reports with context) confirms the scope and any platform pattern, though settings persistence is usually reproducible locally by testing the round trip.

How to Fix It

Fix the broken step. If settings aren't saved on change, persist them when they change (or on a safe trigger) to a proper persistent location, and handle write failures. If they're saved to the wrong place or the write fails, use the correct persistent storage for the platform and ensure writes succeed. If they're not loaded or applied at startup, load the saved settings early in startup and actually apply them (set the audio volume, the resolution, the bindings) rather than just reading them. If defaults overwrite loaded settings, fix the startup order so loaded settings aren't clobbered by a later default-application step.

Verify the full round trip after fixing: change every category of setting (controls, audio, graphics), restart, and confirm they all persist and are applied. Settings persistence is a basic expectation, getting it reliably right removes a small but constant irritation that makes a game feel unpolished. Test on each platform since storage behavior differs.

Lost settings is a broken persistence round trip, not saved, saved wrong, or not loaded/applied at boot. Test change-restart-check to find the break, and make sure loaded settings are actually applied.