All content in this course uses:

Unity Editor 워크플로와 개발 과정을 더 효율적으로 만드는 실용적인 팁과 단축 작업을 익힙니다.

Unity 팁

Unity 개발을 더 빠르고 편리하게 하기 위한 유용한 팁 모음입니다.

CTRL(PC)나 CMD(Mac)를 누른 상태에서 이동, 회전, 확대/축소할 때 개체를 스냅합니다. 또한 V를 사용하여 정점을 함께 스냅합니다. 편집 - 스냅 설정을 선택하여 스냅 설정을 변경합니다.

스내핑

인스펙터에서 프리뷰 창으로 많이 작업하시나요? 상단의 막대를 오른쪽 클릭하여 도킹을 해제하고 원하는 위치에 배치하세요.

프리뷰 창의 도킹 해제

빠르고 쉽게 카메라를 배치하고 싶으신가요? 게임 오브젝트 사용 - 뷰에 맞춥니다.

손쉬운 카메라 배치

플레이 모드에서 Unity는 씬의 게임 오브젝트 인스턴스에 변경 사항을 저장하지 않습니다. 편집을 계속하려면 항상 플레이 모드를 꺼야 합니다 - 플레이 모드 중에 편집기를 틴트하여 작업한거 잃을 수 있는 실수를 피할 수 있습니다. 

플레이 모드 에디터 틴트

Unity의 특정 컴포넌트에 대한 도움말이 필요하신가요? 각 컴포넌트 헤더의 오른쪽에 있는 책 아이콘을 클릭하기만 하면 됩니다.

문서 바로 가기

조정을 위해 인스펙터에서 float 변수를 노출시키시겠습니까? 스크립트에서 변수 위에 Range 선언을 추가하면 public 변수를 슬라이더로 즉시 변환할 수 있습니다.

[Range(min, max)]를 사용하여 public 변수를 슬라이더로 표시

hierarchy 검색에서 스크립트나 컴포넌트의 대소문자를 구분하는 전체 이름을 입력하여 연결된 게임 오브젝트를 표시합니다.

컴포넌트 이름으로 씬에서 오브젝트 찾기

수학 계산을 편집기의 int나 float 필드에 직접 입력하세요!

숫자 필드의 수학 계산

선택하지 않았을 때 빈 게임 오브젝트를 보이게 하려면 표준이나 커스텀 아이콘을 할당합니다.

씬 뷰에서 빈 게임 오브젝트에 대한 사용자 지정 아이콘 사용

전체 게임 오브젝트를 복사하는 방법을 보여주며 단일 컴포넌트의 설정을 복사할 수 있습니다. 추가로 플레이 모드 중에 수행된 변경 사항을 복원할 수 있습니다. 

플레이 모드에서 변경한 내용을 복사하고 복원하는 방법

Unity를 사용하는 가장 큰 장점 중 하나는 에디터 인터페이스와 인스펙터 패널을 쉽고 빠르게 사용할 수 있다는 것입니다. 변수는 인스펙터에서 사용할 수 있도록 public이어야 합니다... 아니면 반드시 그래야 합니까? 아닙니다 인스펙터에서 "Serialize Field" 속성을 사용하여 private 변수를 노출하고 조작할 수 있습니다!

인스펙터에 private 변수 표시

Add Component Button 메뉴의 Search 필드를 사용하여 새 스크립트를 빠르게 만들고 첨부할 수 있습니다.

Add Component 바로 가기로 빠르게 새 스크립트 만들기

Unity는 파일을 구성하는 다양한 방법과 게임 제작 방법을 제공합니다. 이러한 자유는 빠른 프로토타이핑을 가능하게 하지만 프로젝트가 더 커질 때 프로젝트를 열거나 탐색하거나 개발하는 데 잠재적으로 더 느려질 수 있는 대가를 치르게 됩니다. 이 가이드는 이를 완화하는 방법에 대한 지침과 힌트, 프로젝트를 시작할 때 고려해야 할 팁을 제공합니다.

