[카테고리:] 배틀퀸(BattleQueen)

10.22

티스토리가 짜른 원화를 다시 올리자. 다시 생각해도 빡치네. 으.

디자인이 별게 없다보니 생각보다 더 심심한 느낌이 든다.

10.23

옷소매는 원래 팔이 약간 접힌 상태를 기준으로 제작한다. 하지만 한복의 특성인지, 어제 작업을 해본 결과 실제로는 이도저도 아닌 결과물을 보여주어 실망했기 때문에 아예 로우레벨로 돌아가 다시 만들었다.

그리고 깨달음을 얻었다.디테일은 문제가 아니다. 실루엣이 문제였던 것이다.

10.24

문제는 계속 일어난다. 알 수가 없군.

맷캡 접합부에서 문제가 일어나는데 원인을 알 수가 없다.

블렌더의 컬러시스템은 좀 이상한 것이… 컬러 스페이스 변환을 해도 리니어와 sRGB가 완전히 보간되지 않는다.원인이 뭐지? 내가 뭘 놓치고 있는거지..?

조사 결과 계산방법이 바보같았다. 블렌더는 죄가 없다.

레퍼런스 모델에 업데이트된 머티리얼을 추가할 때 사본이 생기는 것 때문에 꽤 골치가 아팠는데, Remap기능을 사용하면 편하게 할 수 있다. 이처럼 요소를 Append하면 생기는 .001사본은

아웃라이너에서 해당노드를 선택해서 Remap해주면 된다.

그러면 짜잔. 이제 씬 내의 모든 노드가 새로운 노드로 대체된다.

장기적인 작업을 위해 깔끔한 데이터 관리는 필수적이다. 사본은 바퀴벌레 같아서 한 마리 생기는 순간 우후죽순 생겨나기 때문에 빨리빨리 없애주는 게 좋다.

약간 더 손을 봐준 모델. 이런것들이 겉으로 티는 잘 안나지만, 마음을 정리해주는 효과가 있다.

이로서 완성.

앨리스나 닐리에 비해 좀 단촐한 느낌이지만, 원래 한복이 그런 여백이 많은 옷이니까.

하지만 여전히 작업공정에 삽질이 많았다. 모델링을 하나 더 해보는 게 좋겠다.

홈페이지를 이전하는 사이 기록을 하진 못했지만 많은 시도를 했다. 결론적으로 충돌체크 과정에서 고민이 생겼는데, 격투게임은 일반적인 게임보다 더 자세한 충돌박수를 사용해야 한다. 이를 위한 동적 콜라이더를 사용하려면 콜라이더가 애니메이션되어야 하지만, 또 이를 위해선 애니메이션을 편집가능한 상태로 만들어야 한다. 애니메이션을 보면서 콜라이더의 크기를 제어해야 하기 때문이다. 하지만 이렇게 되면 FBX와의 연결을 끊고 새로운 애니메이션 클립으로 복사해야 한다.

그렇다면 아예 애니메이션 단계에서 콜라이더를 제작해오는 것은 어떨까. 콜라이더는 유니티의 속성이므로, 1×1의 플랜을 매핑시켜서 콜라이더에 대응하는 것이다. 이를 위해선 2가지 확인이 필요하다.

• Collider2D가 폴리곤 모양대로의 임포트된 데이터를 지원하는가?
• Collider2D가 트랜스폼의 영향을 받는가?

일단 2번은 쉽게 확인할 수 있으니 해보자.

그렇다면, 폴리곤 모양의 임포트 데이터를 지원할까? 블렌더를 켜고

대충만든 이걸 가져가보자.

불러오긴 했는데…으에에… 마땅한 컬라이더가 없다.

처음엔 폴리곤 콜라이더에서 메쉬를 받을 수 있을 것이라 생각했지만, 생각보다 잘되진 않는다. 이걸 위해선 3D데이터로 메쉬를 받은 후, 버텍스의 정보를 폴리곤 콜라이더2D에 넘겨주는 식의 작업을 처리해야 하는 모양이다.

