What belongs in a PC settings menu, and why it is not optional

Updated September 2026 · ShipYourGame

A missing settings menu is one of the most reliable sources of negative reviews for small PC games. Not because players love menus, but because the absence of one turns a solvable annoyance into a refund.

The pattern is consistent: the player cannot change the resolution, cannot rebind the key their hand expects, cannot turn down music that is louder than the voices, cannot play windowed on a second monitor. Each of these is a five-minute fix in isolation and an unplayable game in aggregate.

The list players expect

Display

• Resolution, listing the modes the monitor actually reports
• Window mode: fullscreen, borderless, windowed
• Which monitor, on multi-monitor setups
• VSync on or off
• A frame rate cap, including an uncapped option

Audio

• Separate sliders for master, music and effects at minimum; voice as a fourth if you have dialogue
• Sliders that behave logarithmically, not linearly. A linear slider spends most of its travel doing nothing audible.

Input

• Rebindable keys for every action, not just movement
• Controller support with correct glyphs for the connected pad
• Invert look, and separate sensitivity for mouse and stick
• A way to cancel a rebind without being stuck

Gameplay and accessibility

• Subtitles, with a size option
• A text size or UI scale option
• Something for motion: screen shake off, or reduced
• Colour-blind consideration wherever a colour carries meaning

The mechanics of the menu itself

• Apply and revert, with a countdown that reverts a broken resolution automatically
• Reset to defaults
• Settings that persist across restarts, in a versioned file so a later patch can migrate them
• Full keyboard and controller navigation, with a sensible first selected item

A build order that avoids rework

1. One settings object with change events. Everything else listens to it. Build this before any UI.
2. Persistence with a schema version. Add the version field on day one; adding it later means migrating files that are already on players' machines.
3. Display and audio. They cover most of the complaints and are the least fiddly.
4. Input rebinding. The most work, because of conflicts, cancel paths and per-device glyphs.
5. Accessibility options. Cheap to add if the settings object exists, expensive to retrofit into scattered code.
6. The panel itself, last. If the settings layer is right, the UI is a thin skin over it and can be restyled without touching logic.

The order matters because steps 1 and 2 are the ones that are painful to add afterwards. Everything else can be appended.

The Steam Deck question

If you are shipping on PC, some of your players are on a handheld with a 1280 x 800 screen held at arm's length. The cheapest useful test: launch the game, press the equivalent of start, and try to read the smallest text on screen from a metre away. If you cannot, your UI scale option just became a requirement rather than a nicety.

Controller glyphs matter here too. A prompt that says "press E" on a device with no E is a bug report waiting to happen.

The honest cost

Building this properly takes longer than people estimate, which is why it keeps getting pushed to the end and then shipped broken. It is not conceptually hard; it is a large number of small correct behaviours. Budget real time for it in the month before launch rather than the week.