Feature request: Make piece generator always generate fitting pieces

[chocochino]

First of all, thank you for creating an open source version of 1010!. My undergraduate final project is implementing a validator to avoid unfit pieces being generated, and your project had helped fasten the coding stage. The validator was tested on various device, and so far the longest time recorded was 75ms, so hopefully attaching the algorithm won't slow down the piece generation process.

If possible, would it be okay if I patch the game with an option to always generate fitting pieces and create a pull request as a part of the next Hacktoberfest? By checking this option, the only possible way to lose a game is by misplacing any blocks.

[Lonami]

I'm glad this project was so helpful for your own :)

If your code is clean enough and you are able to add a proper setting for "infinite mode" (we would need to somehow explain to the users what this does, along the lines of "the game will never generate pieces that result in the end of the game"), it would be interesting to have!

Surely some people would prefer playing at their leisure without the fear of a silly RNG screwing up their perfect plain. On the other hand, it's somewhat cheaty, since you can effectively "never lose", and it's a bit less fun, and that's the only thing that worries me. Maybe we can add an infinite mark when sharing the score to let other people know they were using this mode. Also, if you can think of a better name, go ahead.

[chocochino]

Thank you! Infinite mode sounds like a good name, with explanation underneath. To avoid any complaints, maybe it could be an unchecked option by default (?)

For my final project, I created a helper class State where I put all the validation steps, and finally call a method named validatePieces() in takeMore(). The checker works like your initial thoughts in issue #28, so if anyone wants to work on pruning techniques, I'm open for suggestion. Also right now, it only changes the piece that causes most fails, but my lecturer suggested using dynamic difficulty adjustment to choose which piece should be changed in an unfit set (computationally more expensive, but probably more enjoyable).

I will explore the source code this month to add the proper setting before PR-ing next month.

[Lonami]

Yes, unchecked by default if it gets implemented is a must. #28 indeed mentions something similar to this, which you seem to have implemented. For dynamic difficulty, maybe a slider would suit better than toggling some infinite mode, but it's been a while since I used libGDX and I would need a while to figure out how to add such thing myself too :)

Thanks for the interest and effort.