현재 기획은 구체적으로 명세가댄상태에여 (범위가정해져잇단뜻 )
예를들어겜개발할때이런거잇자나여

땅에닿아있을때에만 점프로직이 실행댄다
체공중일때에는 이동수평가속도가좀다르게적용댄다
머할땐 머가안댄다 머하는 머단계에서는 머가안대고 머는댄다 

이런거, 보통 어떻게 구현해야?
단순하게생각하면 이프문계속쓰면대는거잖아야 근데 이러, , , ,  , 고싶지않다는느낌이 강하게드는데 

또한가지 고려해야할사항은 캐릭터구조에요
Character.cs 처럼 캐릭터전체를 대표하는 클래스가 필요할까요?
현재는 일단
오브젝트에
- 입력매니저
- 움직임 컴포넌트 (입력받아서 이동행동으로 해석)
- 점프 컴포넌트 (입력받아서 점프행동으로 해석)
- 잡기 컴포넌트 (..)

등등이렇게 캐릭터가할수있는 액션별로 컴포넌트를만들었고
그 오브젝트 전체를 대표하는 (파사드?) Character.cs 클래스는 없어요

그리고 각 컴포넌트는 인터페이스 상속받아서
입력매니저에서
GetComponent<IMoveAction>().Move(direction)
이런식으로 쏴주거든여? 

궁금한거를 좀 정리해보면
1. 캐릭터 오브젝트 전체를 대표하는 Character.cs 가 반드시 필요한가?
- 장점 -> 외부에서 GetComponent<Character>로 쉽게 캐릭터에대한정보뺴오기가능
_ 단점 -> 상태관리책임이 복잡해짐 Character가 각 행동컴포넌트들의 상태를 읽기만하나? 쓰기도하나???? 복잡복잡 

2. 만약필요치않고 걍 동등위계관게의 컴포넌트들끼리 직접통신을하게한다면?
예를들어 점프컴포넌트가 점프하기전에 점프가가능한상태인지 확인하기위해 질문던져야대는 컴포넌트들한테 질문을 던지게짠다면 (복잡할거같음)
3. FSM? ->
좋아 보이... 지도 않고 불필요한 복잡성처럼보임 (애니메이션 컨트롤러도 스테이트머신인데 이게 편하다고 생각해본적 하나도 없음)

4. 다른 방법?

보통은어떻게 , , , 구현해요? 보통이란말이 좀 어불성설이긴하지만