최종프로젝트 개발일지
- 오늘 본격적으로 기획회의 갈무리하고 프로토타입 개발에 들어갔다.
- 튜터님들이 보고 생각보다 볼륨이 있어서 난이도가 있을거라고 해서 팀원분들과 얘기를 잘 해서 작업분배를 잘 해야겠다.
- 우선 난 목축시스템을 맡아서 동물들을 관리할 예정이다. 오늘은 프레임워크좀 가다듬고 어드레서블 에셋을 하느라 메인 로직을 못짜서 내일부터 진행할 예정
Addressable
<출처 : https://devshovelinglife.tistory.com/398>
- 오늘은 최종프로젝트 특강 때 진행한 어드레서블을 정리해보고자 한다.
<챌린지반 강의노트>
Resources
- 어드레서블을 알기 위해선 먼저 유니티의 리소스 관해 얘기를 해보면 좋을 것같다. 초기 유니티에선 Resources.Load를 이용한 방식으로 관리를 했는데 이방법은 Load를 할때마다 Resources폴더를 전체 순회하는 방식이라 최적화 측면에서 좋지 못했다. 사용하기는 편하지만 메모리를 많이 먹고 비용적인 부분때문에 리소스폴더의 사용은 조심스럽게 사용해야 한다.
- 리소스폴더의 경우 단점이
- 앱사이즈가 커지고,
- 리소스 순회를 하면서 앱 시작 시간이 길어진다(가비지 컬렉터 문제)
- 앱이나 폴더 변경시 재빌드를 해야 한다.
- 에셋 이름 변경이 힘들다( 경로를 찾을 때 이름을 찾아 스크립트도 같이 수정을 해야함)
- 이러한 단점을 보완하기 위해 나온것이 에셋 번들이다.
에셋번들
- 리소스 압축 방식중 하나로 유니티 에디터에서 직접 등록해서 사용한다.
- 선택된 리소스와 관련된 나머지 리소스 전부 압축하는 방식(텍스쳐, 메테리얼, 이미지...etc)
- 과거 구글플래이의 업로드 용량 제한이 존재해서 사용하던 방법
- 빌드사이즈절감, 앱시작 시간을 단축시킨다.
단점
- 번들의 종속성 : 같은 이미지가 A와 B에 묶여 있다면 이미지가 따로 인식되어 2개로 인식된다.
- 사용하기가 어렵다 : 코드적 난이도가 있는편
Addressable의 등장
- 이러한 기존의 리소스관리의 단점들을 개선하기 위해 나온것이 어드레서블 에셋이다.
- 어드레스(주소)를 이용하여 에셋 위치에 상관없이 참조가 가능하다.
- 씬, 프리팹, 텍스트 에셋, 이미지 까지 모든 에셋을 어드레서블로 표시하고 고유한 이름을 부여할 수 있음
- 어드레스를 이용하여 에셋의 관리부터 로딩, 빌드가 통합된 시스템
- 어드레서블은 에셋번들을 토대로 설계되었는데 에셋번들의 리소스 압축 문제가 아니라 관리적 측면의 불편함과 사용방법에 대한 문제로 인해서 에셋번들의 편의성을 개선하기 위해 등장한 시스템이다.
장점
- 에셋 빌드와 배포의 단순화 : 레퍼런스, 리소스폴더, 에셋번들 분리가 단순화되고 편리해짐
- 효율적인 에셋 관리 : 종속성 파악, 중복된 에셋으로 메모리 낭비를 막음
- 초기 빌드 볼륨을 최소화
- 에셋별 동적 로드를 통해 메모리 관리 가능
단점
- 폴더째로 등록 할 경우 키 등록이 불가능함
- 키 등록을 직접하려면 에셋번들보다 힘들어진다.
- 결국 데이터 매핑을 직접 해야 사용성이 높아지는 구조
오늘의 회고
- 장마라고 하더니 비가 하나도안와서 덥기만해서 고생했다 ㅎ..
- 튜터님들이 이런저런 조언을 많이 해주셔서 잘 새겨듣고 해야겠다. 우선 스팀펑크적 요소는 농사와 기본 시스템을 잘 다듬은 상태에서 진행시켜야겠다.
- 생각보다 걱정인건 데이터저장하는것 스타듀밸리를 참고하라고 레퍼자료를 주셨는데 16만줄이나되는 json이라 걱정이크다 ㅎ.. 잘 정리해봐야지.
게임개발을 꿈꾸는 개발자