End Turn button and BGA guidelines

[paramesis]

I'd like to discuss "End Turn" buttons because I think there is a disconnect between the intent of the BGA guideline and how developers are interpreting it. On a few recent projects, I've observed or received pushback against the suggestion that there should be a full interface state to end your turn or undo after a complex series of actions, or that this button should not have an automatic timer. Multiple developers have expressed that it is against the BGA studio guidelines, referencing the following:

II-6 Avoid move confirmations

As a rule of thumb, don't require move confirmation. Confirming a move slows down the user interface and thus, the game flow. You can allow a player to confirm a move if this is a very critical step in a game, and if it is possible to trigger an action by accident. If client interactions are very complex and allow cancellation, the final move can be confirmed with a "Done" button.

Hawaii: Ending a turn is a critical action that happens only 5 times per player in a game. In this case, it is acceptable (and a good idea) to have a confirmation dialog.

Hive: Each move has to be confirmed with click on the location because it is very easy to click by accident.

Russian Railroads: Each move involves multiple interactions and can contains dozens of subactions. When the player is done "planning" he presses a "Done" button to submit the move to the server.

It should be noted for context that the text of the studio guidelines is based on a slideshow presentation. This is the slide that accompanies that guideline:



The confirmation presented in the slide is a modal dialog, which I would agree should be used very sparingly. I would also agree that a confirmation required after every step of a complex move or after simple actions like those in Can't Stop would slow down the interface and be disastrous for game flow.

However, I do not believe that a single End Turn button with the option to undo on games with a complex series of actions violates the letter or spirit of this guideline, given the rationale and examples provided, as well as the last sentence of the guideline itself. If it is, the number of independent complaints across multiple games suggests that the cost in frustration outweighs the benefit of saving a single button click, and the guideline should be amended or clarified. I have seen many more examples of users frustrated they could not take the turn they intended to take than users forgetting to end their turn or users being frustrated by too many confirmation buttons. If the rigid adherence to a guideline is consistently causing this many complaints among users, the problem might be the guideline. Some adaptations that allow an untimed end-of-turn undo/confirm option are Tzolk'in and Crazy Farmers, neither of which I consider to be violating the intent of this guideline.

See below some threads and bug reports on the topic of end-of-turn confirmation and automatic timer in various games.

Asking for an end-of-turn confirm/undo button:
Steam Works
Keyflower
Caylus
Terra Mystica
Takenoko
Troyes
Madeira
All of BGA

Asking to remove or modify an automatic timer on a confirm button:
Santorini
Santorini (Some discussion in Alpha Forum)
Kingdom Builder

Automatic Timer
The last item on the above list is my own suggestion on Kingdom Builder, in which I give some arguments for why there should not be a timer on an end-of-turn confirmation, which I will reiterate and expand upon here:

1. In my experience as a player unfamiliar with the game, the countdown timer makes the actual thought process of "confirming your move" in a relatively complex game much more stressful than it needs to be, and has almost led me to panic and restart my entire turn even though I didn't want to.
2. Because the timer is handled entirely on the client side JS, I was able to close out of the page once the timer started, which froze the game state at the end of my turn. Reopening the page any time later starts a new countdown timer at 15 seconds. This defeats the purpose in turn-based games, as a user who forgets to press the final confirm would be just as likely to leave the page when it is counting down.
3. I frequently take part in virtual meetups, in which we teach and learn new games and play them with no time limit or in training mode, so that we can freely ask questions or make comments. An end-turn timer would be very disruptive in this situation.
4. In real time games, BGA already has a timer pressuring users to end their turn.
5. BGA does a much better job than some other platforms of making it very clear that you are still expected to take an action.

The only place I've generally seen action bar countdowns work well is in lighter games where the interface offers you an action you're not actually able to do, so that BGA doesn't reveal to other players that you're not able to take that action, such as bidding in For Sale or power cards in Celestia (though I would say that automatic timers in a multipleactiveplayer state can be chaotic). Unless I am mistaken, outside of these narrow cases, the automatic timer for end of turn confirmation is a trend that has only appeared very recently. For the reasons outlined above, I don’t think this trend should continue.

From threads I have seen outside of BGA, Undo was one of the most anticipated and celebrated features to be added to this site, and an untimed end-turn option to undo or confirm is a natural extension of that.

Thank your for your consideration on this topic.

[docthib]

My understanding is, there shouldn't be confirm dialogs for every simple / single moves (are you sure you want to move here? buy this card? roll this dice?...) that would effectively slow down the game flow. But I see no objection on adding some confirmation on a serie of actions / critical action, unless you add an undo button.
What we did in Dice Forge was adding a user preference to speed up / slow down the game flow (less / more buttons / confirm). Maybe not the best option but at least players can choose.

About automatic timer, in my opinion it's not a good thing to use it unless the gameplay requires it. It may mainly lead to bad user experience (stress, frustration...).

p.s: yes I like slashes

[fafa-fr]

What we did in Dice Forge was adding a user preference to speed up / slow down the game flow (less / more buttons / confirm). Maybe not the best option but at least players can choose.

I think it is often the best option. I disagree with the opinion that confirmation buttons bother players. They bother some players, but not all. A lot of players like having some, especially when playing on mobile phones, because misclicks are not rare. And in some games, a lot of moves are very important and can ruin the pleasure of playing a game when we make an error, much more than five moves in a game. So when it's possible, let's let them choose!

