why don't they have "take back move" option?

[Squachmo7]

[Oso]

Because isn't easy to program it..

So, also isn't a fault of BGA, it's just about faster players who make wrong movements -like me, sometimes-

Get an undo option also not always could be considerated if an action reveal a card or roll a dice, etc...

[fistOfKross]

Yucata, Boitesjeux, terra.snellman.net, boardgamecore, etc has it. Beeing a programmer myself i can sympatise with the implementors - but soon enough people will take this for granted and then maybe consider alternatives. Like i much rather play "Polis" on Yucata than here just because of this. And really, its not hard.

[veme]

I wouldn't hold my breath on this one, folks. Here is an incomplete list of bug reports and forum topics where an undo/confirm function is one of the primary topics of discussion:

http://en.boardgamearena.com/#!bug?id=3082
http://en.boardgamearena.com/#!bug?id=2264
http://en.boardgamearena.com/#!bug?id=1636
http://en.boardgamearena.com/#!bug?id=100

http://forum.boardgamearena.com/viewtop ... f=9&t=9777
http://forum.boardgamearena.com/viewtop ... f=9&t=3479
http://forum.boardgamearena.com/viewtop ... =9&t=10032
http://forum.boardgamearena.com/viewtop ... f=3&t=9730
http://forum.boardgamearena.com/viewtop ... f=9&t=9615
http://forum.boardgamearena.com/viewtop ... f=9&t=9602
http://forum.boardgamearena.com/viewtop ... f=9&t=9516
http://forum.boardgamearena.com/viewtop ... f=3&t=5395
http://forum.boardgamearena.com/viewtop ... f=9&t=5238
http://forum.boardgamearena.com/viewtop ... f=9&t=5124
http://forum.boardgamearena.com/viewtop ... f=3&t=3912
http://forum.boardgamearena.com/viewtop ... f=9&t=4941
http://forum.boardgamearena.com/viewtop ... f=9&t=4984
http://forum.boardgamearena.com/viewtop ... f=9&t=4743
http://forum.boardgamearena.com/viewtop ... f=9&t=4824
http://forum.boardgamearena.com/viewtop ... f=9&t=4574
http://forum.boardgamearena.com/viewtop ... f=9&t=4485
http://forum.boardgamearena.com/viewtop ... f=9&t=1177
http://forum.boardgamearena.com/viewtop ... f=9&t=4244

In only one of those threads does an admin actually respond (that I saw anyway, someone please point it out to me if I have missed anything), and all that is said is basically, "We are working on it." Although since it has been 1.5 years since then, during which time the admins have developed many new complex games/features/redesigns, I think it is safe to say that they are not working very hard on it, despite the clear desire much of the user base has for such a function.

----------

There are only two semi-plausible arguments that I have ever seen for why a confirm button would actually be a bad idea:

1. It let's a player preview the effect of a move. I'm not sure how much of an advantage this confers since your opponents could also see the effect of the move and plan for it (and have the same ability on their own turns). And since it would not be available for moves where hidden information is revealed, and does not allow you to simulate game positions past the current/active turn - I question how much of an advantage it would give a player even if your opponent could not see what you were trying.

2. It adds time/mouseclicks to the game. Indeed, a player would have to make one more click at the end of their turn. For anyone who has awkwardly cycled moves in Hive to return to a non-misclicked state, or anyone who has had a single misclick ruin a week-long turn-based game, this argument must seem ridiculous. Obviously in many cases, NOT having the functionality wastes much more time. And even if this were a problem, there are better ways to address it:

a. Turn time limits. As long as a player's timer continues to run until they confirm their move, then simply setting the game timer to a tolerable length prevents players from taking too long on their turns. Shorter timer options can always be added.

b. Opt out. If some people don't want to have to make extra clicks, there could be an option added for players to opt out of move confirmation.

----------

In addition, not having a confirm move button disenfranchises the following groups:

1. People such as the one who started this thread - http://forum.boardgamearena.com/viewtop ... =9&t=10128 - who have to deal with a physical disability which makes them more likely to misclick.

2. People who game on devices with touch screens or small screens, which are much more prone to misclicks.

