[chriskw]

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.

[hermannj314]

I peaked at around 21st but stopped playing because it seemed to be a lottery.

I ran simulations with perfect information and found the lower bound for scores. Scenario 2 was mean 3743 rejections with 265 std deviation. This is the curve formed from simulated data and a strategy that had with perfect information, i.e. you could build the best possible strategy after knowing the random assignments.

So winners had scores that I could not even theoretically achieve unless I could see 1000s of scenarios.

So I ran my code locally and was happy that my code was always just a few rejections off of optimal and called that a private success.

[mpeg]

That's what I thought when I saw the challenge originally... maybe a better way of running it would have been to have each run be with a deterministic seed, and apply to all candidates.

That way people can test offline with random sequences, but the leaderboard runs have the same seed for everyone. Maybe I'm missing something obvious, but I think this would have lessened the impact of luck.

[chriskw]

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.

[bogdan-foo]

"Whenever it looked like the networking issue was happening, a script automatically tore down the machine and spun up a new one with a new IP. If this really wasn’t just a me problem I’d be curious to hear what everyone else near the top of the leaderboard was doing to circumvent this."

I remembered that I have a free VPN subscription and put it to good use. When requests started to fail, a script changed my IP to another random country.

As for the solution, I used an approach similar to primal-dual optimization + some manual tweaks that made sure it capitalized when the random gods provided. To make sure I'm close to the optimal, I saved the streams and run an offline solver.

[florianj]

How did you use DP for scenario 2 and 3? The table seems to be way to big unless you do some optimizations.

Also did you optimize for the best case in any way vs expected cases?

[chriskw]

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.

[kuberwastaken]

I KNOW RIGHT, if it were more stable and less luck based, it would've been a lil more fun :)

Also, I do remember seeing you on the leaderboard, cool stuff!!!