Why Do I Need to Restart the Game?

[Shamus Young]

Why Do I Need to Restart the Game?

Today's silly thing is this:

"Why does the game force me to restart when I change the graphics settings?"

Read Full Article

 

[Barbas]

Is there a single problem that's plagued you longer than any other when you're trying to code - something that keeps rearing its ugly head, something that almost requires you to attach a sticky note attached to your monitor so you don't forget to check that it hasn't reemerged?

 

[Callate]

I suppose the related question is, then, "Why don't more games allow you to change graphics settings in an external configuration program, rather than forcing you to go through minutes of logos and initial loads just so you can change one thing and then start the process all over again?"

Before I had a 1080p monitor, I had an extra-special loathing for games that automatically started at that resolution (meaning that, on occasion, the menu selection to change graphic settings was off the damn screen.) Nothing like fishing through an .ini file or the equivalent to change resolution manually to give you flashbacks to messing with config.sys and autoexec.bat files. Good times!

 

[Kenjitsuka]

"It's a problem that really only applies to PC gamers, who are a minority of the customer base."

Well... problem. You change it like once or twice when starting out. Then usually never, unless something extra-ordinary happens.
And with my blazing fast SSD and tons of RAM I dont give a crap about the ten seconds or so it needs to reload itself.

I'm much happier with tighter code that restarts than with a monster with tons more options that *will* by definition be more buggy!

 

[gardian06]

good article, but in some ways your argument is a little flawed. instead of laziness, or budget typically what actually limits the dynamism of especially shaders, and graphics is not the complexity itself, but the overhead of what has come to be the "god shader" the shader that literally does everything. to put this in context for a 1024x1024 texture all of the shaders that we want to use on it take up say 1MB, 3MB, and 5MB respectively for that texture (the good news is that we don't have to reproduce those memory foot prints for all objects that use that same texture, but if we wanted to have a single shader that does all of it then we have to introduce 1 shader that does all the tings, and in many cases memory foot print is additive, but it also has to hold memory open for parts of the shader that are not being used. these god shaders are really great because they can do everything they can even recalculate in real time, but when ever you have to recalculate anything in real time foreach object you have to have a request "did anything change", and if nothing changed the system has to send a response "nope everything is the same", but if something did change you either have to send "these 3 things changed" (requiring that the system has to keep track of all the settings, and then note changes), or "yes something changed here is all the settings" (which just means the graphics system will recalculated everything instead of just what changed). either of these 2 scenarios basically requires a bunch of questions to be asked by what is already the first of second most demanding system in a game (this depends on complexity of actual game logic) the analogy of this is a 3 year old that asks every 5 seconds if they can have a cookie, and the only response you can give is yes, or no (after that nightmare passes) now imagine if you had 500, or 5,000 of those children, and you had to answer them all individually.

I suppose the related question is, then, "Why don't more games allow you to change graphics settings in an external configuration program, rather than forcing you to go through minutes of logos and initial loads just so you can change one thing and then start the process all over again?"

Before I had a 1080p monitor, I had an extra-special loathing for games that automatically started at that resolution (meaning that, on occasion, the menu selection to change graphic settings was off the damn screen.) Nothing like fishing through an .ini file or the equivalent to change resolution manually to give you flashbacks to messing with config.sys and autoexec.bat files. Good times!

the problem with that is that this feature assumes that 1) the user knows to look in the game folder for these options. 2) the user knows what all of those options do without seeing the immediate result. 3) the user is going to know what values to put into what fields so that the system doesn't throw up its hands scream "I do know what you want from me", and crash then the user has to spend a good deal of time tracking down what setting is making the problem happen to begin with.

 

[Pyrian]

Is there a single problem that's plagued you longer than any other when you're trying to code - something that keeps rearing its ugly head, something that almost requires you to attach a sticky note attached to your monitor so you don't forget to check that it hasn't reemerged?

For me: Dead units. Sheesh. For a few reasons I need to keep dead units around, so I just set them to "dead" and take them out of the update loop. But then every time I (or the other programmer for that matter) add a new system that affects units, I forget to check if they're dead.

So far I've had dead units get targeted, take up space, use their shield on behalf of adjacent allies, catch on fire, reappear when the fog of war conceals and then unconceals them, and more.

Then there's the Player units, which mostly come "back to life" for the next battle ("It's just a flesh wound."). And they need to be reset. For living units, most of the resetting happens automatically because they're still in the update loop. But the dead units are exempt from that. So I've had them come back injured, on fire, stuck in mud that isn't there, with a spell half-cast, lying down, and more.

