[📜일지] 스압, 3.8MB) 간단한 키셋팅 UI개발중(입력 시스템 제작완료)

[익명(125.180)]

일단 새해복 많이받으십셔 인디갤 형님들!

드디어 나도 중간단계이긴 하지만 결과물이 나와서 개발일지를 적게 되었지!

시작한건 1월 4일이고, 지금은 2월 12일인데 적지 않은 기간 동안 만들었던 키세팅 시스템인데, 설명절도 있고 이래저래 치이는 와중에 이 정도라도 만든 것이 정말 기쁘다.

 

요약

키 세팅 시스템 만드는중..

UI 빼고 핵심 시스템은 다 만들었다!

사용법은 6번으로

 

1. 시작

언제나 내가 일일이 다 만드는 것보다는 남이 올려놓은 에셋을 찾아서 사용하는 것이 더 가성비가 좋긴 함. 

rewired라는 킹갓 에셋도 이미 있기는 있다(유료).

그렇지만 학교를 다니면서 그런 에셋들 찾아서 비싼 돈을 주고 사기도 애매하고, 혼자 1인개발로 조금씩 유니티엔진 건드려보는 입장에서 복잡한 에셋을 잘 가져다 쓸 수 있을지도 미지수라서 돈쓰기 전에 좀 알아보려는 생각으로 에셋스토어 무료 에셋들부터 살펴보았다.

서너개 에셋을 찾았지만 대부분 버전이 지나있었고, 실제 게임들에서 사용되는 키세팅 UI랑은 거리가 좀 있는 것들이었다.

나름 난이도가 좀 있지만, 무료 에셋들 받아서 코드를 보니 그래도 혼자서 방학 꼴아박으면 내가 원하는 시스템을 만들 수 있겠거니 해서 만들어보기로 결심함.

2. 단순 구상

일단은 내가 뭘 만들고 싶은지 생각을 정리해야 할 필요가 있었다.

 

유니티 Input클래스 키 값들은 유니티 에디터에서밖에 수정할 수 없다.

- 무료 에셋들의 경우는 Input클래스를 덮어쓰는 방식으로 해결하는 편이었음.

키를 Axis로 전환하는 건 쉽지만(인풋매니저 사용), Axis를 버튼형식으로 만드는 건 어렵다.

- 예를 들면 액박패드 D-pad버튼 같은 건 운영체제에 따라서 기본 Axis로 되어있음.

키들을 몰아서 입력해야 하는 시스템보다는 일일이 키를 설정해야 하는 편이 더 좋았다.

키 세팅 화면의 버튼들은 화면에서 설정하는 키들과는 독립적으로 작동해야 할 것이다.

개인취향이기는 한데, 이 부분은 거지같은 사례 하나 보면 될 듯.

이건 격겜인 스컬걸즈 키세팅 화면인데, 플레이어1, 2 둘의 키세팅을 설정할 수 있음.

Config All이 세팅화면을 키자마자 보이는데, 저 상황에서 ok키 한번만 잘못누르면 키세팅이 다 꼬여버린다.

플레이어 당 최소 12개의 키, 도합 24개의 키를 중복 없이 눌러야 하고, 어떻게든 키들을 설정하면 키세팅 화면에서도 바뀐 키들이 바로 적용된다.

키세팅 화면 버튼(잘 눌림) > ok키 > 잘못 누른 키(보통 여기까지 누르고 아차 함)가 바로 ok키로 할당

이 3단콤보로 게임 강종각을 많이 봐서 빡쳤던 기억이 있음.

1p인 내가 조심을 해도 2p가 누르면 걍 겜 꺼야되는거지

반면에 좋은 키세팅 예시는 많이 있다. 롤이라던가, 몬헌이라던가 마우스로 클릭하고, 버튼 입력하고, 저장하는 방식들.

여튼 키세팅은 안전장치가 있어야 한다는 생각을 함.

 

UI환경에서 내가 어떤 키를 입력했는지 보여주는 기능이 있었으면 했다.

스컬걸즈 키 인풋 화면. 게임에 따라 이런 키 입력을 보는 UI도 필요할 것이다.

 

키 안내를 위한 UI화면도 좋을 것이라 생각함.

이건 몬헌하면서 본건데 개인적으로 마음에 들음.

 

키보드 & 마우스와 다른 주변기기별 컨트롤 화면이 따로 있어야 한다.

