Table of Contents

23. Project Architecture (게임 프로젝트 설계)

이 문서의 목표

Framework 위에서 실제 게임을 설계할 때의 권장 아키텍처를 이해한다.

왜 필요한가

Framework는 "위험한 부분 통제 + 재사용 기반 제공"까지만 책임진다. 게임 규칙(전투, 인벤토리, 퀘스트)은 전적으로 Game Layer 설계에 달려있다.

언제 사용하는가

새 Feature(전투, 인벤토리 등)를 설계할 때.

프로젝트에서 어떤 역할인가

Game
 Entry        (부트스트랩, 씬 진입점)
 Features     (전투, 인벤토리 등 도메인별 묶음)
 Controllers  (MonoBehaviour, 상태 저장/조건 분기 금지)
 Adapters     (Framework System을 Feature에 맞게 좁혀서 노출)
 Data         (저장/직렬화 대상)
  • Controller는 상태를 갖지 않고 Service/Model에 위임한다.
  • Feature 간 통신은 직접 참조 대신 IMessageBus를 사용한다.

실제 게임에서는 언제 호출되는가

전투 Feature가 인벤토리 Feature 결과를 필요로 할 때 -> 직접 참조 대신 Message로 통신.

Best Practice

System 조합(Effect->Stat 등)은 Adapter 계층에서 수행하고 Framework Runtime에는 넣지 않는다.

자주 하는 실수

  • Controller가 게임 규칙 조건 분기를 직접 포함 (Rules #4 위반)
  • Feature 간 직접 참조로 결합도 증가

실습 과제

  1. 전투 Feature 하나를 Entry/Controllers/Adapters/Data로 나누어 설계해본다.
  2. Feature 간 통신을 IMessageBus로 구현해본다.

이전 문서 / 다음 문서

이전: 22_Best_Practice.md 다음: 24_FAQ.md

관련 API

MCP_Rules.md #2 사용자 API 설계 원칙

Edit this page