Not enough ratings
Compendium for the perfectionist game developer
By God, owner of the Universe
If it is your goal to maximize satisfaction of your game customers, then this compendium is for you.

Every section deals with an individual facet, e.g. the savegame system, field of view (FOV), volume sliders, menus, interface in general, or how to deal with startup logo videos. All of these are usually implemented more wrong than right, so if you're gunning for the ideal, take a look at what's written here - at least for inspiration.

THIS IS A WORK IN PROGRESS and will be extended over time. Suggestions are welcome via the comments below.
Field of view (FOV) slider with large range required.
It needn't go quite as far as in the game ROOT where you can slide from indeed 1° to 179° - though this considerateness is really appreciated - but it sure as Hell needs to go further than 60° to 110°.

You might agree with that, but did you know that the visual output interface you're looking at is almost the only way you experience a game, so it's quite important to get this right? Of course you did. But did you consciously reflect it? In case you think that there is no such thing as the correct FOV, or that "a 16:9 screen needs FOV xyz" and so on and so forth, then please do yourself and the rest of the world the favor and read this article about FOV (field of view) in computer games, which clears up all those misunderstandings and most probably teaches you a thing or two, without being too technical.
Volume slider implementation requries ears and a brain.
One of the two - if not both - is clearly missing in the case of most games, because the sliders behave far from uniformly. The user can't slide a bit and expect to have the same power of response in other parts of the slider. Instead, this is what happens: If you lower the slider from 100% down to about 70%, you'll have to listen closely, otherwise you won't be sure if the volume changed at all! 30% of the slider ... wasted! BUT WHY? More about this (e.g. the childishly simple fix) in this article:

Developers, fix your volume sliders!

The very least - the VERY least! - you have to do is to show the decrypted version of these high tech abbreviations somewhere (e.g. "Screen Space Ambient Occlusion"). It is ridiculous to assume some kind of PC user elitism where those who don't remember every last of these are declared lame and shall thereby suffer their on disability.

But at this point in time (Seriously, why is standardization such an impossible thing to find in game development? I mean, proper standards, not perpetuation of something wrong/broken, because that we have aplenty.), even the explanation of what these options mean should be present. Because you only have to write/translate them once via your company database. They do not change in between games! The only thing that changes are some details about them, the impact they have on the game, and which one you recommend, but there's no reason to write the general description anew every time - so, if your game's options screen has enough space and is layouted accordingly, there's no reason not to put these into the game.
Don't use fancy labels like "Low", "High", "Ultra".
At the very least, don't make your selectors for such options loop: If I want maximum or minimum, I want to click a few times on the right or left arrow button until things stop changing. Making the selector loop forces the user to invest a lot more effort for no sane reason.

But also take care that the name of the various levels makes it clear whether or not we're now at minimum/maximum. So, we've set the graphics preset to "Ultra". And now we're adjusting the individual options. Whoops - some of them only have "Low", "Med", and "High". Your game's option screen taught me that there is something above "High", namely "Ultra". But clicking on the increase button again gets me back to "Low". That's really the worst case scenario, where the selectors even loop. But even without that, the maximum setting should, if possible, always have the same name, and ideally it should clearly say that there is nothing beyond it, which "Max" usually does.

"Min" doesn't, because there's also "Off" in some cases. Which kind of suggests that what you should do is: Use labeled sliders! This maximizes usability. And why wouldn't you do that, right? Why wouldn't you try to maximize usability? ... I don't know. But too low FOV and broken volume sliders everywhere make me wonder what your agenda really is. It's 2016, we're a decade deep into the comfortable zone, where game development is far from being forefront-of-programming, yet the wheel of volume slider, options controls, the labeling of options etc., is reinvented again and again - and wrongly so. I. Do. Not. Understand.
"All progress since your last save will be lost."
Clearly, developers are neither willing to invest the required love nor are capable of thinking outside the box, of leaving the broadly trampled path giants before them created.

Regarding the former:

If someone just manually saved their game, and seconds later they call "Quit" from the menu or press Alt+F4, then the game should just quit instead of nagging, because the user clearly knows what they are doing, so don't stand in the way of their will. This could ideally be implemented with a "Saved." message that persists for a few seconds on screen and fades out. As long as it's visible, we're inside the grace period, so no questions will be asked. Thy will be done, user! This might even help a bit against save-scumming: If the user doesn't want the message on screen all the time, then they should not save all the time.

Now, if it comes to displaying that warning message about the game not being saved: Please inform us how much we'd be losing by telling us how much time has passed since the last save (Bioshock Infinite actually did this!), bonus points if this information is correctly shown even if we decide to delete the most recent savegame.

Regarding the latter:

Autosave is a normal thing today. Why then don't we create a dedicated "Quit" autosave slot? When the player invokes "Quit", the game is saved, the program quits, and next time, the "Continue" function will load this most recent savegame. If the player does not like the state of things, then they can freely choose to load one of the regular autosaves or their own savegames (e.g. the quicksave).

