스턴 추가

7.9

얼핏 보기엔 쉬울 것 같다. 그냥 많이 맞으면 별이 핑핑 돈다. 스트레스 변수를 추가하고 데미지를 입을 때마다 쌓이지만 시간이 흐르면 자연스레 깎인다. 하지만 일정 수치를 넘으면 다운되고 일어설 때 무방비 상태가 된다. 하지만 이 때 버튼을 마구 누르면 좀 더 빨리 풀려날 수 있다. 생각만큼 쉬울까. 한 번 해보자. 일단 모션부터 만들자.

그리고 스턴 이펙트

공용 이펙트이므로 스턴모션에 붙이는 것은 하드코딩으로 하는 것이 좋겠다.

구현완료. 변수가 몇 가지 있었지만 예상을 크게 벗어나지 않는 작업이었다.

다음은 캐릭터 선택 화면을 작업해 보자.

체력 바 처리

7.7

체력바는 2중 슬라이더가 되어야 하기 때문에 셰이더를 새로 짰다. 기본적인 체력차감 코드도 마무리했다. 콤보가 끊기지 않으려면 1초안에 데미지를 넣어야 하며, 그 이상 지연되면 콤보가 끊기며 데미지가 확정된다.

여기까지는 어렵지 않다. 이제 기획이 좀 필요하다. 데미지는 기본적으로 정해진 숫자는 있지만 상황에 따라 조금씩 보정을 받는다.

  • 카운터일 경우.
  • 연속기일 경우.
  • 타격형 잡기일 경우.

카운터를 판단하는 기준이 좀 어려워 보인다. 공격이 들어가는 타이밍은 이벤트에 의해 제어된다. 그렇다면 스테이트에 공격력이 붙어있고 아직 이벤트를 만나지 않았을 때를 카운터 유효시점이라고 보는 것이 맞는가? 그렇다면 발동이 느리다면 카운터가 쉽다는 이야기가 된다. 흐음. 말 되네?! 해보기로 하자.

7.8

카운터는 구현은 했으나 제대로 작동할 지 모르겠다. 어떤 구멍이 있을지 테스트를 하며 알아보자

콤보는 2콤보부터 10%씩 깎이는 데미지 보정이 있다. 이렇게 되면 짠손을 중간에 섞는 게 오히려 데미지를 깎아먹는 결과를 낸다. 하지만 SuperAttack은 보정하지 않는다. 달래의 경우 많이 때리긴 하지만, SuperAttack은 마지막의 회전차기 뿐이다. 일단은 괜찮아 보인다.

잡기의 데미지처리는 또 별도이다. 일단 비교적 간단한 히트형 잡기부터 처리.

타격형잡기는 버튼을 마구 누르면 좀 더 빨리 풀린다.

초필게이지 처리도 완료. 아. 그런데 때리는 애가 차야지…거꾸로 찬다.

체력바는 얼추 다 된 것 같다. 시간을 줄이는 건 일도 아니지만, 씬로딩과 승패가 들어가야 의미가 있을 것이다. 그 다음은 스턴을 추가해 보자.

전투 씬 UI

7.4

UI랄 게 별로 없다보니 폰트가 중요하다. 그래서 이리저리 알아본 결과 산돌폰트에 괜찮은 유료폰트를 발견했다. 그런데 저작권에 대한 해설이 불분명하다. 폰트란 건 한 번 받아 설치하면 영구히 사용할 수 있는 것인데, 그렇다면 다운로드 후 구독을 끊으면 어떻게 되는 거지? 게임 출시할 때 또 결제해야 하는 건가? 서비스하는 내내 폰트가 보일텐데, 그럼 계속 구독을 끊으면 안되나?

폰트만큼 딴지를 많이 거는 분야도 드물다. 그러다 보니 심지어 이걸 빌미로 사기를 치는 집단도 있다. 마치 공인된 기관인 것처럼 속여 돈을 뜯으려 하는 것이다. 그러니 속편하게 그냥 무료폰트를 쓰도록 하자. 요새는 무료폰트도 예쁜 것이 참 많다.

https://fonts.google.com/share?selection.family=Pirata+One

https://fonts.google.com/share?selection.family=Hahmlet:wght@100..900

게임의 분위기는 적당히 앤틱스럽게 가져갈 예정이다. 잘 어울릴 것 같으니 이걸 사용하자. 여담이지만 이렇게 삐죽삐죽하고 각진 중세풍 폰트를 블랙 레터라 부른다. 처음 알았다.

