언리얼 사화

문제

몬스터 종류가 늘어날수록 같은 기능을 반복 구현하게 됨

반복 구현이 만든 비용

• 몬스터 종류에 비례해 비슷한 기능을 매번 새로 구현하면서 작업 효율 저하
• 같은 코드가 여러 클래스에 흩어져, 버그 수정 시 모든 클래스를 각각 고쳐야 함
• 하나라도 빠뜨리면 동일한 버그가 다른 몬스터에 그대로 남음

개선

공통 기능은 베이스로 내리고, 개별 몬스터는 확장 지점만 붙이는 구조로 설계

BP_Enemy_Base 상속

• 이동·피격·사망 등 공통 기능을 상속 가능한 클래스 BP_Enemy_Base로 분리
• 공통 로직 수정이 모든 몬스터에 일괄 반영

Event Dispatcher로 확장

• 개별 몬스터 클래스는 Event Dispatcher를 통해 공통 기능을 확장
• 베이스를 건드리지 않고도 몬스터마다 다른 반응을 붙일 수 있음

행동 트리 기반 AI

• AI는 노드를 재조합하는 행동 트리로 구현
• 새로운 패턴이 필요할 때 노드 조합만 바꾸면 되도록 구성

결과

신규 몬스터 추가 시 고유 특징 구현에만 집중할 수 있는 구조 완성

문제

레벨 디자인이 계속 바뀌면서 비슷한 기믹을 반복 구현하는 낭비 발생

필요했던 환경

• 기획 아이디어를 빠르게 테스트할 수 있는 환경이 필요
• 비프로그래머도 직접 기믹을 설치·플레이할 수 있어야 함

반복 구현이 만든 비용

• ‘플레이어가 들어오면 길이 막힌다’, ‘플레이어가 들어오면 몬스터가 등장한다’처럼 비슷한 기능을 매번 새로 구현
• 같은 코드가 여러 클래스에 흩어져, 버그 수정 시 모든 클래스를 각각 고쳐야 함
• 하나라도 빠뜨리면 동일한 버그가 다른 곳에 그대로 남음
• 기믹이 늘어날수록 클래스 수도 비례해 늘어 구조 파악이 어려워짐

개선

기믹을 입력 감지와 동작으로 쪼개고, 인터페이스로 연결하는 조립식 구조로 설계

BP_Gimmick_Base 상속

• 기믹을 입력 감지와 기믹 동작으로 분류해 조립하는 방식으로 설계
• 클래스 하나가 맡는 범위가 작아져 이해와 유지보수에 유리
• 기획자가 직접 조립·테스트할 수 있는 환경 확보

기획 요구사항 상속

• 타이머·실행 횟수·반복 유무 등 공통 요구사항을 BP_Gimmick_Base로 분리
• 베이스를 수정하면 상속받은 모든 클래스에 일괄 반영
• 각 기믹 클래스는 고유 기능 구현에만 집중

소통 인터페이스

• BPI_SendIO 인터페이스를 통해 기믹 실행 신호를 전달
• 신호를 받고 싶은 클래스는 인터페이스만 구현하면 연결 완료
• 배치와 연결이 단순해져 기획자도 확장하기 쉬움

결과 및 회고

기획자가 블루프린트로 기믹을 직접 조립해 게임에 적용

회고

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