Unity 프로젝트 작업을 시작하기 전에 몇 가지 단계를 고려해야 합니다.

소스 컨트롤을 사용하는 것은 모든 프로젝트에서 매우 중요합니다. 실수를 최소화하기 위한 보호 장치를 제공하고 팀으로 작업하기 단순화합니다. Unity에는 라는 소스 컨트롤 서비스가 있습니다. 

Git, Svn, Mercurial 또는 Perforce와 같은 외부 소스 컨트롤을 사용하는 경우 몇 가지 설정을 구성해야 합니다.

선택한 소스 컨트롤에서 폴더를 제외합니다 

 다른 컴퓨터에서 프로젝트를 열 필요가 없으며 저장소를 어지럽히고 저장소를 불필요하게 사용하기 때문입니다

버전 컨트롤 > 프로젝트 설정 > 편집

: 파라미터와 가져오기 설정이 저장되는 자산 옆에 메타 파일이 배치됩니다. 이러한 파일을 버전 컨트롤에 포함하여 가져오기 설정 및 참조를 공유할 수 있습니다. 그렇지 않으면 이러한 설정이 라이브러리 폴더에 저장되며 팀 구성원 간에 공유할 수 없습니다.

: 모든 Unity 파일(ScriptableObjects, Scenes, Prefabs 등)이 바이너리 표현 대신 텍스트 표현을 사용하도록 합니다. 이를 통해 소스 컨트롤에서 파일의 완전히 새로운 복사본이 아니라 이러한 파일이 변경될 때 수정 사항만 저장할 수 있으며 충돌을 수동으로 병합할 수 있습니다 

(참고 : 매우 큰 프로젝트에서는 텍스트 자산과 바이너리 에셋을 가져 오는 데 필요한 추가 시간이 상당히 눈에 띄는 차이를 만들 수 있습니다. 대부분의 프로젝트는 바이너리에 비해 텍스트의 이점이 가져 오는 시간에 의해 극복되는 크기 임계 값에 도달하지 않으므로 시작 부분에서 텍스트로 설정하는 것이 여전히 권장됩니다)

Perforce 사용자를 위한 참고 사항:

 Perforce Workspace 설정에서 "revert unchanged files"를 사용합니다. “revert unchanged files”를 사용하며 변경되지 않은 파일의 불필요한 커밋을 방지할 수 있습니다.

프로젝트에 참여하는 모든 사람이 동일한 표준을 사용하도록 프로젝트의 표준을 결정합니다.

 : Unity의 한 단위가 무엇인지 결정하고, 그렇지 않으면 모델이나 스프라이트가 통일된 스케일을 사용하여 생성되지 않습니다. 오브젝트마다 다른 크기 조정을 도입하면 모든 종류의 문제가 발생할 수 있습니다.

Rigidbody 컴포넌트를 사용하는 대부분의 3D 게임에서는 물리 시스템이 적절한 시뮬레이션을 위해 1단위 = 1미터를 사용하는데, 이는 물리 시스템이 적절한 시뮬레이션을 위해 이를 요구하기 때문입니다

Rigidbody 컴포넌트를 사용하는 2D 게임의 경우 1미터 1단위와 동일한 "기본 스프라이트 크기"를 정의합니다. 예를 들어 32px = 1미터 1단위입니다. 모든 스프라이트 설정 

 이 값으로 설정하면, 높이가 64px이고 PPU가 32인 캐릭터 스프라이트는 2유닛이 되므로 물리 시스템의 높이는 2미터가 됩니다.