One might think that such a feature is best only applied for Alt+F4 and therefore not worth the effort, because if the user calls "Quit" from the menu, this might be an accident, so there should be a dialog, anyway, but it's not rocket science to create a considerably larger gap between the "Quit" entry and the rest of the menu above it, so that actual intention can be assumed. Also: Even if we ask the user if they really want to quit, then their answer "Yes." could still create an automatic "Quit"-savegame!

A "Quit"-autosave is also a great solution for the checkpoint problem: Checkpoints can increase immersion, because the player can't mold reality to their whim via excessive saving and loading. But how far is it to the next checkpoint? Can I play some more now, or will my real-world appointment or crying baby ruin this? Very unnecessary problem. In addition to checkpoints, just add a "Quit"-autosave if the game's tech would allow this, and we're good.
Savegame implementations need a lot of love.
First of all: If you don't use "safe saves", you're doing it wrong, because it's very simple to implement a simple two-state save where only once the file has successfully been created, the currently existing old savegame is actually replaced with the new one. This is a simple way to improve the user's data safety, and since this can even easily be abstracted and put in a library, you have no excuse. Personally, I sometimes even implement three-state saves, because: What if something prevented us from replacing the intended data file with the successfully written temporary file? When we later encounter this situation, we won't know if the temp file is actually proper, so we can basically only delete it. By using another intermediary file, we can make a safe automatic decision on program start.

You should even go so far as to have a rotation of several files, if we're not talking about exceedingly large files: The last 10 quicksaves could exist (indeed visible from the load menu) as a rotation. If only one of your customers will avoid a lot of frustration by this, then this library call was justified. Make the backups invisible in the menu, if you want, because things might look cluttered otherwise. But love your user's data like they do, if you can. And how about a bit of innovation: Add a "show hidden" button in the load menu that shows backup files, too.

Btw., if I see yet another game where the quickload key loads the quicksave even though I already created a newer savegame via the menu ... please, use your head! What could possibly be the user's intention? In the vast majority of the cases, when they hit the quickload key, they want to continue where in their mind they placed the last snapshot of the world. If they insist on the quicksave game, they can still use the menu, but this is sure an exceptional case.

I prefer a savegame system where I can give the saves a name over one that only has automatic names. While there should always be an automatic name so that naming does not become an unnecessary burden, the players should be able to freeze those special moments in a way that they can find them again. The savegame system shouldn't be exclusive to users who just get through the game and forget about it. I wonder if your expectation as to how little love players will give their playthroughs is a reflection of the love you put into development.

And what ever happened to (small) screenshots that show the current in-game situation? Prey (2006) even had full resolution shots that were visible ... as the full screen while the game was loading, someone did think outside the box there. That was also the one game (Yep. It's rare.) that showed an image of a keyboard with the actually assigned keys highlighted when you pressed F1. On the topic of savegame screenshots: I have yet to see someone go all out and use a skybox screenshot (6 images) where you can even look around (in low resolution) before even loading the game. Never seen that before. Want to stand out? Here's your chance. Someone's gonna be the first.

Depending on the game, you could even be so radical as to implement a system that allows to smoothly rewind the last 20 seconds. Life Is Strange already did it, for well more than 20 seconds. But the game was designed around this mechanic, and its gameplay is simplistic. Today, such a system for a game as complex as Deus Ex: Mankind Divided is unthinkable. But tomorrow is coming.
better savegame concepts for better immersion
Everything in the game's reality matters more if the player has to take it more seriously, so if the player can't save in every place whenever they want, they will act more strategically instead of forcing themselves through every possibility-corner. I am not advocating to take this ability away! Instead, we should go the route of System Shock 1 where you could adjust various parameters of the gameplay before beginning the game. E.g. the player could define whether or not they are able to save in every place, or if they want to use pre-defined checkpoints, or ...

... or save in any place at any time as long as they have enough savegame points left. E.g. every minute spent in the game (not in the menu or inventory, but in the live action) could earn the player such a point, until they have at the most 2 or something. Maybe change of location is required, too, so no waiting in the same spot. The points could be shown in the menu instead of in the HUD or inventory etc. so that the 4th wall is violated as little as possible. The purpose of all this is to prevent save-scumming. The player can of course still do this if they jump through all kinds of hoops (walk up and down in an abandoned shack etc.), but what's rather gonna happen is that the player will adjust their overall approach to make the most of the game's reality, not so much of the game's reality in combination with abuse of the savegame system.

The opposite approach is possible, too: A manually created savegame that is not even 1 minute old (or whatever time span we decide for) can not be loaded.

The player could define these parameters upon beginning of a game, e.g. "I want to get a new savegame point every 10 in-world minutes, and I want to have max. 2 of those". Instead, all developers give us all the time is a list with 3-4 difficulty entries. Isn't it time to experiment a bit further than this tired trope?

When it comes to using slot machines or any other random-based event in the game world: How about feeding those events with a seeded random generator that produces the same outcome even if the player loads a savegame? To a degree, this can certainly be achieved. Depends on what kind of game and location we're talking about. E.g. in "Fallout 3: New Vegas", whenever the player saves, the slot machines etc. could each have been assigned a new random seed which is also saved in the savegame, so on every load, the exact same thing happens, so they can't cheat the slots.
About those logo video clips ...
It's fine to see a kaboom presentation of the product we just purchased the first time we start it, so let the companies who participated prance their rendered logo animations across our screens by all means.

But not only can this get old, it can even become a significant burden if a game is started often, which happens among power users who tweak everything to the optimum before they dive in, but even the others often face "The game needs to be restarted for these changes to take effect." and thereby ... the logo videos. Hey, what about automatically showing them only once per real-world day? "OMFG I've never thought of that!" Well, I'm available for consulting. If it leads to a better IT/gaming world, I can make time.

The proficient PC user of course opens the game's installation folder, looks for the video folder, tries to determine which files represent the various logo clips, and just renames them so that the game can't find them. Any sane developer's code which discovers such a file missing would just skip this non-essential part of the program, and many games indeed do this.

But not only are there games that just plain simply freeze/crash if they can't find their precious "AMD - The way everything is meant to be challenged!!1" files (Disrespect is the result of people being forced to see these clips.), but too often we don't even have individual files and are instead looking at gigabyte-sized archive-like files. That was kind of ok in the times of Doom 3 (2004), because not only could you look inside with standard tools and see the individual files, you could even put files with the same name and sub-directory structure as shown in the archive in the normal file system, and the game would then prefer those real files over the virtual ones. But in cases where this is not possible, and in our modern times in general, it's not acceptable:

1) We must be able to do those little tweaks. Taking this possibility away makes the world poorer, technical fixes and modifications must be possible. Can you believe that they put the metal music track in the main menu of Doom 3 into the game in mono? Plus it was badly equalized: Too little bass, too much power in the middle frequencies. Then they released the BFG edition of the game. Guess what they did not change ... yeah. "Those 2 additional megabytes for a proper quality stereo version would just have been too much, sorry." Or was it "We just didn't realize that this part of the game you see all the time is done badly, even though we, too, saw it all the time."? - This is one of those cases where the PC master race (In the true meaning of the term, not the perverted one.) shines. E.g. I found a better (and stereo) version of the track online, polished it as well as I could with WaveLab, and put it in!

