Created attachment 164334 [details] Guessing four times magenta, which is absent, the feedback should never contain two pegs. SUMMARY At the level 8 of Mastermind (aka superbrain), two code pegs can be of a same color. If the child only uses that color once and correctly guesses one of the two positions, two key pegs in the feedback relate to the single time the color is used: one black (what is correct) and another one white, which should not be there, as far as I understand. STEPS TO REPRODUCE 1. Launch the Mastermind (aka superbrain) activity and click the left arrow to reach level 8. 2. Guessing one single color for all five positions, find one that is absent (empty feedback) and another one that is present twice (two black pegs in the feedback). 3. Guess one single time the color present twice and the absent color for the other four positions. OBSERVED RESULT The feedback is one black peg and one white peg if (only) one of the positions of the duplicated color is correctly guessed (otherwise the feedback is correct, one single white peg, and another position can be tried to demonstrate the bug). EXPECTED RESULT One black peg and no white peg. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Trisquel 11 (based on Ubuntu 22.04) ADDITIONAL INFORMATION Running bin/gcompris-qt.sh installed from https://download.kde.org/stable/gcompris/qt/linux/gcompris-qt-3.3-Linux64.sh
Thank you for the report! I would go with the opposite fix (but let's discuss it if you think it should work as you propose). To be sure I understand well the issue, let's assume: G = Green, B = Blue, Y = Yellow and the solution of the next examples is GBG. Actual: > the user inputs GYY, there will be 1 black peg and 1 white pegs (as the last correct one is G and it's already placed at the beginning). For me, this behaviour is correct (as we expect the G to be at 2 positions). > the user inputs YGY, there will be only 1 misplaced token. For me, here we should display two white pegs (else the child does not know it should be placed twice). If we go the opposite way and only place one black peg if one of the two positions is found, the children won't have a clue they should reuse the same one (as they could expect to have been warn with a white peg).
> To be sure I understand well the issue, let's assume: G = Green, B = Blue, Y > = Yellow and the solution of the next examples is GBG. > > Actual: > > the user inputs GYY, there will be 1 black peg and 1 white pegs (as the last correct one is G and it's already placed at the beginning). > > For me, this behaviour is correct (as we expect the G to be at 2 positions). Well, EXAMPLE #2 on page 3 of https://www.pressmantoy.com/wp-content/uploads/2018/01/Mastermind_rules.pdf shows a similar example and says there should be only one black peg (actually red in that edition of the game). I believe it is the rule for all the board games named "Mastermind". GCompris uses that name. I would be in favor in changing the rule in GCompris (and the name of the activity) if that feedback was illogical... but it looks logical to me. Applying your proposal to level 8 would actually make the feedback incoherent with that of level 4. At that level too, two code pegs can be of a same color. If the child only uses that color once and correctly guesses one of the two positions, then, after pressing "OK", the background at that position becomes black (not half black and half white) and, accordingly, there is one single black peg at the right (not one black peg and one white peg, as in level 8). > > the user inputs YGY, there will be only 1 misplaced token. > > For me, here we should display two white pegs (else the child does not know > it should be placed twice). In the board games, a two-peg feedback means two of the code pegs that have just been played are in the solution. If both key pegs are white, then each of those two code pegs is at an incorrect position. So, getting two white pegs after playing YGY would indicate that Y must be in the middle and that G is either first or last (but not both: there is a third color). With your proposal, GY* and *YG remain possibilities and G*G becomes an additional possibility. I tend to believe (but I have not done the math, using information theory) that, in general, your proposed way to give a feedback gives less information. That the game actually becomes harder.
You're right, then let's implement it the correct way :)
(In reply to Jazeix Johnny from comment #3) > You're right, then let's implement it the correct way :) I do not really want to look at the existing code (you certainly know how long it usually takes to enter a code you have not written). Anyway, if a feedback at level 1-4 is stored in a std::vector<Key_peg> (where Key_peg is an enum, with three values, for black, white and nothing) of size the number of pegs in the code (3 at level 1, 4 at level 2, etc.), then the same could be done for the harder levels. A mere function could take such a feedback and return a std::pair<unsigned int, unsigned int>: how many black pegs and how many white pegs. It would simply iterate over the vector and, at each iteration, increment the proper counter or none (for the nothing Key_peg). If a feedback at level 1-4 is *not* stored in a std::vector<Key_peg>, well, maybe doing so would be "the correct way". :-)
(In reply to lcerf from comment #4) > (In reply to Jazeix Johnny from comment #3) > > You're right, then let's implement it the correct way :) > > I do not really want to look at the existing code (you certainly know how > long it usually takes to enter a code you have not written). Anyway, if a > feedback at level 1-4 is stored in a std::vector<Key_peg> (where Key_peg is > an enum, with three values, for black, white and nothing) of size the number > of pegs in the code (3 at level 1, 4 at level 2, etc.), then the same could > be done for the harder levels. A mere function could take such a feedback > and return a std::pair<unsigned int, unsigned int>: how many black pegs and > how many white pegs. It would simply iterate over the vector and, at each > iteration, increment the proper counter or none (for the nothing Key_peg). > If a feedback at level 1-4 is *not* stored in a std::vector<Key_peg>, well, > maybe doing so would be "the correct way". :-) No worry, we'll take a look :). We plan to fix it for the next version we should do in February. The function to fix is probably https://invent.kde.org/education/gcompris/-/blob/master/src/activities/superbrain/superbrain.js#L143
(In reply to Jazeix Johnny from comment #5) > The function to fix is probably > https://invent.kde.org/education/gcompris/-/blob/master/src/activities/ > superbrain/superbrain.js#L143 JavaScript... now, I really do not want to look at the code. Lol. Thank you in advance for your fix and for the next version. :-)
Fixed. Merge Request: https://invent.kde.org/education/gcompris/-/merge_requests/167