7.5

이미지가 영 마음에 들게 나오지 않는다. 오늘은 여기까지.

다듬어 보자.

7.6

디자인은 끝났으나, 몇가지 확인해야 할 사항들이 있다. 언리얼은 UI용 셰이더가 구분되어 있다. 유니티도 그럴까?

다행스러운 점은, 유니티는 별도로 구분되어 있지 않은 모양이다. UI를 카메라 기준으로 찍으면 HDR까지 모두 지원된다. 훌륭하다! 캐릭터를 HP바가 가리는 것이 싫기 때문에 캔버스를 뒤에 두고 싶고, 글씨나 몇몇 UI에 블룸을 적용하고 싶다. 모두 가능하다.

빌드하다가 셰이더 경고가 한가득 떴다. 대체로 float3와 float4를 잘못쓴 경우이다. 요새 빌드를 게을리 했더니 이런 선물을 주었다.

셰이더 수정은 간단하니 빠르게 처리하고, 다음으로 알아야 할 것은 폰트의 디자인 확장성이다. TMPro로 텍스트를 어디까지 꾸밀 수 있는가? 어..일단 구워야겠지. 이건 할 줄 모르는데… 인터넷을 찾아보자.

https://taekhyeong.tistory.com/350

요기에 잘 설명되어 있다. 그대로 따라해보자.

오. TMPro… 생각보다 확장성이 더 좋다. 확인이 끝났으니 붙여보자.

한글도 예쁘게 잘 나온다.

머티리얼 프리셋을 만드는 방법은 기본적으로 생성되는 머티리얼을 선택하고 복사하면 된다.

그러면 이렇게 머티리얼 프리셋에 등록된다. 폰트의 모양은 유지한 채, 효과만 다르게 준 글씨를 만들 때 사용한다. 머티리얼만 바꾸면 되겠지 싶어서 한참 찾았네!

실제 게임에 붙여보는 중.

7.7

이것저것 적용해 보니 카메라 기준으로 정렬된 UI는 폴리곤으로 치부된다. 이는 즉 매핑에 필터링이 적용된다는 이야기고, 이는 곧 원본보다는 조금 부옇게 표시된다는 걸 뜻한다.

위의 캔버스가 ScreenSpace, 아래쪽이 Overlay방식이다. 확실히 품질이 떨어져 보인다. 역시나. 렌더파이프라인 상 UI는 블룸을 적용할 수 없는데다가, Z Write계산도 안할텐데, 이것이 모두 적용된다는 게 좀 이상하긴 했다.

하지만 이것이 HDR을 포기할만큼의 퀄리티 저하가 있는 것은 아니니, Clip을 통한 알파테스트를 써보자. UI용으로 셰이더를 만들어야한다.

어..형편없군…?! 그냥 반투명 쓰자.

HP게이지는 3단계. 붉은 색은 콤보가 끊기지 않았을 때의 데미지 누적량이다. 데미지 확정의 중간단계이며 콤보가 끊기면 사라진다.

데미지 처리는 조금 더 복잡한 단계를 거칠 것 같다. 글도 길어졌으니 포스트를 새로 파는 편이 좋겠다.

대시와 백스텝

6.30

이 2개의 상태를 처리하기 위해선 3개의 모션이 필요하다.

  • Rush – 앞으로 치닫는 Dash와 구분하기 위해 달리기는 Rush라는 코드명을 쓴다.
  • Backstep
  • BackstepEnd

Backstep은 뒤로 폴짝 뛰는 모션이지만 SubState를 Jumping으로 두면 안된다. 비주얼에 따라 백덤플링같은 것이 더 어울릴 수 있기 때문.

당연한 이야기지만, 일단 모션이 필요하다. 만들자.

모션 데이터는 액션매니저에 의해 그룹화해서 관리하고 있다. 기존까지는 점프중이 아닐 경우의 이동이 걷기뿐이었으므로 Stand에 포함되어 있었지만, Moving으로 새 카테고리를 만들어 관리하는 편이 좋겠다. 이렇게 모션별로 짤라 카테고리를 만드는 이유는 익스포트 속도때문이다. 데이터가 크다보니 각 그룹별로 익스포트하는데 꽤나 오랜 시간이 걸리는데, 이걸 자주 해야 한다. 데이터가 단순하면 하나에 묶는 편이 여러모로 좋다.

