To answer your question, I code the control logic of my games in C. I choose the data structure that best fit the situation and in most cases I use arrays for fast access.

The barks-to-general-reactive-layer leap is a good one 🎮 — barks are the one place where “conditions → pick an act” is already forced to be data, because designers have to author hundreds of them and nobody is writing that as if/else.

For what it’s worth, the AI in my own game (a browser bomber arena, bots fighting continuously) ended up as a scored candidate list rather than a state machine or a behaviour tree: each tick, generate the legal moves, hard-gate the ones that are suicide, score what is left, take the best. Conditions are data in much the same way yours are.

The thing that bit me, and I think it bites any condition-driven system, is that a condition is rarely read by only one act. I have a “can I survive this?” predicate. Some maps have teleport pads, and a body in transit cannot be touched by anything for four seconds, so it looked obviously correct to let “I can reach a pad” satisfy that predicate. Pure upside. One word to change.

Self-kills went UP nine points. Because that predicate is not only the escape check — it is also what licenses placing the bomb in the first place. Making it easier to satisfy quietly approved exactly the bombs whose escape was the longest walk on the board.

Two things I would hand anyone building this kind of layer:

• Ordering is not a tiebreak. “Walk to a haven” and “dive into a pad” both satisfy survive, but a pad costs four seconds of the round and hands the exit to a draw, so it is asked second, always. In a flat rule list that ordering is invisible, and what you get is a bot that gambles when it did not have to.
• When a number is load-bearing, put it in the code with a test asserting it, because the tempting edit is one word long.

Curious where Fuzzy Brain puts precedence when two Acts have all their Conditions met at once — is it list order in the ActList, or is there a score underneath?