11.11
앵커가 잡힌 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시의 줌블러에 가시 효과를 추가 중. 확실히 셰이더 그래프는 언리얼에 비해 갈 길이 멀다. 무엇보다 무선 노드부터 좀 지원했으면 좋겠다.

요게 기존

요게 수정. 어째 박력이 더 떨어져 보인다..?!

노드정리를 하고, 텍스처를 다듬고.. 뚜닥뚜닥. 최종형태. 셰이더 그래프가 익숙치 않다보니 생각보다 시간이 걸린다. 포스트프로세스 셰이더 작업은 몰아서 하는 편이 좋겠다.
그 외 수정사항
- 닐리의 파이어볼 딜레이를 줄임. 25frm -> 20frm
- 닐리의 날아가기 이펙트 부착 코드를 리팩토링
- Turn모션이 나오지 않는 문제를 해결.
- 풀매니저가 초기 로드된 에셋을 쓰지 않는 현상을 수정

















































































