the problem differs from game to game. If you're playing a game that loses progress if not saved properly, or cannot be saved, then thats where the quitting option becomes a problem.

Their are quite a few games that implement a time feature GameCreator, however most of them are mmorpg's, which is reasonable as the online feature can cause problems if disconnection is immediate. There have been quite a few times where my internet has turned off, but it took a few seconds for my character itself to be removed from in-game, causing me to die. Some mmorpg's implement both the time and are you sure features together, so once you click quit you are given a 10s window in which you can click quit again to close the game immediately. It's a mostly irrelevant feature, save for the off chance you need to leave in the space of the 2s required to click the quit button, but its nice nonetheless.

The problem with this, well, problem, is that their is no entirely correct solution. its a Comfortability vs Security problem, where adding to one will always minus from the other. It really just depend on what game you are playing, as I stated originally. A game that does not have a dynamic or auto save feature,or no save feature at all, would lean more heavily on the security side. Where as a game that does will focus more heavily on the comfortability side.

If I was leaning onto the Security side, I'd only have a quit to the main menu option on my menu bar. most games allow you to continue where you left off from the main menu, so in most cases this stops potential problems. however if that is not the case, I would make sure that accessing the quit option takes at least more then one click once you access the menu (basically a sub-menu, probably accessed through options). Finally I'd implement an are you sure to feature. An additional thing you could do is make sure that each click has to happen on a different part of the screen, so that rapid clicks in the same area don't cause a quit. This would remove 99% of the accidental quits, that 1% being the extremely unlucky person.

However if I was leaning onto the comfortability side, I'd have the quit to menu and quit to desktop on a sub-menu within the quit button. Well, less of a sub-menu, and more of a replacement for are you sure. It removes the need for are you sure and makes quitting feel nice, at least in my opinion. I would also make sure that clicking on them happens at a different part of the screen to avoid rapid clicks, however I'd do this at a lesser degree to make it less movement for your mouse. This makes it a lot less effective, as rapid clicking usually occurs in an area and not just one spot, but we are not going for Security here. There's not much else you can do for this, though I may be wrong, so its the easier of the two.

But to be honest, these kind of features are the 'that'd be nice' kind of features. I'd only worry about it after you've created your game, but by then a lot of developers have already moved onto their next project. moving off-topic, I never really liked the concept of starting a new project so soon after finishing your first one. Give at least half a month of extra time for a refresher, and another half to come back to the game you made and see if their are any design flaws, or areas you can improve in. Not to mention most of them will have already been pointed out by the community. But I digress, that's all I have to say on the topic.

EDIT: in light of the next two posts, I want to rephrase that I was talking about what things worked towards the goal of security, and what worked for the goal of comfort-ability. A combination of the two are generally good for most games. if you're playing a game like CoD Zombies, then you can spend up to entire days (theoretically infinite) playing it. You can't save your progress, and any disconnection results in the loss of your game. During this time you'll be taking plenty of breaks and, more often then not, won't be paying attention to the small things. In a case like that, i'd like as much security as possible. However on the contrary, you can play this game for one minute and then quit.

So on rethinking, I'd prefer to have this 'extreme' version of security as an optional feature. That way when im going for that score break or just want to play as long as possible, I can select it to ensure I don't accidentally disconnect.

The games that annoy me when it comes to quitting them are mostly those that give me a bloody loading screen as I'm quitting, and/or make me wade through stuff to actually exit.

In game > Menu > load screen > some other menu > load spinner > yet-another-menu > long load spinner > main menu > quit menu asking me if I actually want to leave the game > LOAD ****ING SPINNER > desktop

When what I want is

In game > Menu > Confirm I meant to quit in the middle of my game > Desktop. No loading spinners, no delay, no flashy sounds or graphics to make me think the game is more 'polished' than it really is.

The other thing that bugs me on quitting functions are games which have no knowledge about their save state.

In game > menu > save game > menu > quit game (Without doing anything to game state) > Are you sure you want to quit? unsaved data will be lost! (Wait, did I save, or didn't I just save? I'm tired and in a hurry...)

There are a number of approaches. The best approach is one that suits the context. The biggest complexity is how to handle saving data. If players will not wish to manage their own saved games, or are otherwise restricted from doing so, then it's reasonable to auto-save the game when exiting in most circumstances. If automatically saving the game is not a reasonable option, then a prompt might be a solid choice.

After reading this, one approach I considered to avoid cases of accidentally exiting the game would be to impose a time on the interaction of instructing the game to exit itself. Rather than allowing the player to tap/click the exit button, and then implementing something like a timer, make the exit button a 'hold button.' The player would be required to depress the button for a minimum length of time, such as 1.5 seconds. The interface device would then provide visual (and possibly auditory) feedback to indicate the progress toward exiting the game. This minimises the risk of accidentally hitting the wrong button, and diminishes the likelihood of exiting without thinking. Simultaneously it provides feedback to the player and does not require the player to wait, inactive, while a timer expires. Implemented well, it should be a satisfying interaction.

One issue that caught my attention was the two entries about quitting the game back to the desktop/dashboard/whatever, especially the "are you sure you want to quit?" dialog entry.

Hi,

- if I'm doing some shareware game, I put this dialogue with a few seconds delay and product promotion in it until the game is not registered. Registered game comes out without any holdback and fully advertising-free.

Good luck in your work.

The point as listed in the original article makes an assumption that simply doesn't hold true for all players in all games:

Our limbs are not flailing madly out of control. Mouse hands do not go rogue and start clicking random patches of screen. The left hemisphere of my brain has never betrayed me by trying to auction off my Diablo 3 inventory, or closed a game I didn't want closed.

A lot of people do accidentally trigger the option to exit a game for a number of reasons:

• They're in a rush to reach another option, and mis-click.
• They're rushing through a previous option and accidentally trigger multiple inputs.
• They're tired or not paying full attention and simply click the wrong option.

If the player won't lose any progress (thanks to auto-save, because they have already saved manually, or because the whole concept isn't relevant to the game in question) then it's probably fine to simply quit, but if the player will lose progress by exiting the prompt will sometimes be welcome.

You don't need some new solution to this; a correctly implemented prompt is already a pretty ideal solution, and is one that players are already familiar and comfortable with. As others have said above, this is only a problem if it's implemented poorly and becomes intrusive or bothers the player unnecessarily.

Then again on the second point about exiting, the article makes an assumption that doesn't always hold true:

If someone presses "exit," they have a right to expect an exit. It's an unambiguous command. It doesn't mean "hey let's leave the session and then restart the game on the main menu screen." It doesn't mean "the player has indicated they want to exit the game, let's ask them if they're sure they want to exit the game." It means they want you to go away now.

This is a flawed assumption, or at least one that only focusses on some situations whilst ignoring others; it's actually quite common for games to have a command to exit back to the main menu, and in many cases this is actually something the player may very well want to do. The simple solution to this is to provide both options ("exit to menu", and "exit to desktop", or whatever phrasing makes the most sense for your context) and clearly label them.

...and then, because contrary to the authors suggestion the player may have actually chosen the wrong option by mistake, if there is a risk of losing unsaved progress you should probably prompt the player to confirm the action.

Do whatever is contextually appropriate for your game, and if there is a chance that the player might accidentally lose progress provide a fail-safe that is as unobtrusive as possible.