[KSEB] 게임 도메인 팀프로젝트 3주차 개발일지 + 1차 중간발표

728x90

이번 주 화요일에 1차 중간 발표와 멘토들의 피드백이 있었다. 2주차 개발 일지 시연 영상에서 카메라의 움직임이 덜 어지럽게 수정하고, 씬 로드 중의 버그가 일어나는 현상 등을 디버깅해 메인 화면에서 튜토리얼까지의 게임 시연이 원활하게 돌아가게끔 준비하고 발표를 진행했다. 발표자가 내가 아니라서 사진을 안찍었지만, 발표 자체는 우리팀이 제일 잘한 것 같다 ㅎㅎ. 간단하게 중간 발표 및 피드백이 어떻게 이루어졌는지 복기 겸 정리하고 지난 3주차동안 어떤 기능을 개발했는지를 GIF와 함께 정리하겠다.

1차 중간 발표 및 피드백

2주 동안 팀프로젝트 개발을 진행한 곳은 인하대 60주년 기념관 7층이었는데, 이번 1차 중간 발표는 14층에서 진행되었다. 뭔가 발표나 공개 강연 등은 14층에서 진행될 듯 하다. 이번에는 사진을 첨부하진 못했지만, 나중에는 미리미리 허가를 구하고 사진을 찍어 오겠다. 오히려 다음 발표의 사진부터 보여주는게 실제로 구현된 프로젝트를 보여줄 수 있을 거 같긴 하다. 왜냐하면 전체적으로는 아직 2주밖에 진행이 안되서 보통 컨셉을 확실히 잡고 다들 핵심 기능의 프로토타입을 어떻게 구현했고, 이후 어떻게 진행할지를 말하는 사실상의 소개 시간이었다. 다만 우리팀의 경우 기본적으로 컨셉이 이미 잘 알려진 플랫포머 + 로그라이크 액션이기에 빠르게 진행할 수 있어서 좀 더 완성도 있게 보여줄 수 있었다. 각 팀이 10분 정도를 발표한 후 멘토들이 피드백을 해주었는데, K-Enpowerment Software Bootcamp는 주로 "개발자"에 초점을 맞춰 진행하기에 게임의 스토리나 기발한 기획보다도 기능 구현과 최적화 등의 개발적인 측면에서 더 피드백이 이루어진 것 같다. 우리 팀이 받은 피드백은 다음과 같다.

기간에 비해 전체적인 완성도는 좋다.
이제는 조금 더 비주얼적인 부분을 신경써서 추가하면 좋을 것 같다.
전체적인 게임 자체의 마감을 높이면 좋을 것 같다.
효과음, 효과 이펙트(SFX, VFX) 에셋을 적극적으로 활용해보아라.
반응형 UI와 인벤토리는 곧 구현하는건가요(질문)

타 팀의 경우 기능적인 부분이나 전체적인 방향성에 대해 조언을 했으나, 우리팀은 주로 비주얼적인 요소에 대해서만 받았다. 2주동안 진행한 것 치고는 방향성과 진도가 빠른 편이라서 기능적인 부분에 있어서는 거의 지적받지 않았다. 그나마 과제(?)로 던져준 것은 반응형 UI와 인벤토리 시스템인데, 인벤토리 시스템은 다른 팀원이 필요한 정도만 구현할 것 같고(물론 못하면 내가 해야겠지만), 나는 몬스터 클래스를 만들어 상속을 통해 찍어내기와 확장성을 고려한 FSM 기반의 로직 구조를 구현하는 것을 새로운 목표로 삼아 진행했다. 이후에는 세이브&로드 시스템도 내가 가능한 깔끔하고 강건하게 만들어보고자 한다. 아래는 3주차동안 내가 맡아서 진행한 내용을 GIF와 함께 간단히 정리했다.

3주차 게임 개발일지

전체적으로 화요일에 있었던 발표 전까지 자잘한 기능 및 디버깅을 진행했고, 발표 이후에는 새로운 목표 설정과 역할 분배를 진행했다.

먼저 사소한 것부터 간단히 나열해보면 다음과 같다.

데드 존 추가 + 게임 오버 화면 구현 및 관련 로직 구현

보스방 진입시 맵이 잠기는 기능 구현(이벤트 기반)

마을(타운 맵)으로 이동하는 로직 구현

씬 로드 이후 생기는 각종 버그 디버깅
사용할 새로운 에셋 찾기 (+자체제작)

발표 후 새 목표 설정 : 오만 던전 및 관련 몬스터 제작

위의 개발 요소는 기존에 만들었던 요소들을 조합해 빠르게 제작할 수 있었다. 하지만 눈에 잘 나타나진 않지만 로직의 구조를 아예 새롭게 개편하는 시도도 했다. 나름 시간을 들인 어필할 수 있는 요소라고 생각하기 때문에, 아래에 하나씩 구체적으로 정리하겠다.

일반 몬스터 클래스를 확장적인 상속 구조로 개편

