언리얼 사화

문제

몬스터 종류에 비례해 비슷한 기능을 반복 구현하면서 작업 효율이 떨어졌습니다.

같은 코드가 여러 클래스에 흩어지면 버그를 고칠 때 모든 클래스를 각각 수정해야 하고, 하나라도 빠뜨리면 동일한 버그가 다른 몬스터에 그대로 남습니다.

개선

BP_Enemy_Base 상속

공통 기능을 재활용하기 위해 상속 가능한 클래스 BP_Enemy_Base로 분리했습니다.

Event Dispatcher로 확장

개별 몬스터 클래스에서는 Event Dispatcher를 통해 공통 기능을 확장하도록 설계했습니다. 베이스를 건드리지 않고도 몬스터마다 다른 반응을 붙일 수 있습니다.

행동 트리 기반 AI

AI는 노드를 재조합하는 행동 트리로 구현해, 새로운 패턴이 필요할 때 노드 조합만 바꾸면 되도록 했습니다.

결과

신규 몬스터를 추가할 때 공통 기능은 상속으로 가져오고, 그 몬스터만의 특징을 구현하는 데에만 집중할 수 있는 구조를 완성했습니다.

문제

기획 아이디어를 빠르게 테스트할 수 있는 환경이 필요했고, 비프로그래머도 직접 기믹을 설치·플레이할 수 있는 구조가 필요했습니다.

레벨 디자인이 계속 수정되면서 요구되는 기믹도 늘어났습니다. ‘플레이어가 들어오면 길이 막힌다’, ‘플레이어가 들어오면 몬스터가 등장한다’처럼 비슷한 기능을 반복 구현해야 하는 낭비가 발생했습니다.

→ 비슷한 코드가 여러 클래스에 흩어지면 버그 수정 시 모든 클래스를 각각 수정해야 하고, 하나를 빠뜨리면 동일한 버그가 다른 곳에 남게 됩니다. 기믹이 늘어날수록 클래스 수도 비례해 증가해 구조 파악이 어려워집니다.

개선

BP_Gimmick_Base 상속

기능 반복 구현의 낭비를 줄이기 위해, 기믹을 입력 감지와 기믹 동작으로 분류해 조립하는 방식으로 설계했습니다.

각 클래스가 작아져 이해와 유지보수에 효과적이고, 기획자가 직접 조립·테스트하기 좋은 환경으로 개선됐습니다.

기획 요구사항 상속

기획 요구사항(타이머·실행 횟수·반복 유무)을 BP_Gimmick_Base로 분리해 상속하도록 설계했습니다.

수정하면 상속받은 모든 클래스에 일괄 반영되며, 각 기믹 클래스는 고유 기능 구현에만 집중할 수 있습니다.

소통 인터페이스

기획자가 기믹 배치와 연결을 쉽게 할 수 있도록 BPI_SendIO 인터페이스를 통한 신호 전달 구조를 설계했습니다.

기믹 실행 신호를 받고 싶은 클래스는 인터페이스를 구현하기만 하면 신호를 받을 수 있어, 연결이 간단하고 확장이 쉽습니다.

결과 및 회고

회고

• 드래그 앤 드롭으로 대상을 참조하는 방식은 기믹 수가 늘어날수록 관리가 번거로워지고 순서 혼동 가능성이 있음
• 데이터 테이블로 기믹 리스트를 관리하고 테이블 설정대로 자동 연결되는 구조로 개선한다면, 기획자가 더 쉽게 기믹을 관리할 수 있을 것
• 메서드·변수명을 직관적으로 정리하면 기믹 구조 파악 속도도 빨라질 것