Breaking old seeds is probably not too big a deal since the game is currently in early access, and the biweekly patches mean that seeds are already pretty inconsistent. For example, adding new cards/relics/combats to the pool throws off the generation for all cards/relics/combats anyway
Random thing I ran into while trying to seed search for a challenge run, but since the seed is passed through a 32-bit hash function it means there's effectively only 4 billion seeds (as opposed to the first game, which had 64 bit seeds). This is great if you wanna do something like prove/disprove whether there are unwinnable seeds since its trivial to brute force all of them, but it does mean the potential for fun "high roll" seeded runs is much lower, which is a shame since the new game has so much more variance than the original.
The trick for Scenarios 2 and 3 is that most of the constraints don't end up being bottlenecks. For example in Scenario 2, well-connected pretty much always gets satisfied while doing the other constraints, so the DP table only needs 4 dimensions (space, Berlin local, techno lover, creative).
My other trick was to only build the full DP table for the latter half of the game (i.e. when all the constraints are at least 50% satisfied) which across 4 dimensions reduces the size by a factor of 16. For the beginning half of the game I combined Berlin and techno into a single parameter, which technically isn't perfect but doesn’t matter too much in the early game. I wrote up my approach here if you want more details: https://chriskw.xyz/2025/09/16/Berghain/
Re: optimizing for best case vs expected case, I thought about that but in simulations my strategy mostly performed the same as a "perfect knowledge" strategy where you could see all of the people in line ahead of time and retroactively accept people. When it under performed it was usually because some miraculous string of people showed up near the end, but betting on that happening seemed like it would do more harm than good, i.e. it would throw away more best case scenarios than it would salvage.
The tricky thing is the code for making decisions runs locally on the contestants machine, so the first time they submit they can record the sequence locally and compute the best set of actions for the next time they submit. Even if the sequence is somehow tied to a user's account so they can't resubmit against the same sequence, they could do the same thing with an alt account and feed the sequence to a main account.
Sites like Kaggle usually get around this problem by running contestant code in a containerized environment server side, but even then you can get clever with tricks to leak info.
Nice to see another participant's thinking process for the puzzles! I ended up getting 5th place using dynamic programming for all of the scenarios, but I'm under the impression that almost everybody in the top 20 had almost equally good strategies and most of the variance in scores was due to luck with the sequence of people they got.
A quick sanity check is in Scenario 2, you needed 300 creative people each with a ~6.2% chance of showing up. The odds of getting a sequence of people where that's even possible for the first place score (2906 rejections + 1000 accepts = 3906 total people) is on the order of 1 in 10000, and that's without even factoring in the other constraints.
Website: https://chriskw.xyz/
Email: <website.xyz>@gmail.com