Managing Multiple Mechanics?

[cooper37]

@Nawrot

Take look at CGFSM plugin, it is great for what you want to do.
But it is code plugin so if your platformer is made for mobiles, iti is more trouble (to use code plugin) than it is worth.
Anyway you can create prototype (using this plugin) then create all states and functionality in blueprints if needed.

You also can place all that logic inside animation blueprint, use state machine there to drive animations. Add anim notifiers to anims and send information back to player pawn about state of animation and player. But this approach is kind of messy, if you canage animation and forget to add notifier your game code suddenly stops working.

I wish epic just did native finite states machines like that plugin (code is there, it is just not exposed for general BPs, only for anim state machines and blackboards in ai).

**Edit there is moar:
You can also create additional child (inheritied) character blueprints.
I split mine into layers: locomotion and animation, game mechanics like inventory weapon handling etc, and pure cosmetic (look) layer. So i have 3 player character blueprints each with different focus.

Then i use (everywhere i can) blueprintable components. Each component handles some tiny aspect of game.
For eg i have components for eyes and head, that track target and calculate all angles for animation blueprint.
Then each weapon socket has different blueprintable component that handles events like equip/unequip for swapping weapons and attaching them to holster or hands.
Then 2 components of feet that calculate distance to ground, what material player is on, and wait for anim notifier to fire up and tell them to play sound at location.

So all code (whatever i can) is split to smaller containers that are autonomous.**

That’s pretty neat! Is there a link to doing something specific like that? I believe I read somewhere before, where someone had abilities as components, but that related to weapons and spells, not sure how you’ll go about creating mechanic/ability components. But something like that could definitely work! At least, to make the blueprints not look so complex, I had it to where major locomotion and movement were in the event graph, Camera Controls were in another event graph, and abilities were in another. Other small specifics like turning things on and off and changing the player’s “state” was handled using bools and functions, which got crazy. If I just extend the inherited character blueprint to another, how would that be any different from creating another blank page of an event graph?