State component helps you to organize logic of your actors into states. Then you manage those in two ways. In code - by activating, deactivating, setting them on cooldown. In component - by defining static dependencies between states. The aim with the state component is to be simple and straightforward, and to be an extension for blueprints, instead of replacement for them. I've created it for my game, and soon it became an essential tool. I use it to drive all AI and Player logic, and even for handling input.

-- version 5.2 pending --

~~ STATE COMPONENT IS NOT REPLICATED ~~

Trailer #2

Trailer

Example #1 - Player roll like in Dark Souls in less than 5 minutes

Example #2 - Treasure chest like in Legend of Zelda in less than 5 minutes

Example #3 - AI hostage extraction like in Call of Duty in less than 10 minutes

Example #4 - AI boss battle like in Dark Sould in 26 minutes

Tutorial

Changelog and migration guide btwn versions

Documentation

My Game

support: dawid.buj@gmail.com

Features of state component

• Simplicity - Most solutions for managing and developing gameplay logic like Finite State Machine’s, Behaviour Trees and others force you to use dedicated editors (like BT editor), that you need to get familiar with. You may call it a feature, but for me it is not - there is already an editor to write gameplay logic and it’s called Blueprints. With State Component you write code like you used to - in Blueprints/C++, but it makes it more organized and structured, so it protects you from writing spaghetti-like code.

• No forced modularity - Most solutions force you to create a lot of assets. In Behavior Trees you frequently create decorators/tasks/services. Very often those consist of only a couple of nodes. Once again you may argue that this is a feature, but not for me. With SC, you may organize logic as you wish - put all states in blueprint, put only some (simple) in blueprint, but the more complex ones in separate components (and share those components between actors), put each/some in separate graphs, it’s up to you. 

• Saves you from coding - you can define dependencies between states in a table like structure. For example - you can state that the attack state blocks idle state from starting. You don’t need to express this in code by typing if (attack == false) activate(idle). This means there is less branching in your code, it’s simpler. Also you can change dependencies between states just by editing a table (like structure) - you don’t need to write/change any code.

• Debugging out of the box - state component lets you visualize which states are active/blocked/on cooldown. It also automatically records the history of all state transitions. All this can be presented in the form of debug prints or in gameplay debugger.