[TIL] 15주차 4일 트러블슈팅 FSM을 사용하며 일어난 문제들

 

FSM을 사용하면서 일어난 다양한 문제들

문제

• State간의 전환이 안될 때가 있는 경우
• 각 State의 애니메이션 간의 전환이 매끄럽지 않은 경우
• State의 강제적인 변환으로 인해서 일어난 버그들 ( 캐릭터가 굳어 버린다던가 )
• State간의 전환 사이에 1프레임 씩 다른 State가 섞이는 문제
• State의 전환에 따라서 물리적인 문제가 발생하는 경우
• State의 조작과 내부로직이 함께 작동하지 않고 따로 노는 경우
• State를 마구마구 변환 시키다 보면 발생하는 문제 ( 스킬을 막 누르고, 전환을 막 누르다 보면 굳음 )

기존 접근

저 버그들이 한번에 모두 발생한 것이 아니기 때문에

버그가 발생할 때마다 그에 맞은 어느정도 하드코딩으로 대처를 했었다.

예를 들면 State간의 전환이 안될 때는 미리 만들어둔 ChangeState 메소드를 통해서

강제적으로 State를 바꿔주고 그 과정에서 강제적으로 바꿔서 굳어버리는 등 버그해결이

다른 버그를 발생시키는 결과를 초래했다.

스킬 여러개를 동시에 누르면 생기는 문제도 플레이어 Input 자체에서 조건문을 통해 막았었다.

이런 방식으로 해결하니 계속해서 다른 버그가 생겼고

그에 맞춰서 코드를 추가하고 근본적인 해결이 되지 않는 느낌이었다.

해결 방안

근본적인 해결을 위해서는 먼저 내가 짠 StateMachine의 구조를 정확히 파악할 필요가 있었다.

 

내부로직과 실제 인풋이 다르게 행동하는 이유에는

사진에서 보듯이 많은 수의 State들이 있는데

 

이 State들 모두가 PlayerbaseState를 상속받기 때문에

그걸 정확히 인지하고 어떤것을 상속받아야하고 받으면 안되는지를 정확히 구분해줘야했다.

상속받으면 안되는 변수들은 Player로 옮겨서 처리하고

상속받으면 안되는 함수들은 override 메소드에서 Base를 지우면서 구조를 개선했다.

 

UI를 켰을 때 인풋을 막거나 강제로 Idle로 변경시키는 방법은 많은 버그를 유발했다.

일단 Input을 막는 방법으로는 조건문을 통해 막는 것이 아닌

UI가 켜지고 꺼질 때 Input.PlayerActions를 Enable, Disable 해줌으로써

조금 더 깔끔하고 안정적인 해결이 되었다.

 

Input을 비활성화 시켜서 강제로 IdleState로 돌려주지않아도 자연스럽게 돌아가게 되었다.

이 외에 자잘한 애니메이션과 관련된 많은 버그들은

StateMachine을 리펙토링하면서 많이 개선되었고

그렇지 않은 부분들은 애니메이터의 트랜지션 조정과, HasExitTime을 조정함으로써

해결할 수 있었다.

결론

FSM을 사용할 때는 현재 사용하고있는 FSM의 구조를 정확히 파악하고

버그가 생길 때마다 그 구조에 맞춰서 근본적인 해결방안을 찾아야 한다는 걸 알았다.

내가 지금까지 주었던 조건, 특정 상황에 따른 변화 등을 잊지말고 기록해두어야

유지보수가 수월해진 다는 것을 알았다.

또 애니메이션과 관련된 버그들은 트랜지션의 속성들, HasExitTime과 애니메이션 전환의 관계성

등을 조금 더 공부하고 자세하게 알고있으면 훨씬 도움이 되었을 거란 걸 알았다.