Hey Guys,
I would like to create my own FSM for character behavior. I would like to keep it very simple and clean, I do not want to use any of the unreal based classes everything is already bloated with tones of code.
My only problem here is about GC how should i handle this ? and if you think using one of the unreal classes is a better option. which would be the most light weighted approach, I don’t wanna create 50+ states and its objects on a unreal class.
Thank you 
Whenever you want light-weight coding entities I recommend USTRUCTS, then you need at most 1 UObject or Actor manager of your system to tick all your USTRUCTs
UStructs, They Are Awesome!
https://wiki.unrealengine.com/Structs,_USTRUCTS(),_They're_Awesome
**Thousands of UE4-Integrated Stale-Pointer Protected, Light-weight Entities**
This way you can comfortably make 2000+ states with their own instanced variables and proper entitization, and you will have a very stable system that is also light-weight, as with USTRUCTS you can pass everything by reference :)
Keep in mind though with USTRUCTS you still get stale UObject Ptr protection, as long as you store your UStruct State array in a UObject or AActor class and mark it with UPROPERTY().
GameState would be a good place to store your state array :)
```
UPROPERTY() //<~~~~ Gives you GC protection and stale ptr protection if you have ptrs to UObjects inside of FYourState
TArray<FYourState> FSM;
```
But if your FSM is per actor then you can do this same thing in your actor class
then override Actor tick and have it tick each of your USTRUCTS
```
FYourState::Tick(float DeltaSeconds)
{
//Now you are fully hooked into the awesomeness that is UE4 while having instanced vars in a by-ref (more stable than ptrs) GC-protected data format.
}
```
Rama
PS: More on Stale Ptr Protection and GC
https://wiki.unrealengine.com/How_To_Prevent_Crashes_Due_To_Dangling_Actor_Pointers
https://wiki.unrealengine.com/Garbage_Collection_%26_Dynamic_Memory_AllocationThanks a lot Rama thanks for guidance
You don’t need to use USTRUCTS (although it is an option).
You’re entirely free to write whatever C++ code you like. I have a very basic FSM in my plugin and I just use plain C++ classes. The UE smart pointer library can take care of GC if you don’t want to manage the memory yourself.
Thanks a lot mid_gen , I do not mind memory managing myself. as you have more knowledge in this can you suggest me the best place to initialize the run time states ? as i’m not familiar with the execution order of unreal Engine I do not wanna pile up and cause any spike in run time. I can break it down but I wish to keep it tidy
My FSM is mega simple, it’s just the basis for an AI planner, so it just has Idle/Plan, MoveTo, DoAction states. The states are tiny classes. It’s more or less exactly the same as Bob Nystrom’s example.
http://gameprogrammingpatterns.com/state.html
As to when you initialize them, up to you. You can instantiate all the states up front and just flip between them, or create/destroy them as you use them. Usual trade-off of higher memory usage vs more allocations/frees.
Can you give more examples about the type of states you’re talking about? It’s hard to tell you where a state machine should live without knowing what its responsibilities will be. Given that you said you wanted it to control characters, it makes sense to me that you’d put it in your character.
There is an unreal livestream trainging series where they make specifically a FSM plugin for fighting game states. Here’s the first one, and you can find the rest searching for “plugin” or “fighting game state machine” on their twitch videos section.
All that being said, I wouldn’t worry so much about using unreal classes because they seem bloated. Some of the classes certainly are, but a lot of them aren’t so much bloated as they are robust. As an example of the difference, CharacterMovementComponent is something I’d consider bloated, as it contains a lot of logic that is strictly relevant to Unreal/fps characters; it’s not as useful for a generic ACharacter that moves. On the other hand, APlayerController is something I wouldn’t consider bloated (maybe a little, but not the same way I consider CharacterMovementComponent); it’s a large class with a lot of responsibilities, but they’re generally tightly bound to what you’d consider a player controller to be, and a lot of the “extra” stuff is there because of years of accumulated bug fixing/prevention. Stuff in the PlayerController is largely there because it’s where it belongs, especially compared to CharacterMovementComponent.
For a lot of the larger classes, there’s always going to be some bloat, but especially as you go down into some of the smaller more recently added systems there’s a much stronger focus on generic usage, and a lot of the code that’s in there is in there because it fixed/prevented a problem, not just because. Also you get the benefit of the fact that bugs magically get fixed by other people, and they’ve been getting fixed by other people for months/years.
The only reason I’m mentioning this is because I’ve been bitten way harder by times when I decided to do something myself that unreal already had functionality for than when I tried to use an unreal thing that seemed like it had more stuff than I wanted. I’d always recommend making sure the engine doesn’t already do what you want, and if it does at least investigate it to see if there’s actually a reason not to use that before dismissing engine classes outright.
HI mid_gen, you don’t believe i went threw that book even before getting the FSM idea in my mind 
that is a wonderful book .
thanks a lot mid_gen
hey mrooney, I agree with you. my character is mostly custom created it had custom gravity and stuff like that it will affected with external ability so the behavior states changes a lot. right now all the states are created at beginPlay (i’m gonna create another system to automate here), available at all the time and destroyed only when the pawn triggers begin destroy. my state has Enter / Tick / Reset /Exit (and it works based on time/state/flag) states and its been arrayed. i can jump one to another based on index which is pretty handy at the moment.
same here i try to use most of them so I could save time and something that involves in custom behavior i always created my own , for this I believe making the system can make it lean and clean, can tailor it based purely on need and I even ditched out blueprint availability.
Thanks a lot mrooney to share your thoughts
Yea, that sounds good 
FWIW, we do the same thing with an FSM on our characters. I just know we have also made the mistake of creating our own things that already exist in the engine giving us lots of extra work we didn’t need to do 
If it’s just going to manage the state of the character/pawn, I’d stick it in the pawn. If it’s more about the player behind the pawn, I’d put it in the playerstate. If it’s just for movement I’d stick it in a movementcomponent.
Another kind of related mistake we made early and have been slowly correcting was that we originally overrode the playercontroller class, but we used the same inherited playercontroller everywhere in the game, so game logic leaked into the menus. If you decide to put your FSM in your playercontroller/playerstate, make sure that you’re only overriding them in the places it makes sense.
hey mrooney,
That is very valuable information mrooney, I did something very similar split my pawn by 2. kept all the behavior in the pawn and used another actor component to aid only for pawn’s ability and its states. I could have added another Inheritance layer on pawn to keep it much cleaner but using in actor component I can reuse it to another actors if I wanted to. But this is completely based on our specific need.
The player controller I will keep that in mind, for now i have inherited mine from the Engine’s controller but have not changed anything major yet other than few variables to give the flexibility to detect the controller coz the game gonna have multiple controllers, Still yet figure out using keyboard as one and joystick as another. for now engine recognize both as same gotta dig to figure it out. xD