3. People who have made an honest mistake - either by, say, dropping their mouse, or simply due to the online interface. For example, someone who wants to place an irrigation ditch in Takenoko accidentally clicking the 'take irrigation ditch' action instead of clicking on an irrigation ditch in their inventory - a silly mistake I have made many times which is solely due to having to use an electronic interface, and which could never happen at a table.

----------

So 'confirm move' functionality should be added to ALL games which will confirm/undo the previous actions on the active player's turn that did not reveal hidden information (either one action at a time, or all at once, depending on the complexity of a turn in the particular game). It should remain the active player's turn until they confirm that they are done, and all opponents should be able to see everything the active player does during this time. We all know this is possible as it is the case on many (every?) other board game sites, and is implemented very well in some games on BGA already (Tash-Kalar comes immediately to mind).

The failure of the admins to address this issue, or even to offer a good a explanation why it will not be addressed (at least I have been unable to find one in my forum searches), is the primary reason I refuse to pay for a membership here. The only explanations I can think of for adding more and more bells and whistles while neglecting huge UI problems with existing implementations are laziness (it is easier or more fun to work on new games/features than to debug/improve existing ones), greed (we will sell more memberships by adding games than by fixing interface issues), willful ignorance (purposely avoiding threads about this topic), or the belief that it is simply not a problem. And if they believe it is not a problem, then I feel they owe us a decent, comprehensive explanation - completely ignoring the many forum posts and bug reports, including the current #2 most upvoted bug, is just plain rude.

[sourisdudesert]

Hi,

You don't have to be rude and we do answer. This is just that when you are asking hundred of times the same question this is painful.

Complete answer :

