A player friction, stuck-state, and boredom detector that notices circling, hesitation, repeated failures, idle time, lack of progress, and then exposes those states as gameplay signals.

Designed specifically to detect player friction, hesitation, repeated failure, and stuck-state behavior in Characters, Pawns, Actors, and vehicles. UBD does not decide what “progress” means unless you enable movement-based progress or manually notify progress from your own gameplay systems.

Full explanation in documentation PDF.

Add UBD Component → Detect Player Friction Signals → Game Responds

Universal Boredom Detector adds a Blueprint-friendly Actor Component that watches for idle time, hesitation, no progress, circling, repeated failures, and stuck-state behavior, then exposes those conditions as gameplay signals. Use those signals to trigger hints, UI, objective pings, helper dialogue, analytics, adaptive difficulty, or silent assist logic. UBD is not a tutorial system, it is a detection and signal layer. Your game decides what the signal means and how the player, AI, UI, quest logic, or analytics system responds.

100% FREE FOR THE UNREAL ENGINE DEVELOPER COMMUNITY!!

PLEASE PURCHASE THE PROFESSIONAL VERSION OF THE PLUGIN AS THE PRICE IS THE SAME AS THE PERSONAL VERSION

Calculation

• Evaluates the owner at a configurable interval instead of every frame

• The detector uses timers, movement samples, recent failure history, net displacement, travel distance, circling ratio, and progress state

• Idle is based on time since player activity

• Hesitation is based on shorter inactivity or low-action time before full idle

• No Progress is based on time since the last progress notification

• Repeated Failure is based on failure count within a configurable time window

• Circling compares travel distance against net displacement to detect looping or wandering

• Stuck is based on a combined friction score crossing the configured stuck threshold

• Recovered fires when progress or improved behavior lowers the friction score below the recovery threshold

• Movement can count as input activity without counting as game progress

• Progress can be fully manual, automatic through movement distance, or mixed depending on project needs

Usage

(1) Add the UBD Boredom Detector component to a Character, Pawn, Actor, or vehicle

(2) Bind to On Boredom Signal to react when the detector finds player friction

(3) Use Notify Progress when the player reaches an objective, checkpoint, puzzle step, item, path goal, or meaningful game state

(4) Use Notify Failure when the player dies, retries, misses, crashes, fails a puzzle attempt, or repeats an unsuccessful action

(5) Use Reset Boredom Detector when restarting a level, respawning, changing objectives, or resetting gameplay state

(6) Use Get Current Snapshot to read score, timers, movement data, signal state, and failure counts

(7) Use Get Debug Summary during development to print the detector’s current state

(8) Enable Treat Owner Movement As Progress for free-roam games where distance traveled should count as progress

(9) Leave Treat Owner Movement As Progress disabled for objective-based games where progress should be manually defined

(10) Tune thresholds per character, pawn, vehicle, or gameplay mode

Features

• Blueprint Actor Component workflow

• Idle detection

• Hesitation detection

• No-progress detection

• Circling / wandering detection

• Repeated failure tracking

• Stuck-state scoring

• Recovery signal

• Manual progress notifications

• Manual failure notifications

• Manual reset function

• Movement-aware input activity

• Optional movement-as-progress mode

• Runtime debug summary

• Snapshot data for UI, analytics, and gameplay systems

• Per-actor settings

• Adjustable detection thresholds

• Adjustable evaluation interval

• Works with Characters, Pawns, Actors, and vehicles

• Suitable for hints, tutorials, adaptive difficulty, objective pings, analytics, and assist systems

• Built entirely in C++

Note: Most setup issues come from placing the UBD component on the wrong Actor, not binding to On Boredom Signal, forgetting to call Notify Progress or Notify Failure, or using threshold values that are too short for normal gameplay.