Placing items in to randomized locations can succeed or fail based entirely on the approach you take.

For the most part of my time with this problem I had taken the approach of placing items into my location pool and then ensuring that any dependent items had their requirements updated to ensure we don't lock ourselves out of collecting them. for example, I was trying to check for, and avoid, a scenario where a bow is locked by a lamp, which is locked by a hammer, which is then locked by the bow. Here it would be impossible to collect any of those items because they are locked in a cyclical dependency loop.

It was then really trying to find an efficient way to avoid those cyclical loops and coding the back and forth to updating my items' availability requirements. Every time progress was made, a new issue would be found, or a new way of entering that cyclical loop was uncovered. The code grew and grew into an unreadable mess of loops and updates to lists.

It is often the time you take away from your code when the best ideas come to you, or an understanding of a problem reveals itself to you. I had looked at the ALttPR github to try and understand the code there, but my lack of PHP knowledge was a blocker as to what was happening within the placement function. I was also puzzled as to why the placing loop was so much smaller than my attempts, and I wasn't fully understanding their approach to the logic. Until I went in the shower (literally, I took a shower and the thought hit me). They aren't checking for ciclical loops because they've avoided a scenario where a loop can happen.

What they do, and the solution I've implemented and seen work consistently, is that they apply the logic in the same way the player will encounter it in the game: A player at the beginning of the game has access to a limited number of locations which have no access requirements. So we throw all those 'free' locations into a pool, then shuffle that pool and start adding items. When an item is added to a location we check our full list of locations to see if that item has given the player access to any more locations. If it has, we add those new locations to our list of available locations. We then repeat this process until all our locations have become accessible, and we have placed all our items. This approach ensures that no item will be inaccessible if it is required for progression.

At the moment, my location locks are simple, if the player has an item they can open a chest - I haven't actually implemented the mechanics for all of the items. The Chest will simply check if the player has the item and if they have it'll pop open and apply the contents to the player inventory. In ALttPR locations can have multiple locks, I'll need to find a solution to this eventually where we check the item's locks and whether all of them are open. but for now and probably for a potential demo what I have works and simulates the gameplay I'm looking for.

My next goal will be to start implementing inventory item mechanics, which I am excited to start after a few days of randomizer logic headaches.