에셋은 모두 명명 규칙을 따라야 합니다. 접미사를 추가할 수 있습니다(텍스처의 예는 다음과 같습니다. 

N(노멀 맵) 또는 _AO(앰비언트 오클루젼 맵) 또는 접두사(예: LowRes

 또는 변형에 대한 HighRes_) . 검색을 통해 필터링할 수 있으며 사용자 지정 가져오기 설정 값을 자동으로 작성하는 데 도움이 될 수도 있습니다.

Unity 에디터의 프로젝트 뷰를 사용하여 에셋을 정리할 수 있습니다. Unity는 에셋의 임포트 설정을 저장하는 각 에셋 파일 옆에 메타 파일(활성화된 경우 소스 컨트롤 참조)을 유지합니다. 즉, 다음을 수행해야 합니다. 

OS 파일 탐색기를 통해 파일을 이동하지 마십시오.

, 모든 것을 제대로 이동하므로 항상 Unity 에디터 내부에서 이동하십시오. 에디터 외부로 이동해야 하는 경우, 

메타 파일을 같이 이동하는 것을 잊지 마십시오

그렇지 않으면 참조와 가져오기 설정이 손실됩니다.

프로젝트를 쉽게 탐색하려면 루트 Assets 폴더에 파일을 배치하지 마십시오. 하위 폴더를 사용합니다. 이러한 하위 폴더를 구성하는 방법은 일반적으로 프로젝트에 따라 결정되지만 두 가지 주요 방법은 다음과 같습니다.

각 자산 유형에 대한 폴더와 개체별, 영역별 하위 폴더(예: 

오브젝트 또는 영역별 폴더(예: 

Assets/Level1/Enemies/Archer, Assets/Shared/UI, Assets/Forest/Trees

)을 폴더에 있는 자산과 관련된 모든 자산(

두 번째 방법은 사용할 계획이라면 도움이 될 것입니다. 

 그런 다음 상위 폴더를 특정 번들에 추가하고 관련 자산을 다른 번들을 통해 쉽게 분할하여 콘텐츠 테마별로 번들을 만들 수 있습니다.

프로토타입 또는 플레이스홀더와 관련된 모든 항목을 별도의 폴더 계층 구조에 유지하고, 배송 가능한 에셋/코드가 포함된 폴더와 폴더 간에 상호 참조를 피하십시오. 예를 들어, "normal" 파일 계층의 캐릭터 프리팹은 프로토타입 폴더의 테스트 재질을 참조해서는 안 됩니다. 프로토타입 폴더에 있는 프로토타입 캐릭터 프리팹을 만들고 프로토타입이 아닌 장면에서는 해당 프리팹을 사용하지 않습니다(이 규칙이 적용되는지 확인하기 위해 프로토타입 폴더의 오브젝트에서 사용하는 참조를 확인하는 편집기 스크립트를 작성할 수도 있습니다).

Resources 폴더는 가능한 한 많이 사용하지 마십시오.

 Resources는 배치된 에셋을 사용하여 동적으로 로드할 수 있는 Unity의 특수 폴더 이름입니다. 

 코드에서. 일부 게임에는 동적으로 로드된 에셋이 필요하지만, Unity는 사용하지 않는 에셋을 제거할 수 없으므로(코드를 통해 로드하는지 여부를 알 수 없음) 해당 폴더의 모든 항목이 최종 빌드에 포함되므로 해당 폴더에 배치하는 에셋을 최대한 최소화하려고 합니다.

경로 및 filename을 코드에서 로드하여 리팩토링(파일 이동, 이름 바꾸기)이 더 어려워지고 오류가 발생하기 쉽습니다. 리팩토링이 어려워지는 이유는 코드에서 경로나 이름을 수동으로 변경해야 합니다. 

직접 참조(Monobehaviour의 public 변수)를 사용하여 편집기를 통해 할당합니다. 이를 통해 파일 이동 또는 이름 바꾸기도 지원됩니다.

정말로 필요하거나 사용하고 싶다면 

 실행을 차단하지 않는 함수의 버전입니다(일부 장치에서는 로딩하는 데 시간이 오래 걸릴 수 있음). 이 함수는 

 모든 업데이트를 폴링하여 완료되었는지 확인하거나 다음과 같이 completed 이벤트를 사용할 수 있습니다.

Unity는 다양한 소프트웨어(Photoshop, 3DS Studio Max 또는 Blender)에서 소스 파일을 직접 임포트할 수 있는 방법을 제공합니다. 빠른 테스트 또는 프로토타이핑에 사용되는 경우, 

소스 컨트롤에 커밋하거나 프로토타이핑이나 테스트 단계를 지나 Assets 폴더에 보관하지 마십시오

이러한 파일은 일반적으로 내보낸 파일보다 큽니다. 파일이 클수록 소스 컨트롤 기록이 복잡해지고, 하나를 수정할 때마다 소스 컨트롤에 새 버전이 저장되어 리포지토리 크기가 폭발적으로 커집니다.

이러한 파일은 Unity 프로젝트를 여는 컴퓨터에 설치되는 해당 파일이 속한 소프트웨어에 의존합니다. 올바른 소프트웨어가 설치되어 있지 않거나 빌드 머신이 없는 공동 작업자는 프로젝트를 열 수 없습니다.

이러한 파일을 별도의 소스 컨트롤 소프트웨어에 저장하거나(바이너리 파일에 더 적합할 수 있음) 그러지 못하는 경우 Unity가 파일을 가져오지 않고 자산을 Unity 호환 형식으로 내보내 Assets 폴더에 배치하고 게임에서 사용할 수 있도록 Assets 폴더 외부에 저장하는 것이 좋습니다.

애셋 크기를 가능한 한 작게 유지하십시오(나쁜 예는 테이블 위의 커피 머그잔을 위해 2048x2048 텍스처를 내보내는 것입니다). Unity 임포트 설정에서 텍스처의 크기를 줄일 수 있지만 텍스처의 임포트 시간은 줄어들지 않으므로 프로젝트의 새 버전에서 초기 설정이 훨씬 길어집니다.

어떤 형식으로든 로컬에서 테스트하되 결정한 후에는 오디오 및 이미지 파일에 압축된 형식을 사용합니다. .png/.tga/.tiff 이미지(또는 이미지 소프트웨어가 내보내기를 지원하는 경우 .dds), .ogg 오디오. Unity는 훨씬 더 빠르게 임포트(또는 그냥 그대로 사용)하여 프로젝트의 원래 임포트 크기를 줄입니다.

ADF(어셈블리 정의 파일)는 폴더와 그 하위 폴더의 모든 스크립트를 별도의 DLL로 컴파일합니다. 변경된 스크립트 파일이 속한 dll로만 분할하여 컴파일 시간이 줄어듭니다. 예를 들어 모든 적 스크립트에 대한 ADF가 있는 경우 적 스크립트를 변경하면 모든 도우미, 플레이어, 게임 시스템, UI 스크립트가 다시 컴파일되지 않고 적과 관련된 스크립트만 다시 컴파일됩니다.

둘 이상의 팀으로 구성된 팀에서는 영역/에셋/기능의 소유권을 정의합니다. 씬이나 프리팹과 같은 일부 에셋은 여러 사람이 동시에 변경하는 것을 잘 처리하지 못해 충돌이 발생합니다. 주어진 자산을 변경할 수 있는(혹은 변경할 수 있는 권한을 부여할 수 있는) 한 사람이 있으면 이러한 문제를 피하는 데 도움이 됩니다.

프리팹 사용하세요 많이. 프리팹은 게임의 오브젝트 설정을 수정할 수 있는 단일 지점을 유지합니다. 불과 

 원래 프리팹의 변경 사항은 중첩된 프리팹으로 푸시되지 않습니다.

프리팹 사용하세요 많이. 프리팹과 마찬가지로 씬이나 오브젝트 간에 공유할 수 있는 설정을 변경할 수 있는 단일 장소를 제공합니다. 스크립트 가능한 오브젝트가 다른 스크립트 가능한 오브젝트 또는 프리팹을 참조하고 씬의 게임 오브젝트가 해당 스크립팅 가능한 오브젝트를 참조하는 경우, 씬 게임 오브젝트가 로드되면 스크립트 가능한 오브젝트와 오브젝트에 대한 모든 참조의 로드가 재귀적 방식으로 트리거됩니다. 이로 인해 많은 다른 오브젝트나 콘텐츠를 참조하는 스크립트 가능한 오븍젝트에 대한 로딩 시간이 길어질 수 있습니다. 그러나 프로젝트가 씬 로드에서 한 번의 큰 로드로 오브젝트를 로드하는 것을 선호하는 경우 이를 유리하게 사용할 수도 있습니다.

계층의 뎁스를 최소한으로 유지합니다. 일반적으로 하나의 큰 계층 구조보다 루트에 있는 여러 개의 작은 계층 구조를 선호해야 합니다.

계층 깊이가 최소화된 이유는 Unity 트랜스폼 시스템이 트랜스폼이 변경될 때 모든 자식에게 알리기 위해 해당 계층 구조를 걸어야 하기 때문입니다.

다중 계층이 있는 이유는 변경 내용이 계층별로 추적되기 때문입니다. 따라서 루트에 100 개의 계층이 있고 그 중 하나의 객체를 변경하면 하나의 계층 구조 만 변환 순회를 갖게됩니다. 그러나 루트에 하나의 큰 계층 구조가 있는 경우 개체에 대한 변경 사항은 모든 개체에 대한 계층 구조 변경을 트리거합니다. 추가적으로 Unity는 루트 GameObject 계층 구조에 대한 변경 확인을 다중 스레드 변환합니다. 계층 구조가 많을수록 Unity가 더 많은 멀티 스레드를 수행하고 프레임당 여러 트랜스폼 변경의 속도를 높일 수 있습니다.

같은 이유로 모든 것을 배치할 수 있습니다. 

 (static environment, meshes, lights or sounds)를 단일 계층에 배치하면 장면 탐색/구성이 단순화됩니다. 변환이 변경되지 않기 때문에 위에서 언급한 단점이 적용되지 않습니다.

계층 뎁스를 확인하고 루트에서 계층 구조를 분산하려면 다음을 수행하십시오.

순수한 게임 플레이 오브젝트를 그래픽, 물리 및 오디오 표현과 중첩하지 마십시오. 무언가가 캐릭터와 함께 움직일 필요가 없다면 캐릭터의 자식이 되어서는 안 됩니다. 예를 들어, navmesh 에이전트 캐릭터의 순찰 지점을 처리하는 GameObject가 있으면 해당 캐릭터의 자식이 됩니다. 모든 순수 게임플레이 게임 오브젝트는 가능한 한 루트에 가까워야 합니다.

마찬가지로, 게임 오브젝트를 동적으로 생성할 때는 해당 오브젝트와 함께 이동해야 하는 경우가 아니라면 게임 오브젝트를 생성한 오브젝트의 자식으로 만들지 마십시오

계층 뎁스를 줄이면 엔진 성능에 도움이 될 뿐만 아니라 프로젝트에 참여하는 사람의 편의성과 편안함에도 도움이 됩니다. 더 얕은 계층 구조는 이해하고 탐색하기가 더 쉽습니다.

 애니메이션 임포트 설정의 릭(Rig) 탭에서 확인할 수 있습니다. 리그의 "스켈레톤" 게임 오브젝트가 생성되는 것을 방지하여 계층 구조가 줄어듭니다. 여전히 일부를 노출시켜야 하는 경우 (캐릭터에 장비를 부착하기 위해 하나를 타겟으로 사용할 수 있습니다) 수동으로 선택하여 이 것만 노출시킬 수 있습니다.

빈 GameObject를 사용하여 계층 구조를 구성합니다. 예를 들어 다음과 같은 GameObject를 사용합니다. 

참고로, 라이트의 부모로 만들어서는 안 되며, 그저 계층 구조에서 그 위에 위치해야 합니다

 위의 Hierarchy depth 및 count에 설명된 이유 때문입니다.

모든 것을 축소할 수 있도록 Light "헤더" 아래의 모든 라이트를 부모로 지정하기 쉽게 하려면, 빌드 또는 플레이 모드에 들어가기 전에 모든 것의 부모를 해제하는 에디터 스크립트를 작성해야 합니다, 그렇지 않으면 큰 장면에서 성능이 저하될 수 있습니다.

편집기에서 생성되고 실행되는 동적 오브젝트가 있는 경우 

 플레이 모드(예: 씬 뷰에서 리플렉션이 작동하도록 씬 뷰 카메라와 일치하도록 이동하는 리플렉션 카메라 또는 머티리얼에 할당된 씬 뷰에서 업데이트된 렌더 타겟)에서는 

 계층 구조에서 계속 보이게 하여 편집하려는 경우). 그렇지 않으면 위치나 내용의 모든 변경 사항이 씬을 더럽히고 매번 저장하도록 요청합니다. 이로 인해 누군가가 실수로 씬을 저장하고 소스 컨트롤에 커밋하는 경우 항상 모든 사람에게 발생하므로 충돌이 발생할 가능성이 커집니다.

개발/테스트/개선 주기의 속도를 향상시키려면 가능한 한 빨리 다양한 기능에 대한 "치트" 기능을 추가하십시오. 예를 들어 프로젝트에 통화가 있는 경우 치트를 만들어 엄청난 금액을 얻을 수 있습니다. 문을 열기 위해 아이템을 얻어야 하는 경우 해당 아이템을 즉시 부여하는 치트를 만드십시오. 레벨이 긴 경우 플레이어가 레벨의 한 지점에서 텔레포트할 수 있는 방법을 만드십시오. QA 및 디버깅이 훨씬 쉬워질 것입니다. 다음과 같은 여러 가지 방법으로 이 작업을 수행할 수 있습니다.

<b> [MenuItem("Cheat/MyCheat")] </b> 로 치트를 구현하는 스태틱 함수를 사용하면 에디터에서 상단 메뉴 항목을 통해 플레이할 때 치트를 할 수 있습니다.

특정 순서로 키를 누르거나 단순히 키보드의 F1/F2 기능 키를 사용하는 것을 기반으로 하는 오래된 "치트 코드".

키를 눌러 열 수 있고 명령을 입력하고 속임수를 쓰기 위해 해석할 수 있는 게임 내 콘솔을 코딩합니다.

이 모든 것을 정의로 코드로 래핑하십시오. 

 빌드 창의 체크박스를 체크하지 않으면 해당 치트가 제거되며, 모든 치트가 포함된 상태로 게임을 출시하지 않습니다. 다음 두 가지 방법으로 이 작업을 수행할 수 있습니다.

이를 통해 컴파일러가 비 개발 빌드에서 해당 함수를 무시 할 수 있으므로 해당 함수에 대한 호출은 무시됩니다.

또는 함수 내부의 부정 행위와 관련된 코드를 래핑합니다.

이렇게 하면 최종 빌드에서 제거됩니다. 그 사이에 함수를 래핑하면 해당 함수에 대한 모든 호출이 컴파일러에 대해 존재하지 않는 함수를 호출하기 때문에 빌드가 실패합니다. 함수에 대해 위의 Conditional 속성을 사용하는 것이 좋습니다.

단일 기능을 테스트하기 위해서만 만들어진 작은 씬을 별도로 만들고 유지합니다. 예를 들어 전투를 테스트하기 위한 적들로 가득 찬 씬, 움직임을 테스트하기 위한 장애물 코스 화이트박스, 상호 작용 가능한 물체가 있는 장면 등이 있습니다. 이를 통해 기능을 개발, 개선 및 확인하고 기능이 새로운 기능으로 인해 손상되지 않는지 확인할 수 있습니다. 추가적으로 테스터가 "전체" 게임에서 발견했을 수 있는 문제를 보다 간단하게 격리할 수 있습니다. 예를 들어, 때때로 난간을 잡지 못하는 캐릭터가 있습니까? 이는 문제가 발생하는 지점에 도달하기 위해 레벨의 처음 5분을 20번 다시 플레이하는 것보다 작은 씬에서 재현하는 것이 훨씬 쉬울 수 있습니다.

Unity Version 2022.2