캐릭터의 작업 파일은 2개로 나뉜다. 하나는 _WIP(Work In Progress), 하나는 최종파일인 _01이다. 모델링의 모디파이어를 합치기 전의 파일이다. 이들을 합친 후엔 수정이 아주 어려워지기 때문에, 이렇게 원본을 보존한다. 포토샵으로 따지면 레이어를 보존한 버전과 합친 버전을 따로 저장하는 것과 같다.
앤젤링 방향을 맞추는 중
8.23
빌드 준비를 하느라 뭔가 바빠서 작업을 못했다. 배포기념으로 윈도우 포맷을 했는데, 덕분에 블렌더를 강제 업데이트 했다. 그런데 블렌더의 렌더링 시스템이 뭔가 바뀌었다.
뭐야 왜 지저분해졌어…
그림자 처리가 좀 바뀐 것 같다. 아휴.피곤해…
아휴. 못쓰겄다. 롤백. 블룸도 컴포지트탭까지 가야 되고 아주 막.. 와. 애드온이 잘 작동하기만을 바랄 뿐.
8.24
툰렌더의 매핑은 별 게 없다. 그런데 왜 이리 오래걸릴까..
8.25
안일했던 설계가 큰 고통을 불러왔다. 가슴쪽 주름을 넣고 장갑 무늬의 윤곽선을 좀 더 두껍게 하는 ‘별 일 아닌 것 같은 일’도 예정에 없다면 큰 일이 된다. 폴리곤을 굳힌 후의 작업들은 링과 루프를 거치지 못한다면 그냥 포기하는 편이 나을 정도로 작업이 힘들다. 다음부턴 명심해 두자. 으으
8.26
생각보다 복잡했던 발.
1차 모델링 완료. 옷의 두께는 리깅을 한 후에 마무리해야 한다.
달래의 신발이 발레 슈즈 같은데 버선으로 고치는 것이 어떤가?라는 아내의 의견이 있었다. 발의 X매듭은 예쁘긴 하지만 자주 쓰면 안될 것 같기도 하고, 버선의 펑퍼짐한 느낌이 실루엣을 좀 더 재미있게 만들어 줄 것 같아서 수정했다.게임에서 보자
골조 작업이 아직 끝나지는 않았지만, 테스트가 목요일에 잡혀있다. 시간이 좀 빈다. 그럼 미리 다른 캐릭터를 만들어보도록 하자.
아. 모든 기억이 희미하다… 내가 그림을 그렸던가…타블렛을 쥐는 게 얼마만인지 모르겠다.
프리오리는 몰락한 귀족집안의 하녀라는 설정이 있다. 주인은 마약에 물들어 몰락했고, 프리오리는 주인이 권하는 약을 거절하지 못해 결국 중독되었다. 더 이상 약이 공급되지 않자 죽기 위해 몇 번이나 손목을 그은 그녀를 이 대회(?)의 주동자가 구해준다. 오른팔에 감고 있는 붕대는 자해의 흔적이다… 가 러프한 설정이다.
그런데…음.. 모델링을 못하겠어.. 어떻게 하는 거였더라..키부터 잡았던가..? 티스토리 놈들이 달래 모델링 포스트를 지워놔서 참고를 못하겠네. (아휴, 빡쳐!)
미러 모디파이어에서 클리핑을 켜고 모델링을 하다가 모디파이어를 버리게 되면 여전히 클리핑 상태로 점이 0을 벗어나지 못하는 현상이 있다. 이동옵션에서 Mirror Editing을 끄면 해제가 되긴 한다.
하지만, 이것은 블렌더가 버전업되며 생긴 버그같아 보인다. 미러와 클리핑은 다른데 같은 것처럼 동작한다.
오…하지만 분명하게 좋아진 점은 삼각형 폴리곤에 LoopCut(ctrl+R)기능으로 선 중간에 점을 찍을 수 있다! 어..아닌가? 원래 됐었던가…?
모델링은 항상 흐름 먼저.
팔주름을 그리기 위해 텍스처 페인트를 사용하려는데 스포이드 단축키가 먹지 않았다. 블렌더 4.0부터 Shift+X로 바뀌었다.
옷주름을 만드는 방법을 정립하기까진 많은 삽질을 거쳤다. 하지만 정립된 과정도 그리 편하지는 않아 자주 까먹는다. 기록용으로 남겨두도록 하자.
앗.. 애 하원할 시간.
8.20
머리카락 제작방법을 까먹었을 줄 알아서 기록하기 시작했는데, 다행이 몇 번 하다보니 기억이 났다.휴
일단 머리카락은 완료.
8.21
모델링을 할 때엔 모든 파츠를 조각내어 작업을 한다. 이 때 유용하게 사용되는 뷰포트 옵션이 랜덤컬러인데, 이 색상의 범위가 그리 다채롭지 않아서 간혹 구분이 안될 때가 있다.
닐리의 이펙트 제작과정. (삽질 포함) 이제 타임랩스 안찍어야지… 아휴. 작업내내 웹툰도 보고 서핑도 하고 그래야되는데, 누가 뭐라하는 것도 아니건만 카메라 켜있으니 뭘 못하겠다.
8.16
닐리 윙샷. 뿅뿅-!
불손이 소환. 2타 알찬 구성
attack_collider_01본은 본디 공격범위를 그리기 위한 용도로 생성되었다. 이 본의 위치와 크기에 따라 판정박스가 정해진다. 하지만 이것이 본래의 목적이외에 이펙트의 생성위치, 발사체의 발사위치를 알려주는 정보성 본을 겸직하다가 이번에 추가로 던지기 후의 상대방 위치를 알려주는 일도 겸하게 되었다.
문제는 이 본의 초기값이 깔끔하지가 않다는 데 있었다. 스크립트로 제어하고 있던 위치를 컨버팅하려면 깨끗한 정보가 필요했는데, 이를 위해 에디트 모드의 본정보를 0,0,0으로 바꿔주게 되면 기존에 잡아놨던 본의 애니메이션이 모두 틀어진다는 문제가 있다. 일이 크다. 어떻게 해야 할까….
ChatGPT는 답을 알고 있다.
import bpy
# 원하는 본의 이름
target_bone_name = 'attack_collider_01'
# X, Y 위치 수정 값
x_offset = -0.511749
y_offset = -0.205907
# 모든 액션을 순회
for action in bpy.data.actions:
# 각 fcurve를 순회 (액션의 키프레임)
for fcurve in action.fcurves:
# fcurve가 위치 데이터인지 확인 ('location'을 포함한 경로인지 확인)
if fcurve.data_path.endswith('location'):
# 데이터 경로에서 본 이름 추출
path_elements = fcurve.data_path.split('"')
if len(path_elements) > 1: # 본 이름이 포함된 경로인지 확인
bone_name = path_elements[1]
if bone_name == target_bone_name:
# x 좌표 또는 y 좌표에 해당하는지 확인
if fcurve.array_index == 0: # x 좌표
print(f'Updating X location in action "{action.name}" for bone "{target_bone_name}"')
for keyframe in fcurve.keyframe_points:
keyframe.co[1] += x_offset
keyframe.handle_left[1] += x_offset
keyframe.handle_right[1] += x_offset
elif fcurve.array_index == 1: # y 좌표
print(f'Updating Y location in action "{action.name}" for bone "{target_bone_name}"')
for keyframe in fcurve.keyframe_points:
keyframe.co[1] += y_offset
keyframe.handle_left[1] += y_offset
keyframe.handle_right[1] += y_offset
print("Completed updating keyframes.")
아무래도 블렌더 애니메이터라면, 파이썬 기초정도는 익혀두는 편이 좋겠다. 물론 첫단추를 잘 꿰는 것이 더 중요하겠지만.
8.17
이후의 일은 버그잡이다. 테스트를 하며 자잘한 수정사항들을 노션에 적어두었다. 이런 일들은 마음 같아선 바로 처리해버리고 싶지만, 얼마나 걸릴지 모르기 때문에 일단 적어두고 나중에 처리하는 것이다. 원래 하던 일을 벗어나면 안된다. 하지만 자주 벗어난다. 아휴, 급한 성격 좀 고쳐야 된다.
게임은 막타 보정이 들어가 있다. 만약 막타로 10의 데미지가 들어왔으나, 8정도의 HP가 남아있다면 살려준다. 이 때 HP는 1도트도 안보이게 되는데, 이것이 죽었다는 착각을 일으켜서 아직 살았다는 표시를 해줄 필요가 있었다. 그래서 HP가 30% 아래로 내려가면 깜빡이가 표시된다. 당연한 게 이제야 들어갔다.
원안보다 많이 변형되어 별 것아니라고 생각했던 일이 커졌다. 일단 쳐올리기 데미지상태를 추가하면서 피격자의 애니메이션이 필요해서 4캐릭터 모두에게 추가했고, 기본 애니도 좀처럼 예쁜 모양이 나오지 않아 꽤 많은 수정을 거쳤다. 원래 구현은 처올리기 후 어류겐으로 추가타를 넣는 것이었지만, 체공시간이 짧아서 작은 기술밖에 들어가지 않는다. 원했던 방향이다.
이펙트 작업은 심호흡을 하고 한 번에 처리하는 편이 좋기 때문에 나중에 한 번에 처리하기로 하고, 닐리로 넘어가도록 하자.
8.12
닐리의 추가스킬 계획은 바닥에서 커다랗고 뜨거운 손이 나와 캐릭터를 때리는 것이다. 그리고 그것은 2연타이고 싶다.
사실 닐리의 추가 스킬은 그렇게 어렵게 생각하지 않았다. 근접기 하나 더 추가하는 것인데 뭐 그리 어려울까? 하지만 작업하며 깨닫고 말았다. 이것은 새로운 유형의 작업이었구나…근접기인듯 보이지만, 근접기는 아닌 게, 공격을 하는 이펙트가 제자리에 남는 것이다. 캐릭터와 다르게 그자리에 남아 확실한 타격을 준다. 하지만 발사체와는 다르게 타격은 또 일반 히트로 분류되어야 한다. 콤보 시 데미지 보정이 들어간단 이야기다.
타격을 2번 연속 때리는 것이므로 캐릭터에게 Attack이벤트를 2번 넣어도 된다. 실제로 앨리스가 땅을 밟는 스킬을 시전할 때 10프레임과 12프레임에 각각 Attack이벤트를 심었었다. 하지만 이제 와서 왜 타격을 캐릭터와 분리했냐면 대전 테스트를 할 때, 그 2프레임(=약 0.066초)사이에 앨리스가 얻어맞으면 모션이 캔슬되며 1타만 일어나는 현상이 있었다. 정말 짧은 시간인데, 프레임 사이를 다투는 격투게임에선 이런 일이 제법 자주 일어난다.
…
발사체는 생각보다 많은 정보가 필요하다. 공격자, 충돌을 검사할 적, 데미지, 발사체 속도, 원소타입, 공격타입, 데미지타입, 타격타이밍 등등. 때문에 이것들을 발사체클래스 내에 주루룩 변수로 만들었었는데, Bomb이 발사체를 상속받게 만들면서 정리를 할 필요가 생겼다. 하는 김에 코드를 리팩토링하자. 짧다고 좋은 코드는 아니지만, 좋은 코드는 짧다. 개발이 진행되면서 코드가 길어지는 것은 어쩔 수 없지만, 이렇게 틈나는대로 정리를 해주면 보기에도 좋고 무엇보다 나중에 편하다.
뿅뿅뿅. 윙샷도 구현완료. 데미지는 약한데, 많이 맞으니 이것도 아프다.
여기까지 구현된 걸 기록해 놓자.
…
오늘의 깨달음. 블렌더 애니메이션을 할 때 원하는 채널을 잠궈놓으면 해당 채널엔 애니메이션 키가 잡하지 않는다!
루트의 애니메이션은 모든 관절부 애니메이션을 통틀어 가장 중요한데, 때문에 채널별로 키를 다르게 줄 때가 많다. 개인적으로 많이 사용하는 기능이 블렌드 애니메이션(alt+e)기능인데, 이건 다 좋은데 모든 채널에 키를 만드는 것이 문제다. 이럴 때 Location을 잠궈놓으면 로테이션만 키를 줄 수 있다. 물론스케일 채널에도 키를 만들겠지만, 그건 버리는 키니까 상관이 없다.
8.13
러프한 구현완료. 손만 빠르면 점프킥부터 시작해서 초필까지 연계할 수 있다. 아무리 데미지 보정을 받아도 그렇게 되면 거의 절명기 수준인데, 문제는 내 손이 그걸 못한다…
애니메이션도 완료. 빙그르르- 이 짧은 씬을 구성하는데도 4개의 애니메이션이 필요하다. 잡기는 참 번거로운 기술이다.
8.14
그 번거로운 잡기를 또 해야 한다. 이번엔 오로라의 스킬이다.
구현과정을 녹화해 보았다. 사실 이건 스크립팅이라 구현이랄 것도 없다. 기존에 되어있던걸 추가했을 뿐인데, 그럼에도 새로운 트러블이 발생해서 한참 삽질을 했다. 그런데도 타임랩스로 보니 뭐 대단한 전문가가 아주 빠르게 코드를 쓰고 있는 것처럼 보인다. 사실은 ‘이게 맞나…’ 싶어서 코드를 썼다가, ‘아까 했던 게 맞네’하고 되돌리고 나니 ‘앗. 고친 게 맞네’싶어서 허둥대는 모습이다. 그걸 지우고 다시 쓰고하는 삽질도 삽질이지만, 오늘따라 유니티의 못보던 버그도 끼어들어 한층 더 삽질이 심했다. 그런데 이 모든 것이…! 타임랩스로 돌리니 마냥 일잘하는 직원같아 보인다!?! 약은 이렇게 파는 거구나.한 수 배웠다.
본디 이 스킬은 KOF블루 마리의 태클잡기에서 따온 것이다. 테스트할 때 지인이 아이디어를 줬는데, 이걸 그대로 차용한 것이다. “하단인데도 발동이 빠른 기술이예요”. 그걸 듣고 만든건데, 어제 구현하고도 뭔가 좀 이상했다. 잡기에 무슨 하단이 있어… 그래서 생각해보니 막히면 연계되지 않아야 한다. 즉 1타는 타격기다. 그래서 오늘 코드를 수정. 막히면 잡기는 발동되지 않는다. (그리고 얻어맞겠지)
슈웅-!여기서 추가타를 넣으면 잡는다. 닐리나 달래의 장풍 또한 피할 수 있기 때문에 헛점을 찌르는 용도로 사용할 수 있지 않을까
지인 사무실에서 테스트를 진행했다. 이는 사실 처음이 아닌데, 저번 테스트는 버그가 많았고 방어 딜레이가 너무 길어 치고받기가 매끄럽지 않았기에 굳이 영상을 올리지는 않았다. 오늘은 저번에 비해서는 게임이 되는 편이었다. 버그가 일부 발견됐고, 보완할 점이 많았다. 테스트는 역시 중요하다.
영상을 보면 모든 문제가 드러난다. 대충 정리하면 다음과 같다.
오로라는 벽에 몰아넣고 공격할 때 마땅히 할 게 없다.
전체적으로 스킬 3개가 적은 느낌이었다. 하나 더 늘려야 한다.
평타가 대공에 너무 강했다. 덕분에 점프 공격이 봉쇄되는 효과가 있었다. 공격판정을 줄일 필요가 있다.
구르기를 추가하자.
SP를 사용한 카운터를 추가하자.
HP바에 딸피임을 알 수 있는 깜빡임을 추가하자.
구르기와 SP사용 카운터까지 추가하면 꽤나 킹오파에 가까워진다. 버그부터 처리해 보자.
버튼 2개누르기는 피하고 싶으니. 도발 버튼을 사용하자. 이젠 사실상 액션버튼으로 사용된다.
구르기를 추가할 때의 고민은 ‘뒤구르기’를 넣는가였다. 킹오파는 이게 있다. 그런데 백대시도 있다. 그럼 뒤구르기가 왜 필요하지? 쓰임새야 있겠지만, 물량을 하나라도 줄여야 하는 입장에선 고민이 된다. 그래서 우선 모션이름을DodgeForward로 정했다. 하지만 이내 생각을 고쳤다. 자연스럽지도 않고.. 꼭 따라해야 할 필요가 있을까? 싶어서 이름을 그냥 Dodge로 고쳤다. 정답은 테스트가 알려줄 것이다.
다음은 막고 치기. 상대방의 몰아치는 콤보를 끊을 때 사용한다. 고급사용자용. 발동은 방어했을 때 막은 상태에서 P를 누르면 된다.
8.8
오로라 차징까지 완료.
데이터 테이블은 구조체에 직접 써놓고 있다.
지금까진 평타의 판정이 지나치게 넓었기 때문에, 점프 공격을 평타로 막아내는 현상이 있었다. 검을 저렇게 휘두르면 당연히 위까지 다 맞는게 맞지 않을까? 싶었는데… 아.. 그러면 안되는 것이었다. 수정하자.
점프 공격은 판정 상 유리해야 한다. 방어를 할 수 없는데다 이동루트가 예상이 되기 때문에 발동이 빠르다. 그리고 이를 이기는 것이 대공기이다. 모든 게 계산된 것들이었구나. 새삼 격투게임을 창시한 이들이 대단해 보인다.
평타수정은 됐고, 이제 스킬을 하나씩 더 추가해보자. 계획은 다음과 같다.
앨리스(←A or B, Thrust) – 뒤로 뺐다가 찌르기. 소울칼리버의 황성경이나 샹화, 미츠루기등이 사용했던 느낌으로. B는 2연계할 수 있다.
닐리(→A or B, FlameClaw) – 근접 폭발. 바닥에서 불꽃의 손을 소환. 수비형 캐릭터인만큼 공격적인 연계기가 부족했기 때문에 추가하자.
달래(← B, SpinMove ) – 잡아채 돌리며 뒤로 돌아가기. 이오리나 블루마리,각성야시로등이 사용하던 잡아채기. 공격능력은 없고 콤보 연계용이다.
오로라(→K, AnkleHook) – 슬라이딩으로 발목 잡기. 장풍 혹은 상단공격을 피하면서 아래쪽으로 파고 드는 잡기형 기술이다.
몇가지 수정사항이 더 필요해보인다.
닐리(하늘을 나는 동안 A or B) – 폭탄떨어뜨리기를 추가.
달래(플라잉킥 중 K) – 연계기 추가
달래 – 반격을 상단/중단 구분없이 하나로 합침. 하단 반격은 삭제
오로라 – 폭탄안기 발동딜레이를 없애고 A, B의 성능을 분화
8.9
러프하게 구현은 했으나, 예상했던 것만큼 모양이 예쁘지가 않다. 캐릭터들의 강베기 리치가 생각보다 긴데, 이를 회피하려면 앨리스는 더욱 더 멀리 뒤로 갔다와야 하는 문제가 있다. 그냥 써도 문제지만, 1타 후 쓰려면 반발력 때문에 정말 멀리 떨어지게 되어 캐릭터가 지나치게 가벼워 보인다. 다른 기술을 생각해보는 편이 좋겠다.
다른 기술을 생각하다가, 문득 회피를 공격초반에 넣어보면 어떨까 싶어서 넣어봤는데 느낌이 괜찮았다. 문제는 이것이 직관적이지 않고, 성능이 너무 좋다. 그렇다면 반격기로 넣을까..싶었는데, 앨리스는 단순명쾌한 컨셉이므로 섬세한 반격기가 잘 안어울린다. 그렇다면 슈퍼 아머는 어떨까! 싶어서 구현. 슈퍼 아머란 데미지는 고스란히 들어가지만 이를 견딘 채 공격을 수행하는 시스템을 말한다. 내 기억엔 스파3에서 처음 도입된 걸로 알고 있다. 느낌도 좋고 앨리스의 컨셉과도 어울린다. 어떻게 해서든 데미지를 넣겠다는 기술이다. 마음에 든다. 이제 애니메이션을 다듬어 보자.
어제는 지인의 사무실에서 대략적으로 완성된 클라이언트를 가지고 대전테스트를 했다. 역시 혼자할 때와는 다르다! 생각보다 많은 부분에서 문제가 일어났는데, 특히 방어 후 반격을 할 때 조작감이 상당히 좋지 않았다. 게다가 장풍은 왜 이리 안나가는지! 대시가 들어가 템포는 빨라졌는데, 맞고 누워있을 때의 시간은 그대로라 이것도 꽤 길게 느껴졌다. 다행인 점은 버그가 생각보다 적었다는 점이다. 대부분 시스템적 보완사항이다.
조이스틱으로 게임을 하니 커맨드가 생각보다 어려웠다. 난 어릴 적 오락실에서 스틱 깨나 가지고 놀았음에도 장풍이 어려운데, 초심자들은 더 하겠구나 싶다. 이래서 격겜이 고인물 소리를 듣나 보다. 좀 더 간결해야 한다. 2개 이상의 화살표커맨드를 최대한 1개로 줄여보는 작업을 해보자.
…
디지털 방식 스틱에서 대각선 이동이 안되는 현상이 있다는 제보가 들어왔다. 이것은 사실 한 번 테스트한 것이고, 스틱형 조이스틱을 사서 테스트를 한 결과 패드의 이상으로 결론 지었었다. 그런데도 제보가 들어온 것이 이상해서 한 번 더 면밀하게 검사를 해보니, 맙소사! GetAxis()에서 대각선 입력을 할 경우 0.7이 들어온다.
이는 0과 1로만 값을 받는 GetAxisRaw()도 마찬가지다. 때문에 반올림해주어야 한다. 테스트를 해보니 이제야 잘된다. 또 하나 깨달음을 얻었다.
앨리스의 커맨드를 단순화했다. 이제 →A를 누르면 기술이 나간다. 마찬가지로 어류겐은 ↑A이다. 다만 이렇게 되면 일반 공격과 키가 충돌하기 때문에 커맨드를 누른 후 0.2초안에 다음공격을 넣어야 한다. 이미 달래의 반격기가 이렇게 처리되고 있었지만, 좀 더 범용적으로 사용하기 위해 시스템을 개편했다. 커맨드표의 쩜은 누른지 0.2초가 되지 않은 상태라는 이야기이다.
일단 기술 넣기는 한결 쉽다.
닐리는 모으기가 관건인데, 모으기 후 방향을 반대로 꺾고 버튼을 눌러야 했다. ←(모으고) → A하면 파이어볼이 나간다. 모으기 캐릭터는 대체로 모으는 과정이 번거로운만큼 발동이 빠르다는 장점이 있다. 때문에 모으기는 유지하되, 이후의 커맨드를 없앤다. ←(모으고) (레버중립) A이다. 희안한 커맨드지만, 꽤 많이 고민한 것이다.
훨씬 쉽다!
달래와 오로라도 각자에 맞게 커맨드를 단순화했다. 이제 충돌만 나지 않으면 되는데… 이건 테스트를 해보기 전까지는 알 수가 없다.
8.3
공방의 주고받기를 위해 방어시스템을 손보던 중 카운터시스템의 결함을 발견했다. 지금까지 카운터는 상대가 공격이 끝난 후라도 데미지를 입을 당시의 스테이트가 공격형이면 무조건 카운터로 계산되게 되어있었다. 어쩐지 자주 뜨더라!
지금까지는 방어 후 딜레이가 너무 커서 공격을 자주 주고 받을 수가 없었다. 이 수치가 얼마나 컸냐면 기본 0.5초 후, 데미지에 따라 모두 밀릴 때까지(…) 방어한 사람은 아무 것도 할 수 없었다. 코드를 찾아보니 //임시라고 써있는 허망한 주석이. 아… 과거의 난 무슨 생각이었던 걸까.
작은 데미지는 0.1초, 큰 데미지라고 해도 0.3초후엔 반격할 수 있도록 수정했다. 일반 공격이 딜레이가 길기 때문에 아무 짓도 안하면 반드시 반격을 당하며, 연속기를 넣어야 커버가 된다. 그렇다면 이 연속기를 막는 상대쪽은 상대의 연속기가 끝날 때 쯤 반격을 펼쳐야 하는데, 그렇다면 또 이에 대한 훼이크로 앨리스의 3연타가 딜레이를 줄 수 있게끔 설계되었다.
8.4
리팩토링…리팩토링…리팩토링…내일 테스트 해보자.
…
자잘한 버그가 참 많았다. 대체로 커맨드 방식을 바꾼 데 대한 사이드 이펙트지만, 원래부터 문제를 품고 있던 버그들도 많았다. 다 된 것 같아도 테스트하면 문제가 나온다. 참 신기하다.
하는 김에 해상도 대응. 노트북에선 화면 비율이 양쪽 벽은 해상도에 따라 달라진다. 그런데 이렇게 되면 온라인 대전에 변수가 생긴다. ..음. 생각해볼 문제다.
8.6
테스트 플레이를 위해 간단한 AI를 구현. 수비적으로 방어하지만 공격하면 맞고 반격을 한다. 그리고 달래는 그 공격을 받아서 또 반격할 수 있다. 예상하지 못한 빠른 공격들이 생각보다 많은 버그를 쏟아냈고, 이것들을 고치면서 시간을 보냈다. 하다 보니 주 전략은 달려간 후 약손으로 공격을 잇거나, 장풍을 점프로 피해 위로부터 공격하거나…의 킹오파스타일이 됐는데, 일단은 마음에 든다. 실제 대전에서도 예상했던 그림이 나와줄 지 궁금해진다.
인풋매니저의 시스템은 각종 입력체계의 호환성이 좋다. 단, 이것은 방향키를 positive와 negative로 사용했을 경우다. 버튼이야 상관이 없지만, 이런 방향 입력 체계는 이제까지 써왔던 시스템과 충돌을 일으킨다. 지금까진 커맨드 입력을 위해 버튼을 누르는 방식을 사용했는데, 이걸 수정해야 할 것 같다. 이와 같은 정보는 아래블로그에 자세히 기술되어 있다.
방향키는 GetAxis()를 사용하고, 버튼은 조이스틱 버튼을 사용해야 한다. 일단 입력체계를 버튼이 아니라 Axis형태로 바꿔보자
요걸
요렇게
일단 버튼식에서 Axis형태로 바꾸는 건 크게 오래 걸리지 않았다. 그런데… 바꿔도 어쩐지 작동이 안된다. 무엇이 문제일까.
싶어서 살펴봤더니 이 프로젝트를 처음 시작할 때 InputManager를 설정하며 민감도를 0으로 맞춰놓았다. 일단 모르는 숫자는 전부 0으로 바꿔보았는데, 그러고도 잘 되니 이대로 고장난 채 있었던 것 같다. 이걸 0이상으로 돌려놓으면 된다.
조이패드 버튼은 A,B,X,Y 순으로 joystick button 0~3에 대응시키면 된다. A는 약펀치, B는 강펀치, X는 킥에 대응된다.
다 된 것 같으니 아내와 테스트. 이 짧은 영상을 찍는데도 버그가 3개나 나왔다.
7.31
조이패드 대응은 끝났지만 몇 가지 다듬을 것들이 있다. 현재 KO시 적용되는 줌블러는 멋있긴 한데, 피아식별이 힘들다는 단점이 있다.
줌은 히트영역이 중심이다. 따라서 가운데 부분은 줌이 약하다. 약한 김에 좀 더 약하면 안될까?length를 이용해 원을 만들고, 이를 적용치에 곱해주어 가운데 부분엔 왜곡이 덜하도록 수정해 준다.
박진감은 조금 떨어지지만, 그래도 이 쪽이 낫다. 더 선명하게 보일 수도 있으나 이 정도로 하자.
그래도 안보이는 건.. 뭐 어쩔 수 없다.
이제 빌드해보자. 에러가 없기를.
잘 돌아간다.
8.1
패드의 방향키를 아날로그 대응만 해놓았더니 디지털 방식의 방향키(옛날 방식)가 작동되지 않는다는 제보가 있었다. 게임 패드의 십자키가 이에 해당하는데, 문제는 격투게임의 조이스틱이 이 방식을 사용한다는 것이다. 시대가 흘렀어도 이 방식이 여전히 사용되고 있다니! 어쩐지 반가운 느낌이 들었다.
조이스틱은 아날로그만 구현했었는데, 그나마도 2P한정이었다. 이 참에 싹 정비를 해보자.
…버그 없네… 이상하다..
어쨌거나 버그는 없는데, 패드의 아날로그 스틱이 2개의 방향을 동시에 입력받지 못하는 문제가 있다. 이거 왜 이러지..
그래서 급하게 조이스틱 구입. 어제 오후에 주문했는데 오늘 아침에 배송이 왔다. 와..정말 빠르다. 예상대로 조이스틱은 디지털 방식이고, 0과 1밖에 받지 못한다. 대각선 입력이 잘 안되는 것은 패드의 문제였다. 스틱으로 하니 잘 된다.
오늘의 깨달음. 조이스틱 버튼은 joystick button 0~으로 된 키 값을 가지고 있다. 하지만 특정 조이스틱에 매핑하려면 아랫부분의 JoyNum을 지정하는 것으론 부족하고(애초에 저건 Type이 버튼이면 대응되지 않는다는 것을 뒤늦게 깨달았다.) 특정 조이스틱 번호를 기재해 주어야 한다. 때문에 joystick 1 button 0~이 된다. 2P는 자연스레 joystick 2 button 0~ 이 된다.
일반적인 조이패드의 버튼은 4개다. 요새는 트리거와 아날로그등이 추가되어 그보단 훨씬 많아지긴 했지만, 어쌔신 크리드의 튜토리얼을 진행하다가 손이 꼬이는 벽을 넘지 못한 후로 콘솔 게임은 그만두었다. 내게 있어 트리거는 단지 X+Y등의 겹버튼 숏컷용이며, 아날로그는 그냥 방향키의 다른 버전일 뿐이다. 따라서 조작은 4개의 버튼을 넘지 않게 기획되었다. 그것이 약손, 강손, 킥, 도발 버튼이다.
첫 계획은 도발을 추가하는 것이었지만, 작업이 너무 길어지고 있다. 따라서 이번 빌드에서는 도발은 제외하기로 하자. 게다가 도발은 캐릭터성을 상당부분 반영하는 것이어서 캐릭터 설정이 완전해진 후에 제작하는 편이 좋을 것 같기도 하다. 설정을 따지자면 승리와 패배도 마찬가지인데, 어쨌거나 이긴 티는 나야 하지 않을까. 하나는 제작하는 편이 좋겠다.
패배는 정확히 말하면 타임오버 시의 패배모션이다. 일반적인 경우의 KO패배라면 그냥 쓰러지고 끝난다.
늘 그렇듯 앨리스부터 시작. 대사는 “자, 또 한 건 끝났고!” 정도로 계획 중이다. 즉홍적으로 지은 대사가 용병 같은 느낌인데, 괜찮을지도 모르겠다.
손바닥을 치는 게 예상외로 어려웠다. 저건 브레이브 카노를 제작할 때도 어려웠던 기억이다.
패배 모션. 앨리스의 패배모션은 구상이 확실했기 때문에 제작은 쉬운 편이었다.
닐리의 승리 모션도 완료
완성은 했지만, 승리도 패배도 딱히 떠오르는 것이 없어 어정쩡한 구상 상태에서 진행했던 지라 크게 마음에 들지는 않는다.
달래는 인사하기 재활용.
패배모션도 완료
7.23
오로라 승리. 최신 유행 고속버스 춤.
패배모션도 완료. 이제 코드를 짜보자.
7.24
죽음을 처리하기 위해 데미지 처리 코드를 리팩토링 중. 이제 없을 줄 알았는데!!
오늘의 깨달음. 함수에 구조체를 인자로 전달하면 Value로 넘어간다. 난 당연히 데이터의 집합체니까 배열과 비슷하고, 그렇다면 당연히 Reference일 줄 알았는데!! 이것 때문에 한참을 헤멨다.
데미지 리팩토링이 생각보다 오래 걸렸다. 기존에 짜놓았던 코드들이 워낙 중구남방이었던 탓도 있지만, 스탯의 비주얼표현을 위한 hp변수를 그냥 체력처럼 써놓아서 엉뚱한 곳을 뒤지느라 시간을 써버린 탓도 크다. 급조한 코드는 반드시 벌을 받게 되어 있다! 주석을 잘 달아놓도록 하자.
죽음을 처리하는 것도 생각보단 복잡한 과정이었다. 딸피일 경우에 칼처럼 데미지를 처리하면 좀 인정없어보여서, 조금이라도 여유가 있다면 있는 피를 모두 반납하고 한 방정도는 버티도록 설계했다. 이로서 데미지는 75%, 방어는 50%의 피가 남아있다면 막타는 죽지 않고 견딜 수 있다.
그리고 이제야 비로소… 승리포즈를 처리할 수 있다. 아휴. 길었다. 다시 하던 걸 해보자.
7.25
일단은 KO처리. 완전한 승리는 퍼펙트를 의미한다. 한글로 쓸까 영어로 쓸까 고민을 많이 했는데, 긴 문장은 한글이 낫겠다는 결론을 내렸다. 이제 다음라운드로 넘어가야 한다.
7.26
다음 라운드로 넘어가기 위해선 먼저 승리를 기록해야 한다. 이를 위해 승리 라운드 정보를 게임데이터에 저장해야 한다. 그리고 이걸 명시적으로 표시하기 위해선 이긴 라운드를 알 수 있는 UI가 필요하다.
이는 러프 초창기부터 구상했던 모양이 있었으므로 디자인해서 배치해 둔다. 모델링은 어렵지 않은데 별도의 셰이더가 필요하다. 이겼을 때 깜빡거리며 그 존재를 과시할 필요가 있고, 돌아가며 보석느낌을 내려면 쬐그만한 게 빛벡터가 최소 2개는 필요하다. 하지만 스펙에 비해 셰이더 자체는 그리 어렵지 않을 것이다. 단순한 dot연산과 _Time을 이용한 깜빡임 정도면 충분하다.
다이아는 범용적으로 사용될 셰이더는 아니므로, 이렇게 모든 걸 정한 후엔 프로퍼티 정보는 코드 안 쪽으로 넣은 후 삭제해 주는 편이 최적화면에서 좋다.
오늘의 깨달음. StopAllCoroutine()으로 소멸되는 코루틴은 해당 Behaviour가 호출한 코루틴에 한한다. 이는 타클래스에서 코루틴을 public으로 설정해 호출하면 다소 귀찮아질 수 있다는 이야기가 된다.
무승부 처리. 이것도 조금 난이도가 있었다.
아직 불완전한 모습이긴 하지만, 일단락됐다. 이후의 작업은 버그로 간주하고 작업하기로 하자.
2P를 표현하는 가장 좋은 방법은 모델링을 별도로 하는 것인데, 물론 내겐 그럴만한 시간도 의지도 없다. 따라서 고전적인 방법으로 처리하기로 하자. 별 게 아닌 것에 고민이 많았다. 예를 들면 머리카락색을 유지할 것인지, 아니면 바꿀 것인지에 대해. 머리 속으로는 ‘머리카락이 바뀌면 캐릭터가 바뀌어버리는 게 아닌가?’라고 생각했지만, 정작 복장의 색을 바꾸고 나니 머리카락의 색깔이 복식과 어울리지 않는 것이다. 2P의 색은 캐릭터가 확연히 구분되도록 많이 바꿔야 하니, 애초에 1P에 맞게 설정된 머리카락색이 잘 어울릴 리가 없다. 그렇게 머리카락 색깔을 바꾸고 나니, 이번엔 눈동자 색이 또 거슬린다. 결국은 모두 바꿔는 편이 좋겠다는 결론을 내렸다.
다음 고민은 로딩방법에 관한 것이다. 색을 바꾸는 것은 머티리얼을 바꾸는 것이다.수정해 놓고 보니, 캐릭터에게 사용되는 9개의 머티리얼 중, 6개를 바꿔야 한다. 셰이더의 컬러를 바꾸는 것도 있지만, 대체로 텍스처를 통해 색이 바뀐다. 이것을 초반에 로딩해 놓을까? 아니면 중복 캐릭터를 고를 때 실시간 로딩할까? 캐릭터의 텍스처는 비교적 큰 편이니, 분명히 버벅임이 있을 것이다. 그렇다고 2P컬러까지 미리 로딩해 놓자니, 메모리에 불필요한 리소스를 너무 많이 올려놓는 감이 있다. 지금이야 캐릭터가 4명이기 때문에 별 문제가 없지만, 최후엔 13인까지 늘어날 것이고, 행여나 확장이라도 하게 된다면… 그냥 버벅임을 감수하고 실시간 로딩하는 편이 좋을 것 같다.
2P캐릭터 전체를 프리팹으로 만들어놓고 대체하는 편이 편할 것이나 파일이 많아지는 것이 싫으므로 셰이더 드라이버에서 머티리얼만 바꾸는 방법을 택하기로 하자.
파일명 뒤의 숫자를 붙인 건 2P를 고려했던 것은 아니었다. 그냥 리소스엔 전부 넘버링을 붙이는 오래된 습관이다. 좋은 습관이라고 생각한다. 후반으로 갈 수록 일이 편해진다.
오늘의 깨달음. 인스턴싱된 오브젝트의 머티리얼을 바꾸려면 SetMaterials()를 사용해야 한다. 그냥 materials[n]을 바꾼다고 되지 않는다.
…아.. 보호색이 따로 없네. 너무 묻혀서 피아식별이 좀 힘들 것 같다. 채도를 좀만 올리자.
이즈 본거지 