아마 스팀게임을 하면서 패드를 가지고 있다면, 패드 키 조작 따로 키마 조작이 분리되어 있는 것을 본 적 있을 것이다.

 

대강 이 정도까지 생각하고 그림으로 구상한 것을 구체적으로 그려봄

기본 UI화면. 여기에 키 저장 버튼이 하단에 추가로 있으면 목적 달성.

프리팹들은 이렇게 만들어야지 하고 구상한 것

안내화면 대강 구상한 것

3. 분석

먼저, 나는 인풋매니저의 Axis와 정의된 KeyCode를 같은 동일선상에 두고 구성을 하기 시작했다.

Axis는 GetAxis, GetAxisRaw / KeyCode는 GetButton, GetButtonDown, GetButtonUp

이 두 가지가 인게임 스크립트에서 적용되는 컨트롤 메서드라고 생각했음.

그럼 Axis(축) 값을 버튼으로, 키코드로 된 버튼을 축으로 바꾸는 클래스가 있으면 일단 축과 버튼 사이의 단절 문제는 해결된다.

4. 설계

UI 이전까지의 초기 설계화면.

c#의 딕셔너리를 사용해서 이름에 해당하는 조작키에 각각의 입력값을 대입해서 저장하는 방안이다.

여기서 문제가 발생하는데, 하나의 컴퓨터에서 사용할 수 있는 모든 입력 값을 트리거, 스틱 두 가지 방식으로 처리하니까 기기별로 조작키를 부여하는 방법은 위의 모델로는 완성할 수 없었다.

그래서 각각의 기기별로 조작과 입력 값을 분리해서 연결하는 모델을 생각해냈음.

이렇게 하면 UI에서도 조작 이미지랑 입력값 이미지를 분리해서 만들 수 있다는 점도 장점이다.

2차 설계화면. 전체적인 틀은 이후에도 크게 달라지지 않는다.

여기서 실제로 코드를 작성하기 시작.

5. 개발

코드를 작성하면서 생각하지 못했던 부분들은 반드시 생기기 마련이다.

먼저, 유니티에서 자체적으로 지원을 하는 버튼은 이미 정의되어 있는 KeyCode목록을 통해서 바로 사용할 수 있지만, Axis같은 경우는 인풋매니저에 전체 축들을 모두 입력해주어야 함.

그래서 축을 입력하는 부분을 따로 만들었다.

코드로 동작하는데, 원리는 생각보다 간단하다.

빌드 버전이 아닌 유니티 프로젝트에서는, 곳곳에 .asset파일이 저장되어있는 것을 볼 수 있음.

이중에 메모장으로 열었을 때 내용이 %YAML로 시작하는 파일들은 텍스트를 수정하는 방식으로 내용을 바꿀 수 있다.

다시 말해, 아무 유니티 프로젝트\ProjectSettings\InputManager.asset 파일을 메모장으로 직접 수정하는 것으로 유니티 프로젝트의 Axis설정을 바꿀 수 있다.

C#코드를 사용해 텍스트 수정을 해도 마찬가지.

그리고, EditorWindow를 상속받은 클래스는 에디터 내부에 별도의 메뉴를 만들 수 있다.

실제로 구현한 모습. 이걸로 에디터상의 메뉴에서 버튼 하나로 모든 축들의 이름을 직접 집어넣을 수 있다.

 

그리고 또 어이없게 한 가지 실수했던 부분이, 실제로 조작키 값을 저장하는 방법에 대해 생각을 미처 못 했었던 것이다.

 

이번 키 입력 시스템을 만들면서 선택한 방법은, 정적 메서드와 스크립터블 오브젝트였다.

그림으로 설명하자면,

npc가 둘, 주인공 하나 해서 3개의 게임 오브젝트를 게임 내에서 굴린다고 할 때, 일반적인 클래스로는 인스턴스마다 각자의 데이터를 가지고 있어야 하고, 각 인스턴스마다 독립된 메서드를 가지고 있어야 한다.

 

주인공과 같이 중복되지 않는 오브젝트면 상관없겠지만, npc와 같이 중복되는 오브젝트가 있을 때에는 메모리가 낭비되는 셈이다.

이때, 정적 메서드와 스크립터블 오브젝트를 사용하면, 중복되는 오브젝트(여기서는 npc)를 처리하는 데이터와 메서드를 전역으로 지정할 수 있고, 각각의 인스턴스마다 별도로 생성할 필요가 없다.

 

