로딩과 병렬처리와 UI가 만나는 곳에서 일어난 이런저런 사단을 겪은 뒤,

FSM 을 만들어야 이후 발생할 끔찍한 일들을 막겠다 싶어서 검색을 해보니까

c++에서는 std::variant 가 최신 유행이야! 라는 말이 제일 많이 나왔습니다만, 영-_- 마음에 안들어서

가장 간단한 switch 문으로 하다가 모든 일이 그렇듯이 이걸로 감당이 안되겠다 싶어서 더 뒤지다 보니까...

TVariant라는 아이가 있더군요. (지금 쓰는 게 언리얼인지라) 하지만 그래도 마음에 안들어서 더 뒤지다보니까...

Finite State Machines (FSM) in Embedded Systems (Part 3) - Unuglify C++ FSM with DSL
이런 흑마술도 나오더군요 하지만 역시 마음에 안들어서 더 뒤지다보니까...

Oh my...

Tech Breakdown: AI with Finite State Machines

/* shorthand macro */
#define FSM_ID( SID, EID ) ( uint64(STATE_##SID) | (uint64(EVENT_STATE_##EID) << 32) )

uint32 SomeEnemy::HandleEvent( const FSMEvent& Event ) override
{
	switch( Event.MakeSwitch(State) )
	{
	case FSM_ID( STANDING_STILL, ENTER ):
	{
		/* code for entering the standing-still state */
		break;
	}
...
	}
}

상태 enum 을 비트시프트한 다음 합쳐서 switch 문의 case로 쓰고 있는 끔찍한 짓을 하고 있더군요' -'

근데 이게 마음에 들더라구요(퍼엉) 이걸로 하려구요.

@hyaline 이런 FSM은 std::variant처럼 type으로 처리하기에는 코드도 난잡해지고 bloating도 심해지겠다 싶습니다. 마지막 방안인 상태의 종류와 상태의 시점을 합쳐서 처리하는 방식은 처음 보는데, 아이디어가 되는 구현이 날 것이기는 하지만 이를 고려해 설계에 고심을 많이 한 부분이 보였습니다. 잘 읽었습니다. 😄

1