enemy perception systems always end up a tangled mess — how are you structuring yours?

The pattern that finally untangled my perception system: make the data flow strictly unidirectional. Stimuli get emitted into the environment (sound events, visual alerts, footstep markers, whatever makes sense for your game) and the perception layer subscribes and accumulates. No enemy ever actively queries whether it can see or hear the player. The environment pushes relevant data inward.

This inverts the coupling in a useful way. Your AI just consumes a perception feed instead of doing its own spatial lookups. Adding a new stimulus type is just adding a new emitter, not auditing 12 different enemy perception components to see what needs updating.

The friction point is stimulus lifetime. A noise event from frame 40 shouldn't still be influencing decisions at frame 400, so you need a decay mechanism. I use exponential decay with per-stimulus half-lives, which works well, but it does mean maintaining a priority queue of decaying signals per agent, which adds overhead at scale. Worth it for the structural cleanliness, but worth knowing about upfront.

The pattern that's worked best for me is separating stimulus collection from awareness evaluation from alert state. Three distinct layers, no direct coupling between them.

Stimuli (sound, sight, physics events) write into a per-enemy buffer. The awareness system reads that buffer on its own tick and updates a float confidence value, not a binary detected/not-detected flag. State machines only look at confidence, not stimuli directly. That indirection is what prevents the tangling: you can swap the awareness logic completely without touching the state machine, and vice versa.

Confidence-based detection also handles the "almost saw you" case more naturally than binary flags. Enemies that slowly build suspicion just feel better than ones that snap from idle to full alert the instant a threshold trips.

One thing I'd add to the three-layer separation: make sure the stimulus collection layer is typed, not a unified float or merged awareness score. An enemy who heard something but never got visual should investigate toward the last known audio position. One who had visual contact and lost it should hold the last known visual position. If you collapse sound and sight into the same value at collection time, that distinction disappears, and enemies start behaving weirdly in mixed-stimulus scenarios, which is basically every interesting situation in stealth or action AI.

The abstraction is right. The temptation to simplify stimulus types early is real, but worth resisting.

One thing that doesn't come up enough in these perception architecture discussions: tick rate. The three-layer separation is the right design, but evaluating the full stack every frame for 20+ enemies adds up fast. The usual fix is staggering enemy updates across frames, but that interacts badly with the frame-order problem CipherMesh raised. If stimulus collection and awareness evaluation are no longer guaranteed to run the same frame, you can get a one-frame gap where an enemy misses something it should have caught.

The pattern that worked for me: stimulus collection runs every frame (cheap, just appending events into a shared per-enemy buffer), while awareness evaluation only fires on each enemy's designated tick frame. The buffer accumulates between ticks so nothing gets dropped, and evaluation cost spreads across frames without losing stimulus data. The tricky part is flushing the buffer at the right point in the tick so you're not evaluating half-populated data, but once that's solid it's a pretty clean setup.

One thing worth being careful about: the frame order of stimulus collection vs. perception evaluation. If your emitters - footstep events, visual triggers, whatever - run after the perception step in the same frame, enemies are always reacting to one-frame-old data. Usually invisible, but it bit me with a "guaranteed reaction" trigger where a point-blank gunshot occasionally felt like the enemy just shrugged it off. The one-frame lag was exactly the wrong amount of delay to be noticeable without being obvious.

Fix was trivial once I saw it: stimulus collection runs early in _physics_process, flushes to the world blackboard, perception evaluation reads from the blackboard in a later step. It's the kind of thing that stays invisible until it bites you at a playtest demo.