The current implementation is very naive, simply just generating games within the requirements and then trying to solve them, within a concurrency-loop.
It works for smaller values, but there are a whole lot better ways to do this.
For instance, it seems very intuitive to create an implementation that works backwards.
For instance, given the number 768, it could create a set of factors for it:
2 2 2 2 2 2 2 2 3 = 768
It could multiple some of the repeating factors together somewhat to mix it up, but it must keep a count of how many there are, since within a challenge, there is a fixed amount of numbers available.
4 8 2 4 3 = 768
However, according to the game rules, we would need to have a cell with half that value in advance, so we would need 384.
So we need these numbers:
2 2 2 2 2 2 2 3 = 384
384 2 = 768
We keep splitting, until we have only numbers below 12, which is the highest number that the game can generate:
To generate the first number, we need 3, 4, and 12.
To generate the second number, we need 3, 4, 12 and 2. We then combine it with our 24 from the previous step.
To generate the third number, we need 3, 4, 12 and 4. We then combine it with our 48 from the previous step.
To generate the fourth number, we need 3, 4, 12 and 8. We then combine it with our 96 from the previous step.
To generate the fifth number, we need 3, 4, 12 , 8 and 2. We then combine it with our 192 from the previous step.
To generate the sixth number, we need 3, 4, 12 , 8 and 4. We then combine it with our 384 from the previous step.
We then count the numbers needed:
3
4
4
4
5
5
= 25
That means that the number 768 requires at a minimum of 25 cells. So a board of 5x5 cannot possibly have a challenge with the standard rules with the target above 768.
If there is not enough cells available, we can fail early here.
The calculation above should be fairly quick. If we dont fail early, we move on and we add som randomness into the board-values. The randomness could be:
Combining factors into a maximum of 12.
Substituting mulitplication for addition. This usually requies a lot more cells, but if there are available cells for it, we should use it.
From this, we should have a set of cell-values that in some combination should create a valid challenge (probably).
I am not sure how to go from here in a smart way, but I guess we could just bruteforce it for starters. We are at least doing a lot less work than originally, so we should be able to generate boards a lot faster. At least we should be able to fail early, instad of spending all that cpu on requirements that are impossible to fulfill.
The current implementation is very naive, simply just generating games within the requirements and then trying to solve them, within a concurrency-loop.
It works for smaller values, but there are a whole lot better ways to do this.
For instance, it seems very intuitive to create an implementation that works backwards.
For instance, given the number 768, it could create a set of factors for it:
2 2 2 2 2 2 2 2 3 = 768
It could multiple some of the repeating factors together somewhat to mix it up, but it must keep a count of how many there are, since within a challenge, there is a fixed amount of numbers available.
4 8 2 4 3 = 768
However, according to the game rules, we would need to have a cell with half that value in advance, so we would need 384.
So we need these numbers:
2 2 2 2 2 2 2 3 = 384 384 2 = 768
We keep splitting, until we have only numbers below 12, which is the highest number that the game can generate:
3 4 12 = 24 24 2 = 48 48 2 = 96 96 2 = 192 192 2 = 384 384 * 2 = 768
To generate the first number, we need 3, 4, and 12. To generate the second number, we need 3, 4, 12 and 2. We then combine it with our 24 from the previous step. To generate the third number, we need 3, 4, 12 and 4. We then combine it with our 48 from the previous step. To generate the fourth number, we need 3, 4, 12 and 8. We then combine it with our 96 from the previous step.
To generate the fifth number, we need 3, 4, 12 , 8 and 2. We then combine it with our 192 from the previous step. To generate the sixth number, we need 3, 4, 12 , 8 and 4. We then combine it with our 384 from the previous step.
We then count the numbers needed:
= 25
That means that the number 768 requires at a minimum of 25 cells. So a board of 5x5 cannot possibly have a challenge with the standard rules with the target above 768.
If there is not enough cells available, we can fail early here.
The calculation above should be fairly quick. If we dont fail early, we move on and we add som randomness into the board-values. The randomness could be:
From this, we should have a set of cell-values that in some combination should create a valid challenge (probably).
I am not sure how to go from here in a smart way, but I guess we could just bruteforce it for starters. We are at least doing a lot less work than originally, so we should be able to generate boards a lot faster. At least we should be able to fail early, instad of spending all that cpu on requirements that are impossible to fulfill.