2.23
공중에서 점프해서 캐릭터끼리 맞닿을 시에 덜덜거리는 현상이 있다. 이것을 추적하기 위해 코드를 살피던 중, 충돌코드에서 유니티가 기본적으로 제공중인 Intersect()를 쓰는 코드를 발견했다. 오래 전에 이것이 다리의 충돌검사를 제대로 하지 못한데다, 불필요한 연산이 들어가 있어서 직접제작한 걸로 바꿨는데 공교롭게도 이것이 캐릭터를 뛰어넘을 때 도움이 되고 있었다. 연산을 제대로 하니 다리 충돌이 걸려 캐릭터를 못뛰어넘는다.
이론적으로 접근하자면 물론 충돌 박스가 작게 수정되는 것이 맞다.그런데, 가만… 충돌에 한해서 다리를 빼는 것이 더 괜찮은 플레이경험을 제공한다면, 그 쪽이 낫지 않을까?
foreach (BoxCollider2D player1Collider in player1FSM.bodyColliders)
{
if(player1Collider.name.Contains("leg")) continue;
foreach (BoxCollider2D player2Collider in player2FSM.bodyColliders)
{
if(player2Collider.name.Contains("leg")) continue;이제 뛰어넘을 수 있다.
앨리스는 늘 그래왔다. 언제나 첫작업으로 쓰였기 때문에 많은 시행착오를 거쳐 완성하곤 했다. 이번에도 그러고 있다. 잡기 첫모션 제작 중. 오늘은 여기까지
2.24
잡기 1번은 완료. 방향키+강펀치로 발동한다. 어느 쪽으로 집어던질 지 결정할 수 있다.
2번의 구상은 좀 복잡하다. 한 팔로 멱살을 끌어당긴 후, 균형을 잃은 상대의 등 혹은 뒤통수를 돌아서 발로 차서 넘어뜨리고 등을 찌른다. 복잡하다! 구상대로 잘 될까… 이 작업만 며칠 걸릴 지도 모르겠다.
타이밍은 대충 이렇다. 이제 디테일 파보자….지만 오늘은 여기까지인가.
2.25
오늘의 깨달음. FK-IK를 오가는 애니메이션을 할 때엔 겹키를 주는 것보단, 그냥 해당키에서 각각 FK/IK스위치를 한 번씩 해주는 것이 더 효과적이다. 이렇게 되면 각각의 컨트롤러가 알맞게 보간되어 알아서 부드러운 애니메이션이 된다. 맥스-바이패드의 Plant Key를 사용하던 버릇 때문에 지금까지 겹키를 주는 방식을 택하고 있었는데 블렌더에서는 그럴 필요가 없을 듯? 확실히 적응하니 더 편하다.
..지만 그렇다고 하더라도 점프직후의 까치발을 위해선 겹키를 주어야 한다. 음.. 뭐 그렇다고 해도 이 정도면 품이 많이 드는 것이 아니라 괜찮다.
캐릭터 2명은 뷰포트에서는 꽤 느려서 풀 프레임으로 재생할 수가 없다. 때문에 솔리드 모드에서 전체 모션을 확인해야 한다. 오늘은 여기까지.
2.26
칼로 등을 찌르는 모션을 구현하기 위해서는 몇 가지 단계가 필요하다. 애초에 염두에 두긴 했으나 생각보다 더 귀찮은 작업인 것 같다. 먼저, 피격자가 등을 차인 후 앞으로 쓰러지는 모션은 분리해 제작되어야 한다. 이는 몇몇 기술이 머리를 쳐서 바닥에 처박힐 때 공용으로 사용될 것이다. (KOF의 료가 사용하는 수박깨기처럼) 그렇다면 필연적으로 일어나는 모션이 추가된다. 이를 DamageSlam, GetUpSlam으로 제작한다.
그 후엔 앨리스의 잡기 피격 모션으로 복사해서 이식해서 다른 모션과 이어지도록 제작해야 한다. 발차기 이후의 스테이트를 따로 쓸 수도 있겠으나, 그 어떤 게임적 요인으로 인해 위치가 정확하지 않을 가능성이 있다.
또한 화면 끝에서 기술을 사용할 경우, 발차기를 하는 순간에 필요한 거리만큼 밖으로 빼내주어야 한다. 잡기 세트 모션중에는 충돌체크를 하지 않기 때문에, 수동으로 밀어주어야 하는 것이다. 이 때 밀어주는 거리는 어느 정도 정형화되는 편이 좋다. 안그러면 위치가 튈테니까.
마지막으로 모든 세트 모션이 끝난 후, 제자리에 다시 독립된 개체로 누워있을 수 있도록 피격자의 위치를 교정해주어야 한다. 하지만 이 때까지도 피격자는 Caught모션일 것이다. 잡기는 타격자가 먼저 활동이 가능해지기 때문에 충돌 무시 플래그를 피격자에게 심어놨는지, 타격자에게 심어놨는지 조사해 봐야한다. 이것이 피격자라면 타격자로 바꾸자. 또한 스테이트에서 길이를 15프레임 정도 길게 설정해서 누워있는 대기시간을 주어야 한다. 현재 이것을 Length를 강제로 교정하는 식으로 처리해 놨는데 AdditionalLength같은 식으로 변경하는 쪽이 좋아보인다.
오늘의 깨달음. 차일드를 자주 바꾸는 본은 traj보단 그냥 부모없음.으로 설정하는 편이 애니메이션하기에 더 편하다. 주로 대각선 애니메이션을 할 때!
먼저 DamageSlam, GetUpSlam을 제작
피격자의 애니메이션 제작 중. 애니메이션 자체는 내일 마무리할 수 있을 것 같다.z
2.27
좌우를 와리가리하는 애니메이션을 제작하다보니 머리카락 앤젤링의 코드에 문제가 있는 것을 발견했다. 해당코드는 뷰에 따른 UV를 위아래로 움직이기 위해 바이탄젠트를 쓰고 있는데 좌우가 반전되면 방향도 바뀌는 문제가 있는 것이다. 게임은 로컬 스케일의 X값을 사용해서 캐릭터를 반전하고 있으니 이를 알아내어 곱하면 될 것이다. 이를 위해 챗GPT에게 의뢰하니, unity_ObjectToWorld라는 행렬을 이용하면 된다고 한다.
| r11 r12 r13 tx |
| r21 r22 r23 ty |
| r31 r32 r33 tz |
| 0 0 0 1 |
행렬의 대각선값(r11,r22,r33)은 스케일이다. 나머지는 회전값, 오른쪽 3열은 이동값을 기록한다. 따라서 [0].x를 쓰면 될 줄 알았는데…정작 해보니 변화가 없다…? 생각해 보니 그건 어디까지나 메쉬 오브젝트의 행렬이지, 게임오브젝트와는 관련이 없는 것도 같다. 그럼 수동으로 해 줄수밖에… CPU가 수고 좀 하자.
스케일팩터를 추가하고 방향이 변할 때마다 바꿔주어야 한다.
FSM코드만 1000줄이 넘어가지만 아직까지는 알아볼만 하다.
이제 닐리의 잡기로 넘어가자.
이즈 본거지 