Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

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?

Thanks for the input, I use a greedy algorithm so the 1st match is the one that runs, but I have it ordered so that more specific Acts are checked 1st, if certain behaviours are always running where other Acts don't even get evaluated, then adding in more conditions can solve it. There is a bit of a learning curve, but overall it's a very simple system to use.