Glade Raid [https://dl.dropboxusercontent.com/u/52800206/GladeRaid/GladeRaid.html]

 

[Thunderous Cacophony]

Maybe you need a shader for light bloom, another for antialiasing, another both both, and another for neither.

Typo there, I believe it's supposed to be "another for both".

OT: I am really enjoying these technical articles. Do you think I can apply them to an associate degree in computer engineering?

 

[Areloch]

good article, but in some ways your argument is a little flawed. instead of laziness, or budget typically what actually limits the dynamism of especially shaders, and graphics is not the complexity itself, but the overhead of what has come to be the "god shader" the shader that literally does everything. to put this in context for a 1024x1024 texture all of the shaders that we want to use on it take up say 1MB, 3MB, and 5MB respectively for that texture (the good news is that we don't have to reproduce those memory foot prints for all objects that use that same texture, but if we wanted to have a single shader that does all of it then we have to introduce 1 shader that does all the tings, and in many cases memory foot print is additive, but it also has to hold memory open for parts of the shader that are not being used. these god shaders are really great because they can do everything they can even recalculate in real time, but when ever you have to recalculate anything in real time foreach object you have to have a request "did anything change", and if nothing changed the system has to send a response "nope everything is the same", but if something did change you either have to send "these 3 things changed" (requiring that the system has to keep track of all the settings, and then note changes), or "yes something changed here is all the settings" (which just means the graphics system will recalculated everything instead of just what changed). either of these 2 scenarios basically requires a bunch of questions to be asked by what is already the first of second most demanding system in a game (this depends on complexity of actual game logic) the analogy of this is a 3 year old that asks every 5 seconds if they can have a cookie, and the only response you can give is yes, or no (after that nightmare passes) now imagine if you had 500, or 5,000 of those children, and you had to answer them all individually.

I suppose the related question is, then, "Why don't more games allow you to change graphics settings in an external configuration program, rather than forcing you to go through minutes of logos and initial loads just so you can change one thing and then start the process all over again?"

Before I had a 1080p monitor, I had an extra-special loathing for games that automatically started at that resolution (meaning that, on occasion, the menu selection to change graphic settings was off the damn screen.) Nothing like fishing through an .ini file or the equivalent to change resolution manually to give you flashbacks to messing with config.sys and autoexec.bat files. Good times!

the problem with that is that this feature assumes that 1) the user knows to look in the game folder for these options. 2) the user knows what all of those options do without seeing the immediate result. 3) the user is going to know what values to put into what fields so that the system doesn't throw up its hands scream "I do know what you want from me", and crash then the user has to spend a good deal of time tracking down what setting is making the problem happen to begin with.

A third option that is uncommon, because it does require a bit more complexity on the backend, is generating shaders upon configuration changes.

This requires an embedded shader generator, so you can't utilize third party tools to author your shaders, but it does mean that when you change your settings and hit 'apply', the engine itself can run through and rebuild optimized shaders for the changed materials.

The engine I use does that, and while it has it's own limitations, the ability to modify pretty much every single setting other than the rendering API(switching between OpenGL and DirectX still necessitates a reboot because the actual applications' render context changes) and not have to reboot is honestly rather nice.

 

[Kahani]

I suppose the related question is, then, "Why don't more games allow you to change graphics settings in an external configuration program, rather than forcing you to go through minutes of logos and initial loads just so you can change one thing and then start the process all over again?"

Mainly because this doesn't actually help at all. You still have to close the game and restart it any time you want to change any options, you just have the added inconvenience of having to run a second program to actually change those options, and often having to do so for options that wouldn't normally require a restart if they were done in-game.

And with my blazing fast SSD and tons of RAM I dont give a crap about the ten seconds or so it needs to reload itself.

Indeed, even with lower end systems few games actually take that long to start up. It only really becomes a problem when publishers insist on having half an hour of unskippable logos and copyright notices pop up before you can get to the game, and at that point it's not the graphic settings that are the problem.

In any case, I can't remember the last time I actually had to do this. Most games don't use their full graphics capabilities just to display the main menu, so it's easy to allow any options to be changed from there and just not allow some things to be changed from the pause screen while a game is actually in progress.

 

[Callate]

Mainly because this doesn't actually help at all. You still have to close the game and restart it any time you want to change any options, you just have the added inconvenience of having to run a second program to actually change those options, and often having to do so for options that wouldn't normally require a restart if they were done in-game.

Only if having an external program to modify settings precludes having the ability to change settings inside of the game itself. It doesn't. It just means not having to automatically load an ungainly front-end (that is, the game itself) in order to make changes, particularly changes to the initial, default settings.

Nearly every game made with the Unity engine has just such a program.

the problem with that is that this feature assumes that 1) the user knows to look in the game folder for these options. 2) the user knows what all of those options do without seeing the immediate result. 3) the user is going to know what values to put into what fields so that the system doesn't throw up its hands scream "I do know what you want from me", and crash then the user has to spend a good deal of time tracking down what setting is making the problem happen to begin with.

