GG 스튜디오 개발 일지 [6]
게임 개발 일지 7회차
개발 일지 0 개발 일지 1 개발 일지 2 개발 일지 3 개발 일지 4 개발 일지 5
약 2개월만의 개발일지를 작성한다. 그동안 많은 일도 있었고 프로젝트 자체가 많이 바빠서 작성할 아이템이 별로 없었다. 큰 작업들이 끝나고 나서 프로젝트를 회고하며 개발일지를 작성한다.
다뤄볼 목차는 다음과 같다.
- 그동안의 성과
- 팀원과 갈등
- 프로젝트 소통 방식 업데이트
- 프로젝트 개발 방식 업데이트
그동안의 성과
인디게임 개발에서 중요한 것은 도달할 수 있는 목표와 지속적인 동기부여라고 생각한다. 그 중에서 동기부여라는 내용이 정말 불분명한데 팀원 개개인의 열정이 될 수도 있고, 팀 자체의 목표 달성, 돈, 재미 등등 매우 다양하다. 이번에 BIC를 통해서 프로젝트의 가능성을 보여주면서 나름 동기부여가 된 것 같다.
BIC전시, 다른 공모전, 대학생 전시회 등을 통해서 몇 개월동안 시간을 투자한 작품을 남들 앞에서 보여줄 수 있다는 점에서 되게 Grayed Game의 모토와 닯아 있다. 전시와 시연을 통해 결국 개발 과정도 유저를 통해 완성된다는 점을 깨닫게 된 계기가 되었다.
게임은 결국 게임이라는 틀에 한정되면 아니 되고, 수동적인 형태이기에 결국은 유저가 완성시킬 수 밖에 없다.
성과를 정리하자면, BIC 루키 부문으로 오프라인 전시를 진행했고 이를 통해 현재 게임의 방향성을 점검하고 문제점들을 확인할 수 있었다. 또한 게임의 대중성이나 시장의 냉철한 평가도 받을 수 있었다.
이후로 진행한 대학생 연합 발표회 LOGIN에서도 기획 우수상을 받았다.
실제로 팀원들과 소통만하며 개발하다 직접적인 반응을 보게된 것은 처음이라 나 뿐만 아니라 팀원들도 느낀점이 많았을 것이다.
물질적인 성과는 4만원 정도의 상금 뿐이지만..돈은 적자.. 실질적인 성과는 정말 많이 배울 수 있었던 것 같다.
팀원과 갈등
앞에선 긍정적인 이야기였다면 이번 내용은 조금은 무거울 수 있는 이야기다.
팀원과 갈등이 발생한 상황이였는데 처음 팀을 만들 때 세웠던 규칙과 같이 솔직하게 다른 팀원들과 해당 사건에 대해서 솔직하게 이야기를 나누었다. 솔직하게 이야기 함으로써 당시 갈등 상황에 대한 감정적인 사건보다 개인이 왜 그렇게 생각하고 행동했는지 서로를 이해하는 시간이었다.
결론적으로 팀이 성숙해지기 위해서는 계속해서 갈등을 해결하고 나가는 과정이 필요하다. 계속해서 서로의 입장을 이해해야 하고 존중해야 한다. 결국은 갈등을 피하는 것이 아니라 해결하는 것이는 점을 다시한번 느낀 것 같다.
답답한 마음도 조금은 사라지고 갈등에 대한 두려움도 조금은 사라진 것 같다. 첫 프로젝트에서 가장 많이 느꼈던 갈등의 부재를 이번 프로젝트에서 극복할 수 있었던 점이 진짜 마음에 들었다.
한 예로 결국은 미움받을 용기도 어느정도 필요한 것 같다. 내가 디렉터라는 자리이기에 해야할 말을 해야한다는 점과 그런 말을 듣는 팀원들도 서로의 입장을 이해해야 하는 것 같다.
프로젝트 소통 방식 업데이트
위 사건들로 팀 내부 소통 방식을 업데이트하게 되었다. 지금까지는 한달에 한 번 팀원 개개인과 1대1 미팅을 진행했는데, 추가적으로 모든 팀원이 모여서 팀 방향성이나 게임 자체에 대해서 이야기 하는 시간을 가지기로 했다.
확실히 이건 교류가 적고 생각을 들었어야 했는데, 개인적으로 그런 이야기를 하는 걸 싫어한다고 생각했지만 팀원들은 부족했다고 느낀 것 같다. 그래서 회의를 제외하고 대면으로 만났을 때 다같이 팀 자체에 대한 이야기를 하는 시간을 가지기로 했다.
정리하자면 팀 자체에서 사용하는 소통 방식은 다음과 같다.
- 1대1 인터뷰
- 단체 인터뷰 (1달에 한 번 대면)
- 정기 회의
- 비정기 회의
- 깃허브를 통한 비동기 소통
이 외에도 대면이 안되면 온라인 게임을 하거나 하는 방식으로 변경했다.
개인적으로 내가 다 하는게 맞다고 생각했는데, 부탁하기 부담되고 미안해서? 다른 작업을 싫어할 것이라고 혼자서 판단한게 문제였다.
프로젝트 개발 방식 업데이트
기존의 방식에서 변경된 점은 소트트웨어 개발 방식과 같이 버전을 메이저.메이저.패치로 변경하여 각각 버전을 다루고 마일스톤을 약 1~2달 간격으로 잡고 진행하기로 했다. 변경한 이유는 BIC를 준비하며 크게 마일스톤을 잡고 주마다 빌드하며 평가 후 수정하는 방식이 효율적이었기 때문이다.
애자일 원칙에 맞게 팀 내에서 유리한 방향으로 개발 방식을 계속 업데이트하고 있다.
댓글남기기