aclap-dev / jocly

Javascript library and tools to provide user interface (2D, 3D, VR) and engine for playing board games
https://jocly.com/
Other
71 stars 28 forks source link

Winning move in Mana. #19

Closed raman22feb1988 closed 6 years ago

raman22feb1988 commented 7 years ago

mana1 In Mana, in the winning move whenever a player can be able to capture the opponent's Damyo, all squares get highlighted (except the squares upon which opponent's pieces that reside), not just the squares upon which our pieces exist that are only allowed to move during the turn (only our pieces that reside upon 1, 2 or 3 squares corresponding to wherever our opponent had left their Mana during their last turn; or if none of our pieces exist upon that corresponding squares, then all the squares that correspond to all of our pieces wherever that they reside upon).

While this issue does not happen all the time, I am not sure under whatever conditions that whenever this issue occurs. The following are my guesses, they may not all be correct, at all. Sometimes this issue occurs 50% of the time under each of this circumstances and 50% of the time not.

(1) This issue occurs during winning move as Black, not as White. (2) This issue occurs during winning move as White, not as Black. (3) This issue occurs during winning move whenever there is some piece of us that resides in the 1, 2, 3 squares corresponding to wherever our opponent had left their Mana during their last turn. (4) This issue occurs during winning move whenever there is no piece of us that resides in the 1, 2, 3 squares corresponding to wherever our opponent had left their Mana during their last turn.

I will try out to update with more information about it as I get more details by playing more games of it against human players or computer players.

raman22feb1988 commented 7 years ago

I am stopping with this submission right now, I would like to hear within your views into upon whether you are happy with my new submissions or not, before going on ahead with further more submissions. I believe that #18 and #19 issues are related to the Jocly lib, not the app. Right? Please feel free enough to correct me up if I am wrong enough.

I do not want to burden you or trouble you further more if in any case that you are not happy with my submissions, then. I do not have any problems in working hard at all, it is all just lying simply upon into your own happiness, sake and purpose then.

mi-g commented 7 years ago

I am happy with your issue submissions. Thanks for that. Please, do not expect me to jump right away into investigating and fixing those issues as i do not have the required time for now. But the issues you created on github should be seen in the long term: at some point, me or someone else, may you, will fix them. Yes, both #18 and #19 are core related and belong to this repository.

raman22feb1988 commented 7 years ago

Please take with your own (period of) time. :smile: And then no rush needed at all, if then required. :mag: I said that I just wanted to refrain from burdening you or troubling you further more simply if in any case that the issues that I had reported are not appropriate over here by only at all, just simply. :+1:

By using the way, I recently observed that ecobabush and tilera were working very much hard enough towards of fixing up some of the older enough issues, I had received some notification messages through e-mail from them, so I thought that I would assign them some of the work issues, which ever are Jocly lib related and not app related, that are ever appropriate over here by.

And also I thought that type of thing of stopping with this submission right now, hearing within your views into upon whether you are happy with my new submissions or not, before going on ahead with further more submissions.

By using the way, I thought that it would be good enough in order to have with some buffer issues for you, me or some one else to work with during their own spare period of time, whether minor or major whatever, whether important or unimportant whatever.

raman22feb1988 commented 6 years ago

I believe that there is no bug here. So, I am closing this issue. In the above picture, all squares are highlighted (in which no White piece exists) because there is no Black piece at a '1' square where the Mana was placed by White, and so Black is able to drop a piece at an empty square since there is at least one piece of Black which has been captured. Obviously that this situation does not necessarily occur at a winning move but always whenever a piece can be dropped (whenever there is no corresponding piece of a player at a '1', '2' or '3' square wherever the 'Mana' was placed by the opponent and at least one piece of the player has been captured).

raman22feb1988 commented 6 years ago

In my game of Mana against Erik Lerouge, https://jocly.com/jocly/plazza/index.html#/live/7f1934a5668e19f32b4a92b08b97ce57, I had lost a winning position to test with this issue. :disappointed:

My intention was to play 6...m18>30 and there is no way to stop that piece from capturing the opponent's Damyo next turn with 7...m30>31. Instead, all squares were highlighted (in which no opponent's piece exists) and so I thought that it was a bug since I had encountered with that issue before itself (although on a winning move only) and I decided to test that to see what will happen if I clicked on an empty square. An already captured piece was dropped on the square which I had clicked on. My intention was not to play with that move.

Is it not possible to take back that move? :cry: In the next version of Jocly, I suggest that you at least have a confirm move option which can be turned on or off by anyone from the user profile page, so that unexpected behaviour like this, penguins standing up in Penguin Soccer when my intention was to see what squares they can move to, the cases whenever there is only one move allowed in Scrum because there is only one free square for the ball, other possible misclicks or finger mistakes especially from a small screen like mobile device, etc. can be easily avoided.

Anyway that helped me to reveal whether it was actually a bug or not. At least it is possible to take back whenever one move has been played out of two moves as in Scrum, Yohoho! or Penguin Soccer by clicking on My Tables or clicking on the moved piece again.

I will not make the same mistake again. I am familiar with Jocly web site right now.

This issue is only specific to Mana and not to other games available in the Jocly website. I wish that I had investigated with this issue before itself, like whenever I had first encountered it or later on, and avoided this disappointing loss in Mana against Erik Lerouge from a winning position. This loss is disappointing to me because the 'dropping of a piece' move was played in a single click move (no need for clicking an already captured piece of mine outside of the Mana board to drop it at an empty square inside of the Mana board and that piece of mine was captured by my opponent at some point of time during the previously played moves) and this was the first time I had encountered this issue not necessarily in a winning move.

That too, by fate that I had clicked on a '3' square in that game of Mana against Erik Lerouge to drop a piece during testing purposes, not a '1' square and '2' square. Coincidentally that '3' square was a place where a piece of my opponent directly existed at a '3' square to capture by Damyo during my opponent's next turn.

Never mind that I will get him back and the shoe will be on the other leg. In other chess websites, taking back of moves is allowed in unrated games with the permission of the opponent. However, in Jocly website, all played games are automatically rated.

Playing for fun or revealing of bug issues (error fixes).