Hello,
I was redirected here from the DeSmuMe forums.
I am trying to figure out how the puzzle generator that HAL built for Picross 3D on the NDS works.
Some background:
Picross 3D has an editor that allows you to build an object, and then process that object into a puzzle that you used to be able to share on Nintendo WFC. When you have assembled the puzzle shape, you click complete, and then the game goes into this processing state where it figures out an initial state for the puzzle. This is interesting because it seems to optimize the puzzle towards providing a minimum amount of information as possible on the surface of the puzzle such that the player can then solve the puzzle without having to make guesses during play. Based on the way it works, I would guess that it does some kind of brute force optimization because sometimes it can take a few minutes for the generator to wrap up a 10x10x10 puzzle (which feels like a long time if it was a linear growth generator). However it works pretty well, and I would like to know exactly what the algorithm HAL developed for this puzzle creator was.
I am no real ROM hacker. I was able to load the ROM in Ghidra using the NTRGhidra extension (can't post github link because new), but once I see the decompiled C for the ARM9, the impostor syndrome kicks in and I get overwhelmed, as I have no reverse engineering experience
.
I come seeking advice on what you guys might do to figure out this algorithm, and perhaps some guidance on how to navigate the disassembled rom in ghidra, or another tool if possible. Again I have never tried reverse-engineering something like this before, so if there are some basic techniques that would serve me I would be glad to get some pointers there too, or a journeyman's handbook if possible.
Thanks.
I was redirected here from the DeSmuMe forums.
I am trying to figure out how the puzzle generator that HAL built for Picross 3D on the NDS works.
Some background:
Picross 3D has an editor that allows you to build an object, and then process that object into a puzzle that you used to be able to share on Nintendo WFC. When you have assembled the puzzle shape, you click complete, and then the game goes into this processing state where it figures out an initial state for the puzzle. This is interesting because it seems to optimize the puzzle towards providing a minimum amount of information as possible on the surface of the puzzle such that the player can then solve the puzzle without having to make guesses during play. Based on the way it works, I would guess that it does some kind of brute force optimization because sometimes it can take a few minutes for the generator to wrap up a 10x10x10 puzzle (which feels like a long time if it was a linear growth generator). However it works pretty well, and I would like to know exactly what the algorithm HAL developed for this puzzle creator was.
I am no real ROM hacker. I was able to load the ROM in Ghidra using the NTRGhidra extension (can't post github link because new), but once I see the decompiled C for the ARM9, the impostor syndrome kicks in and I get overwhelmed, as I have no reverse engineering experience
.I come seeking advice on what you guys might do to figure out this algorithm, and perhaps some guidance on how to navigate the disassembled rom in ghidra, or another tool if possible. Again I have never tried reverse-engineering something like this before, so if there are some basic techniques that would serve me I would be glad to get some pointers there too, or a journeyman's handbook if possible.
Thanks.
