약 한 달가량의 42게임개발 챌린지가 종료되었다.
프로젝트를 진행하며 배우고 느낀 것들을 하나씩 정리해보았다.
멘토님의 조언
기획 발표날 초청된 멘토님께서 42게임개발 챌린지에 참여한 두 팀에 대해 여러 조언을 해주셨다.
온라인 웹개임을 기획한 팀에게는 이러한 같은 조언을 해주셨다.
- 온라인 게임은 데모버전부터 서버까지 구현해야 한다.
- 솔로와 온라인 게임은 많은 부분이 다르기 때문에 솔로를 온라인으로 변경하기보다는 처음부터 모든 걸 상정하고 만드는 것이 좋다.
- 서버를 올릴 여력이 되지 않으면 엔진에 존재하는 P2P용 서버를 이용해 구현하는 것도 좋다.
- 한 단계씩 개발하면서 넘어가는 것이 문제를 특정하기 쉽다.
- 예를 들어 한 컴퓨터에 4개의 클라이언트를 띄웠을 때 정상 작동되다가, 4 컴퓨터에서 4개의 클라이언트를 띄웠을 때 문제가 생기면 네트워크 관련 문제라는 것을 특정할 수 있다.
- 이 때 문제가 없다고 확정된 것을 다시 파악하느라 시간을 낭비하지 마라.
2D 로그라이크 게임을 기획한 우리 팀에게는 이러한 조언을 해주셨다.
- 4주동안 가장 집중해서 구현해야 하는 것은 우리가 이걸 입력하면 어떻게 됩니다라는 것
- 동작을 먼저 구현하고 그 다음에 규칙을 만들어라, 이런 조작법으로 이런 룰을 통해 게임이 돌아가는구나를 알아야지 앞으로 어떻게 될지를 상상할 수 있다.
- 게임은 완벽한 클라이언트 베이스-완벽한 하드웨어 제어 프로그램이다. 그러니 우선 클라이언트에 집중해라
- 게임의 뼈대를 작성하는 것은 1인이 해라. 그래야 모든 팀원이 하나의 목표를 바라볼 수 있다.
프로젝트를 계속 진행하면서 멘토님의 조언을 온몸으로 느낄 수 있었다.
1. 코드의 구심점을 잘 세워라
매우 방대한 기획을 가졌던 우리 팀은 멘토님께 빠른 개발에 대한 여러 피드백을 받았다. 그 중에 가장 기억에 남는 것이 코드의 구심점이다
우리 게임은 구현해야 할 부분이 너무나 많았다.
너무나 방대한 기획량에 모든 팀원들은 어디서부터 감을 잡아야 할 지 가늠을 할 수 없었고, 결국 각각이 스탯, 스킬, 장비 등 하나의 파트씩 맡아서 구현하기로 하였다.
구현이 진행되면서 뼈대는 한 명이 도맡아야 한다는 멘토님의 조언이 뼈저리게 느껴졌다. 시간이 지날수록 서로의 코드를 이해하기 힘들어지면서 협업에 차질이 생기기 시작했다. 초반에는 피그마에 작성한 다이어그램이나 풀 리퀘스트 설명을 작성해 팀원에게 자신의 코드를 설명할 수 있었지만, 점점 해이해지면서 각자가 각자의 코드에 고립되었다.
- 피그마에 작성한 액터와 그의 부속 클래스 다이어그램
그러다 보니 나중에 서로의 코드를 맞춰볼 때 한바탕 전쟁이 벌어졌다. 서로의 코드가 어떠한 목적을 가지고 작성되었는지 모르고 사용하다보니 버그가 난무하였고 수정 작업만으로 하루를 꼬박 까먹었다.
누군가 주도를 하든, 아니면 각자 남에게 잘 설명하든 최소한 퍼블릭 함수라도 서로가 잘 이해하고 있으면 이렇게까지 복잡하게 얽히지는 않았을 것 같다고 생각한다. 그 부분이 너무 아쉽다.
2. 눈에 보이는 부분을 우선 만들어라
게임은 플레이어가 재미있기 위해 하는 것이다. 플레이어가 재미를 느끼기 위해 가장 먼저 해야 하는 것은 무엇일까 고민한 적이 있었다. 그 때 나는 게임 기획의 어느 한 부분이라도 포기하면 게임의 재미가 온전히 느껴지지 않을 것이라는 결론에 도달하여 모든 부분을 만족할 만큼 개발해야 된다고 생각했다.
이번 프로젝트에서 나는 액터의 이동, 공격, 상태 애니메이션 등 눈에 보이는 작업 위주로 구현했다. 놀라운 건 나는 스킬이나 버프와 같은 복잡한 구조의 구현에 대해 크게 관여하지 않았지만 단순히 캐릭터의 움직임이나 상태 등을 보면서 어떻게 도입이 되어야 하는지 느껴진다는 것이었다. 아무래도 테스트를 하면서 개발자의 입장이 아닌 플레이어의 입장이 되어본 것이 크게 작용한 듯 싶다.
느낀 점을 바탕으로 팀원들에게 플레이어에 추가로 붙는 컴포넌트들의 개발 방향을 제의했지만 결과적으로 영향력 있게 받아지지 않았다. 각자의 생각과 방향이 있었고, 이미 작성 중인 코드를 변경하는 위험성을 팀원들은 겪고 싶지 않았던 모양이었다. 이 때 구심점을 제대로 잡지 못한 것에 대한 아쉬움이 또다시 들었다.
공부한 내용
디자인 패턴
이 프로젝트를 시작하기 이전에는 디자인 패턴에 대해 잘 몰랐다. 기사시험 공부를 하면서 디자인 패턴이 있다는 것은 알았지만 이들의 사용 이유와 사용 방법 등에 대해 깊게 공부하지 않았었다.
그러다 팀원의 조언으로 플레이어의 움직임을 처리할 때 상태 패턴을 사용해보니 편의성과 효율이 이루 말할 수 없을 정도로 높았다.
디자인 패턴의 맛을 느낀 이후로는 GoF에서, 혹은 이후에 제시된 여러 디자인 패턴의 구현 의도, 사용처, 구현 예시들을 공부하여 블로그에 정리하고 있다.
입력 시스템
기존에 사용한 정적인 인풋 매니저를 타파하여 인풋 시스템을 사용해보았다. 이를 바탕으로 멀티플랫폼 확장에 대한 유연성을 확보할 수 있었다.
공부한 내용은 블로그에 정리해 두었다.
