가을의 개발 일지

서론게임 개발을 하다보면, 꼭 한번쯤은 최적화에 관심을 갖게 된다. 내가 처음 최적화를 파던 건 2019년이었는데, 당시 만들던 2D 러닝 게임이 고사양 3D 게임에 버금갈 만큼 버벅였기 때문이다. 그러다보면 꼭 프로파일러를 켜게 되고, 갑작스런 프레임 드랍에서 렌더링, 물리 Vsync, 그리고 가비지 컬렉션(이하 GC)을 만나게 된다. 오늘은 그때의 기억도 되살릴 겸, GC에 대해 다시 공부도 할 겸 포스트를 작성한다. 이번 포스트에선 GC를 사용하는 이유, 정말 간단한 동작 원리, 어떻게 다뤄야 안정적인가에 대해 살펴보자.가비지 컬렉션(GC). 그거 왜 쓰는데?현재 많이 쓰이는 언어들 중, C와 C++을 제외한 많은 언어(Java, Kotlin, 파이썬, C# 등)들이 GC를 채택하고 있다. 그래서 ..

서론유니티 인스펙터는 잘 만들었지만, 사용하다보면 불편한 점이 꽤 많다.예를 들면, Dictionary는 에디터에 나오지 않는다던가. 조금 더 나아가면, 본인의 게임에 맞게 개조할 일도 생긴다. GUI로 스킬을 조립한다던지, 카드를 만든다던지 등등. 오늘은 그런 경우에 도움이 될, CustomEditor와 CustomPropertyDrawer에 대해 간단히 알아보자.CustomEditor. 왜 써야 할까?앞서 언급했듯, 유니티의 인스펙터는 가끔 불편한 점이 있다. 그중 대표적인 게 바로 Dictionary가 나오지 않는다는 것. 예를 들어, 아래 같은 상황이다. 이런 식으로 변수를 선언한 뒤 인스펙터로 가보면, 나머진 모두 잘 나오지만 Dictionary만큼은 나오지 않는다. 이제, CustomEdit..

서론유니티로 개발하다보면, 알기 싫어도 알게 되고, 또 모르면 가끔 크게 데이는 것들이 있다. 그중 하나가 바로 직렬화다. 이번 시간엔 앞서 예고했듯, 직렬화란 무엇인지 차근차근 이해해보고, SerializeReference의 작동 방식, 세이브/로드 구현 시 생겼던 에러 등을 되짚어보자. [Unity] SerializeField vs SerializeReference vs Serializable서론유니티 2019.3에 [SerializeReference]가 추가되었고, 현재 프로젝트에서 Custom Inspector와 함께 사용 중이다. 이번 포스팅에선 SerializeField와 SerializeReference의 차이를 간략하게 살펴보고, SerializeReferenceautumncat.tist..

서론유니티 2019.3에 [SerializeReference]가 추가되었고, 현재 프로젝트에서 Custom Inspector와 함께 사용 중이다. 이번 포스팅에선 SerializeField와 SerializeReference의 차이를 간략하게 살펴보고, SerializeReference의 개념, 올바른 사용법까지 살펴보자.SerializeField는 무엇인가?유니티를 좀 배워본 사람이라면, [SerializeField]를 아마 private 변수를 Inspector에 띄워주는 고마운 친구 정도로 알고 있을 것이다. 이는 절반 정도는 맞는 말이다. 해당 기능은 [SerializeField] Attribute의 부가 기능 정도로 볼 수 있으며, 실제 이 Attribute의 존재 의의는 필드를 직렬화 시킨다는..

이번엔 무엇을 했는가?깃허브에 새 레포지토리를 만들었다.  Gather code snippets that can easily snap onto Unity GameObjects and use right away. - miniron-v/Unity-Snap-On-Scripts" data-og-host="github.com" data-og-source-url="https://github.com/miniron-v/Unity-Snap-On-Scripts" data-og-url="https://github.com/miniron-v/Unity-Snap-On-Scripts" data-og-image="https://scrap.kakaocdn.net/dn/bimU77/hyXGKZUZer/Lh9cshgZkEQZIsKYesi..

귀찮은 걸 못 버티는 사람이 성공한다우리 게임 제노사이드는 시나리오를 아래처럼 관리한다.그리고 이걸 바탕으로 SO를 생성한다.   학기 중엔 이걸 하나씩 복붙 후 이름 변경으로 만들었다. 어디 그뿐인가? 스토리의 시작 번호, 끝 번호도 일일히 적어줘야 했다. 스토리를 20개 정도 추가해서 에셋을 만들려고 봤더니, 너무 귀찮았다!   그래서 GPT에 어떤 방법이 있을지 물어봤다. 간단하게 에셋 이름을 넘버링해 여러 개를 한 번에 만드는 방법을 물어봤다.    그러자 스크립트를 작성해 이를 자동화하는 방법을 추천했다. 그리고 생각했다. 그럼, 인덱스 정돈 혼자 만들 수 있겠는데? 자, 그럼 직접 구현해보자!시작은 늘 구조부터다행히 구조가 복잡하진 않다.   CSV를 불러와 만든다.이미 에셋이 있다면 건들지 ..

어찌어찌 완성은 했다만... 아직 부족한 점이 많다. 펀치 마스크를 활용하며 추가적인 마스크를 쓰지 못하게 된 점이때문에 Block 이미지로 앞을 가려줘야 하는 부분이라던지.DOTween과 Update의 충돌부자연스러운 그림자 위치맞물리지 않는 BackPage와 Mask의 관계등등. 하나씩 개선을 해보자.DOTween과 Update의 충돌DOTween으로 인한 이동과 Update에서의 계산 순서가 정해져 있지 않은지, 책 페이지를 넘길 때마다 BackPage가 잠깐 보이는 현상이나, 맨 윗 줄이 딱 맞물리지 않는 현상이 발생한다.  예를 들면 위 사진같은 상황이 발생한다. 이동한 것보다 더 돌아가서, 정확히는 덜 줄어들어서 위처럼 빈칸이 남아버린다. 이를 고치기 위해선 DOTween 대신 Coroutin..

지난 포스팅에선 위 부분까지 구현했었다.이제 음영을 넣어 자연스레 만들고, 페이지를 늘려 책 한 권을 완성시켜보자.페이지 늘리기원래 음영을 먼저 하는 게 자연스러운데, 까먹고 늘리는 걸 먼저 해버렸다. (이러면 나중에 음영을 일일이 추가해줘야 한다.) 먼저 프리팹화하고, 하이어라키 창에 여럿으로 늘렸다.  그리고 Blocker는 Book의 바깥쪽으로 빼줬는데, 이후 코드에서 Child를 가져올 때 섞이지 않게 하기 위함이다. 개념적으로도 이게 맞고.  그리고 동시에, Page 내 Back Pivot이 제어하던 이동 함수(MoveCorner)를 Book이 전부 관리하게 바꿨다. 굳이 왜 그랬냐면 MoveCorner 스크립트를 또 배열에 담는 게 낭비 같아서...   그렇게 코드는 아래처럼 변경되었다. us..