일반적인 조이패드의 버튼은 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]을 바꾼다고 되지 않는다.
…아.. 보호색이 따로 없네. 너무 묻혀서 피아식별이 좀 힘들 것 같다. 채도를 좀만 올리자.
이제 캐릭터를 선택했을 때와 등장씬의 애니메이션을 만들차례다. 그런데 이걸 하기 전에 애니메이션을 UI에서 좀 더 쉽게 사용할 수 있도록 코드를 리팩토링 해야 했다. 늘 그렇듯이 버그가 잔뜩 나왔고, 이걸 수정하느라 반나절이 걸렸다.
캐릭터를 선택했을 때의 모션은 확실한 피드백을 위해 필요하다. 이 때 음성도 나와야 하지만 그것은 먼 훗날의 일이다. 그보단 입의 셰이더가 당면한 문제를 해결하여야 한다. 지금까지는 작아서 보이지 않던 입이 캐릭터를 확대해 보니 블렌딩되며 문제가 생긴다. 세상에! 블렌딩이 문제가 되다니! 이걸 어떻게 해결하지…
이걸 해결하며 커브는 애니메이션 데이터에 포함되어 있다는 걸 처음 알았다.
챗GPT는 천재야!
이 방법은 일시적인 것이 아니라 유니티의 데이터를 건드는 것이다. 때문에 빌드가 잘될지는 테스트가 좀 필요해보인다.
빌드 에러가 난다. 예상하지 못한 문제지만, 해결책은 대충 예상이 된다. 스크린샷을 찍을 때와 마찬가지로, UnityEditor네임스페이스를 사용한 코드는 에디터 전용이다. 따라서 스크립트가 Editor폴더에 포함되어야 한다. 이는 곧 게임코드에서 파일을 분리해야 함을 의미하는데, 데이터를 한 번만 베이킹 해주면 되는 것이라 어차피 그럴 생각이었으므로 이 참에 분리하기로 하자.
#if UNITY_EDITOR
using UnityEditor;
using UnityEditor.Animations;
#endif
…였는데 완전히 있고 있었다. 이런 방법이 있었지…하지만 여전히 분리하는 것이 효율적이므로 분리하자.
어…음… 그런데 이렇게 하니 Animator를 변수로 받을 수가 없네…?!
따로 뗐더니 되긴 했는데, 이거 빌드가 될까…몇가지 문제가 있었지만 잘된다.
베이킹할 때만 저걸 켜주도록 하자. 별로 세련된 방법은 아니지만, 모로 가도 서울만 가면 되니까.
눈썹이 왜 이렇지?!
요런색이어야 되는데! 셰이더가 이상하다.
결국 큐문제이긴 한데, 과거의 나는 큐를 왜 이렇게 구성했었을까…
각 캐릭터의 선택 모션들을 제작. 다음은 등장 모션들이 필요하다.
7.19
Awake()는 스크립트가 실행되자마자, 혹은 enable이 켜지자마자 실행된다. Start()는 한 프레임 늦다. 시간으로 따지면 1/60초다. 컴퓨터는 이렇게 짧은 시간동안 엄청나게 많은 명령을 수행한다. 이 때문에 컴포넌트 대입식이 Start()에 있었다는 사실은, 많은 버그를 빚어내기에 충분한 원인이 됐다. 개발은 늘 시행착오의 연속이다. 어디 개발뿐이랴. 인생 또한 그렇다. 하지만 지금은 설익은 철학 이야기를 적을 땐 아닌 것 같고, 지금까지의 코드를 리팩토링하는 데 시간을 쓰는 게 더 적절해 보인다.
사실 지금까진 Awake()를 쓰는 일을 가급적 피했는데, 이는 에러가 날 때 Start()에 있는 내용을 Awake()로 옮기면 해결되는 경우가 많았기에 일종의 보험으로 남겨두고 싶은 알랑한 마음이었다. 컴포넌트의 대입과 새로운 변수의 선언은 Awake()로 옮기고, 타클래스를 참조해야 하는 요소들은 Start()에서 처리하도록 바꾸자. 기초를 좀 더 탄탄히 다지고 가는 편이 좋겠다. 그리고 경험상, 며칠 걸릴 것 같은 이런 일들은 작정하고 덤비면 의외로 빠르게 끝난다.
Dotween도 코루틴이다. 하지만 StopAllCoroutine()으로 모든 코루틴을 제거했음에도 Dotween이 자꾸 오류를 냈다. 수많은 삽질 끝에 이는 Dotween이 독자적인 코루틴을 사용하기 때문으로 밝혀졌다. Dotween의 코루틴을 제거하려면
DOTween.KillAll();
을 사용해야 한다.
휴. 리팩토링이 끝났다. 모든 일의 시작은 저 실루엣이었다. 실루엣은 별도의 메쉬를 사용하는데, 얘는 UI의 영역이라 실제 게임까지는 가지고 오면 안된다. 때문에 게임FSM이 가동되기 전 얘를 정리해주어야 했는데, 이것이 실루엣을 별도로 관리하지 않는 코드설계 상 쉽지 않았다.
7.20
길었던 캐릭터 선택이 거의 끝나간다. 이제 같은 캐릭터를 골랐을 경우, 색을 바꿔주는 처리만이 남아있다. 이건 내일 하도록 하자.
기본 틀은 완성이 됐다. 이제 이걸 Battle로 넘겨야 한다. 싱글턴 인스턴스에 선택정보를 저장하고 로딩 씬에서 사용할 리소스들을 로드하여야 한다. 같은 캐릭터를 선택했을 땐 나중에 선택한 플레이어의 캐릭터 색도 달라야 하고, 시작 시 등장모션도 출력해야 한다. 모두 안해본 것들이다. 공부를 해보자.
싱글턴 인스턴스 게임 오브젝트를 하이라키에 포함시키고, 이를 다시 로드하면 해당오브젝트는 중복이 될까? 아니면 그 정도는 알아서 거를까? 테스트를 해보자.
알아서 거른다. 이것은 복사가 아니기 때문인 것으로 보인다.
싱글턴패턴으로 제작된 GameData와 PoolManager를 제작해서 장착
이제 캐릭터는 Select화면이 아니라 로딩프로세스에서 로드해서 들어간다. 메모리에 올린 후엔 확실히 버벅임이 없다.
그리고 그와 별개로 싱글턴은 굉장히 편하다! 배우기 싫어서 미적미적 미뤄놨었는데, 좀 더 빨리 배워둘걸.
씬간에 게임의 정보를 공유하고 이를 처리. 1/3정도 된 것 같다. 아직 할 일이 많다.
7.15
이펙트도 기존의 매니저를 사용하고 싱글턴화 시킨다. 매니저는 선택 때는 공용이펙트를, 전투진입 때엔 캐릭터 이펙트를 로드해 둔다. 2번에 나누어 로드하는 이유는 속도때문이다. 물론 한 번에 로드해봤자 1초도 안되긴 하지만, 눈깜짝할 새에 로드되면 좋겠다. 이펙트를 몇 개를 사용할지는 알 수 없지만, 하나만 로드해두어도 어쨌거나 메모리에 올리는 것이라 버벅임이 훨씬 적을 거라 기대한다.
이 쯤에서 빌드 테스트
잘 된다. 야호.
게임매니저의 1P, 2P의 변수를 따로 만들어둔 것을 배열로 정리했다. 이제 FSM이나 게임매니저는 정말로 손 댈일이 많지 않을 것 같다. 물론 미래는 알 수 없지만..부디 그렇게 되기를
다음은 게임진입 연출씬이다. 본격적인 게임에 앞서 캐릭터가 준비대사를 하는 구간이다. 이 부분에선 캐릭터를 돋보이게 하고 싶은 마음이 있기 때문에, 별도의 배경이 필요하다.
속도선 셰이더는 전에도 한 번 만들어본 적이 있기 때문에, 쉽게 만들 수 있다. 이제 이 앞으로 캐릭터나 나와야 한다.
7.16
캐릭터 등장 러프. 홍코너~!! 앨리스! 청코너~!!도 앨리스!!
그 다음은 화면이 걷히며 캐릭터가 달려나오고 라운드1 – 파이트로 이어져야 한다.
저 번개가 파지직.하고 빛나려면 … 또 번개 셰이더가 필요하겠다. 기본은 cutout과 같고, UV를 빠르게 흘리면 될 것이다. 만들어 보자.
일단 러프를 해보자. 처음엔 플레이어블 8명이지만, 나중에 사천왕 포함해서 12명으로 확장될 것이다. 하지만 1회 클리어까진 8명까지만 보여줄 예정이므로 이에 맞춰서 디자인을 한다.
그런데… 음.. 넣을 게 뭐 별 게 없다…. 느무 심심한 느낌인데..뭘 넣지
디자인하다보니 모노톤이 더 좋아보인다. 역시 디자인에 대해 뭘 모르면 흑백쓰라는 선인의 말을 되새겨야 할 때.
캐릭터 선택창은 이 쯤에서 마무리. 그 다음 절차는 싸울 배경을 소개하고, 화면 전환한 후에 캐릭터들이 등장하고…같은 과정을 거칠 예정이다.
7.11
언리얼은 뷰포트 스샷 기능이 제공된다. 언리얼은 이미 실시간 렌더링을 영화에 사용할만큼 뷰포트 렌더링이 뛰어나기 때문이리라. 하지만 유니티는 이게 없다. 배경을 찍어야 되는데, 뷰포트 렌더링이 없다… 난감한걸.
혹시 내가 못찾는 것은 아닐까? 싶어서 챗GPT에게 물어보니 렌더타깃을 이용해 찍으라는 조언을 해준다. 물론 코드와 함께 친절한 사용설명서까지 덧붙여줬다.
using UnityEngine;
using UnityEditor;
using System.IO;
public class ViewportScreenshot : MonoBehaviour
{
public Camera cameraToUse; // 스크린샷을 찍을 카메라
public int resWidth = 3840; // 원하는 해상도 너비
public int resHeight = 2160; // 원하는 해상도 높이
[MenuItem("Tools/Take Screenshot")]
public static void TakeScreenshot()
{
ViewportScreenshot instance = new GameObject("ViewportScreenshot").AddComponent<ViewportScreenshot>();
instance.CaptureScreenshot();
DestroyImmediate(instance.gameObject);
}
public void CaptureScreenshot()
{
if (cameraToUse == null)
{
cameraToUse = Camera.main; // 기본 카메라 설정
}
RenderTexture rt = new RenderTexture(resWidth, resHeight, 24);
cameraToUse.targetTexture = rt;
Texture2D screenShot = new Texture2D(resWidth, resHeight, TextureFormat.RGB24, false);
cameraToUse.Render();
RenderTexture.active = rt;
screenShot.ReadPixels(new Rect(0, 0, resWidth, resHeight), 0, 0);
cameraToUse.targetTexture = null;
RenderTexture.active = null; // 메모리 해제
Destroy(rt);
byte[] bytes = screenShot.EncodeToPNG();
string filename = ScreenShotName(resWidth, resHeight);
// 디렉토리 생성
string directoryPath = Path.GetDirectoryName(filename);
if (!Directory.Exists(directoryPath))
{
Directory.CreateDirectory(directoryPath);
}
File.WriteAllBytes(filename, bytes);
Debug.Log($"Screenshot saved to: {filename}");
// 에디터 씬에서 이미지 확인
AssetDatabase.Refresh();
}
public static string ScreenShotName(int width, int height)
{
return string.Format("{0}/Screenshots/screen_{1}x{2}_{3}.png",
Application.dataPath,
width, height,
System.DateTime.Now.ToString("yyyy-MM-dd_HH-mm-ss"));
}
}
이걸 그대로 유니티에 넣고 작동시키니… 와. 정말 된다.
전이라면 이걸 손으로 찍어서 이어붙이고 난리도 아녔을텐데…와. 고마워라.
캐릭터를 고르면 이렇게 배경이 나오고 화면을 왼쪽에서 오른쪽으로 쓸고 간다.
구상은 끝났고, 할 일이 남았다. 포트레이트 애니메이션을 만들어 보자.
이걸 제작하고 있노라니 의문이 들었다. 이게 게임에 잘 맞을까?…
더미 작업 없이 바로 실제 리소스 제작을 들어가는 것이 장님 코끼리 만지는 기분이다. 그럼 구현이 먼저다. 구현부터 하자.
새로운 씬을 세팅 중.
뒤로 흐르는 배경과 커서는 별도의 셰이더가 필요하다. 틀은 잡았고, 이제 코드를 짜보자.
DoTween은 UI프로그램을 할 때 가장 먼저 친해져야 할 애드온이다. 코드기반은 무료고 비쥬얼 스크립팅은 유료인 듯?
얼핏 보기엔 쉬울 것 같다. 그냥 많이 맞으면 별이 핑핑 돈다. 스트레스 변수를 추가하고 데미지를 입을 때마다 쌓이지만 시간이 흐르면 자연스레 깎인다. 하지만 일정 수치를 넘으면 다운되고 일어설 때 무방비 상태가 된다. 하지만 이 때 버튼을 마구 누르면 좀 더 빨리 풀려날 수 있다. 생각만큼 쉬울까. 한 번 해보자. 일단 모션부터 만들자.
체력바는 2중 슬라이더가 되어야 하기 때문에 셰이더를 새로 짰다. 기본적인 체력차감 코드도 마무리했다. 콤보가 끊기지 않으려면 1초안에 데미지를 넣어야 하며, 그 이상 지연되면 콤보가 끊기며 데미지가 확정된다.
여기까지는 어렵지 않다. 이제 기획이 좀 필요하다. 데미지는 기본적으로 정해진 숫자는 있지만 상황에 따라 조금씩 보정을 받는다.
카운터일 경우.
연속기일 경우.
타격형 잡기일 경우.
카운터를 판단하는 기준이 좀 어려워 보인다. 공격이 들어가는 타이밍은 이벤트에 의해 제어된다. 그렇다면 스테이트에 공격력이 붙어있고 아직 이벤트를 만나지 않았을 때를 카운터 유효시점이라고 보는 것이 맞는가? 그렇다면 발동이 느리다면 카운터가 쉽다는 이야기가 된다. 흐음. 말 되네?! 해보기로 하자.
7.8
카운터는 구현은 했으나 제대로 작동할 지 모르겠다. 어떤 구멍이 있을지 테스트를 하며 알아보자
콤보는 2콤보부터 10%씩 깎이는 데미지 보정이 있다. 이렇게 되면 짠손을 중간에 섞는 게 오히려 데미지를 깎아먹는 결과를 낸다. 하지만 SuperAttack은 보정하지 않는다. 달래의 경우 많이 때리긴 하지만, SuperAttack은 마지막의 회전차기 뿐이다. 일단은 괜찮아 보인다.
잡기의 데미지처리는 또 별도이다. 일단 비교적 간단한 히트형 잡기부터 처리.
타격형잡기는 버튼을 마구 누르면 좀 더 빨리 풀린다.
초필게이지 처리도 완료. 아. 그런데 때리는 애가 차야지…거꾸로 찬다.
체력바는 얼추 다 된 것 같다. 시간을 줄이는 건 일도 아니지만, 씬로딩과 승패가 들어가야 의미가 있을 것이다. 그 다음은 스턴을 추가해 보자.
UI랄 게 별로 없다보니 폰트가 중요하다. 그래서 이리저리 알아본 결과 산돌폰트에 괜찮은 유료폰트를 발견했다. 그런데 저작권에 대한 해설이 불분명하다. 폰트란 건 한 번 받아 설치하면 영구히 사용할 수 있는 것인데, 그렇다면 다운로드 후 구독을 끊으면 어떻게 되는 거지? 게임 출시할 때 또 결제해야 하는 건가? 서비스하는 내내 폰트가 보일텐데, 그럼 계속 구독을 끊으면 안되나?
폰트만큼 딴지를 많이 거는 분야도 드물다. 그러다 보니 심지어 이걸 빌미로 사기를 치는 집단도 있다. 마치 공인된 기관인 것처럼 속여 돈을 뜯으려 하는 것이다. 그러니 속편하게 그냥 무료폰트를 쓰도록 하자. 요새는 무료폰트도 예쁜 것이 참 많다.
Backstep은 뒤로 폴짝 뛰는 모션이지만 SubState를 Jumping으로 두면 안된다. 비주얼에 따라 백덤플링같은 것이 더 어울릴 수 있기 때문.
당연한 이야기지만, 일단 모션이 필요하다. 만들자.
모션 데이터는 액션매니저에 의해 그룹화해서 관리하고 있다. 기존까지는 점프중이 아닐 경우의 이동이 걷기뿐이었으므로 Stand에 포함되어 있었지만, Moving으로 새 카테고리를 만들어 관리하는 편이 좋겠다. 이렇게 모션별로 짤라 카테고리를 만드는 이유는 익스포트 속도때문이다. 데이터가 크다보니 각 그룹별로 익스포트하는데 꽤나 오랜 시간이 걸리는데, 이걸 자주 해야 한다. 데이터가 단순하면 하나에 묶는 편이 여러모로 좋다.
한 캐릭터에게 필요한 모션은 이렇게나 많다. 나도 몰랐다. 이렇게까지 많아질 줄은.
이제 코드에 대시를 추가해야 하는데, 코드가 다소 엉망이라 정리를 했다. 그리고 정리 수납하고 흐뭇해하는 가정주부의 마음을 이해하게 되었다.
7.2
세상에! 단순히 대시를 넣으려 했던 계획은 감속부분의 문제로 인해 코드 리팩토링으로 번졌다. 솔직히, 쉬울 줄 알았다. 그냥 커맨드 앞앞, 뒤뒤만 추가하면 되는 일 아닌가?! 그런데 기존 코드가 이를 허락하지 않았고 이동관련 코드를 상당 부분 뒤엎어야 했다.
여전히 수정 중이다. 하지만 뜻이 있는 곳에 길이 있다고 했던가? 기존까지 sin함수로 처리하던 코드를 Lerp로 바꾸니 훨씬 간결하고 깔끔해졌다. 처음부터 이랬어야 했지만, 원래 인생이란 시행착오의 연속 아니던가. 허허.
야호.. 빠르다. 버그도 함께 찍혔네.
지금까지는 캐릭터가 그렇게 빠르게 움직일 필요가 없었기 때문에 타격판정을 실제 충돌에도 사용하고 있었다. 이것이 문제가 있던 것은 아니지만 컬리전이 계속 형태가 변하다보니 다소 불안한 느낌은 있었는데, 이동속도가 빠른 모션을 넣으니 확연히 드러난다. 아무래도 이동형 컬리전을 추가하는 편이 좋겠다. 이 쪽이 속도도 더 빠르기 때문에 최적화에도 도움이 된다.
7.3
그런데 이게 쉬운 일이 아니었다. 이번에도 진행하며 여러가지 일을 알게 됐는데, 박스컬라이더가 단순히 트랜스폼을 바꾼다고 업데이트되지 않는다는 사실이다. 컬라이더의 업데이트 주기는 fixedUpdate()를 따른다. 당연하지. 물리니까! 이걸 가지고 반나절을 헤맸는데… 어째 날이 갈 수록 버그 하나 잡는데 걸리는 시간이 늘어나는 것 같다.
여튼 수정완료. 이동형 컬라이더는 이제 단순한 사각박스를 따른다. 충돌검사 부하가 줄었기 때문에 퍼포먼스가 약간 더 좋아졌을 것이다.
퍼포먼스도 좋아졌겠다, 컬라이더 클래스를 수정하는 김에 컬라이더를 팔에 분배했다.
피격 컬라이더는 공격시에만 영향을 받는다. 이전엔 퍼포먼스를 위해 팔은 충돌에서 제외했었지만, 이제는 맞는다. 이렇게 되면 마법사이면서 팔로 장타를 날리는 닐리가 조금 불리하다. 무기는 피격 충돌에서 제외되기 때문.
대기자세도 커서 맞기 쉽다.
점프 후 바로 백스텝하면 반대로 뛰는 버그도 수정했다.
7.4
닐리의 대시모션을 작업하던 중, 여차저차해서 오로라의 데이터를 살펴보게 되었는데 무언가 크게 잘못돼 있었다. 이게 지금까지 돌아갔다고…?! 그래서 원인을 수정하고 블렌더로부터 내리 수정. 이걸 살펴보려던 건 아닌데, 덕분에 큰 버그를 잡았다. 시간은 버렸지만 보람은 있었다. 가만, 그럼 시간을 버린 게 아닌가?
