일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 공부
- 뭐드라
- 코딩
- 유니티
- 까먹기전에메모
- 붕괴 스타레일
- 스파르타내일배움캠프
- 컴포넌트
- 후기
- 게임분석
- 게임용어
- LookAt
- 게임
- 나만의 견해
- 연습
- 원신
- 점프
- ag 내일배움캠프
- 블렌더
- 내일배움캠프
- 취업
- spritelibrary
- materialpropertyblock
- 취미
- spritemask2d
- 스파르타내일배움캠프TIL
- 프로그래밍
- 게임 회사
- 붕괴스타레일
- 일상
- Today
- Total
덴바의 노트
내일배움캠프 15일차 TIL - NEW INPUT SYSTEM(1) 본문
5월 7일 작성했어야 할 TIL을 어제 작성 못했기에 매우 아쉽습니다.

5월 7일 몸 상태가 매우 안좋았기에 9 to 9 동안 제대로 몸이 안움직여서 작성을 못했는데요.
그래도 저는 건강이 우선이라고 생각합니다.

오늘의 키워드
- New Input System
- 단일 책임 원칙
NEW INPUT SYSTEM
오늘부터 유니티를 배우는 강의가 진행이 됐습니다.
다양한 강의 내용들이 있었습니다만,
그 중에서 꼭 부트캠프에서 한 번 다뤄줬으면 하는 기능이 있었습니다.
그건 바로 유니티의 '(NEW) INPUT SYSTEM'입니다.
INPUT SYSTEM인데 NEW INPUT SYSTEM 이란 무엇일까요?
이것은 유니티 2019년 버전부터 새로 추가된 기능입니다.
특징
1. 크로스 플랫폼을 대응하는 유니티에게 있어서, 다양한 입력 장비에 쉽게 대응할 수 있습니다.
2. '입력에 대한 처리'와 이를 이용해 '실제 로직을 처리'하는 부분을 분리가 쉬워집니다.
필요성
왜 이러한 기능이 필요할까요?
처음 유니티를 겪으시면서 독학으로 게임 개발을 하고 계신분들이라면
아래와 같은 방식을 많이 사용하실 겁니다.
private void Update()
{
float x = Input.GetAxis("Horizontal");
float y = Input.GetAxis("Vertical");
rid.velocity = new Vector3(x * speed * Time.deltaTime, y * speed * Time.deltaTime, 0);
}
Update문 안에 입력값을 받아온 후,
바로 아래에서 곧장 입력값에 대한 실제 로직을 처리하는 방식입니다.
이 방법이 잘못되었다!?
그건 또 아닙니다.
실제로 저 방식은 과거에도 많이 사용하던 방식이며,
간단한 몇 가지 조작 등에 대해서 처리하기 매우 쉬웠습니다.
문제점은 그 부분이 아닙니다.
문제점
1. 프로젝트가 커질수록 떨어지는 가독성
2. 키 리바인딩에 불편함
3. 복잡한 코드
4. 크로스 플랫폼에 적합하지 않음
5. SOLID 원칙의 S를 위반함
처음에는 은근 직관적이고 사용성도 쉬워서 사용하게 되지만,
움직임, 점프, 공격, 스킬, UI 버튼 등을 만들다보면,
Update문은 상당히 커져버립니다.
또한 bool을 사용하여 이러한 상황에는 점프가 가능하고,
이러한 상황에는 공격이 가능하고 등...
기능 하나 추가 당 작업이 매우 복잡해집니다.
직관성도 터져버립니다.
또한 저렇게 하면 Update문 안에서 코드를 작성하기에
수많은 KeyCode 변수를 전역변수로 설정해두기도 해야 해서, 키 바인딩 변경도 불편하죠.
제가 생각하기에 가장 큰 불편함은 4번 크로스 플랫폼에 적합하지 않다는 점입니다.
크로스 플랫폼이란
PC, MOBILE, XBOX 등의 다양한 플랫폼에서
해당 게임을 플레이 가능하게 하는 것이라고 간단하게 생각하면 좋습니다.
만약 Update문에서 Old한 방식으로 Input System을 구현한다면,
키보드와 마우스, 모바일 스크린 터치, X BOX의 게임패드 등에 대한
입력 변화를 감당할 수 없을 것입니다.
마지막으로 SOLID 원칙 중 S(Single Responsibility Priciple)를 위반하게 됩니다.
Update에서 모든 처리를 작성하게 되면, 입력을 인지하고 처리하는 기능과
입력값을 이용하여 움직임, 공격 등의 처리를 하나의 스크립트에서 동시에 처리하게 됩니다.
이는 객체지향을 무너뜨리는 하나의 발판이 되게 됩니다.
사용법
1. ProjectSettings -> Player -> Other -> Active Input Handling을 New 또는 Both로 변경합니다.
※Both는 Old방식과 New 방식을 둘 다 사용할 수 있습니다.
2. Package Manager에서 Input System을 Import 받습니다.
3. Project창에서 마우스 우클릭을 눌러 Create -> Input Actions를 생성합니다.
4. Actions를 열어서 설정을 합니다.
기본적인 과정은 위와 같습니다.
다음은 Input Actions의 각 기능에 대해 알아보겠습니다.
Actions
입력 행동을 정의 합니다. 특정 입력 장치로 부터 입력을 받은 후,
이를 트리거와 같이 이벤트를 이어주는 역할을 합니다.
더욱 간단히 설명하자면 C#의 Action 대리자 같은 것이라고 생각하면 좋습니다.
Action Maps
Actions들을 가지고 있는 하나의 집합입니다.
아무 생각 없이 적긴 했지만 PC라는 명칭으로 하기보다는
예를 들어 1:1 대전 게임이라면 Player1, Player2로 명칭을 주는게 더 자연스럽겠죠?
Schema
스키마는 뭘까요? 데이터 베이스를 공부하신 분이라면 아시겠지만
스키마란 Input Action의 내부 구조와 제약사항을 정의하는 하나의 틀입니다.
제가 사용하는 방식은 주로 PC, Mobile, XBox 등으로 정의해서
각 입력장치 별로 스키마를 만듭니다.
다음으로 Action Type에 대해 알아보기 전에 먼저 알아둬야 할 것이 있습니다.
그건 바로 입력에 대한 Callback의 분기, 즉 상태에 따른 Call이 존재합니다
CallbackContext
위 사진과 같이 InputAction.CallbackContext 라는 것이 존재합니다.
그 안의 내용을 보면 Phase, Performed, Started, Canceled 등이 있습니다.
이 중 핵심이 바로 Started, Performed, Canceled 입니다.
Action Type에 따라 존재 여부나 타이밍 등은 다릅니다.
하지만 기본적인 작동 여부는 아래와 얼추 비슷합니다.
1. Started : Waiting(아무런 입력값이 없는 상황)에서 입력을 받은 순간
2. Performed : 입력이 존재하는 동안
3. Canceled : 입력이 존재했다가 0이 되는 순간
Action Properties의 Action Type
Action Type은 디바이스나 사용 용도에 따라 선택해야 하는 것이 달라진다고 봅니다.
일단 눈에 확실히 보이는 차이는
Value, Pass Through는 Control Type이 있지만
Button은 Control Type이 존재하지 않습니다.
즉 Button은 이름대로 버튼에 적합한 형식으로,
해당 키 또는 버튼 등 Input만을 처리하는 Type이라고 봐도 무방합니다.
또한 상세히 조사해보면 입력에 따른 다른 차이가 존재합니다.
위에서 설명한 CallballContext에서 차이가 발생합니다.
Value의 경우
위 사진과 같이 아무런 입력이 없을 때는 Waiting 상태였다가
입력이 들어오면 Started 상태로 변합니다.
Started가 호출되면서 동시에 Performed가 호출됩니다.
또한 순서상으로는 사진만 보면 Started가 먼저 호출이 되지만
타임의 차이 등의 차이는 없는 걸로 알고 있습니다.
아마 동시에 호출될 것입니다.
Value와 Button의 차이점은 이 부분입니다.
Performed 상태에 진입 후 계속해서 입력을 받고 있다면 계속해서 Performed를 실행합니다.
OnTriggerEnter, OnTriggerStay, OnTriggerExit와 동일하다고 보면 좋을 것 같습니다.
Button의 경우
Button의 경우 약간의 차이가 발생합니다.
Press, Release를 기준으로 해당 값을 넘었는지 아닌지 등의 조건이 생깁니다.
Press와 Release의 기준 수치는 아래 사진과 같이 ProjectSettings에 보면 알 수 있으며
기준 값도 직접 변경 가능합니다.
또한 가장 큰 차이는 Performed에 있습니다.
Value의 경우 Performed를 계속해서 반복해서 돌지만,
Button의 경우 특정 키를 계속해서 누르고 있다고 한들,
Performed Phase를 실행하는 것은 단 1번입니다.
즉, UI를 띄우는 키 등에 매우 적합하다고 봅니다.
Pass Through의 경우
기존과는 달리 Started가 사라진 형태입니다.
키 입력이 있으면 Performed가 호출이 되고,
키 입력이 없으면 Waiting으로 돌아오고 Canceled는 호출되지 않습니다.
Canceled가 호출되는 경우는 디바이스 변경 시에 이뤄집니다.
디바이스 변경이란
PC 유저가 키보드와 마우스를 이용해 게임을 플레이 하다가,
갑자기 X Box Pad를 연결하는 경우
이 때 한 순간 Canceled가 발생하게 됩니다.
오늘의 회고
오늘부터 유니티 개발 입문에 돌입했습니다.
드디어 검은 화면의 Console을 보지 않아도 된다는 생각에 매우 기쁩니다.
하지만 생각했던 것 보다 입문인데 난이도가 높다고 생각했습니다.
과거 Input System을 독학하면서 매우 내용이 복잡하고 어렵다고 느꼈기에
이번 강의에 Input System을 다루면 좋겠다고 생각했고, 아무 입문을 넘어선 강의 때 다룰 줄 알았지만
입문에서 바로 나와서 매우 놀랐습니다.
그만큼 내일배움캠프의 강의에서는 과거의 방식이 아닌
최근의 트렌드에 맞게 강의를 준비한다는 것을 알 수 있었고 매우 기분이 좋았습니다.
제법 긴 글이 되었지만 아직 적을 내용이 많습니다.
Input System의 가장 중요한 꽃인 Behaviour 방식 4 종류에 대해서는 다음 포스트 때 다루도록 하겠습니다.!

'프로그래밍 노트 > TIL' 카테고리의 다른 글
내일배움캠프 17일차 WIL - 라디안 (0) | 2024.05.10 |
---|---|
내일배움캠프 16일차 TIL - NEW INPUT SYSTEM(2) (0) | 2024.05.09 |
내일배움캠프 14일차 WIL (1) | 2024.05.03 |
내일배움캠프 13일차 TIL (0) | 2024.05.02 |
내일배움캠프 12일차 TIL (1) | 2024.05.01 |