한 번만 하면 되는 일일테지만 어찌할 지 모르겠어! 그냥 블렌더에서 플랜의 크기를 정규화해서 들고 오는 편이 낫겠다. 다시 블렌더로 가서 데이터를 수정하고, 애니메이션을 준 후에 들고와 보자.

임포트된 데이터에서 메쉬를 끄고 대신 컬라이더를 사용한다. 잘 작동한다!

그렇다면 이제 충돌체에 대한 제작방침을 확정할 수 있다. 블렌더에선 정규화된(1×1)사이즈의 플랜을 사용해서 커스텀본에 붙이고, 임포트된 데이터에선 플랜을 박스컬라이더로 변경하면 된다.

마음이 편해졌으므로 이제 다시 충돌로 넘어가보자.

기본구현은 완료. 다음은 공격을 해보자.

10.23

오늘의 깨달음.

• 콜라이더가 disable된 상태에서 불러다 쓸 경우 쓰레기값이 들어간다. 반드시 enable확인하자.
• Collider2D는 z가 0이어야 제대로 작동한다. 90도를 돌린 오브젝트에 사용할 경우 z값을 가로로 이동시켜 충돌을 일으킬 수 없다.
• 스케일이 0이어도 충돌이 일어난다.
• 코드로 제어한 콜라이더의 enable/disable은 애니메이션보다 우선순위가 떨어진다.

짠손을 구현

밀려나기는 내일 해보자.

10.25

타격 시 밀려남을 추가.

짠손을 빠르게 타격시 모션이 안맞는 문제가 있었다. 두가지 원인이 있었는데

• 타격의 경직 때문에 시간이 멈추었을 때에도 play()함수가 작동하면서 모션이 바뀐다. 그렇다고 play()를 막을 경우, 맞는 포즈가 나오지 않는 문제가 있다. 모션이 변할 수 없도록 time scale이 0일 땐 키입력을 금지해야 한다.
• 애니메이션 시작부분을 정하는 play()함수의 세번째 인자는 정규화된 시간을 사용하여야 한다.

10.26

데미지 처리를 하며 점프코드를 리팩토링. 현재 0에서 시작하고 있는 사인함수를 절반 짤라쓰기로 하자. 이제 중력은 유지하되 점프가 필요할 땐 파워로 제어할 수 있다.

벽 충돌이 지속적으로 말썽을 일으켜서 며칠 째 보고 있다. 충돌은 총 3번 일어난다.

• 캐릭터가 겹쳤을 때 서로를 밀어낸다.
• 한쪽 캐릭터가 벽에 몰려있다면 몰리지 않은 쪽만 밀어낸다.
• 한쪽 캐릭터가 벽에 몰려있을 때 데미지를 입었을 경우 많이 밀어낸다.

이젠 문제없기를.(이라고 말하는 순간 다른 문제가 일어나서 또 수정)

이제 선입력을 위해 커맨드를 만들어야 한다. 이를 작업하며 알아낸 사실이 있다. 이 버튼들은 유니티 프로젝트 설정에 반드시 포함되어야 한다. 없으면 지속적으로 에러를 내뱉어서 콘솔창을 어지럽게 만든다.

• Submit
• Cancel
• Horizontal
• Vertical

이동을 Axis만으로 처리할 경우 문제가 있다. 키 이벤트는 KeyDown으로 받아야 하는데, Axis로 처리할 경우 2개의 키를 동시에 누를 때 0으로 처리된다. 이렇게 되면 아주 빠르게 조작할 때 커맨드가 제대로 들어오지 않는다. 프로젝트 설정에서 Input을 바꿔주면 되긴 하는데, 이게 조이스틱 대응이 잘되는지 모르겠다. 조만간 조이스틱을 하나 사야할 것 같다.

커맨드를 먼저 구현한 이유는 조작감을 위한 선입력때문이다. 비단 캔슬기 뿐 아니라 약손이나 다리걸기등은 하위기술 중간에 모션이 빠르게 변할 필요가 있다.

러프 구현은 했지만 코드가 꼬인다. 문제가 많을 것으로 예상된다. 으으음…좀 더 좋은 방법은 없을까?