1. There are a lot of games where the settings aren't being updated live but only when the player presses the confirm or apply button. Why is that? Is applying all the settings at once that much faster and easier? Obviously, making players wait for a couple of seconds every time they change a slider or press a button is absurd but updating some small settings live like that shouldn't make the game freeze and stop that long, right?
2. Some games even make you restart the whole game to fully update it. Why?
3. I'm currently implementing a settings menu for my game and I'm interested in hearing more of your opinion about normal UI and features. What settings feature that you really like but most games don't have (e.g the game doesn't have a pop-up in case I accidentally exit the menu or the game has too many pop-ups appear and there's no way to turn them off). What do you think about the current standard 3 buttons: Cancel/Back, Reset to default, and Confirm/Apply?
4. I love to hear more about how you implemented these things in your past projects (both from a technical and architecture standpoint and UI design standpoint).
5. How does the current handmade hero handle these things? Can it update settings instantly?

HH does not have any user settings, I would guess it probably won't have any settings.

As to why games require restarting - poor engine architecture that cannot change something at runtime. There is no reason code could not simply change whatever needs to be changed without restarting process.

This ‘pattern’ seems to work pretty good https://github.com/Olster1/woodland/blob/f08e38cdf490a49779cddfa65f58554789bb5429/src/save_settings.cpp

You just have a struct storing the settings values and load it on startup, then apply your settings for the game. Then when the user is changing settings in ui, I’d just save the whole thing everytime they change any value. If a lag is noticeable, you could put it on another thread.

Also you’ll want to save the file in something like the SavedGames/ folder or AppData folder in case the user puts your game somewhere your not allowed to write to. https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderpath

If we're talking about actually writing to file, then there is one thing that almost all games do it wrong - they directly write save files or game settings to destination path overwriting previous file. Which is bad. If there is any error happening (in game, or with filesystem, issue with OS, resident software, or maybe disk is full etc..) and process crashes then you have corrupted and lost your game save or settings. This is not good!

Instead always write to a new file - strictly verify that write succeeded (every single write function succeeds), and close file also succeeds - because CRT or OS may be flushing file buffers during close call. And then do a move of new file over old file by replacing it. This operation should be performed atomically - meaning if move is not possible then filesystem should leave old file intact. On Windows 10 this can be done SetFileInformationByHandle function + FileRenameInfoEx enum / FILE_RENAME_INFO struct / FILE_RENAME_FLAG_POSIX_SEMANTICS flag. On older Windows atomic replacement is not guaranteed, but MoveFileTransacted is probably what will give you as close as possible to that.

An alternative I use to what mmozeiko said is to always create a new file with a different name. I add the UTC date and time to the filename, and I keep several versions of the file. When loading I look for the file with the most recent date in the name.

You just have a struct storing the settings values and load it on startup, then apply your settings for the game. Then when the user is changing settings in ui, I’d just save the whole thing everytime they change any value. If a lag is noticeable, you could put it on another thread.

That's also my first idea. Just have a GameSettings struct that stores all the game settings. Then you have something like GameSettings defaultSettings, currentSettings, tempSettings;. Every time you change the UI you change the tempSettings, and when you press Apply you just need to assign the tempSettings to the currentSettings and apply it.

Also you’ll want to save the file in something like the SavedGames/ folder or AppData folder in case the user puts your game somewhere your not allowed to write to.

What is somewhere that I'm not allowed to write to? I usually prefer to store everything inside a folder so the installation is clean and the player can remove everything by just deleting the folder. Also, isn't steam make you install your game to a specific path?

What is somewhere that I'm not allowed to write to?

Many locations. Like root of C:\ drive. Or Program Files. Or Windows folder. etc..

Having software placed or installed into location that cannot be modified is security thing. So other more malicious software (or just on accident) don't go around modifying random .exe files or other files game needs.

Steam does really bad thing from security perspective - they make their Progam Files folder writeable by everyone. Which can be huge issue on computers with multiple users - one user modifies .exe file that other more privileged user runs. Or just .dll file overriding system functionality, etc.

Also, isn't steam make you install your game to a specific path?

No, it allows to override library location in settings. You can install games into different locations if you want.

But then you should install the whole game in a special folder, rather than just the saved files. I don't really understand the advantage of saving saved files to a separate folder. Most gamers don't really touch the saved files, and if they do then there's no way to stop them from doing that.

Also, why do game developers have to care about security anyway? If I make a game that isn't competitive then shouldn't it be the user's job to not have malicious software or accidentally mess with the game's files? And is putting the game into C:\ drive that much more secure?

If for example, I care about my game security. What can I do to make it more secure? What problem should steam fix to help normal, non-competitive games?

It’s that windows can’t trust that you’re game isn’t going to do malicious things, so it just says ‘you can read files but you can’t modify anything in these folders’, if you need to write data like save files, settings etc. we’ve got these designated ‘safe’ folders to do that.

Aswell the appdata, savedgames etc. folders are unique to computer user, so when someone else logs into their account and tries to play the game, their not getting all your save files or settings, which is just a nicer experience.

I think this is what you were getting at.

Oh, it makes sense now. But isn't steam

they make their Progam Files folder writeable by everyone

so I don't think Windows can't trust you is a problem here.

No, it allows to override library location in settings. You can install games into different locations if you want.

That's kind of my point! Most games usually get installed into the same root folder by steam which can be easily read or written from (haven't looked into it but I think steam provides some API and as you said steam allows anyone to read and write to). "You" in my original post is the game developer, not the player.

Which can be huge issue on computers with multiple users - one user modifies .exe file that other more privileged user runs. Or just .dll file overriding system functionality, etc.

Are we only talking about the saved files here or the whole game? I'm kind of confused. And again, if the user wants to modify the executable, I can't stop them.

Also, why do game developers have to care about security anyway? If I make a game that isn't competitive then shouldn't it be the user's job to not have malicious software or accidentally mess with the game's files?

Because when you have kids using same PC as you, then you don't want their user account have admin access. Otherwise you will get full of "free robux" or "cool minecraft skins" or "free V bucks" malware installed.

Do you mean like: "oh, if you want free Minecraft skins then download this program from this website (probably give your personal information) and drop it in your game folder"? This kind of malicious software can be in many forms and doesn't need to be related to the game in any way. It can compromise other stuff on your program and don't care about your game, or can be downloaded into your computer through other kinds of advertising (i.e doesn't need to be related to cool Minecraft skins). How can game developers prevent any of this? And also what is the benefit of manipulating the game's executable (assuming the game doesn't store any personal information and/or has any kind of microtransaction)?

Yes, exactly.

Game developers can prevent this by allowing main user (admin/you) to install game in read-only folder (Program Files) where other Windows users (non-admin/kids) cannot write - they will be able to launch & play the game. But not modify any files.

But users choose where to install the game, not developers. I don't understand what do you mean by "allowing user".

I mean it in a context "game allows to run from read-only location" which means storing settings & save games somewhere else than next to .exe or its subfolders (see Oliver's initial reply).