한 캐릭터에게 필요한 모션은 이렇게나 많다. 나도 몰랐다. 이렇게까지 많아질 줄은.

이제 코드에 대시를 추가해야 하는데, 코드가 다소 엉망이라 정리를 했다. 그리고 정리 수납하고 흐뭇해하는 가정주부의 마음을 이해하게 되었다.

7.2

세상에! 단순히 대시를 넣으려 했던 계획은 감속부분의 문제로 인해 코드 리팩토링으로 번졌다. 솔직히, 쉬울 줄 알았다. 그냥 커맨드 앞앞, 뒤뒤만 추가하면 되는 일 아닌가?! 그런데 기존 코드가 이를 허락하지 않았고 이동관련 코드를 상당 부분 뒤엎어야 했다.

여전히 수정 중이다. 하지만 뜻이 있는 곳에 길이 있다고 했던가? 기존까지 sin함수로 처리하던 코드를 Lerp로 바꾸니 훨씬 간결하고 깔끔해졌다. 처음부터 이랬어야 했지만, 원래 인생이란 시행착오의 연속 아니던가. 허허.

야호.. 빠르다. 버그도 함께 찍혔네.

지금까지는 캐릭터가 그렇게 빠르게 움직일 필요가 없었기 때문에 타격판정을 실제 충돌에도 사용하고 있었다. 이것이 문제가 있던 것은 아니지만 컬리전이 계속 형태가 변하다보니 다소 불안한 느낌은 있었는데, 이동속도가 빠른 모션을 넣으니 확연히 드러난다. 아무래도 이동형 컬리전을 추가하는 편이 좋겠다. 이 쪽이 속도도 더 빠르기 때문에 최적화에도 도움이 된다.

7.3

그런데 이게 쉬운 일이 아니었다. 이번에도 진행하며 여러가지 일을 알게 됐는데, 박스컬라이더가 단순히 트랜스폼을 바꾼다고 업데이트되지 않는다는 사실이다. 컬라이더의 업데이트 주기는 fixedUpdate()를 따른다. 당연하지. 물리니까! 이걸 가지고 반나절을 헤맸는데… 어째 날이 갈 수록 버그 하나 잡는데 걸리는 시간이 늘어나는 것 같다.

여튼 수정완료. 이동형 컬라이더는 이제 단순한 사각박스를 따른다. 충돌검사 부하가 줄었기 때문에 퍼포먼스가 약간 더 좋아졌을 것이다.

퍼포먼스도 좋아졌겠다, 컬라이더 클래스를 수정하는 김에 컬라이더를 팔에 분배했다.

피격 컬라이더는 공격시에만 영향을 받는다. 이전엔 퍼포먼스를 위해 팔은 충돌에서 제외했었지만, 이제는 맞는다. 이렇게 되면 마법사이면서 팔로 장타를 날리는 닐리가 조금 불리하다. 무기는 피격 충돌에서 제외되기 때문.

대기자세도 커서 맞기 쉽다.

점프 후 바로 백스텝하면 반대로 뛰는 버그도 수정했다.

7.4

닐리의 대시모션을 작업하던 중, 여차저차해서 오로라의 데이터를 살펴보게 되었는데 무언가 크게 잘못돼 있었다. 이게 지금까지 돌아갔다고…?! 그래서 원인을 수정하고 블렌더로부터 내리 수정. 이걸 살펴보려던 건 아닌데, 덕분에 큰 버그를 잡았다. 시간은 버렸지만 보람은 있었다. 가만, 그럼 시간을 버린 게 아닌가?

달래까지 완료. 달리기가 있으니 확실히 공격패턴이 늘어난다.

완료. 다음엔 UI를 붙여보자.

대전 준비

6.30

▲ IX.(좌)와 임모씨(우), 사진 오모씨(View)

얼마 전, 앨리스의 스킬이 완성되던 시점에 지인 사무실에서 간이 대전(?)을 해본 적이 있다. 원래는 혼자서 할 수 없는 몇가지 사항을 확인하기 위해 진행한 테스트였지만, 한 번씩 키보드에 손을 댄 후엔 ‘왜 대시 없어?’라는 반응이 가장 먼저 자연스레 튀어나왔다.

