Why do some video game and computer program graphical options have to be “applied” manually while others change the instant you change the setting?
In: Technology
While technical issues do play a role, it often comes down to usability. Do you really want to scroll through 20 different resolution presets and apply the changes every single time immediately? Or load new geometry every time you adjust the details? Probably not, use a button instead. But now your menu becomes inconsistent because you need the apply-button for 2-3 settings and nothing else. Inconsistency is one of your worst enemies, so let’s not do that. If you want to be really sneaky, you can add an “apply and back” button and rename it to something else.
Okay so you’re programming on Windows and you want to make a window with some buttons, text input boxes, checkboxes, [radio buttons](https://en.wikipedia.org/wiki/Radio_button), etc; a settings menu, let’s say. To make everything easy for the programmer and consistent across the OS, Windows provides these widgets to all programs on the system. An arbitrary program just needs to tell Windows “Put a checkbox with text label ‘Some String of Text’ at some particular place in this window”, and Windows takes care of how exactly that checkbox works (how it looks (animation maybe?), how it behaves (response to being clicked, text input, mouse hover, etc)). Then, a few lines down in the program, the programmer can ask Windows “What is the state of that checkbox I created a while ago?” and Windows will answer “checked” or “unchecked”. Or the programmer can ask for the value of a particular text input box and Windows will respond with the text contained in the box.
The programmer can also tell Windows stuff like “When this widget is interacted with in this particular way, run that particular function that I wrote”. So some programs just do that for every widget on screen, and save each change somewhere every time the user changes anything. Usually this is what’s going on when you don’t have to Apply or Save your settings. Each time you change a setting it gets autosaved right then and there. So when you’ve set everything how you want, just exit the settings window and you’re good to go.
But there’s a cost here. If the user is messing around with game controls, those settings don’t need to be updated in the game memory until the player starts playing again, so it doesn’t make sense to go through the effort of updating each setting each time it changes. And for some settings, like graphics settings, a lot of work/reloading has to happen in the background to apply your change. So it makes more sense to just have the user set everything how they want without their changes going into effect, and then give them buttons to actually enable all of these changes, with the understanding that clicking said buttons might result in several seconds (or, especially back in the day, minutes) of downtime while the game gets everything in order. The standard three buttons are “Ok” (apply changes and exit this menu), “Apply” (apply changes but stay in this menu), and “Cancel” (exit this menu without saving changes).
As computers have become more powerful and UI programming has become more flexible (at this point most games draw all of their own widgets instead of using the OS widgets), programs and games have started moving to autosaving by reacting to every UI event, and only use the Ok/Apply/Cancel scheme for things like changing graphics settings, since there’s no getting around that momentary black screen, or the possibility that the new settings will be completely unusable on your screen.
I’m a developer who has programmed a game engine from scratch. The reason some settings can be applied instantly and some need to be “applied” is because of how it is coded. It takes extra work to develop a system that is able to change on the fly and still run efficiently. Also like others have said, it is much easier and safer (less likely to create bugs) if everything is wiped from memory and everything is loaded again with new settings.
It’s significantly easier to just shut it down and start everything over. Much less time to program and much easier to avoid bugs.
It’s mainly a user interface design choice.
Many graphics settings affect or interact with each other. When adjusting settings, you may need to change several and then apply them all at once to see what the overall effect looks like.
If each change was applied independently the instant you made the change, then you wouldn’t be able to easily see the difference that your overall selection of changes made.
Applying the settings changes all at once makes it really easy to do an A-B comparison between old and new settings.
Another reason for the “Apply Changes” design choice is that it allows you to easily cancel. The pending changes are staged, and you can easily back out of them without having to reload anything. If the changes were applied the instant you made them, then they would have to be undone in order to “cancel” them, and you’d end up reloading twice.
It actually applies to a lot of design of both software and hardware. You’ll have some initialization you do on startup. As a designer/engineer/developer, the least amount of additional work needed to support modifying a setting is to just re-run that initialization process. As an added bonus, it’s less likely to introduce a bug, since that single initialization process can be tested more thoroughly.
Now, if you want to change individual settings and apply them individually, you have to break that initialization up into different sections. You have to pull out all the error checking/handling, all the consistency checks, etc. The amount of development goes up.
In short, it’s easier to check and apply everything at once. But the user experience is better if you can do things individually and see the results immediately. So there’s a tradeoff.
Usually is just a matter of developer’s preferences. Sometimes it’s a bit challenging to apply the settings as soon as they’re changed (e.g. in a video game where you have to reload objects while being careful to remember their state), sometimes it’s just not feasible (applying the screen resolution as soon as the option for it changes can be annoying for the user) but most of the times it is just a choice, applying settings as soon as they’re changed is a pretty new thing so many developers are used to do this via an “Apply” or “OK” button.
Think of the program like a workplace.
Sending out a memo for a price change is easy. You can do that during a workday. That is what it is like to change a simple setting.
However, asking all employees to change their uniform to a different one would require a significant logistics planning to perform while everyone is at work. It would require changing rooms, and rotating employees in. Unless you are fine with your business entirely pausing (program freezing) while everyone changes.
It is simpler in the second example to just send employees home with a note to come dressed differently tomorrow. Especially if the dress code rarely changes.
The clothes are the different variables/functions/resources that would need to be loaded to change an integral setting.
It’s not just graphical settings – it’s the basic principle of caching information to memory so you don’t have to re-fetch it every time using a slower process.
This applies to all computer programs, and even the OS (i.e. restarting your computer/phone).
If you build a building, and somebody wants to change the pain or the windows it can be done after the fact. If you want the walls or support beams of the building made out of different materials the builders need to know *before* they begin construction. Each time you start the game it’s like constructing that building.
Some settings are paint/windows/decorations. Some settings are like the materials used to make the walls and support beams.
Latest Answers