[Project_MTS] 개발 일지 - 1 [플레이어 이동, 오브젝트 상호작용]

기존에 조금씩 생각하던 게임을 개발하고자 했다.

그래서 기획을 수정하며 확정된 내용만 기능부터 먼저 개발하며 프로토타이핑을 진행하기로 했다.

캐릭터는 Spum을 통해 임시로 만들어 사용했다.

플레이어 움직임 구현

플레이어의 이동 구현

플레이어의 이동은 입력 처리와 물리 구현을 분리하여 설계했다.

Unity의 Update와 FixedUpdate는 호출 주기와 목적이 다르기 때문에 역할을 분리하는 것이 안정적인 이동 구현에 유리하다. Update는 프레임마다 호출되어 입력 처리에 적합하고, FixedUpdate는 일정한 시간 간격으로 호출되어 Rigidbody 기반의 물리 연산에 적합하다.

따라서 입력 값은 Update에서 처리하여 상태로 저장하고, 실제 이동과 물리 적용은 FixedUpdate에서 수행하도록 구성했다. 이를 통해 프레임 변화에 따른 입력 처리와 물리 연산의 불일치를 방지하고 일관된 이동 동작을 유지할 수 있다.

이러한 구조를 사용한 이유

입력은 프레임 기반으로 변동될 수 있는 반면, 물리는 시간 기반으로 안정적으로 계산되어야 하기 때문이다. 또한 Update와 FixedUpdate는 서로 독립적인 실행 흐름으로 동작하므로, 역할을 분리하더라도 서로 간섭 없이 안정적인 처리가 가능하다.

 

플레이어 캐릭터 상태 구분

UI가 출력된 도중 이동하는 현상을 막기 위해 구현했다.

 

마을에서 상호작용이 가능한 행동을 EnumType으로 미리 작성해 사용

여기서 작성된 내용을 바탕으로 PlayerController에서 조건에 따라 이동을 하지 못하도록 조건을 추가했다.

PlayerController의 Update

오브젝트 상호작용

플레이어 상호작용 구현

public interface IInteractable
{
    void Interact();
}

상호작용 기능을 인터페이스로 추상화하여 다양한 오브젝트가 동일한 방식으로 처리되도록 구성했다.

이렇게 구현한 이유는 표지판, 포탈, NPC, 퀘스트 NPC 등 서로 다른 성격의 상호작용 오브젝트들이 존재하기 때문이다. 각 오브젝트마다 개별 로직을 처리하는 방식은 코드 중복과 유지보수 부담을 증가시키기 때문에, 인터페이스를 통해 공통된 상호작용 규약을 정의했다.

이를 통해 플레이어는 구체적인 오브젝트 타입에 의존하지 않고 동일한 방식으로 상호작용을 처리할 수 있으며, 새로운 상호작용 오브젝트 추가 시에도 기존 코드 수정 없이 확장이 가능하도록 설계했다.

표지판에 사용될 SignObject 스크립트

 

상호작용 UI 설계

상호작용 UI는 BaseScene에서만 사용되는 특수한 UI이기 때문에 별도의 Canvas로 분리하여 설계했다. 이를 통해 씬 간 UI 의존성을 줄이고, 공통 UI와 전용 UI의 역할을 명확히 구분할 수 있도록 구성했다.

전체 UI 구조는 GlobalCanvas와 CanvasObject로 나누어 설계했다.

GlobalCanvas는 설정, 인벤토리, 저장/불러오기 등 여러 Scene에서 공통적으로 사용되는 HUD 요소를 담당한다.
반면 CanvasObject는 BaseScene에서만 사용되는 지도 UI, 지역 선택 UI, 위치 이동 UI 등 특정 씬에 종속된 UI를 관리하도록 분리했다.

UIType만 작성된 UIType Script

이러한 구조를 통해 UI의 역할을 명확히 구분하고 책임을 분리하고자 했다.

또한 UIType을 열거형(enum)으로 정의하여 UI 종류를 미리 구분하도록 설계했다. 이를 통해 문자열이나 직접적인 참조 방식 대신 타입 기반으로 UI를 관리할 수 있으며, 오타로 인한 오류를 방지하고 코드의 가독성과 유지보수성을 향상시킬 수 있다.

BaseScene에서는 BaseUiController를 통해 해당 씬에서 사용되는 UI를 통합적으로 제어하도록 구성했다. 현재는 UI를 표시하고 숨기는 기본 기능만 구현되어 있다.

동시에 UI를 보여줄 가능성은 없지만, 혹시 몰라 켜진 UI가 있다면 종료하도록 작성했다.

UI를 닫는 메서드

 

이벤트 기반의 상호작용 구조

플레이어 상호작용을 이벤트 기반 구조로 설계하여 객체 간 결합도를 낮추었다. 이렇게 작성한 이유는 이벤트 기반 구조를 사용함으로써 각 객체는 독립적으로 동작하면서도 필요한 시점에만 연결되도록 구성할 수 있어, 확장성과 유지보수성을 챙기기 위함이다.

---

현재 프로토타입을 구현하면서 객체지향 프로그래밍을 적용해 유연성과 확장성, 가독성을 확보하는 방향으로 구조를 설계하고 있다. 프로토타입 단계에서는 기능의 추가와 변경이 빈번하게 발생하기 때문에, 초기부터 구조를 분리해 두지 않으면 이후 수정하기 힘들어질 것이라고 생각한다. 따라서 책임 분리와 의존성 감소를 통해 변경에 유연한 구조를 만드는 것을 목표로 하고 있다.