얼핏 보기엔 쉬울 것 같다. 그냥 많이 맞으면 별이 핑핑 돈다. 스트레스 변수를 추가하고 데미지를 입을 때마다 쌓이지만 시간이 흐르면 자연스레 깎인다. 하지만 일정 수치를 넘으면 다운되고 일어설 때 무방비 상태가 된다. 하지만 이 때 버튼을 마구 누르면 좀 더 빨리 풀려날 수 있다. 생각만큼 쉬울까. 한 번 해보자. 일단 모션부터 만들자.
체력바는 2중 슬라이더가 되어야 하기 때문에 셰이더를 새로 짰다. 기본적인 체력차감 코드도 마무리했다. 콤보가 끊기지 않으려면 1초안에 데미지를 넣어야 하며, 그 이상 지연되면 콤보가 끊기며 데미지가 확정된다.
여기까지는 어렵지 않다. 이제 기획이 좀 필요하다. 데미지는 기본적으로 정해진 숫자는 있지만 상황에 따라 조금씩 보정을 받는다.
카운터일 경우.
연속기일 경우.
타격형 잡기일 경우.
카운터를 판단하는 기준이 좀 어려워 보인다. 공격이 들어가는 타이밍은 이벤트에 의해 제어된다. 그렇다면 스테이트에 공격력이 붙어있고 아직 이벤트를 만나지 않았을 때를 카운터 유효시점이라고 보는 것이 맞는가? 그렇다면 발동이 느리다면 카운터가 쉽다는 이야기가 된다. 흐음. 말 되네?! 해보기로 하자.
7.8
카운터는 구현은 했으나 제대로 작동할 지 모르겠다. 어떤 구멍이 있을지 테스트를 하며 알아보자
콤보는 2콤보부터 10%씩 깎이는 데미지 보정이 있다. 이렇게 되면 짠손을 중간에 섞는 게 오히려 데미지를 깎아먹는 결과를 낸다. 하지만 SuperAttack은 보정하지 않는다. 달래의 경우 많이 때리긴 하지만, SuperAttack은 마지막의 회전차기 뿐이다. 일단은 괜찮아 보인다.
잡기의 데미지처리는 또 별도이다. 일단 비교적 간단한 히트형 잡기부터 처리.
타격형잡기는 버튼을 마구 누르면 좀 더 빨리 풀린다.
초필게이지 처리도 완료. 아. 그런데 때리는 애가 차야지…거꾸로 찬다.
체력바는 얼추 다 된 것 같다. 시간을 줄이는 건 일도 아니지만, 씬로딩과 승패가 들어가야 의미가 있을 것이다. 그 다음은 스턴을 추가해 보자.
UI랄 게 별로 없다보니 폰트가 중요하다. 그래서 이리저리 알아본 결과 산돌폰트에 괜찮은 유료폰트를 발견했다. 그런데 저작권에 대한 해설이 불분명하다. 폰트란 건 한 번 받아 설치하면 영구히 사용할 수 있는 것인데, 그렇다면 다운로드 후 구독을 끊으면 어떻게 되는 거지? 게임 출시할 때 또 결제해야 하는 건가? 서비스하는 내내 폰트가 보일텐데, 그럼 계속 구독을 끊으면 안되나?
폰트만큼 딴지를 많이 거는 분야도 드물다. 그러다 보니 심지어 이걸 빌미로 사기를 치는 집단도 있다. 마치 공인된 기관인 것처럼 속여 돈을 뜯으려 하는 것이다. 그러니 속편하게 그냥 무료폰트를 쓰도록 하자. 요새는 무료폰트도 예쁜 것이 참 많다.
Backstep은 뒤로 폴짝 뛰는 모션이지만 SubState를 Jumping으로 두면 안된다. 비주얼에 따라 백덤플링같은 것이 더 어울릴 수 있기 때문.
당연한 이야기지만, 일단 모션이 필요하다. 만들자.
모션 데이터는 액션매니저에 의해 그룹화해서 관리하고 있다. 기존까지는 점프중이 아닐 경우의 이동이 걷기뿐이었으므로 Stand에 포함되어 있었지만, Moving으로 새 카테고리를 만들어 관리하는 편이 좋겠다. 이렇게 모션별로 짤라 카테고리를 만드는 이유는 익스포트 속도때문이다. 데이터가 크다보니 각 그룹별로 익스포트하는데 꽤나 오랜 시간이 걸리는데, 이걸 자주 해야 한다. 데이터가 단순하면 하나에 묶는 편이 여러모로 좋다.
한 캐릭터에게 필요한 모션은 이렇게나 많다. 나도 몰랐다. 이렇게까지 많아질 줄은.
이제 코드에 대시를 추가해야 하는데, 코드가 다소 엉망이라 정리를 했다. 그리고 정리 수납하고 흐뭇해하는 가정주부의 마음을 이해하게 되었다.
7.2
세상에! 단순히 대시를 넣으려 했던 계획은 감속부분의 문제로 인해 코드 리팩토링으로 번졌다. 솔직히, 쉬울 줄 알았다. 그냥 커맨드 앞앞, 뒤뒤만 추가하면 되는 일 아닌가?! 그런데 기존 코드가 이를 허락하지 않았고 이동관련 코드를 상당 부분 뒤엎어야 했다.
여전히 수정 중이다. 하지만 뜻이 있는 곳에 길이 있다고 했던가? 기존까지 sin함수로 처리하던 코드를 Lerp로 바꾸니 훨씬 간결하고 깔끔해졌다. 처음부터 이랬어야 했지만, 원래 인생이란 시행착오의 연속 아니던가. 허허.
야호.. 빠르다. 버그도 함께 찍혔네.
지금까지는 캐릭터가 그렇게 빠르게 움직일 필요가 없었기 때문에 타격판정을 실제 충돌에도 사용하고 있었다. 이것이 문제가 있던 것은 아니지만 컬리전이 계속 형태가 변하다보니 다소 불안한 느낌은 있었는데, 이동속도가 빠른 모션을 넣으니 확연히 드러난다. 아무래도 이동형 컬리전을 추가하는 편이 좋겠다. 이 쪽이 속도도 더 빠르기 때문에 최적화에도 도움이 된다.
7.3
그런데 이게 쉬운 일이 아니었다. 이번에도 진행하며 여러가지 일을 알게 됐는데, 박스컬라이더가 단순히 트랜스폼을 바꾼다고 업데이트되지 않는다는 사실이다. 컬라이더의 업데이트 주기는 fixedUpdate()를 따른다. 당연하지. 물리니까! 이걸 가지고 반나절을 헤맸는데… 어째 날이 갈 수록 버그 하나 잡는데 걸리는 시간이 늘어나는 것 같다.
여튼 수정완료. 이동형 컬라이더는 이제 단순한 사각박스를 따른다. 충돌검사 부하가 줄었기 때문에 퍼포먼스가 약간 더 좋아졌을 것이다.
퍼포먼스도 좋아졌겠다, 컬라이더 클래스를 수정하는 김에 컬라이더를 팔에 분배했다.
피격 컬라이더는 공격시에만 영향을 받는다. 이전엔 퍼포먼스를 위해 팔은 충돌에서 제외했었지만, 이제는 맞는다. 이렇게 되면 마법사이면서 팔로 장타를 날리는 닐리가 조금 불리하다. 무기는 피격 충돌에서 제외되기 때문.
대기자세도 커서 맞기 쉽다.
점프 후 바로 백스텝하면 반대로 뛰는 버그도 수정했다.
7.4
닐리의 대시모션을 작업하던 중, 여차저차해서 오로라의 데이터를 살펴보게 되었는데 무언가 크게 잘못돼 있었다. 이게 지금까지 돌아갔다고…?! 그래서 원인을 수정하고 블렌더로부터 내리 수정. 이걸 살펴보려던 건 아닌데, 덕분에 큰 버그를 잡았다. 시간은 버렸지만 보람은 있었다. 가만, 그럼 시간을 버린 게 아닌가?
얼마 전, 앨리스의 스킬이 완성되던 시점에 지인 사무실에서 간이 대전(?)을 해본 적이 있다. 원래는 혼자서 할 수 없는 몇가지 사항을 확인하기 위해 진행한 테스트였지만, 한 번씩 키보드에 손을 댄 후엔 ‘왜 대시 없어?’라는 반응이 가장 먼저 자연스레 튀어나왔다.
처음부터 대시를 넣을 생각은 아니었지만, 참여자 모두가 대시를 원했으므로 어느 정도 궤도를 수정할 예정이다. 오로라의 작업이 끝난 이 시점의 다음 작업은 버그픽스 후 신캐제작이었지만, 이를 잠시 미뤄두고 실제 대전에 적합한 게임의 형태를 만드는 편이 더 좋다고 생각되었으므로 체력바를 달자. 승리포즈도 필요할 것이다. 좀 이르지만 캐릭터 선택화면도 필요하다.
필요한 모션은 상당히 많다. 이젠 인게임 모션과 아웃게임 모션을 분리해야 한다. 일러스트를 3D가 대체할 것이므로, 포트레이트 애니메이션이라고 하자. 이번엔 캐릭터 선택 정도에 사용되지만, 이후엔 대화씬 등에서 사용된다.
인게임
대시(Dash)
백스텝(Backstep)
스턴(Stun)
승리1(Victory_01)
승리2(Victory_02)
도발(Provoke)
타임오버(TimeOver)
포트레이트
캐릭터 선택대기(Portrait_Idle)
캐릭터 선택확정(Portrait_Confirm)
등장 애니메이션(Portrait_Ready)
씬이 하나 더 필요하다. 미루고 미뤄왔던 씬로딩. 허허. 이젠 할 때가 됐다.
Battle(현재)
Select(캐릭터 선택화면)
이제 체력바 그려야 된다. 배틀씬에 필요한 UI를 정리해보자.
체력 게이지
이름
라운드 승리횟수
시간
초필 게이지
라운드 텍스트
파이트! 텍스트
XXX 윈! 텍스트(승리)
더블 KO 텍스트
타임오버 텍스트
퍼펙트 텍스트
체력 처리를 위한 시스템 추가도 필요하다.
타격형 잡기는 상대방의 저항이 있을 경우 좀 덜 때려야 한다.(닐리의 궁디팡팡, 오로라의 꿀밤)
오로라의 필살기는 주로 잡기다. 이것만으로 할 일이 좀 더 많은 편인데, 이걸 한 이후에도 각 캐릭터에게 잡기에 해당하는 애니메이션을 추가해 주어야 한다. 많이 한 것 같은데, 아직 먼 길 가야 된다. 차근차근 가자.
팔돌리기에 트레일을 추가. 달리기 속도 높이니 뜻밖에 연계기가.. 되네?!
초필을 만들자.
팔돌리기만 반나절이 걸렸다. 힘든 애니메이션이었어. 그런데 아직 안끝났다는 것이…
6.28
와. 요근래 가장 힘든 작업이었다. 그나저나 화면이 좁네!
6.29
공중잡기와 초필살기에서 위치가 어긋나는 문제가 있었다. 현상은 같지만 원인이 달랐는데, 버그추적을 하다보니 결국 같은 문제였다는 것이 밝혀져서 허탈.. 덕분에 코드의 구멍을 좀 더 메울 수 있어서 완전히 헛된 시간은 아니었다.
오로라의 이펙트는 별 게 없다. 잡기 캐릭터이다 보니 거의 먼지투성이다. 별도의 포스트를 거치지 않고 빠르게 완료하자.
와… 어려웠다. 이제 정리 작업을 해보자.
오로라는 앨리스밖에 잡질 못한다. 왜냐면 앨리스에게만 잡기 모션이 포함되어 있기 때문이다. 이제 이것들을 다른 캐릭터들에게도 포함시켜 주어야 한다.
내가 게임을 개발하며 정말 많이 놀랐던 것이 이런 부분이다. 우리가 당연하다고 생각되는 것들은, 누군가의 손을 거친다. IT업계라고 하면 아주 놀라운 최첨단의 업무처리방식을 갖추고 있을 것 같지만, 내막을 살펴보면 대부분 누군가의 그림자 노동으로 이루어져 있다.. 자동으로 되는 건… 유감스럽지만, 거의 없다. 개발자란, 그냥 최신식 기술을 사용하는 일꾼일 뿐이다.
길게 맞기(DamageHeavyLong) : DamageHeavyHead와 같다. 연출상 딜레이를 두고 맞아야 할 때 사용한다.
커맨드기는 아직 구상 중이다. 잡기 캐릭터이니 초필은 커맨드잡기 확정이고, 필살기 중에도 하나는 있어야 한다. 그리고 버튼 연타기술도 구현돼야 한다. 버튼 연타는 구상한 기술입력 시스템의 마지막 퍼즐이다. 이 외에 버튼 2개이상 동시에 누르기 등이 있지만, 난 버튼 동시 발동을 별로 좋아하지 않으므로 패스하기로 하자.
허그(Hug) – ←↓→ A or B (구상 중)
대공잡기(AirCatch) – 공중에서 ←↓→ A or B (구상 중)
팔 휘두르기(Swing) – A연타 or B연타.
정신없이 쿵쾅쾅(SmashDown) – ↓←↓→ B 초필.
필살기 말고도 만들 모션은 많다. 차차 생각해보자.
방어부터 시작
이야야야아아아-ㅇ아-=
소점프킥. 얘는 연계기로 연결이 안됨.
야야야얍
방어 후 바로 반격을 할 수 있는 버그가 있어서 추적을 시작했는데, 해결까지 무려 4시간이 걸렸다.[…] 이게 전부터 재현이 안되던 버그였는데, 이번에 재현이 되어 추적 끝에 결국 해결. 지금까지 개발하며 어려운 상황을 많이 맞이해봤지만, 이번 버그는 역대급이었다. 아휴… 이제 안정될 때도 됐건만…
다시 애니메이션으로 돌아가자.
커맨드잡기 – Hug는 상대를 끌어안은 다음, 폭탄을 쥐어주고 본인은 떨어진다. 뱀파이어 세이버의 바레타와 같다. 원래는 끌어안는 척 하면서 뒤로 물러서 기계손으로 머리를 친 다음 쓰러진 상대를 덮치면 심판이 튀어나와 1,2,3을 외치려고 했는데…너무 길다!
폴짝. 이렇게 끌어안는다.실패 시 딜레이가 큼.
구현 중… 생각보다 손이 많이 간다.
6.24
작업이 하기 싫을 때가 있다. 모든 일을 의욕적으로 처리하기는 당연히 어렵다. 그럴 때 난 느릿느릿~하는 편을 택한다. 머리를 비우고 일을 천천히 진행하는 것이다. 클릭도, 타이핑도 느리게. 또박또박. 재미있게도 목표점에 다다르는 시간이 크게 차이가 나질 않는다. 아니, 오히려 더 빠를 때도 있다. 그리고 무엇을 했든, 그 결과가 의지를 충전해 준다. 글씨를 또박또박 쓰는 것과 같다. 하고 나면 뿌듯하다. 작업을 이어갈 수 있는 원동력이 된다.
그래서 일단…음. 폭탄을 만들었다.오로라가 이걸 앨리스에게 주도록 해보자.
요로케 붙여야지.
…
오늘의 깨달음. 폭발 후 어깨에 불이 계속 붙어있는 문제가 있어서 추적을 해보니 particle의 입자를 생성중인가의 조건식의 particle.IsAlive()가 문제였다. 이것은 파티클의 입자가 아직 살아있는가?를 조사하는 게 맞기는 한데, looping이 켜져있을 경우 여전히 살아있는 것으로 인식한다. 야이… Stop()으로 파티클을 껐으면 당연히 looping도 끄는거지! 결국 수동으로 라이프타임을 재계산해서 파괴하는 방식을 썼다. 뜻밖에 멍청한 구석이 있네. 내가 못찾은 건가…
세상에서 가장 뜨거운 포옹이다. 퍼엉이겠지
6.26
어제 작업을 건너뛴 건 아닌데, 소득이 없었다. 공중 잡기의 컨셉이 정말 어려웠는데, 팔이 너무 크다 보니 리치가 지나치게 길어져서 OP가 된다. 안그래도 상대하기 까다로운 게 잡기 캐릭인데, 공격범위까지 넓을 수는 없다보니 구상에 많은 시간이 걸렸다.
그래서 최종 구상은 파리잡기!
잡히면 요래 땅에 박힌다. 애니메이션은 아직 완성이 덜 됐다.
땅에 박히는 모션을 복사하기 위해 데미지 액션 중 DamageSlam의 전체 액션을 복사해야 했다. 그런데 잘 안된다. 원인을 찾아보니 다양하다.
다리의 본 애니메이션이 Euler로 만들어져 있다.
쿼터니온으로 변경해서 해결할 수 있다.
채널이 없다.
alt+r등으로 fcurve를 생성해 주어야 한다. 블렌더는 애니메이션을 붙일 때 fcurve가 없으면 붙이지 않는다.
그룹 외 커브이다.
이는 스크립트를 사용하다 생기는 오류인데, 몇몇 애니메이션은 본의 그룹을 벗어난다. 정상적인 상황이라면 커브는 모두 본의 이름을 그룹으로 갖는다. 하지만 이것이 바깥으로 빠져나와있는 경우가 있다. 이럴 경우, 복사가 되질 않는다. AutoRig Pro의 쿼터니온 변환이 이런 오류를 일으킨다. 그룹에서 벗어나 있어도 애니메이션은 잘 되기 때문에 큰 문제삼지 않았는데, 이런 문제가 있을 줄은.
키를 복사할 때 그룹이 선택되어 있다.
특정 채널이 선택되어 있을 경우, 전체 선택(A)를 눌러도 해당 채널만 복사되는 현상이 있다. 이건 버그가 아니고 블렌더에서 그렇게 설정되도록 한 것이다. 불편해!
이 때문에 오랫만에 스크립트를 업데이트하고, 정리하다 보니 타임오버. 쿼터니온 문제는 첫단추를 잘못 꿴 댓가이다. 첫 데이터가 말썽이면 개발 내내 고통받는다. 레퍼런스 모델은 필요한 관절은 모두 쿼터니온으로 변경해 놓았다. (다시 한 번 체크해보자.) 5번째 캐릭터부터는 이런 고통이 좀 줄어들 것이다.
공중잡기 완료. 그런데 이걸 테스트하면서 잡기 위치가 어긋나는 현상을 발견했다. 이건… 음. 과거에 프레임이 튈 때 위치가 어긋나는 문제가 있어 방어코드를 넣은 것이 오히려 버그를 내고 있었다. 이를 삭제하니 잘되는 것 같아 보이긴 하는데, 좀 더 정확한 건 테스트를 해보아야 알겠다.
화살에 이펙트를 붙이지 않으면 덩어리감이 없어 눈에 잘 띄지 않으므로 뭐라고 붙여야 한다. 그래서 생각해낸 것이 삐죽삐죽한 이펙트이다.
드래곤 플라이트를 만들 당시, 캐릭터 주변에 붙는 가시이펙트는 맥스를 이용해서 만들었었다. 당시는 자체엔진을 사용했기 때문에 파티클로 저걸 구현해낼 방법이 없어서 맥스로 만든 걸 익스포트해서 썼었는데, 유니티라면 되지 않을까
오.. 잘 된다.
화살은 완료
뜻밖에 매우 어려웠던 대각선 화살. 이게 왜 어려웠냐면 스케일때문이다. 현재는 파티클을 생성시킨 후, 세로스케일을 줄여서 사용하고 있는데, 이것이 월드 기준으로 계산된다. 따라서 이것을 로컬기준으로 변경하려면 몇가지 설정이 필요하다. 일단 렌더러 설정에서 렌더정렬을 Local로 바꿔주고
스케일링 모드를 하이라키로 바꿔준다.
그리고 스케일을 줄인 후, 로테이션 또한 하이라키에서 제어해야 한다.
처음엔 파티클의 기울기를 StartRotation에서 제어하고 있었는데 이게 오답이었다. 이것 때문에 저녁작업시간을 홀라당 날려버렸다. 흑흑
6.20
이펙트를 등록하려면 많은 과정을 거쳐야 하는데, 이것이 너무 번거롭게 느껴져서 리팩토링. 이제 데이터에 이펙트 정보가 없다면 빈 정보를 생성하고, 좌우 반전 이펙트의 경우 오른쪽 정보를 먼저 찾아보도록 변경했다. 코드가 한결 깔끔해졌다. 그럼 스테이트 정보도 이렇게 하면 더 깔끔하겠네! 싶어서 봤더니, 스테이트는 빈 데이터를 사용하는 경우가 거의 없어서 의미가 없었다.(비어있는 경우는 None과 Idle밖에 없었다!)
길게 맞기(DamageHeavyLong) : DamageHeavyHead와 같다. 연출상 딜레이를 두고 맞아야 할 때 사용한다.
6.14
모션의 구성을 생각해서 분리한 뒤에, 스테이트를 등록하고… 기존에 만들었던 시스템에 맞추어 코드를 수정하고… 즉, 준비작업만 2시간 남짓. 자동화도 어려운 작업이라 일일이 손으로 해야 한다. 챙겨야 할 것들이 참 많다.
6.15
활 쏘기, 공중쏘기는 발동이 느려서 대공기로는 조금 어려울 것 같고, 견제용이다. 그런데 숫자채우려고 넣은 날아차기가 뜻밖에 매우 고성능이다. 이제 반격을 만들어 보자.
반격! 번거롭긴 했는데 생각보다 구현은 쉬웠다. 가용시간은 1/6초인데, 노인이라 그런가. 맞추기가 꽤 어렵다.
닐리 작업하다가 달래를 보니 좀 심심한 느낌이 든다. 모션 느낌이 아직 많이 덜 잡혔지만 오늘은 타임오버.
6.16
모션 디테일 중. 활쏘기 프레임이 꽤 많이 나와서 회수동작을 넣었는데 너무 번잡시럽게 느껴진다. 내일 다시 고민해 보자.
6.17
활쏘기 프레임을 고민하다가 조상님들은(스파2) 어떻게 했을까? 를 살펴보았다. 지금까지는 장풍이 충분히 느리다면, 화면 안에 2개의 장풍이 존재할 수 있게 된다. 하지만 게임내에서 장풍을 2개 본 기억이 없는데, 지금까지는 이것이 화면비율때문이라고 생각했었다. 격투게임이 유행하던 시절의 화면비는 4:3이었다. 현재의 16:9화면에 비해 가로화면이 짧으므로 다음 장풍이 나타나기 전에 이전 장풍이 화면밖으로 사라진다…라고 생각했는데, 아니다! 장풍은 1개만 발사하도록 강제되고 있었다. 와. 정말로 섬세한 게임이다. 전설이 될만하다. 왜 이 쉬운 방법을 생각못했을까…
공중으로 화살을 날릴 땐 각도가 맞아야 한다. X로 4, Y로 2이동할 때 이 화살의 정확한 각도는 몇일까? 자비스에게 물어보자.
따라서 26도 정도 기울여 모션을 만들면 정확하다.
반격에 성공했을 땐 상대의 1타를 무시하고 역공을 한다. 비단 격투 게임뿐 아니라 거의 모든 게임에서 카운터는 후한 점수를 주기 때문에, 맞으면 넉백이 되는 강력한 공격이다. 그런데 비주얼이 너무 약하게 제작된 것 같아서 한 번 고쳤는데… 여전히 약해 보인다는 것이 좀 고민이다. 하지만 더 뾰족한 수도 떠오르지 않으니.. 그냥 하기로 하자.