2) In the case of the August 2016 game "Deus Ex: Mankind Divided", the two largest data files are 15 and 23 GB. Yep - that huge. At this point, let me explain Steam's game patch/update process: If some parts of a game are patched by the developer, Steam will transmit only those few changes to the consumers, which is great, and then their existing files will be changed accordingly. In the extreme case, there might be a few bytes that change in both these large files in one patch, and what happens then? Steam will create the new version of both files, thereby not only writing 38 GB of data, but also occupying 38 GB of extra space until the process is complete. Because only once all files that need change exist in their new version, the outdated files will be replaced by them, which then frees up the additional space. But I have seen many forum posts that not only wondered WTF was taking so extremely long for a 100 MB patch, but also many SSD (solid state disk, today's HDD (hard disk)) users didn't have enough space, so the patch process failed.

So ... huge archive-blob files that can't be viewed with standard tools? GO HOME! We don't want you.

Now back to the logo video clips and how they should be done.

No matter what you decide to do on the game's first start, eventually the user must be able to skip these logo videos. Esc, Space, Enter, mouse buttons ... whatever. And if you do it, make sure that this skips all of them, because anything else just shows a half-arsed developer behind the scenes. Bonus points if you allow to completely switch the logos off via the options menu. But no matter which route you go: If your videos are individual files, then the absence of such a file must result in the skipping of the playback of that video, not in a crash/freeze! There is no excuse whatsoever for such behavior.

And if you want to go all out: Implement the possibility to launch from the desktop / Steam straight into the last savegame. I haven't seen that one yet. Even though that's the primary use case, right? Don't you start the game application to trigger the "Continue" entry in the menu and get back to the gameplay? In most cases, you do. And in all cases, the developers have different plans. And you, the developers, should finally begin to ask yourselves why you are so insistent on implementing your interfaces contrary to their users' intentions!
Stop telling us that it's a "game".
"Game saved." - Just "Saved." would have been enough. We've gotten proficient in overlooking all these penetrations of the fourth wall, but a perfectionist would still aim to keep the player's mind confined to the world you've created for them. Also, as we know from typography/DTP, the mind is affected even if the person is not consciously aware of the subtleties that went into the design (e.g. amount of different fonts/styles - in most cases, less is more).

"New Game" could just be replaced with "New". Or maybe "Enter Tamriel". And "Continue", which is alright anyway, could become "Continue Adventure", but this emphasis of the fact that we're about to enter that world like through a portal might even have the opposite effect, it might stay with the mind. This is a front for experiments, for gaining new knowledge. But in any case, the term "game" should be avoided.