처음부터 대시를 넣을 생각은 아니었지만, 참여자 모두가 대시를 원했으므로 어느 정도 궤도를 수정할 예정이다. 오로라의 작업이 끝난 이 시점의 다음 작업은 버그픽스 후 신캐제작이었지만, 이를 잠시 미뤄두고 실제 대전에 적합한 게임의 형태를 만드는 편이 더 좋다고 생각되었으므로 체력바를 달자. 승리포즈도 필요할 것이다. 좀 이르지만 캐릭터 선택화면도 필요하다.

필요한 모션은 상당히 많다. 이젠 인게임 모션과 아웃게임 모션을 분리해야 한다. 일러스트를 3D가 대체할 것이므로, 포트레이트 애니메이션이라고 하자. 이번엔 캐릭터 선택 정도에 사용되지만, 이후엔 대화씬 등에서 사용된다.

인게임

  • 대시(Dash)
  • 백스텝(Backstep)
  • 스턴(Stun)
  • 승리1(Victory_01)
  • 승리2(Victory_02)
  • 도발(Provoke)
  • 타임오버(TimeOver)

포트레이트

  • 캐릭터 선택대기(Portrait_Idle)
  • 캐릭터 선택확정(Portrait_Confirm)
  • 등장 애니메이션(Portrait_Ready)

씬이 하나 더 필요하다. 미루고 미뤄왔던 씬로딩. 허허. 이젠 할 때가 됐다.

  • Battle(현재)
  • Select(캐릭터 선택화면)

이제 체력바 그려야 된다. 배틀씬에 필요한 UI를 정리해보자.

  • 체력 게이지
  • 이름
  • 라운드 승리횟수
  • 시간
  • 초필 게이지
  • 라운드 텍스트
  • 파이트! 텍스트
  • XXX 윈! 텍스트(승리)
  • 더블 KO 텍스트
  • 타임오버 텍스트
  • 퍼펙트 텍스트

체력 처리를 위한 시스템 추가도 필요하다.

  • 타격형 잡기는 상대방의 저항이 있을 경우 좀 덜 때려야 한다.(닐리의 궁디팡팡, 오로라의 꿀밤)
  • 장풍은 서로에게 맞을 경우 상쇄된다.
  • 대시, 백스텝 처리
  • 대시할 때 점프하면 더 높이 점프
  • 조이스틱 지원
  • 데미지 처리
  • 연계 데미지 처리
  • 카운터 데미지 처리
  • 공격 우선순위 결정(판정)
  • 데미지가 누적될 경우 스턴처리
  • 공격할 때마다 초필 게이지 처리

캐릭터 선택화면에 필요한 UI작업

  • 처음엔 8캐릭터, 한 번 보스를 클리어한 후엔 12캐릭터가 선택되어야 한다.
    • 히든 캐릭터는 조건만족하면 튀어나오는 식이니까 UI엔 없어도 된다.
  • 인게임 스테이지는 양쪽 모두 캐릭터를 선택하면 랜덤하게 선택된다.
  • 뒤쪽으로 뭔가 움직이는 배경을 깔아야 한다.

시스템 작업

  • 씬 전환
  • 각 캐릭터에게 딸린 이펙트 프리로딩.

주저리주저리 길게 적어놨지만, 결국 끝나는 작업들이다. 하나하나 해보자.

일단 버그리포트에 적어둔 사항을 처리하자. 장풍을 맞으면 서로 상쇄되어야 한다.

오로라의 2기 애니메이션 #2

6.27

오로라의 필살기는 주로 잡기다. 이것만으로 할 일이 좀 더 많은 편인데, 이걸 한 이후에도 각 캐릭터에게 잡기에 해당하는 애니메이션을 추가해 주어야 한다. 많이 한 것 같은데, 아직 먼 길 가야 된다. 차근차근 가자.

팔돌리기에 트레일을 추가. 달리기 속도 높이니 뜻밖에 연계기가.. 되네?!

초필을 만들자.

팔돌리기만 반나절이 걸렸다. 힘든 애니메이션이었어. 그런데 아직 안끝났다는 것이…

6.28

와. 요근래 가장 힘든 작업이었다. 그나저나 화면이 좁네!

6.29

공중잡기와 초필살기에서 위치가 어긋나는 문제가 있었다. 현상은 같지만 원인이 달랐는데, 버그추적을 하다보니 결국 같은 문제였다는 것이 밝혀져서 허탈.. 덕분에 코드의 구멍을 좀 더 메울 수 있어서 완전히 헛된 시간은 아니었다.

