Unity 프로젝트의 좋은 구조

이 글은 Unity프로젝트가 확장될 때 코드 설계 방법을 참고하였습니다. 아래 링크

게임쪽에서 마이너한 코드나 좋은 구조에 관련된 책이나 코드, 설계방법은 생각보다 찾기 어렵다..

오픈소스도 웹앱만큼 열리지 않았기 때문일까..?

그런 도중 지인이 추천해준 좋은 글이 있어서 나름대로 정리해보려고 한다.

프로젝트 예제

핑퐁게임을 예로 들어서 하나의 항목은 하나의 프리팹, 하나의 항목에 대한 커스텀 로직은 하나의 MonoBehaviour를 만들어서 사용한다.

애플리케이션은 상호 연결된 프리팹을 포함하는 씬을 기반으로 한다.

인스턴스, 프리팹 및 스크립터블 오브젝트

image

플레이어 1의 패들 게임오브젝트에 붙어 있는 패들 컴포넌트이다.

여기서 세 가지 파리미터가 있지만 이 화면에서는 확인하고자 하는 기반 코드가 표시되지 않는다.

즉, 수정 작업을 인스턴스 단계에서 변경해야 하는지, 프리팹 단계에서 해야하는지 알 수 없다.

이 도메인을 조금만 생각해보면 입력Axis는 사실 각 플레이가 개별적으로 변경해야 하는 부분임을 알 수 있다.

MovementSpeedScaleFactor, PositionScale은 두 플레이어가 공유해야 하는 값임을 알 수 있다.

이때 한번만 필요한 것이라면 프리팹을 생성한 다음 인스턴스화 한다.

여러번 필요하며, 인스턴스와 관련해서 몇 가지 수정이 필요하다면 프리팹을 생성하고 인스턴스화 한 다음 일부 설정을 오버라이드 한다.

여러 인스턴스를 동일하게 설정해야 한다면 프리팹 대신 스크립터블 오브젝트와 소스 데이터를 생성한다.

스크립터블 오브젝트가 유리한 이유는 변경되지 않는 동일 값들을 공유가 가능하기 때문에 수정이 간단하다.

즉, 입구가 하나..

규모가 큰 MonoBehaviour 분할하기

게임을 개발하다 보면 가장 많이 하게 되는 실수중 한가지 클래스에 너무 많은 책임을 몰아 넣는 것이다..

여러가지 안티패턴이 있지만 싱글톤같은..

이는 SRP(Single Responsibility Principle)를 위반하는 것이다.

규모가 큰 MonoBehaviour 클래스를 분할하기 위해선 다음과 같은 방법이 있다.

  • 일반적인 게임 로직, 입력 처리, 물리 시물레이션 및 프레젠테이션은 MonoBehaviour, 스크립터블 오브젝트 또는 원시적인 C# 클래스내에 있을 수 있다.
  • 인스펙터에서 파라미터를 표시하려면 MonoBehaviour또는 스크립터블 오브젝트를 사용해야 한다.
  • 엔진 이벤트 핸드러와 게임 오브젝트의 수명주기 관리는 MonoBehaviour에서만 가능하다.

나도 가장 추천하는 방법은 MonoBehaviour에서 일반적인 C#클래스로 이동하는 것이다.

상속 구조를 벗어나 구성, 협동의 단계로 나아가야 하기 때문에 이런 구조를 추천한다.

MonoBehavior에서 일반적인 C# 클래스로

image

진짜 맛있는 코드…

인터페이스로 의존성을 분리 즉, DIP(Dependency Inversion Principle)를 적용하여 삭제조차 위임을 하였고, 프로퍼티를 인터페이스로 구현할 때 내부 구현은 해당 클래스가 직접 담당하기 때문에 모듈성도 문제없다.

동작 자체도 시뮬레이션, 로직으로 분리되어 작동하는 모습..

이 코드를 포스팅하고 싶어서 들고왔다..

아래 링크에서 더 자세한 내용을 볼 수 있고 게임의 완성도를 높이는 다양한 방법이 기술되어있다.


https://unity.com/kr/how-to/how-architect-code-your-project-scales#simple-complex

태그: ,

카테고리:

업데이트:

댓글남기기