1. If the user is forced to search in a subfolder to manually modify a settings file, that's an issue. If there's a link or shortcut in the directory along with the "launch" link called something like "settings", that shouldn't require a scavenger hunt. As I said, most Unity games do this automatically when you choose "launch" anyway.

2. It's true that it's difficult to know how much various levels of anti-aliasing will effect a user's frame rate, or how much of a performance hit enabling vsync might entail, without being able to see the immediate results. But many long-time users have at least some idea what their graphic cards can handle. And they almost certainly know their monitor's native resolution. Nudging the configured specification from the user's best guess isn't always going to be easier than doing so based off of the game's default settings, or the settings assigned by a hardware assessing sub-program, but it will a good portion of the time- especially as the game's programmers don't know if the user doesn't care about soft shadows or water reflections, so long as the frame rate never drops below 60.

3) Again, this is more of a problem if the user is monkeying around with the settings file with a text editor than with a small program with drop-down menus designed to change the game's settings. It's possible the user might still select options that aren't compatible with their hardware, but less likely- and a well-designed external configuration program would make it all but impossible, and generally take less effort to put together than one set of textures.

 

[Drejer43]

all this time I thought "shaders" were literally only for shadow effects.

 

[gardian06]

...snip...

the problem with that is that this feature assumes that 1) the user knows to look in the game folder for these options. 2) the user knows what all of those options do without seeing the immediate result. 3) the user is going to know what values to put into what fields so that the system doesn't throw up its hands scream "I do know what you want from me", and crash then the user has to spend a good deal of time tracking down what setting is making the problem happen to begin with.

1. If the user is forced to search in a subfolder to manually modify a settings file, that's an issue. If there's a link or shortcut in the directory along with the "launch" link called something like "settings", that shouldn't require a scavenger hunt. As I said, most Unity games do this automatically when you choose "launch" anyway.

2. It's true that it's difficult to know how much various levels of anti-aliasing will effect a user's frame rate, or how much of a performance hit enabling vsync might entail, without being able to see the immediate results. But many long-time users have at least some idea what their graphic cards can handle. And they almost certainly know their monitor's native resolution. Nudging the configured specification from the user's best guess isn't always going to be easier than doing so based off of the game's default settings, or the settings assigned by a hardware assessing sub-program, but it will a good portion of the time- especially as the game's programmers don't know if the user doesn't care about soft shadows or water reflections, so long as the frame rate never drops below 60.

3) Again, this is more of a problem if the user is monkeying around with the settings file with a text editor than with a small program with drop-down menus designed to change the game's settings. It's possible the user might still select options that aren't compatible with their hardware, but less likely- and a well-designed external configuration program would make it all but impossible, and generally take less effort to put together than one set of textures.

my statements were meant to only be in direct response to the "question" though the presumptions that you make in your points are a little staggering. the Unity launching optimization window is actually a double edged sword for, and against Unity. it is a Hallmark that the game is made with Unity (this is where much of the current hate for Unity comes from), and the other issue with the launcher is that it over simplifies things to such a degree that even a "stupid user" will be able to understand, but the most developers that enable the launcher don't realize that they have to actually implement different settings for these presets to actually make those settings do anything (many of these developers just thing that DirectX, or OpenGL will take care of it). I have seen point blank evidence of this by looking at the active shaders, and memory footprint of my graphics card at these different settings levels, and seen they were identical.

the context of a user knowing the capabilities of their hardware, so that they "just know" what features, or levels to set what things to is kind of funny actually because these can very from game engine to game engine. I know through some countless hours of trouble shooting that if the game is in Cry engine 3 my hardware can do Medium to High pre-sets, Unity depending on optimizations by the developers anywhere from Pretty-fast, in Unreal 3 I can get away with Medium without second. Like I said that is with numerous hours of making changes, and seeing differences then even knowing this I still have to validate this hypothesis whenever I load up a new/different game because optimizations, expectations, and drivers in other words benchmarking. expecting a random user know the absolute capabilities of their hardware is a little excessive. you probably don't realize but a large majority of users buys a system as is, and just expects it to work, and they might not know what the exact specs of their system is much less where to look to find it. then think about all of those users that buy $5K+ machines so that it will run anything and then have it come crashing to a hault when something like Batman Arkhem Knight comes out, and runs like shit unless you have the exact specs the developers programmed to (what they had in their systems).

my comment of point 3 where mostly as direct response to the ability to modify a games settings through a text editor (basically if the user tries to put in 3x AA the system will either in best case ignore the field, or in worst case crash on load). but your point of an external optimization program is not without its merits, but in the end when presented with the original thought proposed in the editorial "why do games make you restart to change settings" the difference between a in games settings menu, and a optimization launcher is how far out of the game I have to go to change settings, and if I manually have to end the program, and relaunch the game in order to get to it.