오로라의 이펙트는 별 게 없다. 잡기 캐릭터이다 보니 거의 먼지투성이다. 별도의 포스트를 거치지 않고 빠르게 완료하자.

와… 어려웠다. 이제 정리 작업을 해보자.

오로라는 앨리스밖에 잡질 못한다. 왜냐면 앨리스에게만 잡기 모션이 포함되어 있기 때문이다. 이제 이것들을 다른 캐릭터들에게도 포함시켜 주어야 한다.

내가 게임을 개발하며 정말 많이 놀랐던 것이 이런 부분이다. 우리가 당연하다고 생각되는 것들은, 누군가의 손을 거친다. IT업계라고 하면 아주 놀라운 최첨단의 업무처리방식을 갖추고 있을 것 같지만, 내막을 살펴보면 대부분 누군가의 그림자 노동으로 이루어져 있다.. 자동으로 되는 건… 유감스럽지만, 거의 없다. 개발자란, 그냥 최신식 기술을 사용하는 일꾼일 뿐이다.

오로라도 오로라에게 잡힌다. 뭔가 귀엽네.

물론 폭탄 엔딩은 똑같지만.

오로라의 2기 애니메이션

6.20

4번째 캐릭터쯤 되면 시행착오가 많이 사라진다. 모델링을 오로라까지 했던 이유도 마찬가지였다. 작업이 편해지는 단계다. 시작해 보자.

