GNOME Bugzilla – Bug 710139
Better handling of invalid moves
Last modified: 2018-05-22 12:28:28 UTC
The current invalid moves UI is unfriendly, moves the content of the window around, and gives feedback in a way that isn't really appropriate for a game. Instead of using an info bar, I would suggest: * Changing the colour of valid cells on pointer hover (to show that they are sensitive). * Showing a friendly message as a semi-transparent label over the board - "You can't go there!" - if someone tries to select an invalid cell.
Maybe we could use the color change for both cases? On a tablet we don't have a pointer to hover with but we could highlight all valid cells during a click on an invalid one. We could also choose to always highlight the valid cells? I guess that a part of the gameplay is to discover the valid cells to click on. Highlighting them will remove that aspect of the game but I think the tradeoff is worth it.
(In reply to comment #1) > Maybe we could use the color change for both cases? On a tablet we don't have a > pointer to hover with but we could highlight all valid cells during a click on > an invalid one. That would work. > We could also choose to always highlight the valid cells? > > I guess that a part of the gameplay is to discover the valid cells to click on. > Highlighting them will remove that aspect of the game but I think the tradeoff > is worth it. I'm not so sure. It could make it feel a bit too much like multiple choice.
The current handling of invalid moves is not friendly. I think valid blocks should be highlighted, i play similar game reversi in mobile , it shows the valid blocks where i can put the coin.That makes it more interesting.
(In reply to comment #3) > The current handling of invalid moves is not friendly. Yup. > I think valid blocks > should be highlighted, i play similar game reversi in mobile , it shows the > valid blocks where i can put the coin.That makes it more interesting. I'm fine with highlighting a cell on hover, but not highlighting them all always. As per comment #2: "It could make it feel a bit too much like multiple choice."
> * Changing the colour of valid cells on pointer hover (to show that they are > sensitive). Hey Allan, Amisha is working on this. If you have time, could you work on a quick mockup to show what this should look like?
I would like to work on this bug. I've already managed to get the cell that's hovered by the mouse. Not sure how should I indicate a good or bad move. Pining Allan Day
An idea came to me just as I pressed submit. Maybe we can display a transparent piece with a highlighted background where a move is possible. Thoughts?
(In reply to Iulian Radu from comment #7) > An idea came to me just as I pressed submit. Maybe we can display a > transparent piece with a highlighted background where a move is possible. > Thoughts? I would just change the color of that cell, as suggested in the first comment. :)
Created attachment 296971 [details] [review] Highlight the hovered cell if the move is valid I used the color of the board's lines as a highlight (with 0.4 alpha - it looks better in my opinion). A problem I'm having is that you can see cell highlighted even if waiting for the opponent to move and I'm not sure we want that. I tried with 'game.current_player_can_move' but it seems to always be 'true' in the 'motion_notify_event' method.
Created attachment 297048 [details] [review] Adds small animation when highlighting square
Created attachment 297049 [details] [review] HIghlight the hovered cell if the move is valid Fixed small coding style problem
Created attachment 297070 [details] Screencast of attached patch Good job. I think something along these lines will work, yeah. Can you work more with Allan and Arnaud to figure out how the visual effect should work please? (Shaded black is probably not the way to go.) The box is a bit too big on the right and bottom sides, too.
About this implementation: * as noticed by Michael, the highlights are too large and not centered; * you can highlight the cells the opponent could play during its turn; * I like the animation. =) Concerning the design, I’m not really fan of this solution, but that’s good I can test it. The main problem is that I don’t like to be disturbed when playing (I’m a casual reversi player with a good level), and having the background changing is definitively disturbing. By the way, who says “hover” means it’s not the same game when playing on a touchscreen… and, I don’t know how this would work with a “highlighted cursor” on one cell when playing with keyboard (no, there’s no bug open right now for that, but it’s a thing I have in mind). I probably would prefer a solution where valid cells are highlighted (temporarily?) when you click on an invalid one. That would offer a quite good reversi experience for all players, advanced like casual ones. And if really we need to help beginners, I’m not opposed to an option to highlight them all the time, but that shouldn’t be activated by default. Maybe a togglebutton in the UI, so that it could be switched on the fly for one turn?
Created attachment 297459 [details] [review] Improvements I could see the bigger box only in the HighContrast theme and that's why I missed it (my bad cause I didn't check that theme :(). * Fixed the highlight box being too big * Cells should only be highlighted when it's the player's turn (always in two players mode) - Thanks Robert for help * Added property for the highlight's color (not sure what color I should choose for the HighContrast theme - I went with (0.7, 0.7, 0.7) with 1.0 alpha; gray) Waiting for feedback (both code review and design thoughts)
I just pushed support for playing keyboard, and it was originally based on your patch, thanks for this work. I didn’t use something like “animation_cut” as the tiles’ size could change between two redraws (so it’s better to not save a value based on it). Colors are the same IIRC. I continued to play sometimes with the “hover” thing, and I’m really not happy with that solution, we’ll need to design something better. The patch should be always testable with branch gnome-3-16.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/iagno/issues/5.