숏컷 코드
Boot Scene
-> 공통 서비스 생성
-> 초기 설정 주입
-> 메인 씬 진입문법과 예시
bootstrapper는 "무엇을 만들까"보다 "누가 먼저 준비돼야 하나"를 정리하는 구조다
오디오, 세이브, 로컬라이제이션, 입력, 네트워크 초기화가 각 씬에서 제각각 일어나면 순서 버그가 반복됩니다. Boot Scene과 bootstrapper는 공통 서비스 초기화 지점을 한곳으로 모아 수명주기와 조립 순서를 고정하는 역할을 합니다.
singleton 남용 대신 조립 지점을 명시하는 데 유용하다
모든 매니저를 singleton으로 두는 대신, bootstrapper가 필요한 서비스를 만들고 연결하면 초기화 순서와 책임이 더 선명해집니다. 이 방식은 DIP 카드와도 자연스럽게 이어집니다.
씬 전환을 자주 하는 프로젝트일수록 boot scene 가치가 크다
메인 메뉴, 로비, 전투, 결과 화면처럼 씬이 자주 바뀌는 프로젝트에서는 공통 서비스가 어디서 살아남고 언제 리셋되는지 명확해야 합니다. Boot Scene은 그 기준점을 제공해 줍니다.
preload scene, boot scene, 첫 씬 직접 초기화는 같은 문제가 아니다
아주 작은 프로젝트는 첫 씬 직접 초기화로도 충분할 수 있습니다. 하지만 서비스가 늘고 씬 역할이 나뉘면 preload/boot 개념이 필요해집니다. 핵심은 이름보다 "공통 서비스 조립을 어디서 한 번만 끝낼지"를 고정하는 것입니다.
bootstrapper를 둘 때 핵심
| 상황 | 적합한 선택 |
|---|---|
| 공통 서비스 초기화가 씬마다 반복될 때 | boot scene / bootstrapper |
| 초기화 순서 버그가 자주 날 때 | 조립 지점 고정 |
| 서비스 생성과 연결을 한곳에 두고 싶을 때 | bootstrapper |
| 아주 작은 프로젝트로 씬 수가 거의 없을 때 | 과할 수 있음 |
| singleton이 너무 많아 생성 시점이 흐릴 때 | bootstrapper로 재정리 |
특이 케이스와 주의할 점
흔한 실패는 bootstrapper를 또 하나의 거대 매니저로 만드는 것입니다. 조립 지점이어야지 모든 게임 로직의 집합소가 되면 안 됩니다. 생성과 연결까지만 맡기고 실제 기능 책임은 각 시스템으로 돌리세요.
실패 예시
- BootSceneManager가
초기화뿐 아니라
저장, 오디오, 전투 진입, UI 제어까지 모두 처리
결과
- 조립 지점이 아니라 거대 관리자 하나가 됨
- 수정 이유가 계속 늘어남참고 링크
1 sources