우선 데미지 모션을 붙이고 수정하자. 달래의 초필을 구현하며 HeavyLong스테이트가 추가로 필요했다. 나머지는 닐리와 같다.

  • 방어 (Block) – 엔진에선 3분할 된다.
  • 앉아서 방어(CrouchBlock) – 마찬가지로 엔진에선 3분할 된다.
  • 소점프킥(SmallJumpKick)
  • 소점프킥 착지(SmallJumpKickLanding)
  • 일직선 날아가기(DamageFlying)
  • 날아가 벽에 부딪히기(DamageFlyingWall)
  • 바닥에 엎드려 떨어지기(KnockDownFront)
  • 공중에서 바닥에 꽂히기(DamageJumpSlam)
  • SlamAir의 넉다운 모션(KnockdownSlam) : DamageSlam에서 짤라쓴다.
  • 회전하며 맞기(DamageScrewCW)
  • 회전하며 맞기(DamageScrewCCW)
  • 맞고 날아가기(DamageKnockback) : DamageJumpHeavy와 같다.
  • 길게 맞기(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번째 캐릭터부터는 이런 고통이 좀 줄어들 것이다.

이게 실무에서는 어떨까… 작업자마다 오일러에 익숙한 사람(=커브 사용자)이 있고, 쿼터니온에 익숙한 사람(=직관 사용자)이 있을텐데.. 그야말로 혼파망일 듯.

공중잡기 완료. 그런데 이걸 테스트하면서 잡기 위치가 어긋나는 현상을 발견했다. 이건… 음. 과거에 프레임이 튈 때 위치가 어긋나는 문제가 있어 방어코드를 넣은 것이 오히려 버그를 내고 있었다. 이를 삭제하니 잘되는 것 같아 보이긴 하는데, 좀 더 정확한 건 테스트를 해보아야 알겠다.

버그픽스

버그는 끊임없이 나온다. 원래 그렇다. 우리가 괜찮은 게임이라 부르는 것들은 모두 이런 담금질을 거친다. 그리고 이 포스팅은 좀 심심하다. 기록할 게 별로 없다.

화살은 버튼을 누르고 있으면 쏘는 타이밍을 잠시 지연시킬 수 있다. 그 전까진 이것이 무기한 가능했는데, 1.5초로 제한하자. 그 이상 누르고 있으면 강제로 발사한다.

앗.. 생각보다 빨리 끝났다. 이제 오로라로 넘어가자.

달래의 이펙트

6.19

화살에 이펙트를 붙이지 않으면 덩어리감이 없어 눈에 잘 띄지 않으므로 뭐라고 붙여야 한다. 그래서 생각해낸 것이 삐죽삐죽한 이펙트이다.

드래곤 플라이트를 만들 당시, 캐릭터 주변에 붙는 가시이펙트는 맥스를 이용해서 만들었었다. 당시는 자체엔진을 사용했기 때문에 파티클로 저걸 구현해낼 방법이 없어서 맥스로 만든 걸 익스포트해서 썼었는데, 유니티라면 되지 않을까

오.. 잘 된다.

화살은 완료

뜻밖에 매우 어려웠던 대각선 화살. 이게 왜 어려웠냐면 스케일때문이다. 현재는 파티클을 생성시킨 후, 세로스케일을 줄여서 사용하고 있는데, 이것이 월드 기준으로 계산된다. 따라서 이것을 로컬기준으로 변경하려면 몇가지 설정이 필요하다. 일단 렌더러 설정에서 렌더정렬을 Local로 바꿔주고

스케일링 모드를 하이라키로 바꿔준다.

그리고 스케일을 줄인 후, 로테이션 또한 하이라키에서 제어해야 한다.

처음엔 파티클의 기울기를 StartRotation에서 제어하고 있었는데 이게 오답이었다. 이것 때문에 저녁작업시간을 홀라당 날려버렸다. 흑흑

6.20

이펙트를 등록하려면 많은 과정을 거쳐야 하는데, 이것이 너무 번거롭게 느껴져서 리팩토링. 이제 데이터에 이펙트 정보가 없다면 빈 정보를 생성하고, 좌우 반전 이펙트의 경우 오른쪽 정보를 먼저 찾아보도록 변경했다. 코드가 한결 깔끔해졌다. 그럼 스테이트 정보도 이렇게 하면 더 깔끔하겠네! 싶어서 봤더니, 스테이트는 빈 데이터를 사용하는 경우가 거의 없어서 의미가 없었다.(비어있는 경우는 None과 Idle밖에 없었다!)

달래의 작업이 끝났다. 버그픽스로 넘어가자.

달래의 2기 애니메이션 작업

6.13

일단 활을 들었으니 활은 쏘아야 한다. 그리고 대공기를 넣으려 했는데… 앨리스도 닐리도 대공기를 가지고 있기 때문에 밸런스가 좀 안맞다. 때문에 달래는 대공기를 빼기로 했다. 대신 공중으로 화살을 날리기로 하자.

  • 활쏘기(Shot) : ↓→A or B, 홀드 시 타이밍 지연
  • 공중으로 활쏘기(ShotAir) : ↓←A or B, 홀드 시 타이밍 지연
  • 날아차기(FlyingKick) : ↓←K
  • 반격(Parrying) : →B(상단) or ↓B(하단) or↑B(점프공격)
    • 기술명 – 미시기장(靡恃己長) – 자신의 장점을 믿지 마라.
  • 난타(Combo) : →←↓→B
    • 기술명 – 화무십일홍(花無十日紅) – 열흘 붉은 꽃은 없다.

그리고 2기 데미지 모션들이 필요하다. 기본적으로 닐리와 같고, 더 추가가 되지는 않았다.

  • 방어 (Block) – 엔진에선 3분할 된다.
  • 앉아서 방어(CrouchBlock) – 마찬가지로 엔진에선 3분할 된다.
  • 소점프킥(SmallJumpKick)
  • 소점프킥 착지(SmallJumpKickLanding)
  • 일직선 날아가기(DamageFlying)
  • 날아가 벽에 부딪히기(DamageFlyingWall)
  • 바닥에 엎드려 떨어지기(KnockDownFront)
  • 공중에서 바닥에 꽂히기(DamageJumpSlam)
  • SlamAir의 넉다운 모션(KnockdownSlam) : DamageSlam에서 짤라쓴다.
  • 회전하며 맞기(DamageScrewCW)
  • 회전하며 맞기(DamageScrewCCW)
  • 맞고 날아가기(DamageKnockback) : DamageJumpHeavy와 같다.
  • 길게 맞기(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타를 무시하고 역공을 한다. 비단 격투 게임뿐 아니라 거의 모든 게임에서 카운터는 후한 점수를 주기 때문에, 맞으면 넉백이 되는 강력한 공격이다. 그런데 비주얼이 너무 약하게 제작된 것 같아서 한 번 고쳤는데… 여전히 약해 보인다는 것이 좀 고민이다. 하지만 더 뾰족한 수도 떠오르지 않으니.. 그냥 하기로 하자.

6.18

점프와 하단 반격모션

그 다음은 초필. 용호난무.

때리는 건 내일 해보자.

러프는 잡았고…

6.19

모션 디테일도 잡았고, 이제 내일은 세컨더리 애니메이션을 해보자.

달래는 치마본의 움직임이 모두 수동이다.뚫리지 않도록 잘 조절해 주자.

으으음. 대충 된 듯? 이펙트 넘어가자.