And I also disagree with the opinion that we shouldn't implement confirmation or undo buttons because it slows down the game. On BGA there are time settings for choosing the speed of games. So if a player wants a fast game, they can choose fast games only, and in any time settings, what's the difference if players use their time to think a little or to undo and redo their move? And if fast games aren't fast enough, then implement a "very fast" setting, it has been asked multiple times (and at the same time, a "very slow" setting would be useful sometimes).
(Of course I agree that there shouldn't be frequent and mandatory confirmation buttons after a single-step action.)
In addition, I'm not sure that undo buttons necessarily slow down games, because it can take more time for some players to think till they're absolutely sure they're not making an error than to try and undo if they see they've made an error.

So I'd be in favor of changing a bit the wording of the Guidelines.

[shadowphiar]

As the developer of one of the games in question, I am interested to hear more opinions on this! At first I had no confirmation step at all, but because of requests, in a later build I added an End Turn button with a short countdown. Nobody has yet said they dislike having the extra End Turn stage, but I've had about 50:50 of people saying they like or dislike the timer.

Regarding the idea of a user preference to enable or disable the end of turn confirmation step - where people have done this before, has it been client side or server side? At the server you could completely avoid going into the Confirm End state at all, but I can't see how to access user preference state in my php, only in my js. Or at the client you could automatically make a call as though the button had been pressed, but are there any restrictions on when this.ajaxcall() can be used, i.e. would there be any problems if I sent a confirm response during onEnteringState?

[quietmint]

I just changed this for Santorini. I implemented it as a client-side user preference with 3 choices:

• Enabled with timer -- default behavior, button to confirm with 15-second countdown
• Enabled -- button to confirm but no timer
• Disabled -- immediate confirmation

I'm completely against using a server-side game option for this (e.g., the kind set once by the table administrator at game setup). This makes the lobby clunky and doesn't solve the problem (not everyone at the table may agree).

I think it's a different answer for different games. I am also the developer for Coup and Taluva. Neither of them matches what I did for Santorini. For Coup, users will always be required to have the countdown timer because this game is all about bluffing, social deduction, and time pressure. For Taluva, there is a confirm button (with no timer) at each individual step needed because you can rotate pieces after placing (otherwise I wouldn't know when you are done rotating) -- but there's no confirmation for the entire turn as a whole.

Or at the client you could automatically make a call as though the button had been pressed, but are there any restrictions on when this.ajaxcall() can be used, i.e. would there be any problems if I sent a confirm response during onEnteringState?

Yes, it is a problem. I couldn't see how to access the prefs from PHP, and I had this same problem about triggering the ajax too early. I opened a discussion here: https://boardgamearena.com/forum/viewto ... 12&t=17278 and the solution I settled on was override undocumented JavaScript function unlockInterface().

[shadowphiar]

Yes, what I’m doing in the current Steam Works alpha is to have the same set of user preferences. The following code, inside onUpdateActionButtons instead of displaying button, appears to work for allowing immediate progression to the next state. This requires no change in the php.

Code: Select all

if (this.prefs[100].value == 3)
{
     // don't show this stage at all!
     // call after this function has returned.
     window.setTimeout ( function(page) { page.onConfirmEndTurnButton(); }, 0, this );
}

[Victoria_La]

Redarding the end of turn confirmation it really depends of game and other factors.
For example in game like battleship it will be superannoying to ask confirmation for every move as a dialog.
In Hive it would be annoying too but if you make mis-clicking mistake it can cause you a game, so it is done as second click
to confirm.
In russian railroads each turn has is very long and and to confim it uses Done button on action bar (and you Undo/Cancel the who turn before that).
I think guidlines is more about "dialog" idea, because dialogs are annoying not the concept of confirming.
In some games misclicking is very unlikely so it is not needed.
If you do use preference for that it user side preference, it is described in docs not sure if you still need admin help to "load" it.

[paramesis]

I absolutely agree that not every game should have an end-turn confirmation state. A "rule of thumb" makes sense as just that, not the final answer to every situation. I appreciate the intent behind avoiding excessive confirmations and undos. Excessive clicking and other misfits in game flow can have a negative impact on the overall quality of the site in a way that is inherently less likely to result in user complaints.

That said, when developing an adaptation, you come out of the process having implemented so many rules and resolving so many edge cases that you end up knowing the game better than almost everyone. It's hard to then understand the experience of your interface through the eyes of someone who's never played the game before.

I love trying new games here and experience this frequently. I always appreciate it when the interface is designed to be reasonably empathetic toward a user who's not very confident about their understanding of the game and is thinking "is that really what I wanted to do?" and "I didn't realize I wouldn't be allowed to do that if I did this..."

Thank you for implementing a user preference.

[quietmint]

Yes, what I’m doing in the current Steam Works alpha is to have the same set of user preferences. The following code, inside onUpdateActionButtons instead of displaying button, appears to work for allowing immediate progression to the next state. This requires no change in the php.

Code: Select all

if (this.prefs[100].value == 3)
{
     // don't show this stage at all!
     // call after this function has returned.
     window.setTimeout ( function(page) { page.onConfirmEndTurnButton(); }, 0, this );
}

It definitely did not work for me to click a button inside onUpdateActionButtons. Perhaps there's a race condition - it may work sometimes and not others?

[shadowphiar]

It definitely did not work for me to click a button inside onUpdateActionButtons.

With the window.setTimeout bit as well? That ensures the button is called only after completing the handler which notified the client about the change of game state.