First of all, I don’t know if I’m posting this in the correct thread. I’m working in a C++ based project, so I supposed this one is the correct one. But move it if you consider it necessary.
Anyway, the thing is I’m creating a puzzle game. The numbers that compose the puzzle are randomly chosen every time the level is loaded. However, I need to know if the puzzle will have a solution with those numbers. And I need to know this BEFORE the level is loaded. The function I implemented to test this is recursive, and it must execute for each number until it finds a solution or a dead end. And of course, if it finds a solution, the testing stops (I don’t need to know if there are other solutions). In case there is no solution, I have to generate a new array of random numbers, and test them again.
The problem I’m having is that if I test this when the BeginPlay event triggers, everything (game and env.) crushes.
So… what I did is to create a blueprint based on my C++ class blueprint. And I did this testing in the construction script… but it crushed everything again. If I do the test just once (testing just one number), it works fine…
The question is: How should I solve this? I need to pre-calculate this array of random numbers. I’ve been thinking about creating a loading level or something, to calculate these numbers, and then load the level with the puzzle… but I don’t know if the loading level will crush too. Maybe I should use multi-threading… I don’t know. Any ideas?
You might be better off writing a separate app that generates a large list of known good number sets, save to a file, load the file at runtime and randomly selects a set of numbers from the list.
Yeah, that’s my plan B… but I if it’s possible to do it in-game, it would be better, because the puzzle would always be random (and new). Thanks for your suggestion though
I think what happens is you’re flooding the game thread with the recursive calls each time you fail to find a solution to the puzzle, or if the solution is too intricate. A recursive function is neat in some cases, but not this case. It’s going to allocate memory on the stack each time a recursion occurs, and de-allocate once the function reaches its end. When the recursion gets “deeper and deeper”, without any end, you get stack overflow.
Using recursion in this case is a bad idea if you ask me.
If you cannot guarantee the recursive function’s end, you shouldn’t use it.
Try treating the problem more carefully. Use an iterative solution, set a max number of iterations before “giving up”.
Good luck!
Is the puzzle the entire game or one small element of a larger game? The idea of it being randomly generated every time may be novel, but if you have to run a deeply recursive function that might fail, repeteadly, to get a solution and the user has to wait until there is a solution, you are creating a bad user experience.
You could make a list of thousands of good number sets and from a users perspective it will be random and different every time. They’d have to play the puzzle several times over the total number of number sets before they might realize they aren’t completely random.
Start calculating when the game is showing splash screen etc… I am sure the games doesn’t start right after splash screen vanished. At the very least, user still need to press ‘Start The Game’ or so… So now you have ample time to calculate something. And of course, all calculation is done at separate thread.
But I know when the recusion ends. I have a base case. However, in the worst case, it could go deeper and deeper, as you say… Yes, an iterative solution was going to be my next option. It’s a pity to implement a backtracking algorithm like that, but at least I have to try it.
]
Start calculating when the game is showing splash screen etc… I am sure the games doesn’t start right after splash screen vanished. At the very least, user still need to press ‘Start The Game’ or so… So now you have ample time to calculate something. And of course, all calculation is done at separate thread.
[/QUOTE]
Yes, that was why I thought about using like a loading screen to calculate the numbers. But how would this impact in the gameplay if the calculation delays in time too much? I’m not too convinced…
Yes, the puzzle is the key in this game. That’s why generating random puzzles was important to me. Creating a battery of possible convinations is my plan B… and my last option.