• This is really difficult to implement. And this has nothing to do with being a good, a bad, a slow or a fast developer. This is difficult to explain to non-developers, but basically on BGA we let programmers do whatever visual effects they want when a move is played. In consequence, the is no generic solution to revert these move on the interface. Some games build a game-specific system to do it (ex: Tash Kalar, Dungeon Twister) which cannot be extended to others games without a lot of pain. A game (TTA) finds a solution that requires a browser refresh, which is acceptable in turn-based mode, but not in real-time (imagine your browser has to refresh for every opponent's undo). This is also why turn-based websites manages this easily.
• We don't consider this as a priority. Yes a lot of players are complaining about this, but is there really a majority of players that would accept to wait that some opponents take back their move 2 or 3 times before deciding? So sometimes we are considering specific situation, and especially game-specific situation, but I'm not sure this option will be used by the majority of players here once proposed in the future.
• The final solution to this is an update of BGA Framework with a complete different approach, and many other improvements. Let's call it "BGA 2.0". And yes, we are working on it, for a long time, but this is a long-terme challenge so "yes" we give priority to new games / new features / new stuff.

To conclude : we are only 2 developers working on BGA, and only 1 fulltime, so we have to make priorities. Please keep in mind that every player do not have the same priorities than you, and this is not easy for us to satisfy everyone.

[fistOfKross]

Ok beeing a developer myself i wonder what would wrong with the following approach?

1. Model the game into some immutable structure "GameState"

GameState {
index:Number,lastCommand:Command,..
}
Command {
isUndoable,...
}

define function with signature

f(Command,GameState) : GameState // The-state-from-a-given command.

gameStateN = f(commandN,f(commandN-1,f(gommandN-2(...(...f(possibleSeedCommand,initialState)...)..))))

Then either
1. save last non undoable (Random Effects, Turn Commit etc) GameState and all undoable commands after that or...
2. Save all commands and just replay the game from InitialState to generate state of last command.

Now, supply "undo last" as
alt 1: apply undoableCommands.tail in order on lastNonUndoableGameState => undoed gamestate
alt 2. apply allCommands.tail in order on InitialState => undoed gamestate

..and "all undoable" in similar fashion.

2. For view:
* Implement animations for one command transitions forward transitionForward(commandLast,gameStateOld,gameStateFromCommandLast). // gameStateFromCommandLast from server

* If you transition to arbitrary state - implement resetView(GameState).

What would be bad with this approach or in what way do i oversimplify things?

[Oso]

What happen if:

- I'm playing in real-time with an opponent
- My opponent moves, so the game calls me for my turn
- I see my turn but after 3 sec my opponent press "undo"...

So, it isn't nice neither .

[apollo1001]

in what way do i oversimplify things?

Disregarding the question as to whether players should be allowed to undo moves (e.g. Oso's post above), as sourisdudesert has already mentioned, an approach such as yours is not a massive undertaking for turn-based games where you can simply roll back the game state to the previous turn and load it upon a browser refresh.

The problems come with real-time games where the assumption is that you do not want to be losing time for browser refreshing or replaying moves. Imagine a real-time game with a 2 minute clock, where your opponent tries out a move (to which you are about to respond), clicks undo, and your browser is forced to refresh. Even more alarming would be the case where the game has to replay through from the beginning (taking 2 minutes in itself) to get to the correct state!

Back to the problem however: given we do not want a browser refresh, upon the code being informed of an 'undo' it will need to reassign all the tokens/pieces etc. to their correct locations. This might require some previous cards being re-created, some tokens removed, others being animated to their old locations, different parts of the screen to be highlighted, a different selection of pieces given cursor pointers etc. Each game will have a different and unique set of animations and game objects which will need to be coded in order to restore smoothly to a previous game state. In short, every game would need to have its own customised undo routine written for it.

Given the volume of games, the potential complexity of each, and the minefield behind whether being able to undo should be allowed in any case, this is unlikely to be implemented (other than for occasional specific new games) until a more generic solution can be applied to all games at once.

[veme]

I think there is some confusion about how this function would work given Oso's and apollo's responses.

If you were playing in a real-time game, and your opponent moved a piece, it would not then be your turn. Your opponent would have to click 'confirm' before your turn/timer would start - at which point your opponent would no longer be able to change their move. Turns would not be switching back and forth every time you undid a move, you would just have to do your turn over again if you undid a move (your turn timer would be ticking the whole time - see Tash Kalar).

So again, if the problem is "I don't want to wait for my opponent to make/undo his turn X number of times" the solution is not "no confirm button" it is "shorter timer". People can already use the whole timer if they want - set the turn timer to a time you can stand and it doesn't matter how long the other guy twiddles his pieces, you will always have the same amount of time to think.


sourisdudesert:

I was not trying to be rude, just brutally honest. I was active on BGA for over a year, during which time I tried to make bug reports and simple 'me too' comments on forum posts to initiate change. None of the bugs I posted were responded to; none of the things I cared about changed. So now I have started making some more thought out and scathing forum posts in an attempt to poke the user base and perhaps admins into action. Recently I got a Tokaido bug fixed (after some convincing), and I see you have added a confirm function to Hive after this post (Thank you very much! I'll probably buy a membership next time I get paid). I wouldn't bother writing this much or agitating for change if I didn't love and care about this site. I do appreciate all the work you do, and all the things that are right with the site (the vast majority of them), but it doesn't help to make the site better if I pat you guys on the back for your accomplishments, as nice as that would make everyone feel. I believe that criticism begets change, so that is what I post.

I have done my share of programming and I do understand that universal confirm is not a change that can be made overnight. My point was that it is not very high on your list of priorities, which you freely admit. I am quite confident that 'confirm' could have been implemented for many games instead of the addition of some of the other games/features that you have put out in the last year and a half. It is your site, so do what you want, it is just my opinion that UI and game rules bugs are more important issues than adding more stuff.

It is also very cool to know that you are working on a major update to the framework (especially if it will allow reversible replays ). Even if it is a long-term project it is very encouraging to know it is in the pipeline somewhere. Thanks for the informative reply, and all of your work on the site.

[Realdeo]

The problem with "Confirm" button is it won't help. My experience in UX shows that when the confirm button appears too many times...people will just press the button without thinking. Imagine playing Can't Stop having to press confirm button every single time.

The confirm button can be analogized as installing software. When you check "I agree with the term. Continue the installation." Did you actually read the terms? Most of the times, you don't.

I would like to wager for 2:1 that Confirm button won't solve the problem. People just need to start thinking carefully. In chess, there is a rule called Touch Rule. The moment you touch your pawn, you must play it.