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
닐리의 대시모션을 작업하던 중, 여차저차해서 오로라의 데이터를 살펴보게 되었는데 무언가 크게 잘못돼 있었다. 이게 지금까지 돌아갔다고…?! 그래서 원인을 수정하고 블렌더로부터 내리 수정. 이걸 살펴보려던 건 아닌데, 덕분에 큰 버그를 잡았다. 시간은 버렸지만 보람은 있었다. 가만, 그럼 시간을 버린 게 아닌가?
얼마 전, 앨리스의 스킬이 완성되던 시점에 지인 사무실에서 간이 대전(?)을 해본 적이 있다. 원래는 혼자서 할 수 없는 몇가지 사항을 확인하기 위해 진행한 테스트였지만, 한 번씩 키보드에 손을 댄 후엔 ‘왜 대시 없어?’라는 반응이 가장 먼저 자연스레 튀어나왔다.
처음부터 대시를 넣을 생각은 아니었지만, 참여자 모두가 대시를 원했으므로 어느 정도 궤도를 수정할 예정이다. 오로라의 작업이 끝난 이 시점의 다음 작업은 버그픽스 후 신캐제작이었지만, 이를 잠시 미뤄두고 실제 대전에 적합한 게임의 형태를 만드는 편이 더 좋다고 생각되었으므로 체력바를 달자. 승리포즈도 필요할 것이다. 좀 이르지만 캐릭터 선택화면도 필요하다.
필요한 모션은 상당히 많다. 이젠 인게임 모션과 아웃게임 모션을 분리해야 한다. 일러스트를 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업계라고 하면 아주 놀라운 최첨단의 업무처리방식을 갖추고 있을 것 같지만, 내막을 살펴보면 대부분 누군가의 그림자 노동으로 이루어져 있다.. 자동으로 되는 건… 유감스럽지만, 거의 없다. 개발자란, 그냥 최신식 기술을 사용하는 일꾼일 뿐이다.
이즈 본거지 