■ 개요
○ 오늘 계획
- 중간점검 발표
- 앞으로의 2주치 팀 계획 세우기
■ 중간발표 예상질문 정리
○ 매니저들 중 일부만 new로 인스턴스를 생성한 이유
-
답변
-
MonoBehaviour를 상속받지 않은 매니저들은 new로 인스턴스를 생성했습니다. MonoBehaviour를 사용하지 않는 일반 클래스는 단독으로 인스턴스화하여 사용할 수 있습니다.
-
반대로 MonoBehaviour를 사용하는 클래스들은 Unity의 GameObject에 연결되어 있어야 합니다. Unity에서는 MonoBehaviour는 기본적으로 스크립트가 Unity 엔진과 상호작용하도록 하는 베이스 클래스입니다.
-
따라서, MonoBehaviour를 상속하는 스크립트는 Hierarchy 창에 표시되는 게임 오브젝트에 부착되어야 합니다.
-
-
이유
-
Unity Lifecycle 관리 : MonoBehaviour는 Unity의 주요 이벤트(Lifecycle Methods)인 Start, Update 등을 제공합니다. 이를 위해서는 해당 스크립트가 어떤 게임 오브젝트의 구성 요소로 존재해야만 합니다.
-
Scene과의 연결 : Hierarchy 창에 나타나는 오브젝트는 Unity Scene의 일부이며, 이는 게임 실행 중 메모리에 로드됩니다. MonoBehaviour 클래스가 GameObject에 부착되어 있지 않으면, 실행 중 동작하지 않습니다.
-
직접 관리 불가 : MonoBehaviour를 상속하는 클래스는 new 키워드로 인스턴스화할 수 없으며, 반드시 AddComponent() 또는 Unity 에디터를 통해 GameObject에 연결해야 합니다.
-
○ 매니저스를 사용한 이유
-
답변
- 싱글 게임에서 매니저 구조를 사용하는 것은 게임의 유지보수성과 확장성을 크게 향상시키는 데 유용합니다.
- 다음은 이러한 구조를 사용할 때 얻을 수 있는 주요 장점들입니다
-
이유
-
중앙 집중식 관리
- 상태 관리 : 매니저 클래스들은 게임 전반에 걸친 상태(예: 게임 진행 상태, 플레이어 정보, 설정 등)를 중앙에서 관리합니다.
- 데이터 공유 용이성 : 여러 오브젝트가 매니저를 통해 데이터를 공유하거나 접근할 수 있어 중복 코드가 줄어듭니다.
-
모듈화 및 코드 분리
- 각 매니저는 특정 책임(예: 오디오 관리, UI 관리, 게임 상태 관리)을 수행하므로 코드를 잘 분리할 수 있습니다.
- 기능별로 나누어진 매니저 클래스는 독립적으로 개발, 테스트, 디버깅할 수 있습니다.
-
싱글톤(Singleton) 패턴과의 조합
- 많은 경우 매니저들은 싱글톤으로 구현됩니다. 이는 게임 내 어디서든 동일한 인스턴스를 통해 접근 가능하게 하여 불필요한 객체 생성을 방지합니다.
- 싱글톤 매니저는 프로젝트의 메모리 사용량을 줄이고 성능을 최적화할 수 있습니다.
-
유지보수성
- 기능이 매니저 단위로 분리되어 있어 문제가 발생했을 때 특정 매니저만 수정하면 됩니다.
- 새로운 기능을 추가할 때 기존 시스템과 충돌을 줄이며, 매니저를 확장하거나 교체하기 쉽습니다.
-
게임 상태 제어
- 전역 제어 가능: 매니저는 게임의 상태를 전역적으로 제어할 수 있어 게임 일시 정지, 레벨 로딩, 리소스 해제 등과 같은 작업을 쉽게 구현합니다.
- 전환: 싱글 게임에서는 게임 상태의 변경이 잦은데, 매니저를 통해 상태 전환이 체계적으로 이루어집니다.
-
재사용성
- 매니저 구조를 잘 설계하면 다른 프로젝트에서도 쉽게 가져다 사용할 수 있습니다.
- 특정 매니저(예: 오디오 매니저, 입력 매니저 등)는 대부분의 게임에서 반복적으로 사용되므로 초기 작업을 줄여줍니다.
-
-
예상되는 단점
- 병목 현상
- 모든 게임 오브젝트가 매니저에 의존하면, 매니저의 성능이 병목 지점이 될 수 있습니다.
- 특히, 매니저가 빈번히 호출되거나 많은 데이터를 처리하는 경우 성능 저하를 초래할 수 있습니다.
- 모듈 간 결합도 증가
- 매니저를 중심으로 모듈 간 상호작용이 이루어지면 모듈 간 결합도가 높아져 변경이 어려워질 수 있습니다.
- 이로 인해 특정 매니저를 수정할 때 의도하지 않은 다른 모듈의 동작에 영향을 미칠 수 있습니다
- 초기 설계의 중요성
- 매니저 구조는 초기 설계 단계에서 많은 시간을 요구하며, 잘못 설계하면 장기적으로 문제를 일으킬 수 있습니다.
- 요구사항 변경이나 확장이 잦은 프로젝트에서는 초기 설계를 지속적으로 수정해야 할 가능성이 높습니다.
- 병목 현상
