비네트의 선택을 처리하기 위해서는 먼저 캐릭터 선택화면의 개량이 필요하다. 기존의 8캐릭터만 선택가능한 화면은 페이즈1화면으로, 스토리 모드를 한 번이라도 클리어하기 이전의 화면이다. 스토리 모드를 한 번이라도 클리어하게 되면 페이즈 2화면이 되는데, 이 때부터 12캐릭터 + 히든 아이시의 선택이 가능해진다.
선택화면 레이아웃은 페이즈1을 디자인할 때부터 구상해 두었던 것이다. 히든인 아이시는 멜라에 커서를 둔 상태에서 아래로 3번 내리면 선택되게 할 예정이다.
이제 이미지를 줄일 시간인데, 프리뷰와 품질차이가 있다…오른쪽 경계선 옆쪽이 깔끔하게 떨어지지 않고 1픽셀의 이격이 발생한다. 이유가 뭘까 고민해봤는데 원본의 가로길이가 홀수라 그런 게 아닐까 싶다. 포토샵은 0.5픽셀을 표현하지 못하니까, 양 옆 픽셀을 섞어서 중간색을 취할 것이다…1픽셀을 지우던가 늘리던가 해보자.
좀 낫다.
하지만 완벽하진 않다. 어쩔 수 없지.
페이즈 완료. 휴일의 힘을 빌려 일찍 끝냈다. 영상을 올리고 나니 보이는 버그. 수정하자.
이제 7개정도 처리한 것 같다. 생각보다 더 오래 걸리고 있지만, 허투루 하면 나중에 어차피 다시해야 하기에 확실히 해두는 편이 좋다.
5.24
역대급으로 처리가 어려웠던 비네트의 조심해요! 스킬.완료!
5.25
이제 그네타기를 제작할 차례인데…이건 애매한 부분이 있다. 현재의 캐릭터는 전체적으로 평면적 공간에서 약간 회전된 상태로 제작된다. 이는 순수하게 심미적으로 예쁘게 보이기 위한 처리이다.
그래서 이것을 앞에서 볼 경우
이렇게 손이 어긋나는 문제가 발생한다.
가장 심플한 해결방법. 보조본을 사용해 수동으로 위치보정을 해준다…가 생각보다 잘 작동한다…? 그냥 이렇게 쓰면 될 것 같다.
이제 그네를 모델링하기 전에… 길이를 맞춰야 한다. 배틀퀸은 공중에 있을 경우 타격판정에서 다리를 제외한다. 공중공격을 좀 더 유리하게 만들기 위한 조치다. 때문에 다리를 주욱 뻗고 공격하는 이 자세는 판정면에서 꽤 유리할 것이다. 하지만 줄이 길면 궤적이 길어져 공격이 느릴 것이고, 줄이 짧다면 화면중간에 줄이 끊기니 그 자체로 문제가 있다. 적당한 길이를 맞춰야 한다. 유니티로 가서 길이를 재어보자.
더미로 대충 만들었던 그네인데, 한 번에 적절한 값을 찾았다. 행운이 뒤따르니 오늘 완성할 수 있을 지도!?
블렌더로 가져오니 폴리곤이 5만개 가까이 된다. 그냥 써도 사실 문제는 없겠지만, 마음이 불편하다. 정리를 하자.
5.30
폴리곤 정리를 하고, 게임용 셰이더로 맞추자. 예상은 했지만 소품이 참 많이 필요한 아가씨다.
5.31
이제 자전거 리깅을 하고
코드에 적용. 야, 자전거 타고 가야지!!
6.1
Cursor가 좋다길래 함 써봤는데, 프로젝트 전체를 훑으며 코드를 보는 능력은 탁월한 것 같다. 다만 이거에 의존하게 되니 순식간에 뇌가 안돌아가는 느낌을 받게 된다. 코드란 건 사실 머릿속으로 생각한 걸 그대로 짜는 게 더 빠르지 않은가… 의도를 말로 설명하는 게 더 힘들다. 제대로 전달되지도 않는 것 같고. 버그가 잘 안잡힐 때만 간간히 사용해야 할 것 같다.
원래대로라면 캐릭터의 선택/등장 애니메이션을 작업해야 할 시점이지만, 이를 처리하기 위해선 캐릭터 선택화면의 페이즈2를 만들어야 한다. 기존까지의 작업은 플레이를 처음 시작하면 나오는 페이즈1화면이고, 시나리오 모드를 한 번 이상 클리어하면 열리는 페이즈 2화면은 12캐릭터(+히든)를 모두 선택할 수 있다. 하지만 이것이 당장은 일이 크니까, 일단 스킬 애니메이션부터 제작을 해보자.
일의 시작은 구상으로부터
우산돌리기(Rolling) : A or B 연타 – 본래 근접 강펀치였던 공격
조심해요!(FallObject) : ← A or B – 화분, 공, 벽돌등이 화면 위에서 떨어진다.
그네 타기(Swing) : ↑ K, 발을 주욱 뻗고 그네를 탄다.
따르릉따르릉 비켜나세요(Bycycle), →K – 자전거를 타고 적이 있는 곳까지 돌격. 맞든 막든 부딪히면 비네트가 튕겨나가며 역가드 판정을 일으킨다.
둥실둥실(Gliding) : ↑누르고 있기 – 우산을 펼쳐서 저속낙하.
사뿐즈려밟고(StepAir) : 공중에서 ↓K – 적을 밟고 한 번 더 뛰어오른다.
우박이 내릴 예정입니다.(Hail) : ↓→B – 우박이 내린다. 닐리의 메테오와 비슷하지만 그 수가 훨씬 더 많다.
우산돌리기
..는 전에 만들어둔 모션도 있어서 어렵지 않다. 쉽게 구현.
5.16
조심해요!
최근에 애니메이션의 작업방식이 조금 바뀌었는데, 이는 블렌더의 Relax Pose기능을 활용한 것이다. 기존에는 만들어질 애니메이션을 예측해 각 관절을 차례차례 잡는 방식이었는데, 최근의 작업방식은 좀 더 전통적인 애니메이션 방식(원화간 프레임을 동화로 보간)에 가깝다. 기존의 방식보다 결과물 예측도 쉽고 빠르다. 자신의 실력이 또 한단계 향상되었다는 것을 느끼는 것만큼 기쁜 일이 또 있을까!
이제 떨어질 물건들을 구할 차례. 하늘에서 물건이 떨어지는 것은 차원의 틈새로 이세계의 물건들이 떨어지는 것이다. 따라서 무엇이든 떨어질 수 있다.
오브젝트가 캐릭터에게 맞았다면 그 물건이 부셔져야 한다. 이 때 부셔지는 요소를 단순 파티클로 처리할 것인가? 컴포넌트가 붙은 오브젝트로 처리할 것인가?
만약 오브젝트로 처리할 경우, 쓰레기통처럼 2개로 분리되는 오브젝트에 대해선 어떻게 처리를 할까?
파티클로는 원하는 움직임을 구현하지 못하는 것이 확실한데, 스킨드메쉬까지 사용해 가며 고비용으로 처리할 것인가?
땅에 떨어졌을 때의 파편은 캐릭터에게 맞았을 때와 같은 이펙트를 사용할까? 공중에서 무언가에 맞았을 때와 땅에 떨어졌을 때의 파티클은 튕기는 정도나 궤적이 다를텐데 무엇이 더 나은 선택일까?
고장난 요소를 어디까지 모델링해줄 것인가?
발사체로 처리한다면 추후 추가될 한여름의 장풍반사에 반응할 것인가? 궤적이 좀 이상해지지만 게임적 요소로는 더 재미있긴 할터인데.
오브젝트가 사라질 땐 어찌할 것인가? 디졸브? 스케일다운?
파티클은 열외로 치더라도 본체를 위한 셰이더를 별도로 쓸 것인가? 비네트에 포함시킬 것인가?
낙하궤적은 사인곡선을 사용해 가속을 줄 것인가? 등속으로 해줄 것인가?
낙하 예고는 어찌해줄 것인가?
기타등등
이것들을 쉽게 할 수도 있지만, 후회가 남을 것 같았다. 그래서 이 구현의 난이도를 상급으로 올리고 진지하게 임해보도록 하자.
일단 모델링 리토폴로지.
텍스처링
5.19
애니메이션
비네트 본체에 애니메이션을 끼워넣고
코드를 짜고
좀 작네..? 뭐 그건 중요한 게 아니고…
5.20
제작방침을 스킨드메시가 아니라 정적 메시로 변경했다. 기존 계획이 워낙 일이 크기도 하고, 예외처리가 많아서이다. 그보단 기존의 발사체에 대응하는 것이 제작이 편하다. 스킬을 제작할 땐 원래 코드작업이 좀 있는 편이었지만, 이번엔 꽤 크게 걸렸다. 덕분에 진전이 없다. 오늘은 끝장을 볼 수 있을 줄 알았는데, 코드 작업조차 끝내지 못했다.
추적 결과, 원인을 찾았다. 최근까지 입을 AlphaTest로 그리고 있었는데, 배틀퀸은 해상도를 꽤 높게 렌더링하고 있음에도 불구하고 실제 게임에서는 입이 생략되어 나오는 경우가 많았다. 알파값이 임계점을 못넘은 것인데, 이 때문에 닐리나 오로라처럼 대기자세에서 입이 크게 표현되는 경우가 아니라면 입 자체가 생략되어 버리는 경우가 많았던 것. 그러나 개발기간이 길어지며 이걸 까먹고 ‘이게 왜 반투명이 아니지?’싶어서 설정을 바꾸니 오류가 일어났던 것이다. 그럼 … 좀 이상한 방법이긴 한데, 큐를 3000번 이전에 그리면…?
되기..는 된다. 그런데 이것도 좀 이상하다. ZWrite를 켜놨는데… 그럼 Z엔 뭘 쓰게 되는거지…?
혼란스럽네?! 입은 얼굴로부터 일정 수준 떨어져 있다. 그러므로 Z엔 폴리곤 정보…아…
일반적인 경우라면 Z에는 Opaque나 Cutout처럼 확실하게 짤리는 마스킹만 쓰게 되어 있다. 하지만 반투명은 시스템 안티앨리어싱과는 다르다. 즉, 반투명도 Z에 써지기는 한다. 다만 이렇게 할 경우 다른 반투명과 뎁스 충돌을 일으키기 때문에 그리 하지 않을 뿐이다.
하지만 입의 경우 사용처가 매우 한정적이라 사용해도 될 것 같다. 원하는 결과다.
5.12
비네트의 잡기애니메이션은 이전에 비네트의 기본 이동 애니메이션을 업로드했을 때, 댓글로 달린 아잉-f2x님의 아이디어에서 착안했다. 우산 속에서 뭘하는 지는 나도 모르겠다.(…)
하지만 이를 위해 처리를 해야 할 거대한 작업이 하나 있는데, 그것은 얼굴 홍조의 처리.
사실 멜라의 잡기에 키스를 넣을 생각이었기 때문에 언젠가 필요한 작업이기는 했다. 당연한 이야기지만, 얼굴이란 생각보다 훨씬 더 다양한 감정을 표현한다. 이 게임을 처음 개발할 당시, 캐릭터를 이렇게까지 디테일하게 표현할 생각이 없었기 때문에 중요하지 않은 것들(+번거로운 것들)은 제외하고 작업을 했었는데, 결국 프로젝트를 매듭짓기 위해서는 모두 필요하다.
이 홍조를 표현해주기 위해서 각 캐릭터를 돌며 홍조메쉬를 추가하고, 컨트롤러를 설정하고, 드라이버를 설정하고, 모델을 다시 익스포트해준 후에, 유니티로 가서 셰이더를 추가하고, 셰이더 드라이버를 업데이트해주어야 비로소 게임에서 이것이 제대로 돌아가는걸 확인할 수 있다. 프로젝트는 첫단추를 잘 꿰야 한다. 흑흑.
컨트롤러 아이콘부터 제작
셰이더와 드라이버를 연결.
잠이 늘어 작업시간이 적다. 나머지는 내일 하자.
5.13
겨우겨우 유니티에 띄웠다.
새로 추가된 셰이프키가 키를 지정하지 않았을 경우, 기존의 값이 쓰레기값으로 남아 이후의 모션에 영향을 끼치지 않을까? 하는 것이었는데 다행히 다른 모션에서 별다른 키가 지정되지 않았을 땐 기본값인 0으로 돌아간다.
원래 이 공격의 컨셉은 정신공격이었다. 귓속말로 “너 살찐 것 같은데?”같은 대사를 하는 것인데… 얼굴이 빨개지는 이유는 나도 모르겠다.(…)
5.14
잡기2번. 동전줍기. 이걸 작업하며 확실해진 컨셉. 비네트는 덜렁대며 여기저기 머리를 부딪힌 탓에 머리가 매우 단단하다!
애니메이션은 완료가 됐는데, 적용을 하려면 시간이 좀 더 필요하다. 하지만 오늘은 타임오버. 내일 적용해 보자.
본격적인 애니메이션을 작업하기 전에 충돌메쉬를 만들자. 충돌 메쉬는 치마처럼 이중 레이어의 구조를 가진 캐릭터들을 작업할 때, 본을 다리밖으로 빼내거나 붙이기 위해 지침이 되는 메쉬이다. 이는 게임엔진으로 익스포트되지는 않고, 작업할 때만 사용된다.
블렌더를 처음 배울 때 혼란스러운 것이 바로 아웃라이너 오른쪽의 아이콘들이다. 화살표는 선택가능 여부, 맨 끝의 카메라는 렌더링 여부이다. 그렇다면 도대체 눈과 모니터의 차이가 뭘까? 둘 다 오브젝트를 숨기거나 보여주는 기능이다. 하지만 모니터를 꺼둘 경우 alt+h(숨긴 메쉬 보이기)로 보여지지 않는다. 충돌메쉬처럼 영원히 안보이고 싶은 메쉬에 설정해주면 좋다.
대기자세에서 얼굴이 잘 보이도록 하고 싶었기 때문에 머리를 땋은 방향을 반대로 변경했다. 달래도 마찬가지 이유로 머리를 내린 방향이 원화와 반대로 되어 있다.
이를 위해선 본의 위치를 반전시켜야 한다. 그렇다면 필요한 본을 분리한 후 스케일을 -1시켜야 하는데 이 때 주의해야 할 것들이 불필요한 드라이버의 삭제이다.
이 드라이버들은 분리되어 나온 모체에서 사용하는 것들이다. 이 상태로 아마추어를 합칠 경우, 드라이버가 중복설정이 된다. 2배 중복 정도로는 성능에 크게 영향을 끼치지 않지만 이러한 작업이 잦아질 경우 작업을 할 수 없을 정도로 느려지기 때문에 분리한 아마추어에선 반드시 미사용 드라이버를 지워주는 편이 좋다.
아마추어는 사실 첫 설정에서 아무 것도 건드리지 않는 편이 이상적이다. 그러고 보니 이전 프로세스를 진행할 때에도 비네트 작업을 할 때만 말이 참 많았던 것 같기도 하다.
비네트의 대기 자세. 비네트는 사실 싸움을 못한다. 그러나 극단의 운빨로 상대를 무력화시키는 컨셉을 갖고 있다. 그녀의 의지와 상관없이 그녀의 움직임에 따라 상대는 데미지를 입는 식이다. 때문에 대기자세도 전투적이면 안된다.
5.3
비네트의 앞걷기는 경쾌하고 발랄한 느낌을 주기 위해 꼬마 아이들처럼 걷도록 만들었다. 그런데 이것이 난이도가 꽤 높아서 하루 종일 걸렸다. 보기엔 참 쉬워 보이는데 말이다. 더구나 동작이 살짝 느린 것 같아서 게임에 어울릴지 모르겠다… 잘 어울렸으면 좋겠다.
5.4
우산이 셰이프키 형태의 애니메이션으로 교체되며 생긴 영향. 메쉬가 엄청 많아졌다…
최적화에 좋지 않은 영향을 끼치긴 하지만, 메쉬가 많아지는 것이 싫어서 스킨메쉬를 하나로 통일한 것인데, 셰이프키가 붙어있을 땐 메쉬 수정에 제약이 꽤 많다. 이 때문에 우산을 별도의 메쉬로 분리하는 것은 맞다. 그러나 이로 인해 아웃라인과 그림자 메쉬도 별도로 써야 한다. 관리가 조금 귀찮아지고 Shadow메쉬에 들어가는 Decimate도 수동으로 해 주어야 한다. 할 일이 좀 있지만 1회성이라 다행이다.
이제 유니티로 넘기고…
머티리얼을 연결하고…
데이터를 등록하고…
오랫만에 캐릭터가 엔진에서 돌아가기 시작한다.
이번엔 다이나믹 본에 꽤 공을 들였다고 생각했는데, 치마가 생각보다 많이 깨진다. 이는 나중에 세컨더리 본을 처리할 때 한 번에 처리할 것이다. 게임 개발은 예전에 비해 많이 자동화가 됐지만, 작던 크던 마무리는 결국 사람 손을 거쳐야 한다. 이 사실만은 영원히 변하지 않을 것 같다.
근접 우산 공격. 본인만 신나서 민폐를 끼치는 타입.
5.7
앉아서 강펀치. 본래 비네트는 모든 공격을 우연에 의한 민폐 컨셉으로 계획을 했었다. 때문에 모든 공격은 비공격적으로 제작하고 싶었으나, 이것은 한계가 명확했다. 장우산은 실생활에선 다양하게 민폐를 주긴 하지만, 이를 20프레임 남짓되는 짧은 공격모션에 녹여내기가 쉽지 않다. 이틀간 쉬면서 이 모션에 대해 고민했으나 도무지 떠오르지 않아 이는 일반적인 공격모션으로 대체되었다. 기억에 남는 몇몇 장면만으로는 캐릭터가 만들어지지 않는다. 창작의 고통이란, 이렇게 비어있는 부분을 뭘로 채울지 고민하는 과정이리라.
하지만 여전히 수정하고 싶은 마음이 크다. 공격 작업이 끝날 때까지 꾸준히 고민을 해보자. 뮤즈의 선물은 불현듯 찾아오는 법이니까.
근접 킥은 발을 헛디뎌서 박치기라는 컨셉이었는데, 게임하기엔 좀 답답한 감이 있다.
뮤지컬 배우같은 컨셉으로 발박수를 넣었는데, 이건 생각보다 너무 안어울린다. 폐기.
오히려 이건 괜찮아 보인다. 역시 게임에 넣어보기 전까진 알 수가 없다.
공격 타이밍은 둘째 치고, 전반적으로 ‘독특한’모션이 게임과 지나치게 안어울리는 감이 있다. 몇몇개는 그냥 공격적인 모션으로 변경할 필요가 있어 보인다.
기본적으로 리깅은 수학적이다. 실시간 3D게임이 폴리곤을 별로 사용하지 않던 시절, 게임 릭 설정 시간의 대부분은 웨이팅에 할당되었다. 하지만 폴리곤이 많아지며 웨이팅은 별로 중요하지 않게 되었고, 본의 심도깊은 세팅과 스크립트가 더 중요한 시대가 됐다.
하지만 리깅이 어설퍼도 캐릭터는 움직인다. 애니메이션만 좋다면, 아무리 허접한 리깅이라도 그럭저럭 잘 움직인다. 이 때문에 리깅은 그 중요성에 있어 언제나 후순위로 밀려있다. 배우기도 어려운데 취업도 잘 안된다. 그 때문에 유튜브든 블로그든 자료가 많지 않다.이것이 내가 리깅에 애를 먹는 이유다. 아휴 힘들어.
어깨 숄의 리깅은 벨의 것을 그대로 따왔다. 여기에 여름이의 자켓에 활용한 헬퍼본 기반의 위치교정을 좀 섞었다. 여러 모로 고민한 결과 3D캐릭터에게 숄을 사용하려면 클로스말고는 완전한 해답이 없어보인다. 그렇다고 클로스를 쓰자니 일이 너무 복잡해지고, 동영상처럼 정해진 프레임을 재생하는 것이 아니기 때문에 튀는 부분이 분명 발생할 것이다. 튀는 부분은 프레임을 느리게 돌려 계산해야 하는데, 그렇게 계산해 베이킹한다쳐도 인게임에서 동작간 보간이 안된다. 이것이 게임에서 숄을 뭔가 단단한 물건처럼 느껴지게 만든다. 결국 여기까지 고민하고 나면 다시 본 링크 베이스의 작업으로 돌아오게 되고, 적당한 선에서 타협을 봐야 한다. 그런데 그것치곤 벨의 숄 본 설계가 꽤 잘된 것 같긴 하다. 잘했어. 과거의 나.
이즈 본거지 