나는 이렇게 이해를 했음. 내가 이해를 잘못하고 있는 부분이 있을 수 있다.

스크립터블 오브젝트로는 메서드를 사용하지 않는 것 같아서 정적 메서드를 썼는데 실제로 스크립터블 오브젝트에서 메서드 사용 가능한지는 모르겠다.

이전까지 설명한 저장방식을 실제 그림으로 적용하자면 대강 이런 느낌.

하나의 클래스를 데이터와 메서드 부분으로 나눈다.

이것때문에 코딩하던걸 한번 다 엎어버려야 했음ㅠㅠ

UML상으로 적어놓은 구조는 생략했을 때 이런 식으로 작성되었고, 실제로 코드도 거의 비슷하게 따라간 것 같다.

실제로 작성중인 UML은 다운로드 사이트에 같이 있음.

6. 지금까지 만든 프로젝트 사용해보기

https://seintcat.itch.io/unity-diy-keybind-asset

itch에 프로젝트 폴더째로 업로드해놓았다.

 

먼저 인풋매니저에 Gamepad~~와 같은 축이 약 400개가량 등록되어있는지 확인한다.

 

축 정보가 없다면, 상단바 > Tools > Key Binder > Axis Setup 실행 후

Apply Axis버튼 클릭 > 축이 잘 적용되었는지 다시 확인하자.

중간에 오류가 날 때에는 인풋매니저의 축 개수를 줄여서 복구 가능.

이후 프로젝트를 보면 다음과 같은 폴더들이 있을 텐데,

AxisButtons = 축을 버튼과 같이 사용하기 위한 값

KeyCodeAxis = 버튼을 축처럼 사용하기 위한 값

ModifiedButton / Stick = AxisButtons, KeyCodeAxis를 포함해서 버튼 / 축으로 합침

BindingDevice = ModifiedButton / Stick을 한데 모은 집합

- 예를 들면 액박패드는 버튼 + 스틱 + 트리거 뭐 이런 식으로

Controls = BindingDevice에 1대 1 대응되는 컨트롤 값

이렇게 구별을 해놓았어. 

 

버튼의 경우

(축이라면 AxisButtons >) ModifiedButton > BindingDevice

 

스틱의 경우

(버튼이라면 KeyCodeAxis >) ModifiedStick > BindingDevice

 

이렇게 연결된다.

 

Controls가 설명이 좀 필요할 것 같은데,

PC버전에서 공격 = A, 선택 = S 뭐 이렇게 나뉘는 조작이 있다고 하면,

게임패드로는 공격/선택 = A 와 같이 입력기기마다 조작이 다른 경우가 있어서 분리해놓았음.

 

Sprite는 키세팅을 할 때 들어가는 모든 이미지들을 배열로 묶은 건데, 아직은 UI가 완성되지 않아서 나도 사용한적 없다. 

프로젝트에 하나만 있으면 돼서 딱히 더 만들 필요도 없고.

모든 스크립터블 오브젝트파일은

프로젝트창에서 우클릭 > Create　> Key Binder 메뉴를 통해 생성 가능.

 

나머지는 따로 만든 TestUI폴더에서 테스트신이나 테스트코드를 사용해서 실험해볼 수 있어.

문제생기는 거 댓글남기면 고쳐드림.

좋은 한해 되길 바래!

[연어(smosal)]

혹시 유니티 새로나온 인풋 시스템 써보셧나여?
https://docs.unity3d.com/Packages/com.unity.inputsystem@1.0/manual/index.html

[익명(125.180)]

장기적인 목표로는 비슷한 포맷으로 새로운 인풋시스템이랑 텍스트메시 프로 적용시켜보려는 생각은 있는데, 지금은 안쓰고 있습니다

[이미본거야콘(bgycon)]

[익명(118.221)]

GetAxis하고 GetButton 을 같은 창구로 일원화안 거 같은데 결국 모든 컨트롤러의 버튼을 전부 축으로 할당한거임? 너무 과해져버린거 아닌가?

[익명(125.180)]

ㄴㄴ 딱 필요한 부분만 스크립터블 오브젝트로 생성 가능 예를 들면 wasd를 방향 스틱으로 사용하고싶다고 키보드 알파벳자판을 죄다 스틱으로 만들어버릴 필요는 없는거지

[익명(175.200)]

님 혹시 이거 아직 개발하고 있음?