Input System은 Input Actions와 PlayerInput으로 구성된다. Input Actions는 입력과 행동의 연결을 정의하는 구조이고, PlayerInput은 그 정의를 바탕으로 실제 입력을 감지하고 동작을 실행하는 컴포넌트다.
동작의 주체가 되는 Player 게임 오브젝트에 PlayerInput 컴포넌트를 추가하고, Actions 필드에 사용할 Input Actions 에셋을 지정하면 PlayerInput을 사용할 준비가 완료된다.
unity - PlayerInput
Default Scheme
어떤 입력 장치(키보드마우스, 게임패드 등)에 대한 입력을 처리할지 지정할 수 있는 설정이다.
Player Input - Scheme
기본값인 Any는 어떤 장치에서든 입력을 받을 수 있다. 특정 장치를 지정하더라도 Auto-Switch가 활성화되어 있다면, 다른 장치의 입력이 감지되었을 때 자동으로 해당 장치로 전환되어 입력을 처리한다. 반대로 Auto-Switch가 비활성화되어 있다면, 처음 감지된 장치만 계속 사용하게 된다.
예를 들어 Default Scheme을 Any로 설정하면 먼저 사용된 키보드마우스로 Control Scheme이 잡힌다.
PlayerInput - Keyboard&Mouse
이 상태에서 게임패드를 연결하여 조작을 하면 Auto-Switch 덕분에 자동으로 게임패드로 입력이 감지되어 처리된다.
PlayerInput - GamePad detection
Default Map
Default Map은 Input Action Maps 중에서 기본으로 사용할 Map을 지정하는 설정이다.
Input Actions - Default Map
Input Action은 상황에 따라 다른 Map으로 전환할 수 있다.
예를 들어 캐릭터 조작 시에는 Player 맵을 사용하고, 메뉴를 열었을 때는 UI 맵으로 전환하여 입력을 UI 조작에만 반응하도록 만들 수 있다. 이러한 방식은 게임패드나 조이스틱처럼 여러 입력이 혼합되는 환경에서 특히 유용하다.
UI Input Module
UI와의 상호작용은 EventSystem에 연결된 Input System UI Input Module 컴포넌트를 통해 처리된다.
기본 Unity UI 시스템은 단일 입력만 처리하도록 설계되어 있지만 멀티플레이 게임(로컬)에서는 각 플레이어가 자신의 UI를 조작해야 하는 경우가 생기기 때문에 각 플레이어에게 UI 입력용 시스템도 별도로 연결해주어야 한다.
Event System
PlayerInput 컴포넌트가 사용하는 Input Action Asset은 UI Input Module에도 동일하게 적용되어, 동일한 동작과 디바이스 설정으로 UI와 게임 조작을 일관되게 제어할 수 있다.
멀티플레이 환경에서는 MultiplayerEventSystem 컴포넌트를 사용하여 화면에 여러 UI 인스턴스를 동시에 표시하고 각 UI를 서로 다른 플레이어가 독립적으로 제어할 수 있게 만들 수 있다.
MultiPlayer Event System
Camera
Camera 필드는 멀티 플레이어 상황에서, 플레이어 관리에 사용되는 PlayerInputManager 컴포넌트의 Split-Screen 기능이 활성화된 경우에 의미를 갖는다.
PlayerInputManager
이 기능이 켜지면 각 플레이어는 자신만의 카메라를 통해 분할된 화면을 보게 되며, 이때 PlayerInput의 Camera 필드에 각 플레이어의 카메라를 연결해주어야 한다.
Mario Kart 2P
이렇게 설정하면, UI의 입력 처리도 해당 카메라를 기준으로 이루어지므로 플레이어마다 올바른 UI 포커스 및 이벤트 처리가 가능해진다.
Behavior
이벤트가 발생했을 때 어떤 방식으로 처리할지 결정하는 옵션이다.
Send Messages
PlayerInpt - Behavior
Send Message는 Unity의 고전적인 메시지 전달 방식으로, SendMessage("함수명", 파라미터) 형태로 특정 메서드를 실행한다.
PlayerInput 컴포넌트는 Input Action이 발생했을 때, 해당 액션 이름을 기반으로 구성된 함수명을 자동으로 호출한다. 이 메서드는 GameObject에 연결된 MonoBehaviour 스크립트 내에 정확한 이름으로 존재해야 하며, 그렇지 않으면 호출되지 않고 무시된다.
예를 들어 Jump라는 액션이 정의되어 있다면, PlayerInput은 OnJump()라는 함수명을 찾아 호출한다.
이처럼 Input Action에서 정의된 Action 이름 앞에 On을 붙인 함수명이 호출 대상이 되며 위 이미지에서 텍스트로 사용가능한 함수명이 표시된다. 이 함수명 텍스트는 Input Actions 에셋에서 Action의 이름을 추가하거나 편집하고 Asset을 저장하면 자동으로 수정되어 보인다.
SendMessage 방식의 장점은 간단하고 빠르게 연결 가능하기 때문에 코드 구조가 가볍지만 메서드명이 정확히 일치해야 작동한다는 점과 동적 호출 방식이기 때문에 컴파일 타임에서 오류 체크가 불가능하며 함수의 파라미터가 InputValue만 전달되기 때문에 복합적인 처리나 Context 정보 전달, 다중 파라미터 기반 로직등의 처리가 어렵다.
public void OnMove(InputValue value)
{
moveInput = value.Get<Vector2>();
}
Broadcast Message
Broadcast Message 방식도 Unity의 고전적인 메시지 전달 방식으로 Send Message와 동일한 형식을 따르지만, 차이점은 현재 GameObject 뿐만 아니라 모든 자식 오브젝트들에게도 메시지를 전파한다는 점이다.
예를 들어 계층 구조 내 여러 컴포넌트가 동일한 함수명을 가지고 있다면, 모두 호출되기 때문에 예상치 못한 중복 동작이 발생할 수 있다. 또한 자식 오브젝트가 많거나 계층이 깊을 경우, 성능 저하의 원인이 될 수 있어 주의가 필요하다.
Invoke Unity Events
이벤트 기반 정적 연결방식으로, 함수명을 신경 쓸 필요 없이 에디터에서 간편하게 메서드를 지정할 수 있다.
Behavior - Invoke Unity Events
Input Actions에서 정의한 Action들은 PlayerInput 컴포넌트 내에서 자동으로 이벤트로 생성되며, 인스펙터 창에서 해당 이벤트에 호출할 메서드를 직접 할당할 수 있다. 이러한 이벤트 - 리스너 구조는 코드 간의 결합도를 낮추고, 동작을 시각적으로 구성할 수 있어 직관적이고 유지보수도 용이하다.
Invoke C Sharp Events
Invoke C# Events는 코드 기반으로 입력을 처리하는 방식으로, PlayerInput이 제공하는 onActionTriggered 이벤트에 리스너를 등록하여 모든 입력 액션을 하나의 이벤트에서 감지할 수 있다.
action.name을 기준으로 원하는 액션을 구분해서 처리할 수 있으며, Unity Events 방식은 인스펙터에서 함수명을 문자열로 참조하기 때문에 함수명이 바뀌면 참조가 끊길 수 있는 반면 Invoke C# Events는 코드에서 직접 리스너를 등록하기 때문에 함수명을 변경하더라도 안전하게 리팩토링이 가능하며, 유지보수에 강점을 가진다.
정리
각 Behavior 방식은 특징이 다르기 때문에 상황에 따라 적절히 선택해서 사용하는 것이 중요하며 다음과 같이 요약할 수 있다.
- Send Message : 간단한 구현이 필요할 때 유용
- Broadcast Message : 하위 오브젝트까지 포함하여 입력 처리를 해야 하는 특수한 경우에 사용
2019 버전을 발표할 시점인 19년도에 새로운 Input System을 업데이트하면서 기존까지 입력 처리를 담당했던 Input Manager에 대해서 앞으로 추가 업데이트 사항은 없다고 언급을 했었다. 그 후 아직까지도 호환성은 유지한 채 사용할 수 있도록 제공하고 있지만 공식 문서에서도 legacy로 표현하며 Input System을 권장하고 있다.
Input System을 권장하는 이유는 새로운 입력 처리 방식의 장점과 Input Manager의 오래된 기술로 인한 한계에 있다.
Input System 장점
- 다양한 입력 장치를 지원하며 사용자 정의가 가능하다. 이를 통해서 다양한 플랫폼에서 일관된 입력을 처리할 수 있다.
- 비동기 입력 처리를 지원하기 때문에 입력 이벤트를 더 효율적으로 관리할 수 있어 게임 성능의 향상을 모색할 수 있다.
- Input System의 API는 더 직관적이어서 사용하기 쉬워 코드의 가독성을 높인다.
Input Manager 한계
- 다양한 입력 장치를 동시에 처리하는 등의 현대의 게임 개발에서 요구되는 사항을 충족하기 어렵다.
- 기본적인 입력 처리만 가능하기 때문에 복잡한 입력에 대한 요구 사항을 처리하기 부적합하다.
Unity 6 버전을 기준으로 진행한다.
Project Settings
기본 선택은 both로 되어있는데 Input System만 을 사용하기 위해서 Project Settings > Player > Active Input Handling에서 Input System Package를 선택한다.
어느 버전부터인지 모르겠지만 이전에 사용했던 버전에서는 Input System을 선택 시 패키지 설치가 필요했는데 현재 버전에서는 패키지가 기본적으로 설치되어 있고 InputSystem_Actions 파일이 기본 생성되어 있다.
Input Actions
Input System - Input Actions
Input Actions Asset 파일을 열면 입력에 대한 처리를 맵핑과 세부 설정을 할 수 있는 Input Actions Editor 창이 열린다.
Action Maps
입력을 그룹으로 묶어 관리할 수 있는 단위이다. 기본적으로 Player, UI 맵이 제공된다.
각 Action Map은 관련된 여러 입력 동작인 Action들의 설정 묶음으로 하나의 Input Actions Asset에서 활성화되는 Map은 하나만 처리되므로 플레이어의 상태에 따라 Map을 전환하여 상황에 맞는 입력만 처리하도록 구성할 수 있어 게임 내 다양한 상태에 따라 입력 처리를 명확하게 구분하고 유지 보수 및 확장도 간편하다.
Actions
사용자 입력에 반응하여 수행될 동작을 정의하는 요소이다.
Input Actions - Actions
이동, 점프, 공격 등과 같이 플레이어의 입력 행동 단위이다. 각 Action은 하나 이상의 입력 Binding과 연결되고 키보드, 마우스, 게임 패드 등 다양한 장치의 입력을 조합하여 정의할 수 있다.
Action은 하나의 입력 동작에 대한 정의이며 Binding은 Action을 어떤 입력 장치에 매핑할지 설정한다.
각각 Properties에서 세부적인 옵션 설정을 할 수 있다.
Action Properties
각 Action의 동작 방식과 입력값의 처리 형태를 세부적으로 설정할 수 있는 항목이다.
입력의 종류, 처리 방식, 반환 값의 형태 등을 정의하여 다양한 입력 상황에 대응할 수 있도록 옵션이 제공된다.
각 옵션의 기본 설정은 Project Settings > Input System > Settings의 값을 따르며 개별 값을 조정하려면 Default 플래그를 끄고 직접 수정하거나 Settings Asset을 생성하여 값을 커스텀한다.
Action Type
입력 시스템의 동작 방식을 정의하는 요소로 각 타입마다 입력 이벤트를 처리하는 방식에 따라 다르게 동작한다.
Value, Button, Pass Through 세 가지 방식이 있다.
Action Properties - Action Type
Value
지속적인 입력 값을 반환한다. 입력이 활성화된 동안 현재 상태 값을 계속해서 업데이트한다. 주로 조이스틱의 위치나 슬러이더처럼 지속적으로 변화하는 값을 처리할 때 유용하다.
Button
버튼의 누름 상태를 감지한다. 점프, 공격, 상호작용처럼 단일 이벤트 트리거에 적합하다.
PassThrough
입력을 필터링 없이 그대로 전달한다. 가공되지 않고 호출 대상에 직접 전달되며 주로 복잡한 입력 로직, 멀티 컨트롤 입력, UI 입력 등에 활용한다.
Control Type
Action Type에 따라 달라지는데 Value인 경우 다양한 값 형식으로 가공해서 받을 수 있다.
Value - Control Type
Type
설명
반환 타입
예
Axis
단일 축(1차원)의 연속적인 값 (-1 ~ 1)
float
조이스틱 축, 키보드 이동, 마우스 휠 등
Analog
0.0 ~ 1.0 범위의 연속 아날로그 값
float
게임패드의 트리거, 슬라이더 등
Integer
정수 값
int
타임라인, 메뉴 인덱스 등
Digital
이진 값 (0 또는 1, true/false)
float or bool
버튼 입력, 온/오프 스위치 등
Double
높은 정밀도 실수
double
정밀 제어, 시뮬레이션 등
Vector2
2D 벡터
Vector2
2D 이동, 마우스/터치 위치, 텍스처 좌표 등
Vector3
3D 벡터
Vector3
3D 위치, 방향 등
Delta
변화량을 나타내는 값(차이값)
Vector2
마우스 드래그, 터치 슬라이드 변화량
Quaternion
3D 회전을 나타내는 사원수
Quaternion
컨트롤러 회전, 장치 방향
Stick
아날로그 스틱 입력
StickControl
게임 패드의 조이스틱
Dpad
4방향 디지털 입력
DpadControl
게임 패드의 십자키
Touch
단일 터치 정보
TouchControl
터치 스크린
Pose
위치 + 회전 정보
PoseControl
VR, AR 디바이스
Eyes
시선 추적 데이터
EyesControl
VR HMD, 아이 트래킹 장비
PlayerInput의 Behavior 방식에 따라 다르지만 Stick, Dpad, Touch, Pose, Eyes와 같은 타입들은 내부적으로 해당 클래스 타입(StickControl, DpadControl 등)으로 처리되며, Callback 방식에서 해당 클래스를 직접 참조하여 세부 데이터를 추출할 수 있다.
Interactions
Action의 세 가지 이벤트 상태(started, performed, canceled)에 도달하기 위한 조건을 세부적으로 정의하는 항목이다.
Action 상태
- started : 입력의 시작점
- performed : 입력이 성공적으로 완료된 시점
- canceled : 입력이 도중에 중단 또는 실패한 경우
Action Properties - Interactions
Hold
일정 시간 동안 누르고 있을 때만 유효한 입력으로 인식한다.
Interactions - Hold
Press Point : 입력 강도를 판정하는 것으로 어느 정도 눌렸을 때 Press로 보는지 판단하는 기준으로 트리거나 스틱 같이 값 변경이 미세한 경우에서 중요하게 판단된다.
Hold Time : Press Point를 넘은 후 이 시간만큼 입력이 유지됐을 때 performed 상태가 되고 그전에 입력이 중단되면 canceled 상태가 된다.
Multi Tap
일정 시간 안에 특정 횟수만큼의 입력이 발생했을 때 작동한다.
Interactions - Multi Tap
Tap Count : 몇 번을 입력해야 performed 되는지
Max Tap Spacing : 탭과 탭 사이 최대 허용 시간
Max Tap Duration : 각 탭이 유지될 수 있는 최대 시간
Press Point : 유효한 입력으로 판단할 최소 세기
입력 사이 간격이 Max Tap Spacing을 넘거나, 각 탭 유지 시간이 Max Tap Duration을 넘기면 canceled
Press
버튼을 누르거나 뗄 때 발생하는 단순 입력을 세밀하게 제어할 때 사용한다.
단순 버튼의 입력에 대한 처리라면 Action Type의 Button으로 설정하면 되고 세부 제어가 필요한 경우 Press Interaction을 사용한다.
Interactions - Press
Trigger Behavior : Press Only, Release Only, Press and Release 세 가지 상태가 있으며 각 상태는 버튼을 눌리는 순간, 떼는 순간, 누를 때 started 뗄 때 performed로 처리한다.
Slow Tap
버튼을 누른 뒤 일정 시간 후에 뗄 때 performed 상태가 된다.
Min Tap Duration : 탭이 performed 되기 위한 최소 시간
Hold와 비슷하지만 hold는 시간 조건이 됐을 때 performed, slow tap은 시간을 채우고 뗄 때 performed 되는 차이가 있다. 하지만 겹치는 동작이 발생할 수 있기 때문에 동일한 Action에서 Hold와 Slow Tap 두 인터랙션을 동시에 사용할 때는 조건을 명확하게 하여 구분할 필요가 있다.
Tap
버튼을 빠르게 누르고 떼는 동작을 인식한다.
Max Tap Duration : 입력이 Press Point 이상으로 감지된 이후에 started 상태가 되고 Max Tap Duration 안에 입력을 뗄 때 performed 된다.
Processors
입력값을 처리하여 최종적으로 Action에 전달되는 값을 조정하는 기능이다.
컨트롤러의 조이스틱, 마우스, 트리거 등 다양한 입력 장치에서 입력된 원시 값을 자동으로 보정, 변환, 필터링할 수 있다.
Action Properties - Processors
Axis Deadzone, Stick Deadzone
Axis Deadzone은 축 단위(float)의 선형적인 입력값에 대해 deadzone을 적용한다.
입력값이 min 보다 작으면 0, max 보다 크면 1, 그 사이의 값은 0 ~ 1 사이로 정규화된 값
Processors - Deadzone
주로 게임패드의 트리거와 같이 선형적인 입력에서 의도치 않은 작은 입력을 무시하거나 거의 끝까지 입력된 경우 1로 보정한다.
Example - Trigger Axis Deadzone
Stick Deadzone은 2D Vector 입력에 대해서 방사형 범위의 deadzone을 적용한다.
입력된 벡터의 길이(magnitude)가 min 보다 작으면 0, max 보다 크면 1, 그 사이값은 정규화하여 보정한다.
Processor - Stick Deadzone
게임패드의 아날로그 스틱 입력에서 중앙 근처의 미세한 입력을 무시하고 가장자리에 가까우면 1, 범위 내의 값은 정규화하여 보정한다.
Example - Stick Deadzone
Clamp
입력값이 특정 범위를 벗어나지 않도록 제한해 주는 기능이다. 즉, 최소와 최댓값을 지정하고 그 범위를 벗어나는 값은 경곗값으로 보정한다.
Processors - Clamp
Min : 입력값의 최솟값
Max : 입력값의 최댓값
Invert, Invert Vector2, Invert Vector3
입력값의 부호를 반전시킨다.
Processors - Invert
단일 수치(float) 뿐 아니라 Vector2, Vector3 타입의 입력에도 사용 가능하며, 각 축별로 플래그로 개별 설정할 수 있다.
Normalize, Normalize Vector2, Normalize Vector3
입력값을 -1 ~ 1 사이로 정규화한다.
Processors - Normalize
벡터의 크기는 무시하고 방향성만 필요한 경우에 사용한다.
Scale, Scale Vector2, Scale Vector3
입력 값에 곱셈 계수 Factor를 적용한다.
Processors - Scale
마우스 민감도 등 감도 조정에 사용할 수 있다.
Binding Properties
Binding
단일 입력 바인딩
Binding Properties - Binding
Path
이 Binding이 참조하는 입력 장치와 입력 경로를 지정하며 기본 입력 연결 포인트로, 해당 Action이 어떤 입력에서 데이터를 받을지 결정한다.
Show Drived Bdings : 입력 장치마다 자동으로 파생되는 바인딩 목록을 확인할 수 있다.
Use in control scheme
특정 Control Scheme에 이 Binding을 포함할지 여부를 정한다.
예를 들어서 Keyboard&Mouse, Gamepad, Touch 등으로 나누어진 스킴에서 이 바인딩이 어떤 스킴에서 사용되는지 지정한다.
Composite
복합 입력 바인딩
Binding Properties - Composite Binding
여러 입력 값을 조합해서 하나의 논리적 입력으로 만들 때 사용한다.
대표적으로 WASD 나 방향키 조합으로 Vector2 이동을 구현하는 것이 있다.
Composite Type
어떤 형태의 입력 조합인지 지정한다.
1D Axis
두 개의 입력을 받아서 -1 ~ 1 사이의 float 값으로 반환한다.
1D Axis
Negative 입력 -1, Positive 입력 +1 두 입력이 동시에 있다면 Which Side Wins에 따라 결과가 달라진다.
Composite - 1D Axis
Neither : 두 입력이 상쇄되어 0
Positive : Positive 입력 우선, +1 반환
Negative : Negative 입력 우선, -1 반환
2D Vector
네 개의 입력을 받아 Vector2(x, y) 값으로 결합하여 반환
Composite - 2D Vector
Up : +y
Down : -y
Left : -x
Right : +x
2D Vector - Mode
Analog : 아날로그 입력 값을 그대로 사용
Digital Normalized : 디지털 입력의 정규화 값
Digital : 입력이 있는 방향에 대해 -1/0/1의 벡터 구성
3D Vector
여섯 개의 입력을 받아 Vector3(x, y, z) 값으로 결합
Composite - 3D Vector
2D Vector에서
Forward : +z
Backward : -z
추가
모드는 동일하다.
Button With One/Two Modifiers
하나 또는 두 개의 Modifier 키와 Button의 조합이다.
Modifier의 입력이 있으며 Button이 눌려야 Action이 발생한다.
Composite - Button With Two Modifiers
일반적으로 shift, ctrl, alt 등의 키를 modifier 키지만 일반키를 Modifier로 사용할 수 있다.
Button With Two Modifiers
Override Modifiers Need To Be Pressed First : Modifier 키가 먼저 눌려야 Action이 발동되는지 결정하는 옵션
활성화 시 Modifier 키들이 먼저 입력된 상태에서 Button이 입력되어야 동작 비활성화 시 순서 상관없이 모두 눌려지면 동작
One/Two Modifiers
하나 또는 두 개의 Modifier 키의 조합이다.
Binding이 있지만 이 키의 입력은 상관없이 Modifier의 입력만으로 판단한다.
Composite - Two Modifiers
Button의 입력이 중요한 Button With ~ Modifier와 달리 Modifier의 입력만으로 동작의 조건이 충족된다.
Binding은 Modifier 입력을 기반으로 추가 입력을 받을 수 있는 여지를 만들어 주는 역할을 한다.
빌트인 컴포넌트인 PlayerInput을 플레이어 오브젝트에 추가해서 키입력을 바로 받을 수 있다.
unity - PlayerInput
Actions에 등록된 InputSystem_Actions를 열어볼 수 있는데 일반적으로 사용되는 키로 바인딩되어 있는 걸 확인할 수 있다.
unity - input action
이 파일을 수정해서 바인딩 키나 값을 변경하여 처리할 수 있다.
플레이어 조작 스크립트에서 이 입력을 가져다 쓰는 방법은 다음과 같다.
private void Awake()
{
rb = GetComponent<Rigidbody>();
}
private void FixedUpdate()
{
if (currentInput != Vector2.zero)
{
// 방향 설정
body.forward = new Vector3(currentInput.x, 0, currentInput.y).normalized;
// 속도 계산
float currentSpeed = walkSpeed;
Vector3 moveVelocity = new Vector3(currentInput.x, 0, currentInput.y) * currentSpeed;
// 물리 이동
rb.linearVelocity = moveVelocity;
// 애니메이션
animator.SetFloat("Move", currentInput.magnitude);
}
else
{
// 정지 상태
animator.SetFloat("Move", 0);
rb.linearVelocity = Vector3.zero;
}
}
public void OnMove(InputValue value)
{
moveInput = value.Get<Vector2>();
}
업데이트 안에서 이동키 입력으로 변경되는 moveInput 값을 갱신해서 플레이어를 움직인다.
unity - player move
Action Properties 설정을 통해서 필요에 맞춰 수정해서 쓸 수 있다.
unity - sprint properties
쉬프트를 누르면 달리고, 떼면 걷도록 상태를 변경하는 기능을 추가해본다.
기본 Action은 눌렀을 때만 처리하고 있는데 이 부분을 PressAndRelease로 변경한다.
그리고 Initial State Check를 활성화 해준다.
private void FixedUpdate()
{
currentInput = Vector2.SmoothDamp(
currentInput,
moveInput * (isSprint ? 1f : 0.5f),
ref smoothVelocity,
smoothTime
);
if (currentInput != Vector2.zero)
{
// 방향 설정
body.forward = new Vector3(currentInput.x, 0, currentInput.y).normalized;
// 속도 계산
float currentSpeed = isSprint ? sprintSpeed : walkSpeed;
Vector3 moveVelocity = new Vector3(currentInput.x, 0, currentInput.y) * currentSpeed;
// 물리 이동
rb.linearVelocity = moveVelocity;
// 애니메이션
animator.SetFloat("Move", currentInput.magnitude);
}
else
{
// 정지 상태
animator.SetFloat("Move", 0);
rb.linearVelocity = Vector3.zero;
}
}
private void PlayerAnimation(float moveAmount)
{
animator.SetFloat("Move", moveAmount);
}
public void OnMove(InputValue value)
{
moveInput = value.Get<Vector2>();
}
public void OnSprint(InputValue value)
{
isSprint = value.isPressed;
}
InputManager의 GetAxis처럼 입력이 서서히 -1 0 1 사이에서 움직이는 선택 없이 GetAxisRaw처럼 고정된 숫자로 값이 반환되는데 이 부분이 InputSystem에서 설정으로 제어 가능한 부분이 아닌 것으로 현재 판단되어서 일단 damp를 사용해서 임의로 값을 증가, 증감시켜 범위 내 변하는 값으로 움직임을 처리한다.
이 값이 필요한 이유는 애니메이션을 블렌딩으로 처리하기 때문에 자연스러운 애니메이션을 표현하기 위해서 시작-도착 값까지의 변화하는 값이 필요하다.
Sprite Renderer를 사용하는 상황에서 뭔가 발산하는 이펙트를 사용한다면 어떻게 하는 게 좋을까 생각하면서 파티클 시스템과 오브젝트를 직접 제어하는 방법 두 가지를 사용해 보았다.
있는 리소소 가지고 대충 테스트만 하려고 만들다 보니 별로 이뻐 보이진 않는다.
이러한 상황에서는 오브젝트를 가지고 직접 제어하는 게 나은 방식인 거 같다.
실제로 사용한다면 풀링을 해서 쓰겠지만 그럼에도 상당히 많은 오브젝트를 뿜어낸다면 파티클을 쓰는 게 적합하다고 보인다.
상황에 맞게 잘 조율하는 게 필요하다.
위에서 사용한 코드
using UnityEngine;
public class Coin : MonoBehaviour
{
private const float power = 10f;
private void OnEnable()
{
transform.position = Vector3.zero;
ApplyForce();
}
private void ApplyForce()
{
var rb = GetComponent<Rigidbody2D>();
float randomHorizontal = Random.Range(-1f, 1f); // -1 to 1 for left/right
Vector2 direction = new Vector2(randomHorizontal, 1f).normalized;
rb.AddForce(direction * power, ForceMode2D.Impulse);
}
}
using UnityEngine;
public class Coin : MonoBehaviour
{
private const float power = 10f;
private void OnEnable()
{
transform.position = Vector3.zero;
ApplyForce();
}
private void ApplyForce()
{
var rb = GetComponent<Rigidbody2D>();
float randomHorizontal = Random.Range(-1f, 1f); // -1 to 1 for left/right
Vector2 direction = new Vector2(randomHorizontal, 1f).normalized;
rb.AddForce(direction * power, ForceMode2D.Impulse);
}
}
대충 동전이 뿜어지는 듯한 모습을 중점으로 만들었다.
Coin 간에는 충돌처리하면 초기 한 위치에 모여있을 때 서로 부딪혀서 Physics2D > Layer Collision Matrix를 꺼두었다.
바닥에 충돌 후 튕기는 것과 미끄러지는 정도는 Phsics Material로 조절한다 (Friction 마찰력, Bounciness 탄성력)
UI Effect
위 내용들은 겸사겸사로 같이 정리한 내용이고 이 글을 쓰기 시작한 이유는 이 부분 때문이었다.
상황은 대충 이렇다.
간단한 퍼즐 게임을 만드는 중에 스프라이트 렌더러를 쓰기에는 귀찮은 부분들이 있어서 간단하게 만들려고 UI를 베이스로 해서 게임 로직들을 만들었고 그렇게 진행하다 보니 효과를 추가하는 과정에서 물리적인 부분을 사용할 수 없어 직접 위치를 이동시켜서 유사하게 재현할 수밖에 없었다.
UI Animation
using UnityEngine;
public class UICoinMaster : MonoBehaviour
{
[SerializeField] UICoin[] uiCoins;
bool isOn = false;
public void OnClick_UICoinMaster()
{
if (isOn)
{
foreach( var coin in uiCoins)
{
coin.gameObject.SetActive(false);
}
isOn = false;
}
else
{
foreach (var coin in uiCoins)
{
coin.gameObject.SetActive(true);
}
isOn = true;
}
}
}
using UnityEngine;
public class UICoin : MonoBehaviour
{
[SerializeField] private float initialForce = 10f;
[SerializeField] private float gravity = 9.8f;
[SerializeField] private float bounceForce = 0.5f;
[SerializeField] private bool isMoving = false;
private RectTransform rect;
private Vector2 velocity;
private Vector2 originPos;
private void Awake()
{
rect = GetComponent<RectTransform>();
originPos = rect.position;
}
private void OnEnable()
{
ApplyPower();
}
private void OnDisable()
{
rect.position = originPos;
}
private void ApplyPower()
{
float randomX = Random.Range(-1f, 1f);
velocity = new Vector2(randomX, 1f).normalized * initialForce;
isMoving = true;
}
private void Update()
{
if (!isMoving) return;
velocity.y -= gravity * Time.deltaTime;
rect.anchoredPosition += velocity * Time.deltaTime;
if (rect.anchoredPosition.y < 0)
{
rect.anchoredPosition = new Vector2(rect.anchoredPosition.x, 0);
velocity.y = -velocity.y * bounceForce;
velocity.x *= 0.8f;
if (Mathf.Abs(velocity.y) < 0.1f)
{
isMoving = false;
}
}
}
}
UI 크기에 맞춰서 값들을 적절하게 세팅하면 그럴듯해 보인다. 구현하는 데는 크게 무리가 없지만 UI 가지고 이래도 되나 싶은 생각이 들기도 한다.
개인적으로는 필요한 기능만 직접 구현해서 쓰는 걸 선호하는 편이라 잘 쓰진 않지만 위처럼 UI를 제어하는 데는 DoTween을 사용하는 게 더 간단하고 다양한 동작들도 처리할 수 있을 것이다.
UI Particle System
한 번쯤은 'UI위에 파티클 뿌리기'에 대해서 많은 고민과 탐구를 해보았을 것이다. 이 경우 나는 주로 카메라의 렌더링 모드를 Screen Space - Camera로 세팅해서 파티클을 보이게 하는 방법을 사용했다. 그런데 이 방법은 원하는 파티클을 사용할 때나 좌표계를 다룰 때 은근히 귀찮고 까로운면이 있었다.
예전 에디터 버전에서는 Asset Pipeline 은 version 1, 2를 구분하여 선택하여 사용할 수 있었지만 최근 버전에서부터는 Asset Pipeline 2로 자동설정되며 선택할 수 없다.
Asset Pipeline
에셋을 처리하는 과정에 대한 설정을 관리하는 항목들이다.
Remove unused Artifacts on Restart
재실행시 사용하지 않는 아티팩트들을 삭제할지 여부에 대한 토글로기본으로 활성화된 상태이다.
Remove unused Artifacts on Restart
유니티는 에디터가 실행될 때 라이브러리 폴더의 artifact 파일과 에셋 데이터베이스 엔트리에서 제거한다.
가비지 콜렉션의 형태로 이 설정을 비활성화하면 에셋 데이터베이스의 가비지 컬렉션이 비활성화된다.
즉 더 이상 사용하지 않는 수정된 아티팩트가 에디터가 재실행될 때에도 계속 보존되기 때문에 예상하지 못한 임포트 결과를 디버그 할 때 유용하다.
하지만 계속해서 사용하지 않는 데이터들이 쌓여갈 수 있기 때문에 일반적인 상황에서는 활성화해두는게 나을 것 같다.
라이브러리 폴더
유니티에 임포트 된 에셋은 두 가지 버전으로 구분된다. 하나는 사용자가 사용하기 위한 것이고 다른 하나는 유니티가 사용하기 위한 것이다. 이 유니티가 사용하기 위한 에셋은 프로젝트의 라이브러리 폴더에 캐시로 생성된다. 즉 라이브러리 폴더 내의 캐시들은 로컬에서 에디터가 빠르게 작업을 처리하기 위해 사용하는 정보들로 많은 정보들을 계속해서 저장하기 때문에 용량이 큰 편이다.
로컬에서만 필요한 이 정보들은 프로젝트가 켜질 때마다 확인하는 과정을 거치며 폴더가 없으면 다시 생성하기 때문에 프로젝트를 공유하는 경우에는 제외시켜도 되는 파일들이다.
Parallel Import
Parallel Import
에셋을 임포트 할 때 동시에 진행하도록 하는 설정이다.
Parallel Import tip
해당옵션은 기본으로 비활성화되어있고 이 경우 에셋을 순차적으로 임포트 하게 된다.
이 기능은 특정 유형의 에셋에서만 지원되며 에디터가 프로젝트 폴더에서 에셋이 새로 임포트 되거나 수정된 에셋을 감지하고 자동으로 임포트 할 때 발생하는 에셋 데이터베이스가 새로고침을 수행할 때만 실행된다. 이때 에셋은 하위 프로세스에서 임포트가 실행된다.
특정유형
- Texture Importer로 가져온 이미지 파일
- Model Importer 로 가져온 모델 파일
특정 유형은 임포트 시간이 오래 걸리는 두 가지로만 구성되며 현재 버전까지는 별도의 스크립터블이 가능한 API는 마련된
지 않은 상태이다.
Parallel Import
이외의 유형은 해당 설정이 활성화되어 있어도 순차적으로 임포트 된다.
Desired Import Worker Count
병렬 임포트에서 사용할 작업 프로세스의 최적의 수
Standby Import Worker Count
쉬고 있는 상태에서도 유지시킬 최소의 작업 프로세스의 수
에디터에서 작업에 필요한 프로세스의 수가 최소보다 큰 경우 쉬고있는 프로세스를 중지시키고 시스템 리소스를 확보하도록 한다.
Idle Import Worker Shutdown Delay
쉬는 상태의 작업 프로세스를 종료할 때 대기하는 시간
또한 Edit > Preferences > Asset Pipeline에서 새 프로젝트에서 필요한 작업 프로세스의 기본 값을 제어할 수 있다.
Preferences > Asset Pipeline
Import Worker Count % 의 값을 사용하여 Desired Import Worker Count 값을 할당할 수 있다.
이때 할당되는 값은 시스템에서 사용할 수 있는 논리 코어 수의 비율에 해당한다.
(16개의 논리 코어가 있다면 이중 25%를 할당하여 Desired Import Worker Count 값은 4가 할당된다.)
Cache Server (project specific)
Cache Server
Asset Pipeline 1 일 때 사용한 기능으로 버전 2에서는 기본으로 비활성화되어 있고 활성화할 수 없고 Unity Accelerator로 대체되었다.
Accelerator
팀 작업 속도를 높이기 위한 기능이다.
임포트 한 에셋의 사본을 유지하는 캐싱 프락시 에이전트이다. 팀이 동일한 네트워크에서 작업할 때 프로젝트 일부를 다시 임포트 할 필요가 없도록 하여 반복 시간을 줄일 수 있도록 돕는다.
