유니티 prefab
Prefab은 미리 구성된 게임 오브젝트 템플릿을 의미함
è 완성된 게임 오브젝트(컴포넌트 + 자식 + 설정 + 머터리얼 + 월드공간 위치 정보 등)을 에셋으로 저장해 놓음
è 에셋을 씬에서 가져와서 여러 번 꺼내서 사용할 수 있음
템플릿 : 한번 만들면 여러 씬/ 위치에서 재사용 가능함
è 프리팹으로 만들 때 월드공간의 트랜스폼, 로테이션, 스케일, 평행이동 정보를 가져옴
인스턴스: 프로젝트에서의 프리팹을 씬 공간에 블러올때는 인스턴스화 해서 불러옴(참조만)
오버라이드 변경: 씬에서의 프리팹의 정보를 변경하면 프로젝트의 메인 프리팹에 대해서는 변경 안되고 인스턴스에 대해서만 변경 됨 (Apply로 원본에 반영 가능).
프리팹 배리언트: 기본 프리팹 바탕으로 일부만 바꾼 서브탬플릿 생성 가능, 프리팹 우클릭 후 Create > Prefab Variant
네스티드 프리팹: 프리팹 안에 중첩하여 다른 프랩을 둘 수 있다
프리팹 모드: 프리팹 편집시 전용 에디터에서 프리팹의 로컬 공간에서 편집 가능
공부하다가 문제점
1. 날짜마다 만드는 기능들이 제각각 다른데 이를 하나의 Scene에 모두 처리해 버리면 언제 무엇을 만들었는지에 대해 관리가 어려움
2. 나중에 해당 기능에 대해서 재사용을 할 때 하나의 scene에 통합해 버리면 재사용하기 어렵다
è 구성 요소와 설정을 갖춤 게임 오브젝트를 쉽게 재사용 할 수 있고 설정으로 여러 인스턴스에서 공통적인 변경 사항을 적용할 수 있음
예를 들어 게임 개발 시 특정 캐릭터 이미지를 사용 중에 있는데 해당 캐릭터의 외형 이미지를 변경 할 경우 해당 이미지를 사용한 전체 scene 에 대해서 일일이 수정해야 하는 번거로움이 있을 수 있음
prefab으로 파일을 만들어 두면 원본 파일이 변경되면 프리팹으로 생성된 다른 오브젝트 또한 일괄적으로 변경됨
1. Reuseable(재사용성)
2. Constant(일관성)
3. Efficiency(효율성)
4. Manageable(관리성)
Prefab생성 방법
1. 하이러키 창에서 만든 오브젝트를 프로젝트 창에 드래그 앤 드롭하면 파란색 사각형 표시가 뜨면서 프리팹이 생성됨 해당 프리팹에 대해서 다양하게 설정을 두어 다양한 바리에이션을 둘 수 있음
2. 프리팹을 통해서 스포너 만들기 등을 통해 자동적으로 인스턴스가 반복되어 생성되도록 처리할 수 있음
3. 프리팹을 통해 변경 사항 등을 일괄적으로 처리되게끔 할 수 있음
프로젝트 관리 방법
프로젝트를 만들 때 날짜별로 관리하는 방법은 재사용성에 좋지 않음
2025-11-20
스크립트
머터리얼
오브젝트
로 하기 보다는 아얘
메인 루트 폴더를 두고 그 아래에
머터리얼
스크립트
인풋액션
쉐이더
오브젝트
씬
으로 나누어 관리하는게 좋다
1. 씬을 복사해서 관리하게 되면 서로 다른 씬에 대해서 동일 오브젝트에 대한 참조 등이 안되기 때문에 매번 새로운 오브젝트를 만들어서 생성해 주어야 함
2. 따로 만들어 놓은 씬간 병합이 어려움
3. 미리 만들어 놓은 오브젝트나 스크립트 등의 이름이 복사하였기 때문에 충돌함
씬의 역할을 단순하게 프리팹을 집어 넣는 껍데기 용도로만 사용하고 씬에는 중복될만한 요소등을 제거한 채로 관리해 주는게 좋다
1. 오브젝트 프리팹
2. 환경 프리팹
3. 나중에 게임 만들 때 해당 프리팹 들을 조합해서 모듈 느낌으로다가 넣기만 하면 됨
ð 이러한 방식을 실무에서 GameKit 이라고 부른다
프리팹 사용 규칙
Prefab 이름 규칙: 이름_형태_버전
Crosshair_UI_v1, FPSCamera_Core_v0.1
날짜 백업은 YYYYMMDD 형식으로 -> 엔진단에서 검색 쉬움.
중첩(네스티드) Prefab을 적극적으로 사용 (Player ← Head ← Camera ← Crosshair).
실험은 Variant로 하고, 괜찮으면 변경 내용만 Apply해서 원본을 업데이트.
유니티 GUID
유니티에서 파일 옮길 때 경로 변경 등의 문제에 대해서는 크게 걱정 안해도 됨
유니티는 파일 경로가 아닌 GUID 값으로 파일을 참조함
GUID(Globally Unique Identifier)
경로기반 참조시, 개발자가 경로를 실수로 바꾸거나 하면 해당 파일에 대한 연결관계가 끊어짐
è 일일이 경로를 재설정하거나 하면 시간 낭비이므로 엔진차원에서는 일반적으로 GUID 값으로 파일을 참조함
GUID는 해시 방식이 아니라 128비트 난수 기반 식별자
유니티의 모든 에셋에는 .meta 파일이 있으며 이 안에 GUID가 존재한다.
Unity Editor에서는 보이지 않지만
파일 탐색기로 폴더를 열어 보면 바로 보임
따라서
Script를 다른 폴더로 옮겨도
Material을 다른 폴더로 옮겨도
InputAction 파일을 다른 경로로 옮겨도
연결은 끊기지 않음
GUID를 찾을때 프로젝트 파일을 순회해서 찾지 않고 에셋 데이터베이스(AssetDatabase)를 통해서 찾음
데이터베이스는 Dictionary<GUID, FilePath> 형태로 되어 있음
즉, 초기에는 GUID와 파일 어셋에 대한 경로 연결 스캔이 한번은 필요함
한번 등록되면 나중에 사용될때(실제 우리가 사용할때)는 O(1)로 처리
Unity Scene 파일은 YAML직렬화 파일의 형태로 저장됨.
YAML은 json보다 더 읽기 쉽게 만들어짐
YAML JSON XML
è 데이터 직렬화 (serialization)
메모리 데이터를 전송 가능한 형태로 변환
YAML: 사람 친화적 + 복잡한 구조 표현에 강점 -> Unity가 사용하는 직렬화 형식
JSON: 경량 + 빠른 파싱 → 웹/통신용
XML: 엄격한 표준 + 스키마 → 레거시, 문서, 기업용
'Unity Study' 카테고리의 다른 글
| 2025-11-23 3rd perosn camera(2) (0) | 2025.11.24 |
|---|---|
| 2025-11-22 3rd person camera (0) | 2025.11.24 |
| 2025-11-20 raycast (0) | 2025.11.24 |
| 2025-11-19 Jumping (0) | 2025.11.24 |
| 2025-11-17 running (0) | 2025.11.24 |