가장 키가 작은 오로라는 잡히기 작업에서 키를 맞추어주어야 하기 때문에 일이 많다. 그래도 닐리보다야…
다른 게임들은 이런 잡히기 모션들을 공유해 쓰는 것처럼 보이던데, 어떻게 한 거지..
11.25
잡히기 작업이 생각보다 길고 코드 이슈가 없다. 흐음. 그렇다면 네트워크 작업을 위해 11월말까지 코드를 넘겨주는 편이 좋으니 코드작업을 선행하는 편이 좋겠다.
스턴은 버튼을 마구 누르면 빨리 풀 수 있다. 이는 원래 적용되어 있던 것이지만, 애니메이션의 속도를 조절해 명시적으로 알 수 있도록 변경
타격잡기의 경우 로직을 조금 변경했다. 이 때의 애니메이션 속도는 상대의 버튼연타 유무에 따라 느려질 수도 빨라질 수도 있다. 내가 더 많이 누르면 애니메이션 속도가 빨라지고, 상대가 더 많이 연타하면 느려지는 식. 여기서 일정 수준이하로 느려지게 된다면 좀 더 일찍 타격에서 풀려나게 된다.
프리오리가 연타했을 경우
Nate님의 의견대로 프리오리의 연계기를 하단으로 변경. 첫번째 공격은 OverHead, 두번째 공격은 Down이다. 즉, 첫번째는 서서, 두번째는 앉아서 막아야 한다. 덕분에 꽤 까다로운 조합이 됐다.
그 외의 수정사항
한여름 스킬들 상향
스턴 시 트레일이 튀는 현상 수정
KO시 줌블러 약화
작업보드에 적어둔 내용들은 비주얼과 관련된 내용을 제외하곤 모두 끝났다. 하지만 이것이 끝이 아니다. 이제 오래 전에 온 리포트를 점검할 시간이다.
앵커가 잡힌 UI라면 일반 position보단 AnchoredPosition의 부호를 반전시키는 쪽이 제어하기 더 쉽다는 사실을 깨달았다! 내친 김에 이것도 손을 보자.
키 바인딩 작업 중 적어놓을 것.
XBox360패드
Back – button6
Start – button7
스틱형 장치에선 Start가 작은 버튼이다. 7번버튼이 6으로 작동한다.
리팩토링한 코드에서도 조이스틱이 잘 작동하긴 하는데, 자료를 좀 찾아보니 InputSystem이란 게 새로 나왔다고 한다. 지금 와서 손보기엔 좀 늦은 것 같고 다음에 자료를 찾던가 말던가 하자.
키바인딩을 처리하기 위해 키입력을 변경하는 시스템과, 이를 저장하는 코드를 제작…하기 위해 또 한번 대대적인 리팩토링. 이번 리팩토링 중 안 사실이 있는데, InputManager의 Vertical은 위아래가 거꾸로 입력된다. 명백한 버그같은데 발견이 늦어져서 대처를 못한 느낌이다. 이게 왜 버그라고 생각되냐면 버튼형 스틱은 위아래가 제대로 입력되기 때문이다. 원인을 찾느라 한참걸렸는데 새 프로젝트를 만들어 확인한 결과 기본값이 위아래 인버스가 체크되어 있다. 에라이…. 어쨌거나 키바인딩 시스템의 기본은 완료했다. 에디트 버튼을 누르고 순차적으로 사용할 키를 누르면 된다.
핵심적인 구현은 끝났다. 이제 예외처리를 하고, UI를 붙여야 한다. 현재값을 기본값으로 돌리는 기능도 필요하고, 입력 중간에 취소할 수 있는 기능도 있어야 한다. back버튼을 누르면 게임을 종료 처리(최종 버전에서는 타이틀로 돌아감)하는 기능도 넣을 것이다
11.15
지스타 구경으로 인해 이틀간 부재였다. 11월이지만 부산은 따뜻했다. 그런데 서울 올라와 보니 서울도 따뜻했다. 그냥 따뜻한 시기같다. 다음 주부터 다시 추워진다고 한다.
키 바인딩의 핵심구현은 끝났지만, 예외처리와 마무리를 해주어야 한다. 신경쓸 게 많으니 목록을 적어두고 하나하나 처리해보자.
지정이 모두 끝나면 0.8초간 화면을 유지하고 있다가 화면이 닫힘
동시에 지정이 끝나면 키입력을 더 이상 받지 못하도록
키를 기본값으로 초기화하는 기능
스틱은 위로, 키보드는 F3, F4
지정할 수 있는 키에서 예외키를 제외
키보드 : 펑션, ctrl, alt, window키등
조이스틱 : 0~5번버튼까지만.
한 번 지정한 키를 다시 지정하지 못하도록 중복검사
조이스틱 자동감지
모두 처리했으나, 자동감지는 조금 위험하다. 행여나 게임기에서 키보드가 잡힌다면 달리 바꿀 방법이 없다. 따라서 이건 기기체크를 해서 스팀덱같은 게임기에선 1,2P를 모두 조이스틱으로 기본설정하는 편이 합리적으로 보인다. 다만 이건 아주 먼 이야기이므로 지금작업에서는 제외하자.
이제 UI가 필요하다. 키 설정은 조이스틱부와 키보드로 나뉜다.
11.16
작은 창에 사용되는 글씨가 꽤 굵게 느껴져서 얇은 글씨가 있으면 좋겠다고 생각했다. 어차피 앞으로 대사창이나 작은 UI에 사용해야 하므로, 미리 폰트를 만들어두는 편이 좋겠다.
Window – TextMeshPro – FontAssetCreator
이런 건 자주 안쓰는 기능이라 미리 세팅값을 저장해두는 편이 좋다. 특히나 한글폰트의 커스텀 레인지는 필요할 때마다 찾으니 박제해 두자.
32-126,44032-55203,12593-12643,8200-9900
윗쪽의 얇은 글씨가 새로 만든 폰트이다. SDF의 특성인가? 포토샵보다 한단계 굵게 나오므로, 보이는 것보다 한단계 낮은 얇기로 폰트를 만드는 편이 좋다.
폰트를 바꾸는 김에 이제 ‘우리(US)’가 아닌 진짜 VS로 변경.
11.17
비주얼을 붙이기 위해 셰이더를 짜고… 붙이고 연출하고…이것도 생각보다 꽤 걸리는 작업이었다. 총5벌의 키맵을 저장한다.
혼자 키보드를 쓸 때
둘이 키보드를 쓸때 2벌
조이스틱 2벌
싱글플레이는 키배열을 편하게 하기 위해 별도로 취급한다. 이걸 위해 구조를 다르게 짜고 예외를 처리하느라 꽤 오래 걸렸다. 힘들 거라 생각했고, 예상만큼 힘들었다.
자, 이제 다음은 뭐지?
11.18
닐리의 추가스킬, ↑A or B (BroomAttack)의 러프한 구현.
상승 후 A를 누르면 직선으로 날아가고
B를 누르면 하강한다.
방향 전환 딜레이가 길어서 콤보용으로는 못쓴다… 싶었는데 운좋으면 연결이 되기도 하네?!
11.20
이펙트를 만들던 도중 ‘이 셰이더를 어디에 썼더라…’싶어서 검색하는 기능을 찾으려 했지만 유니티에는 그런 기능이 없다. 이런 점은 레퍼런스 참조를 직관적으로 보여주는 언리얼이 좋다. 하지만 코파일럿에게 부탁하니 무려 툴을 만들어준다.
using UnityEngine;
using UnityEditor;
public class ShaderUsageFinderWindow : EditorWindow
{
Shader targetShader;
[MenuItem("Tools/Shader Usage Finder")]
public static void ShowWindow()
{
GetWindow<ShaderUsageFinderWindow>("Shader Usage Finder");
}
void OnGUI()
{
GUILayout.Label("🔍 셰이더 사용 머티리얼 찾기", EditorStyles.boldLabel);
targetShader = (Shader)EditorGUILayout.ObjectField("Target Shader", targetShader, typeof(Shader), false);
if (targetShader != null)
{
if (GUILayout.Button("사용 중인 머티리얼 찾기"))
{
FindShaderUsage(targetShader);
}
}
}
void FindShaderUsage(Shader shader)
{
string[] materialGuids = AssetDatabase.FindAssets("t:Material");
int count = 0;
foreach (string guid in materialGuids)
{
string path = AssetDatabase.GUIDToAssetPath(guid);
Material mat = AssetDatabase.LoadAssetAtPath<Material>(path);
if (mat != null && mat.shader == shader)
{
Debug.Log($"✅ 사용됨: {path}", mat);
count++;
}
}
if (count == 0)
{
Debug.LogWarning("해당 셰이더를 사용하는 머티리얼이 없습니다.");
}
else
{
Debug.Log($"총 {count}개의 머티리얼이 해당 셰이더를 사용 중입니다.");
}
}
}
AI를 뭘 쓰던 유니티와 관련된 질문은 정확도가 꽤 높은 편이다. 아마도 자료가 많아서 그런 것 같다. 어쨌거나 이를 바탕으로 불필요한 코드를 지운다.
이펙트까지 완성. 빗자루 공격은 중간에 2번까지 좌우 방향전환을 할 수 있다. 이걸 직선이동과 하강코스를 나누어 원하는대로 사용하려니 생각보다 꽤 힘들다. 숙련이 좀 필요한 기술이 되지 않을까.
스샷을 찍고 나니 역방향 먼지가 방향이 틀렸다는 걸 깨달았다. 일단 이걸 수정하고…
일은 왜 할 수록 늘지…?
KO시의 줌블러에 가시 효과를 추가 중. 확실히 셰이더 그래프는 언리얼에 비해 갈 길이 멀다. 무엇보다 무선 노드부터 좀 지원했으면 좋겠다.
요게 기존
요게 수정. 어째 박력이 더 떨어져 보인다..?!
노드정리를 하고, 텍스처를 다듬고.. 뚜닥뚜닥. 최종형태. 셰이더 그래프가 익숙치 않다보니 생각보다 시간이 걸린다. 포스트프로세스 셰이더 작업은 몰아서 하는 편이 좋겠다.
도레미의 초필에 관한 가장 많은 요청은 KO시엔 납작한 상태를 유지해달라는 것이었다. 이걸 구현하려면 코드는 어려운 게 없는데 데이터를 수정해야 했다. 지금은 종이가 완전히 아래로 깔리기 전에 회복하는 걸 전제로 애니메이션을 제작했는데, 이를 완전히 바닥에 깔리도록 수정해야한다. 그런데 이 작업을 하던 도중, 그림자가 90도 돌아가 출력되고 있는 현상을 발견했다. 수정하지 않았다면 큰 버그를 놓칠 뻔 했다.
납작이 잘 안보이기 때문에 눈속임이 조금 필요하다. 때문에 세로스케일을 3배로 늘려찍는다. 위에서 보면 아래와 같은 그림이 된다.
그 외의 문제들을 해결
스트레스 수치가 스턴을 거칠 때마다 10씩 상승하도록 수정했다. TOD를 막기 위한 조치
잡기 후 좌우가 반대로 입력되는 현상을 수정
달래의 설풍 후 달려가기를 막음. 무한 [달려가기-약손-설풍] 방지용
그레텔의 벽점프가 정방향일 때 반대쪽으로 점프하지 않는 문제를 수정
…를 하다보니 새로운 문제들이 속속 추가되어서 다시 수정 중. 대부분 입력시스템 변경에 따른 사이드 이펙트이다.
잡기 시에 입력키에 따른 방향전환 삭제
이는 0.26버전에선 작동하다가 0.45에서 버그가 있어 작동이 되지 않고 있었는데, 고치고 나니 캐릭터의 위치가 바뀌는 것이 별로 마음에 들지 않아서 삭제
11.6
이제 도레미의 휠윈드는 사소한 장풍을 피할 수 있다. 어쩐지 그래야 할 것 같았다.
프리오리의 초필은 점프과정이 불필요한 것 같아서 삭제. 점프가 없으므로 커맨드도 ↓(모아서)↑B에서 ←(모아서)→B로 변경
그레텔은 또 너프. 워프공격의 딜레이를 5프레임(0.167초 정도) 늘렸다.
그레텔의 강발을 무한히 쓸 수 있다는 제보가 있었는데, 맙소사! 방어 코드에 심각한 결함이 있음을 발견했다. 처음 동작을 디자인할 때, 큰 데미지의 전체 모션길이는 20frm으로 설정했지만, 무방비로 맞을 수 있는 시간(safeTime)은 10frm으로 설정했다. 때문에 딜을 넣으려면 10frm내에 해결해야 한다. 이 시간을 넘기면 데미지 모션 중일지라도 방어를 할 수 있는데, 리팩토링을 하며 부호가 잘못 들어가 있었다. 때문에 실제로 데미지 액션 중엔 계속 처맞는 버그가 있었고, 이것이 대부분의 공격이 20frm이하인 그레텔을 탑티어로 만드는데 기여했을 것이다.
그래서 이를 수정. 이제 무한히 딜을 넣는 건 불가능하다.
그 외 오늘의 사소한 해결사항들
SlamDamage를 공중에서 맞을 경우, 바로 회복되는 문제를 해결
모든 초필 도입부는 무적시간 적용. 약손에 초필이 씹히는 경우가 없도록.
앉아있을 땐 가까워도 잡기가 적용되지 않도록 수정.
프리오리의 장풍은 맞으면 넘어지도록 수정
11.7
넘어졌을 때 빠르게 일어날 수 있도록 방향성을 추가. 위아래키로는 예전처럼 제자리에서, 좌우키는 각 방향으로 구른다. 무적판정시간은 기존의 구르기와 같으나 여기엔 원론적인 문제가 있었다.
기존의 구르기는 판정에 버그가 있었다. 이것은 디스코드의 리포트로부터 알게 된 것으로 오래도록 묵혀둔 문제였다. 그런데 오늘 코드를 살펴보니 그냥 충돌판정이 잘못되어 있었다.
캐릭터가 이동할 땐 이동과 공격, 2가지를 위한 충돌검사를 한다. 2가지의 충돌검사는 병렬로 이루어져야 한다. 구르기의 경우 이동판정은 무시하지만, 공격판정은 적용되어야 하기 때문. 그런데 이 공격판정 코드가 이동판정안에 있어 이동이 무시되면 공격도 무시되게 처리되어 있었다.
해결책은 쉽다. 그냥 이동판정의 블럭에서 공격판정코드를 빼어 밖으로 배치하면 된다.
구르기의 무적판정은 8프레임이다. 8/30 = 0.267초 정도 된다.
11.8
배경 선택 기능을 위해 페이즈를 나눠 입력기능을 분리하다가 주먹구구식으로 처리하던 입력 지연 코드를 리팩토링. 짧아지는 코드를 보는 것은 언제나 기분좋은 일이다.
배경 수동 선택 구현. 필수적인 단계는 아니다. 그냥 기존처럼 랜덤으로 선택이 되지만, 원하면 바꿀 수 있다.
그 외 사소한 수정 사항들
스킬바 위치를 약간 낮춤. 캐릭터의 발 끝을 조금 덜 가리도록.
11.9
‘앉아 막기’에는 빈틈이 있었다. 캐릭터가 서 있을 땐 앉는다는 동작을 거친 후에야 막기가 가능했는데, 이것이 1프레임이 걸린다. 1/60초. 이 시간동안 타격이 있을 경우 막기가 안된다. 굉장히 짧은 시간이지만, 어쨌거나 일어난다.
때문에 방어를 할 경우 앉기를 동시에 판단하도록 설계를 변경. 일단 테스트는 잘된다. 실제 테스트때할 때도 좋은 결과가 있기를.
아래는 소소한 수정사항들
히트 후 연계기 유효 시간을 줄였다. 이게 길다보니 이상하게 공격이 연결되는 경우가 종종 있어 그림이 좋지 않았다. 벨의 달리기처럼 의도적인 딜레이를 주는 경우는 예외.
작업보드에 쌓인 내용들은 내가 적은 것들이니 수정사항의 일부이다. 이번 버그 픽스엔 디스코드 채널에서 온 리포트를 함께 고려하여야 한다. 대체로 2~3일이면 끝났던 작업이지만, 이번 작업은 조금 더 길어질 것 같다.
도레미의 베팅은 OP라는 평가가 많았다. 실제로 상대가 스턴에 걸리면 리스크 없는 데미지 증폭이 가능해서 문제가 있긴 하다. 이제 베팅을 위해선 칩의 수만큼 비용을 지불해야 한다.
10.26
코드가 의도한 대로 동작하지 않을 땐 답답하지만, 코드를 안짰는데 의도한대로 잘 작동할 때도 당황스럽긴 마찬가지다. 이게 왜 되지…? 무섭다… 후에 반드시 문제를 일으킬 것이니, 찾아서 해결해야 한다.
동시타는 자동으로 처리되는 것이 아니다. 예외 처리에 속한다. 추가로 작업해주어야 한다.
오로라의 초필 판정은 다소 열악했었다. 범위를 늘리고 앞으로 조금 전진.
여름이의 초필성공 거리 이슈가 고구마줄기처럼 다양한 문제가 줄줄이 엮인 이슈였다.
10.27
기본 공격이 2타인 공격들은 2번째 히트가 맞지 않았을 경우 데미지 손해를 보는 편이다. 이는 기본공격력을 절반으로 나눠 1,2타에 배정하기 때문에, 둘 중 하나를 실패할 경우 실제로는 절반의 데미지밖에 들어가지 않는다.
이를 개편하느라 데미지 공식을 좀 손봤더니 일이 커졌다. 수정방안은 1,2타중 처음으로 먹히는 공격에 대해 80%의 데미지를 입히고, 2타는 40%의 데미지를 갖는다. 1타를 실패하고 2타를 맞혀도 80%의 데미지는 보장이 된다. 이렇게 되면 2타를 모두 맞출 경우, 1타 공격보다 좋은 성능을 갖게 되는데, 실제로는 콤보 보정이 들어가기 때문에 10%감쇄가 일어나 1.16배정도로 줄어든다. 여기에 도레미 베팅, 멜라의 영역, 캐릭터의 공격력 스케일등이 추가로 계산된다. 그레텔의 캐릭터 공격력은 타 캐릭터의 0.9배로서, 너프되었다. 대신 발이 빠른 캐릭터가 될 것이다.
그 외에 스트레스 수치가 데미지 감쇄의 영향을 받게 되는 등의 수정이 있었다. 이로서 어지간한 무한 스턴은 막을 수가 있다.
10.28
사실 [동시에 잡기]는 대충 처리되어 있었다. 지상에서 잡을 땐 서로 밀려나긴 했지만 이펙트나 딜레이등이 구체적으로 설정되어 있지 않았고(충돌처리 한켠에 기생하는 코드로만 존재했다.) 공중잡기의 경우 충돌판정루틴이 1P를 먼저 도니까, 1P가 무조건 이기도록 설계되어 있었다. 이런 경우 자체가 매우 희박하기 때문에 크게 신경을 쓰지 않은 것인데, 놀랍게도 실제 게임에선 생각보단 빈번히 발생해서 제대로 된 코드를 만들었다. 프레임 처리 비용이 조금 늘어나긴 했지만, 확실한 게 좋으므로 처리해 두자.
차징어택(가드캔슬)은 문제가 많았다. 공중공격에는 잘 맞지도 않고, 비쌌다. 게다가 공격범위는 캐릭터가 제각각이었다. 달래같은 경우 그냥 지상 공격에도 잘 반격이 안되던 문제가 있었다.
그래서 비용을 깎고, 범위를 늘렸다. 그에 맞게 게이지도 2분할->3분할로 바꿨다.소소하지만 이 기술은 게이지를 쓰는 것인데, SP가 차오르는 문제도 있었다. 분류상 슈퍼 어택이므로 게이지가 차오르지 않아야 정보에 혼란을 덜 준다.
Nate님의 의견을 듣고 WarpAir의 발동딜레이를 좀 더 길게 조절했다. 이로서 이 기술을 절명기의 막타로 사용하기는 힘들 것이다.
10.29
입력 코드를 리팩토링 중이다. 시작은 AI를 추가하기 위함이었다. 앉아서 빠르게 약공격을 하는 기능이 필요했는데 현재 구조로는 이를 처리하기 힘들었다. 어차피 AI를 추가하려면 언젠가 손을 보긴 해야 할 터였다.
짜다 보니 산만하다. 전형적인 스파게티 코드. 세월의 흔적이 느껴졌다. 입력 코드는 0.26배포를 마지막으로 건든 적이 없다. 당시는 실력도 부족했고 챗GPT도 없었다. 비트마스크 알고리즘같은 건 생각도 못했다. 이제야 좋은 선생님을 만나 여러 모로 배우고 있다. 코드 줄 수가 획기적으로 줄었다. 원래 실속이 없으면 말이 많다. 안정화되려면 며칠 더 걸릴 것이다.
11.1
KopBot님의 의견을 받아들여 대공기의 후딜레이를 0.1초 늘렸다. 0.45버전에도 딜레이가 있긴 있었는데 아무래도 좀 약했나보다.
벨의 대공기도 바로 넉백이 되도록 변경.
11.2
닐리의 초필은 빈틈이 많았다. 연속기로 사용하기는 여전히 힘들겠지만, 이전보다는 나을 것이다.
세컨더리 애니메이션은 머리카락과 표정등의 부가 애니메이션을 의미하지만, 가장 일이 큰 건 펄럭거리는 의류다. 아이시의 세컨더리 애니메이션은 치마외엔 별 게 없다. 이 시점에서 생각해 보니 이게 얼마나 다행인지 모른다. 카피 스킬 탓에 아이시의 애니메이션은 다른 캐릭터들보다 곱절로 많기 때문이다.
그렇다고 해도 캐릭터 제작공정상 가장 지루한 작업이다. 늘 이 시기가 되면 드는 생각. AI는 이런 걸 해줘야지!
10.19
비네트의 우산돌리기를 작업하며, 쥐불놀이 캐릭터가 있어도 재미있겠다는 생각이 들었다.
다리를 이처럼 구부린 동작의 경우의 치마는 늘 문제다. 일단 아이시의 치마가 좀 낮은 것도 문제이긴 한데, 그와 상관없이 대부분 문제가 일어나는 구간이 바로 저 부분이다. 로우폴리곤 게임이라면 치마를 다리에 붙여 움직였을텐데 표현이 정교해지다보니 다양하게 새로운 문제가 생긴다. 다음 번이 있다면 반드시 고려해야 할 문제다.
이런 동작은 그냥 포기할 수밖에 없다. 왜 히어로가 쫄쫄이를 입는지 깨닫게 되었다.
그럭저럭 세컨더리 애니메이션은 완료했다.이제 이펙트로 넘어가 보자.
아이시는 얼음 메쉬가 몇 개 필요하다. 에셋이 발달하지 않았던 예전이라면 그냥 망설임없이 제작에 들어갔을테지만, 대체수단이 많은 요즘 시절엔 망설이며 제작에 들어간다.(선택의 폭이 늘어나는 것이 꼭 좋은 것 같지는 않다.) 어쨌거나 리스트업을 해보면
얼음기둥(IcePost)
얼음!(Freezing) – 캐릭터가 갇힐 정도로 커야 한다.
얼음파편(IceFragment)
얼음창(IceSpear)
10.21
얼음이 너무 투명해서 셰이더를 수정중이다. 이렇게 되면 얼음을 쓰는 모든 머티리얼이 영향을 받는데, 결국 해결해야 할 문제이긴 했다.
이렇게 저렇게..
얼음 이펙트를 완료.
얼리기는 기본은 됐으니 이제 메쉬를 예쁘게 다듬기만 하면 되겠다.
10.23
글을 쓰진 않았지만 많은 일이 있었다.
가장 큰 버그 2개는 발사체가 사라지지 않는 문제와 DetachEffect가 작동하지 않는 문제다. 지금까지는 잘 작동되던 기능이었다. 아이시는 지금까지의 거의 모든 코드에 걸쳐 말썽을 일으켰다. 마지막 데미를 장식한 캐릭터답다.
그래도 어쨌거나 가장 커다란 덩어리는 끝났다. 버그는 있지만 플레이는 된다. 실질적으로 13개의 캐릭터가 서로 치고 받을 수 있다. 그러므로 가장 중요한 일은 마무리가 되었다.
하지만 테스트를 위해선 아직 일이 많다. 일단 3기 캐릭터들에게 잡힐 수 있는 건 아직 앨리스 뿐이므로 잡히기 모션을 추가해 주어야 한다. 2차테스트 때 쌓인 버그와 밸런싱도 손봐주어야 하고, 새로운 버그도 고쳐야 한다. 마지막으로 배경을 추가해 주어야 한다. 여전히 할 일이 많지만 그래도 매우 중요한 이정표를 지났다. 버전 0.58정도 되려나? 다음으로 넘어가보자.
영상에도 기록된 얼음창의 비주얼이 남는 버그의 원인을 찾았다. 풀매니저 자체의 문제였는데, 맙소사. 이걸 왜 지금까지 모르고 있었지? 풀매니저는 배틀퀸 이전에 만든 물건이다. 사용 기간이 오래됐기 때문에 당연히 문제가 없을 거라고 생각하고 있었다. 이펙트의 문제이니 혹시 DetachEffect()가 작동하지 않는 것도 비슷한 문제가 아닐까?
정답이다. 같은 방법으로 버그를 재현할 수 있다. 라운드를 리셋할 때 전체 이펙트를 제거하는 과정에서 IsAlive()검사를 빼먹고 있었다. 이렇게 되면 해당이펙트의 큐에 리소스를 중복등록하게 되고, 그 결과 인덱스가 꼬여 잘못된 이펙트를 불러온다.
이 버그를 추적하기 시작한 것은 3일전이다. 얼음창을 구현한 후 처음 발생했지만, 이 버그는 이전에도 계속 존재해 왔다는 이야기가 된다… 이 문제를 처음 발견한 날엔 새벽내내 원인을 못찾고 결국 포기했었는데, 오늘 낮잠을 자고 일어난 뒤 이펙트가 사라지지 않으려면 어떻게 해야 할 지 역추적을 하는 방법이 불현듯 떠올랐다. 확실하다. 잠이 부족하면 머리가 돌아가지 않는다. 일이 잘 풀릴 땐 휴식을 하지 않아도 에너지가 넘치지만, 그렇지 않을 땐 쉬어야 한다.
스킬 제작 시즌이 돌아왔다. 아이시의 특징은 타캐릭터의 스킬을 하나 카피하는 것이다. 여느 때와 마찬가지로 기획부터.
얼음기둥(Post) : → A or B, 연달아 3개 솟는 얼음기둥.
얼리기(Freeze) : ↑ A or B, 대공기
흉내내기(-) : ← A or B, 상대의 기술 중 하나를 따라한다. 장풍 제외 타격기만.
만약 상대가 아이시라면 모르겠다는 몸짓을 (Shrug)한다.
윈드밀(Windmill) : → K, 거꾸로 서서 발로 3연타.
롤링어택(Rolling) : 공중에서 ↓ A or B
얼음창(Spear) : ↓→ B, 초필, 5개의 얼음창을 꺼내장전한다. B를 누르고 있으면 잠시 홀드가 되며 버튼을 떼거나 데미지를 입는 순간 차례대로 발사된다.
이외의 기술은 아직 구상 중…
원래 두 손으로 땅을 치고 싶었는데 결과가 너무 추해서 변경. 폭발 형태는 장풍. 멜라의 초필과 같다.
얼리기는 위로 찬공기를 일으켜 상대를 얼린다. 이를 위해 얼음 메쉬, 그리고 특수 모션이 필요하다.
10.2
얼음기둥은 멜라의 빛기둥과 본질이 같다. 그러므로 쉽게 구현
이번엔 Bomb스타일의 충돌 코드를 리팩토링. Bomb스타일은 이미 가지고 있는 물건이 아닌 걸로 타격할 때의 처리를 위한 것이다. 앨리스의 발구르기나 닐리의 불타는 손 같은 것들이 여기 속한다. 이것들은 다른 것들과는 다르게 딱 한프레임 충돌검사를 하고 있는데 이것이 날아오는 장풍을 상쇄시키는 확률을 낮추기에 다른 일반 타격계처럼 4프레임동안 검사를 하는 방향으로 바꿨다. (에디터에선 프레임이 튀며 가끔 무시되기도 한다!)
하지만 이렇게 해놓고 정작 얼리기는 그냥 클래스를 새로 만들었다(….) 지금은 이펙트 제작기간이 아니므로, 모든 이펙트는 임시. 게임의 모든 컨텐츠는 구현이 우선이다. 비주얼은 나중에.
10.4
추석이라 7일까지 작업 중단.
10.9
유니티에 보안이슈가 있다고 해서 내친김에 6.2로 업데이트…하고 나니 하루가 다 갔네.
카피 기술은 동작만 복붙하면 될 줄 알았는데 생각보다 어렵다! 일단 IK이슈로 애니메이션 복붙이 쉽게 안되고, 닐리처럼 불을 얼음으로 바꾸어야 한다던가, 리그레이 처럼 카피할 스킬이 마땅치가 않은 경우도 있다. 신규스킬을 캐릭터수만큼 만드는 것보단 품이 덜 들겠지만, 생각보단 만만치 않은 작업이 될 것 같다.
10.11
3일부터 시작된 긴 연휴가 어느 덧 끝을 향해 달려가고 있다. 한껏 풀어졌던 마음이 좀처럼 추스러지지가 않는다.
작업은 느릿느릿 프리오리까지 진행. 이제 벨의 차례인데 한 가지 이슈가 있다.
아이시가 따라할 벨의 기술은 백스텝 찌르기이다. 하지만 이 기술은 디스코드 팬서버의 의견에 따라 리뉴얼 예정에 있었다. 아이시가 이를 따라해야 하는 이슈가 생겼으니 미리 고치도록 하자.
A는 훼이크. 이건 단순 회피라 무적판정이 없다.
B는 원래기술 그대로지만, 초반에 약간의 무적판정을 갖는다. 이로서 점프에 대응할 수 있다. 하지만 이는 대공기가 이미 무적시간을 가지고 있어서 고민이 된다.
어쨌거나 얘도 완료.
도레미 트레일은 입체적으로 생겼다. 아이시 본인은 트레일을 안쓰는데, 카피 스킬 때문에 온갖 트레일을 갖고 있어야 한다. 하이고 복잡해라.
10.12
흉내내기 기술완료. 생각보다 성가신 작업이었다.IK문제는 결국 해결되지 않아 손으로 비슷한 키를 다시 잡아주어야 했고, 무기와 검기등의 부속품들이 캐릭터에 귀속되어 있다보니 일일이 이를 찾아 아이시에게 꾸역꾸역 넣어주었다. 요즘처럼 캐릭터 구조가 복잡한 시대엔, 캐릭터 애니메이션을 공유하기 위해선 생각보다 더 많은 사전 준비가 필요하다는 걸 깨달았던 작업이었다.
10.14
윈드밀도 완료.
롤링어택을 구현하는 과정에서 SetDelayState가 제대로 작동하지 않는 버그가 있어서 이를 추적하다보니 그레텔의 코드가 말썽이었고, 그 과정에서 또 버그를 발견해 리팩토링을 하니 또 사이드 이펙트가 생기고…
그래도 덕분에 숨겨진 버그를 찾아 없앨 수 있었다. 또 다른 문제가 없길 바란다.
10.16
끝까지 예외의 연속이었다. 이로 인해 기존의 발사체가 영향을 받는지 살펴봐야 하는 문제가 남아있긴 하지만, 어쨌거나 기본 코드는 완성됐다. 아이시는 B버튼을 홀드한 채 움직일 수 있고, 이 땐 얼음창도 본체를 따라 움직인다. B버튼을 떼거나 데미지를 입을 경우 얼음창은 상대를 향해 날아간다. 하지만 장풍과 타격이 동시에 일어날 경우 타격감이 좋지 않은 문제가 있기 때문에 이를 손봐야 한다. 또 다시 베이스를 건드려야 하는 상황. 하지만 오늘은 타임오버이므로 이 작업은 주말로 미루도록 하자.
현재 코드엔 캐릭터에게 잡기가 없을 경우의 예외처리가 들어가 있다. GrapplingPunch 혹은 Kick을 검사해서 상태 데이터가 없을 경우 잡기가 실행되지 않는다. 실제로 이 게임을 만들 때 가장 많이 참고했던 스트리트 파이터2에는 잡기가 없는 캐릭터가 있으며, 당시엔 모든 잡기 대응 애니메이션을 만들기 힘들거라 생각해서 몇몇 캐릭터는 Punch나 Kick중 하나를 생략하고 만들 생각이었다.
하지만 이제 그 코드는 필요없게 됐다. 실제로 잡기 대응애니메이션을 만드는 작업이 힘들기는 했다. 하지만 이런 페어 애니메이션은 게임 장르를 막론하고 쉽게 볼 수 있는 것이 아니다 보니, 재미있는 볼거리를 준다는 점에서 무리해서라도 넣는 편이 좋다고 생각됐다. 결과적으로 고생 중이다. 하지만 보람은 있다.
아이시는 정규캐릭터 외 히든 캐릭터이다. 하지만 유저에게나 히든이지, 개발자 입장에선 기존 캐릭터와 똑같은 작업이다. 다만 보너스 캐릭터인만큼 스토리는 없으니, 추후엔 일이 적어지긴 할 것이다.
9.18
유니티에 띄우긴 띄웠는데, 가슴의 리본이 자꾸 파묻힌다.
여차저차 삽질끝에 다이나믹 본까지 세팅완료. 캐릭터 추가는 쉽지 않지만 여기까지 진행되면 이제부턴 애니메이션에 집중할 수 있다.
요래 저래 기본 이동은 완료. 공격을 위해선 얼음을 써야 하는데, 이 부분에 대해선 고민이 좀 필요하다.
9.21
고민 결과 일반 공격은 그냥 일반적인 공격으로 하기로 결정.
맨손격투를 하니 장르가 바뀐 것 같은 느낌.
난 춤은 전혀 모른다. 이런 동작을 Flare라고 한다는 사실도 처음 알았다. 하지만 어쩐지 격겜에서 이 킥을 차는 캐릭터가 꼭 하나씩은 있다. (어려워!)
9.22
맨손을 쓰다보니 팔이 짧다 보니 기본기가 그리 좋지 않아 타이밍을 조금씩 땡겼다.전반적인 딜레이는 스피드 캐릭터인 그레텔과 비슷하지만, 타점은 조금 더 빠르다. 이러면 너무 좋아지니 대신 데미지를 조금 적게 책정할 예정. 그레텔도 조정되어야 하지만, 얘는 더 약할 것이다.
9.23
게임에서 돋보이는 것은 화려한 애니메이션이지만, 사실 애니메이션 제작의 대부분은 그렇지 않은 것들로 이루어진다. 데미지 애니메이션을 만들어 보자.
이즈 본거지 