기존의 슬라임 몬스터 코드는 공통된 슬라임상태와 이동 로직 정도만 공동으로 사용하고, 이외에는 전부 다르게 구성했다. 이는 일반 몬스터의 양산이 어렵고, 일반 몬스터의 경우 공격 패턴을 제외하면 순찰 중 발견 시 공격한다는 매커니즘은 동일하기에 공통 상태와 순찰 로직이 포함된 일반 몬스터 클래스를 제작하고, 이를 상속받아 상태를 추가하고 공격을 오버라이드해서 다르게 구현할 수 있도록 만들었다. 가능한 확장적으로 만들려고 노력했는데, 이후 서술할 FSM 시스템 개편에서 어느정도 다시 갈아 엎었기에 간단히만 언급하고 넘어간다.

일반 몬스터 로직에서 코드와 데이터 분리(깊은 복사 + Scriptable Object)

간단하게 구현할 수 있을 거라 생각했는데, SO(Scriptalbe Object)를 상속한 클래스도 클래스이기에 참조 형식이며, 때문에 SO 데이터를 참조해서 바로 접근해 사용하면 SO 원본 데이터가 변경되어 버린다는 점에서 조금 애를 먹었다. 특히 공통적으로 사용되는 SO 데이터 내에 있지만 절대 갱신되면 안되는 좌표 정보나 체력 등이 갱신되어 주소를 참조하는 방식의 얕은 복사로는 생각했던 공용 데이터로 동작할 수 없었다. 이에 "일반 몬스터 데이터 구조"라는 이름으로 일반 몬스터의 공통 데이터들을 구조체로 묶어버리고, 몬스터가 초기화될때 SO 데이터의 값을 직접 복사하는 깊은 복사를 통해 참조하도록 했다. 또한 SO 데이터 내에서 변경이 불필요한 데이터는 빼고, 초기화시 기본값으로 설정되도록 만들었다(예 : 좌표값)

Delegate 기반 Finite State Machine 방식 몬스터 로직으로 개편

여기에서 다시 어느정도 다 갈아엎었다. 기존에는 상태를 enum으로 받아서 Update() 내 또는 각 동작 메서드 내에서 예외처리를 하나씩 추가했는데, 몬스터의 상태가 많아지고, 로직이 복잡해짐에 따라 디버깅하기가 몹시 힘들고 코드의 직관성도 몹시 떨어진다는 점을 인지했다. 또한 지난 주에 개발한 슬라임 보스의 경우, 애니메이션 컨트롤러 내에서의 상태에 따라 애니메이션 클립이 재생되고, 그 애니메이션 클립에서 스크립트의 이벤트를 발생시켜 진행하는 방식으로 했는데 한계가 분명했다. 이해 자체는 쉽지만, 로직을 변경하려 할때 애니메이션 클립을 변경하면 그 애니메이션 클립을 쓰는 모든 상태를 다시 다 관리해야 한다. 따라서 애니메이션 이벤트 트리거는 정말 필요할때만 쓰고, 로직 자체 내에서 직관적으로 상태를 관리하며 애니메이션을 실행시키는 방식으로 진행하기로 했다. 이를 위해 기존의 이상한(?) FSM 방식을 버리고 새로 개편했다.

Delegate(위임자) 기반 FSM 방식

이 방식을 채택한 이유는, 확장이 몹시 쉬우면서 Update() 함수의 내부를 정말 깔끔하게 관리하고, 트랜지션을 관리하는 곳을 별도로 두어 흐름을 직관적이고 일관되게 관리할 수 있기 때문이다.

또한 일반 몬스터 클래스에는 공통적으로 사용되는 상태를 선언해두고, 추가적인 상태가 추가된 몬스터는 오버라이드를 통해 추가할 수 있도록 구성해 더욱 확장성 있는 방식을 도모헀다.

이를 통해 공통 상태 + 공통 상태별 로직을 상속 받으면서 필요한 상태 또는 상태별 로직을 추가적으로 부여할 수 있게 되었다. 단, 로직 흐름을 반드시 한 곳에서만 제어해야 한다는 사실에 주의.

Delegate 기반 FSM 방식의 보스 몬스터 구현 (1 페이즈)

아직 보스의 상태 및 공격 패턴 등이 확실히 정해진 것은 아니지만, 위에서 구현한 방식을 활용해 보스 몬스터를 만들고 있다. 지난 주에 만든 킹슬라임 보스 몬스터는 수정할때마다 너무 애를 먹어서, 좀 더 확장적인 FSM 방식으로 바꾸었다. 다만, 일반 몬스터와 달리 페이즈와 다양한 공격 패턴을 위해 좀 더 복잡해지다 보니, 아무래도 다소 복잡도가 확 올라간다. TransitionCheck() 함수 내에서 주석과 함께 최대한 간결하게 작성해 직관성을 좀 더 보장해야 할 것 같다.

다음 주차 목표

이제 어느 정도 몬스터 로직은 찍어낼 수 있도록 만들었으니, 빠르게 필요한 몬스터를 구현해내고 디버깅까지 끝내서 프리팹으로 만들어 팀원들이 자유자재로 쓸 수 있게 만드는 것이 1차 목표다. 이후 세이브&로드를 깔끔하면서 확장성 있게 구현하는 법을 찾아보며 구현하는 것이 다음 주차의 최종(?) 목표이다.