20231207_팀 프로젝트 회고

오늘의 TIL은 팀 프로젝트 발표 및 피드백에 관한 내용이다.

 

오늘 팀 프로젝트를 마무리하는 과정에서 생겼던 문제들을 해결하는 내용으로,

 

Unity Editor를 이용하여 작업하는 상태에서는 발생하지 않았던 문제들이 Build한 프로그램에서는 발생하였다.

 

1. Debug.Log();에서 한글을 사용해서 발생하는 오류(렉)

작업하는 과정에서 남아있던 Debug와 관련된 내용으로,

Debug.Log();가 남아있다면 Build한 프로그램이 무거워지고 렉이 발생할 수 있는데,

그 Log의 내용에 한글이 들어가있다면 UTF-8로 글을 수정하는 과정까지 거치기 때문에

영어나 숫자를 사용하는 경우보다 더 무거워지고 렉이 발생할 수 있다.

 

특히 남아있던 Debug.Log();에 관한 내용이 점수를 실시간으로 표기하는 정보를 체크하기 위했던 것으로,

실시간으로 계속해서 Debug를 하다보니 렉이 심하게 발생했다.

이는 Debug.Log();를 지우거나 주석처리하는 것으로 해결했다.

 

 

2.데이터를 세이브하는 과정에서 csv 파일을 사용할 때 발생한 문제.

스코어를 관리하는 과정에서 csv 파일에 데이터를 저장하여 이를 가지고 ScoreBoard에 표시하도록 하고있었는데,

Unity Editor에서는 사전에 만들어둔 파일을 가지고, 그 파일의 경로를 지정해주어서 문제가 발생하지 않았었지만,

 

Build한 프로그램의 경우, 지정한 경로에 csv 파일이 없어서 문제가 발생하였다.

이를 해결한 방법은 csv 파일이 존재하지 않는 경우에 csv 파일을 만들도록 생성하도록 로직을 추가함으로써 해결했다.

 

 

3. Build 시에 화면 해상도 관련 문제

Build 하는 과정에서 사전에 설정한 해상도인 720 X 1280 으로 게임을 Build 해야되는데,

컴퓨터의 Fullscreen으로 Build 함으로써 문제가 발생하였다.

 

해결 과정

1) Build 하는 과정에서 Player Settings에서 Resolution and Presentation에서 Fullscreen Mode -> Windowed로 변경

2) Default Screen Width, Height를 맞는 수치( 720 X 1280 )로 변경

   (만약 크기를 조절할 수 있게 하려면 Resized Window를 체크)

3) 이후 각 Scene에 존재하는 Canvas Scaler들을 수정.

4) 각 Canvas Scaler들의 UI Scale Mode -> Scale With Screen Size로 변경

5) Reference Resolution을 위에서 조정한 수치( 720 X 1280 )으로 변경

6) Screen Match Mode 를 Match Width Or Height로 변경

7) Match 를 1(Height를 기준으로 하도록) 변경

을 통해서 Unity Editor에서 보던 화면과 같은 크기의 UI를 구현할 수 있었다.

 

---

 

아래는 발표 과정에서 튜터님들이 말씀해주셨던 피드백에 관한 내용이다(모든 팀들의 피드백을 종합)

 

1. 몬스터 생성 및 파괴를 관리하는 경우, 오브젝트 풀을 사용하는 것이 좋다.

-> 오브젝트 풀을 사용하지 않는다면 가비지처리에 문제가 발생하여 렉이 발생할 수 있다.

 

2. 함수가 중복으로 만들어져서 사용되는 경우가 있다.

-> 함수가 중복으로 사용되어야하는 경우, 상속을 받아서 불러오는 것이 효율적이다.

 

3. UI의 크기와 관련된 문제

-> 게임을 개발하는 경우에 초기에 해상도를 미리 정하고 개발하는 것이 좋다.

 

4. 게임 오브젝트끼리 충돌하는 문제

-> Unity 옵션에서 충돌 매트릭스에서 특정 오브젝트끼리는 충돌되지 않게 설정할 수 있다.

 

5. Coroutin, DonDestroyOnLoad에 관련되서 공부하면 좋다.

-> 이후에 TIL이나 공부한 것으로 정리해서 올리면 좋을 것 같다.

 

6. 아이템 효과를 적용하는 경우에는 그 스크립트가 아니라 관리하는 스크립트에서 하는 것이 좋다.

-> 아이템 효과를 적용하는 경우에 Ball이나 Paddle 스크립트에 그 효과를 바로 적용하는 경우가 많은데,

그런 식으로 적용하는 것보다 GameManager 등에서 효과를 받을 객체를 가지고 있다가

아이템 효과를 적용하는 것이 좀 더 효율적이고 좋은 방법이다.

 

7. GameManager에 너무 많은 것을 담지 말아야한다.

현재 GameManager의 사용법을 잘 몰라서 필요한 내용들을 GameManager에 담는 팀이 많은데,

SOLID 원칙에 따라 GameManager도 단일 책임으로 만드는 것이 이상적이다.

 

GameManager가 관리해야되는 부분이 많기에 어느정도 책임이 늘어날 수 있지만,

가능하다면 최소한의 책임(가능하면 단일 책임)으로 만드는 것이 이상적이라고 피드백해주셨다.

---

 

일주일간의 Unity 기초 프로젝트가 끝났는데,

 

이전과는 다르게 좀 더 구체적이고 명확한 주제가 정해지고,

 

이를 팀별로 구현하면서 좀 더 수월하게, 목적성을 가지고 프로젝트를 진행할 수 있었다.

 

유니티를 사용하는 것으로 생기는 문제가 발생하는 것이 고충이 된 부분이지만,

 

C#의 콘솔만을 사용해서 작업하는 것보다 훨씬 이해하기 쉽고 적용하기도 쉬웠던 프로젝트였다.

 

충돌이 일어나는 경우에도 이전에는 수정하기 어려웠지만,

 

현재는 GitHub Desktop을 이용하여 보다 수월하게 수정할 수 있었다.

 

내일부터는 좀 더 심화적인 과정을 가지고 개인과제 및 팀프로젝트를 해야되는데,

 

이번 프로젝트를 진행하면서 부족한 점을 많이 발견할 수 있었다.

 

돌아오는 개인과제 시간에 개인과제를 수행함과 동시에 부족했던 지식을 쌓을 수 있도록 노력할 것이다.