Steam

Steam

Pas assez d'évaluations
Compendium for the perfectionist game developer
De 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.
   
Récompenser
Ajouter aux favoris
Favoris
Retirer des favoris
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!

HBAO, SSAO, MLAA, FXAA, SMAA ... ARE YOU KIDDING ME!?
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 own 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, for 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 having been saved recently: 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. If you insist, you can delete this autosave whenever the player continues playing, so that the save-abuse possibility hasn't increased.
"Do not turn off your PC" ... really?
Almost every game in the 2020s greets us with these words. It warns us: "While this demonstrated symbol is visible on screen, the game is in the process of saving." (Good.) "And thus you should not turn off your PC." (Uuuuh...)

Like "Press any key" game logo screens that serve as an unnecessary gateway to the actual main screen which has the menu etc., other such clichés (or memes) are just mindlessly repeated by game developers. Maybe it's kind of like back in the 1980s, when we so loved to type "Copyright (C) 1985 by Namehere" without actually meaning it - it just felt good. I actually know the energetic mechanism behind it, but let's leave my inner McKenna out of this.

One such mindless meme is the "Don't turn off your PC!" warning. It's unnecessary. It's plain simply false. It's just a waste of screen space and user attention.

First of all: Non-programmers are probably not aware of it, but any sane developer will not just overwrite your current main document with a new one, so that failure would leave you with nothing. Instead, they will save a temporary file. Once that has succeeded, they will replace your actual main document with this new file, and this can not fail: It is an "atomic" operation (dev slang). It either completes - or it doesn't. There is no 99%-whoops danger here.

So ... you will either have your new save game or not - but you will sure as human stupidity at least have your old save!

But what about the problem of writing to your computer's disk and disconnecting the power right then? That's bad, no? ... No, it's not. Well ... it should be avoided. Shut down (or, better in my personal 20 years of hibernating, hibernate if you have many programs open) your PC properly, never just disconnect the power.

Whatever they exactly mean by "do not turn off your PC", it also applies to all other things your PC is writing to disk, and ... it is doing that all the time! It is always active, shuffling things around, executing background tasks and services. There's hardly a safe moment to just disconnect the power of your PC without a "saving" process taking place right then.

So, what happens if the power cuts out while it's writing things? Nothing bad. Because for the longest time now, we've been having journaling file systems. This means: A file will not just be opened for writing, and the power dies, and then the half written file will remain unclosed so that only a thorough disk scan will find and fix it. Instead, the PC will write down its intention to do that thing. Then it will do the thing. And once done, it will remove the journal entry. So if it boots up after having died surprisingly, it can quickly look up the things it may have to clean up in 10 milliseconds, and that's it.
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.

In addition to "safe saves", you should also consider a rotation of several files, if we're not talking about excessively 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 explicitly manually 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.

Also ... have you ever realized that savegames have tree hierarchy? You load your first savegame, play a little, save a new one. That's a child of this one. Linear, not branching. But if you'd load the first savegame again, play, and save a new one, now you have two branches, and in this same way, a tree could emerge. Plus, your several play-throughs, of course, would be individual trees. Usually, when I do another play-through and old savegames are still present, only proper sort order prevents them from being mixed up. But they could also be presented as two separate graphical trees, "sorted" by temporal order of course. Usually, a player would abstain from causing an actual tree, for several reasons, but one of them is that they'd get confused which savegame is which. Here's a front to be inventive, as described. Who knows what will come of it. You and your players might not end up being the ones who really benefit, but the gaming world as a whole might, because often a working implementation is needed to inspire new ideas. A game whose concept warrants rather tree-like savegames as a result? No, I can not imagine this - because I haven't thoroughly thought about it yet. But maybe, there's a whole world waiting, and someone implementing a tree GUI for savegames might be the portal to get there.
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 starting a new game. E.g. why not let the player decide whether or not they will be able to save in every place, or if they have to visit dedicated save-stations, 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. Even if the player would end up with one or two savegame points left most of the time, the mere presence of such a system would strongly motivate to approach the game in a more realistic instead of molding-to-one's will fashion.

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 their personal current random generator seed 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, even for the feeling of this new big thing we just took home to enjoy for a hopefully long time, 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. This may sound like additional work, but it's only ... one program statement. (30+ years of development experience here.)

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 (My disrespect is the inevitable result of being forced to endure 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 use common standard tools to look inside and see/change 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, much 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 (not even the whole affected files) to the customers, 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 eventually aborted harmlessly. (Maybe Valve has woken up by now and at least checks for sufficient space in advance.)

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!
Do not cause unnecessary breaking of product.
An online multiplayer game sure needs servers, else it can't be played. But not only can, in many cases, these servers be run by individuals, not just by the company, it's also sometimes possible (though a lot harder, especially when it comes to cheating/"hacking") to implement this in a pure peer-to-peer fashion, so no servers are required in the first place. Anyway, a server-based game should not die if the company does. It really doesn't have to (in most cases).

But a singleplayer game that dies because the company does? Really? How isn't that considered theft by the lawgiver? You need to make sure that your product doesn't die without absolutely having to. Else the main people involved should be pursued, no matter what company they later join/create, and their products should not be bought, because obviously their priority is not the customer.
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).

Just a few thoughts, not solutions: "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.

And don't be a complete idiot: In Metal Gear Solid V, the guy you guides you out of the hospital in the beginning actually tells you in his own voice in the game: "Time to walk. Press the Stance Button to stand up." Translation: "Fourth wall - begone!"
< >
1 commentaires
Mert 24 févr. 2023 à 15h41 
Wow, now I don't have to write any of these myself haha, thanks again!