팀 구성
다니고 있는 학교의 '캡스톤디자인' 수업에서 팀별로 SW를 개발하는 과제를 진행했다. 사전에 계획되어있던 팀이 없다 보니 우선 각자 자기소개부터 진행되었다. 간단하게 유니티 및 안드로이드 스튜디오 개발 경험을 설명했고, 다른 사람들의 소개도 들었지만 나는 다소 의욕이 없었다. 그 당시 여러 번 게임 개발 프로젝트를 진행하면서 엎고 다시 만들고 가 반복되어 게임 개발에 지쳐있었던 터라 주도적으로 프로젝트를 이끌고 싶지 않았다. 뚜렷한 아이디어나 기획 없이는 모래성처럼 쉽게 무너질 것이 두려웠다. 그런 상태에서 팀은 나 포함 3명으로 구성되었다.
아이디어 도출
아무래도 다른 팀원 또한 게임 개발에 관심이 있었던 터라 결국은 게임으로 가닥을 잡았다. 처음엔 언어 학습 플랫폼인 "듀오링고"에서 영감을 받아 여기에 게임 요소를 더 추가하는 방향으로 결정했다. 초기의 기획은
- 깜빡이 학습으로 단어를 외우고 퀴즈를 맞추는 여러 개의 스테이지로 구성된 "학습"
- 학습의 성과에 따라 티켓을 얻어 플레이할 수 있는 "미니게임"
으로 구성되었다. 미니게임은 행맨, 워들, 가로세로 퍼즐과 같이 단어와 관련된 게임들로, 복습 효과를 노려 3개를 구성했다. 그러다 문득 이런 생각들이 들었다.
- 학습과 미니게임 컨텐츠가 공존해야 하는 이유가 뭘까? (다른 학습 플랫폼과의 차별점)
- 미니게임을 플레이할 수 있는 티켓을 얻는 것이 과연 학습의 동기부여가 될까? (게이미피케이션)
- 미니게임을 3개나 넣어야하는 이유는 뭘까? 플레이어가 굳이 이 미니게임들을 할 필요가 있을까? (플레이어의 경험)
'내가 플레이어라면 이 게임을 하면서 어떤 생각이 들까?'를 중점적으로 생각해본 결과 이 기획안으로는 학습 플랫폼도 게임도 아닌 엉성한 무언가가 될 것 같았다. 따라서 수정이 필요하다고 느꼈다.
아이디어 수정
주변 친구들에게 물어보고 나름대로 고치려고 노력했다. 당시 '프로젝트 메이크오버'를 즐겨했고 과거에 '스머프 빌리지'를 했던 기억이나 '쿠키런 킹덤'이 떠올라 SNG 장르를 가져와 마을을 꾸미는 형태로 동기부여를 하면 어떨까 싶었다. 자세히는 깃허브 저장소에 올려놓았지만, 간단히 설명하자면
- 깜빡이 학습 및 퀴즈로 구성된 "단어 암기" 컨텐츠, 완료 시 미니게임을 플레이할 수 있는 티켓을 줌
- 단어 관련 퍼즐이나 게임으로 구성된 "미니게임" 컨텐츠, 완료 시 마을을 꾸밀 수 있는 코인을 줌
- 건물 및 장식물을 건설하는 "마을" 컨텐츠, 코인을 사용해 마을을 꾸밈
- 각각의 미니게임마다 보상 코인 유형이 다르며 각각 다른 건물을 건설할 수 있음(예를 들면 A코인으로는 식물, B코인으로는 상가, C코인은 주택 등)
이다. 마을을 예쁘게 꾸미기 위해서 학습 및 미니게임 컨텐츠를 플레이한다는 것인데, 솔직히 컨텐츠 간 유기적으로 연결되는 느낌은 잘 없지만 이전보단 낫다고 생각했다. 하지만 여러 가지 컨텐츠가 들어가면서 복잡해져 게임을 설명하기 어렵다는 단점 또한 생기게 되었다. 또 SNG가 그렇듯 다른 플레이어와의 상호작용도 있었으면 좋았겠지만 개발 여건 상 녹록지 않아 빼버렸다. 이렇게 아이디어의 기반을 정하고 문서 작업에 들어가게 되었다.
문서 작성
제일 어려웠고 막막해서 스트레스를 많이 받았던 단계이다. 제안서 또는 기획서의 형태로 쉽게 알아 볼 수 있는 문서를 제작해야 했다. 프로젝트와 관련이 없는 제삼자가 봤을 때도 부드럽게 읽히고 구조를 파악할 수 있어야 했는데 이 프로젝트는 교수님께서 그 역할을 맡아주셨다. 그 과정에서 왜 교수님은 내용도 제대로 안 보시고 피드백을 해주시는가...라는 의문이 들었지만, 지금 생각해보니 애초에 그런 몇십 장의 문서를 일일이 다 읽는 사람은 없는 것이었다.
어떻게든 교수님이 알아볼 수 있게끔, 파악할 수 있게끔 쉽게 쉽게 작성하려 했다. (이미 여러차례 설명드린 결과 교수님께서 다 아시긴 하셨지만) 교수님께서는 문서를 꼼꼼하고 디테일하게 잘 작성하는 것보다, 프로젝트의 구조를 알아보기 쉽게 작성하고 디테일 또한 찾아보기 쉽게끔 작성하는 것을 가르쳐주려고 하셨던 것이다. 어떻게 보면 당연한 사실이지만 큰 깨달음을 얻게 되었다.
- 최대한 도표같은 그림으로 정리한다.
- 문서의 구성은 Top-down 방식으로 전체 흐름을 파악하고 그 뒤에 세부 내용을 알 수 있게끔 한다.(구글어스를 확대, 축소하시면서 예를 들어주셨던 것이 기억에 남는다.)
기획문서가 어느정도 완성된 뒤에는 구현 단계에 들어갔다. 사실 개발 문서도 작성하고 들어갔어야 했는데 시간이 촉박한지라...
구현
구현은 유니티로 진행했으며, 형상관리로는 Git을 사용했다. 구현 중 발생한 이슈나 기획안의 수정은 깃허브 이슈를 게시판 삼아 이용했다. 사실 하나의 브랜치로 개발을 진행했고 이슈 및 커밋 메시지도 잘 정리되어있진 않았지만, 이것만으로도 팀 작업에 있어서 많은 도움이 되었다.
특히 Github Issue를 통해서 할 일을 추적 및 관리하는 기능은 당면한 또는 예정된 작업이 무엇인지 파악할 수 있어 용이했다. 마일스톤을 잘 설정하면 칸반보드 형태로도 볼 수 있어 대단히 유용한 것 같은데, 문서 작성 단계에서 많은 시간을 할애하느라 구현은 좀 급하게 진행되어 활용하지는 못했다.
구현 세부사항
UI 구현
이미 기획에서 틀을 정해놓은지라 큰 어려움은 없었다. 있었다면 처음 UI 오브젝트를 배치하고 버튼 이벤트 추가하는 귀찮음 정도?
- JSON 파일에서 불러온 단어장 리스트를 기반으로 런타임에 버튼을 동적으로 생성, 스크롤뷰로 보여줌
- JSON 파일에 저장된 데이터에 따라 단어 암기 컨텐츠의 성과를 별 갯수로 표시(0~3개)
- 깜빡이 학습때 단어를 일정 시간만 보여주고 미니게임 플레이 시 타이머를 표시해주는 등의 동적인 부분은 코루틴 활용
저장 기능
단어 데이터와 플레이어의 세이브데이터를 저장 및 불러와야 했는데 이에 JSON을 사용하기로 했고, Json.NET을 사용해 구현했다. 이 부분은 다른 팀원이 구현을 해주었고 나는 그저 불러온 데이터를 클래스나 리스트 형태로 사용하기만 하면 되어 편리했다.
학습
깜빡이 학습은 단어를 일정 시간 보여주고 뜻을 보여주는 형식으로 반복되었는데, 코루틴을 활용해서 일정 시간이 지나면 표시할 단어가 바뀌게끔 구현했다.
미니게임
플레이어가 단어의 뜻을 보고 무작위로 배치된 알파벳 판에서 연결시켜 단어를 완성하는 게임인데, 알고리즘이 의외로 어려웠다. 그래프 탐색 비슷하게 구현하면 될 것이라 생각하고 구현했다. 비슷한 게임 예시는 word search puzzle로 검색하면 나온다.
- 4x6칸에서 시작점을 무작위로 정하고 단어의 첫번째 글자를 배치한다.
- 동서남북 무작위 방향으로 전진하고 다음 글자를 배치한다.
- 이미 배치한 칸이거나 막다른길에 막혀 더 이상 전진할 곳이 없다면 배치하지 않고 되돌아간다.
- 마지막 글자를 배치할때 까지 반복한다.
- 배치되지 않은 칸에는 무작위로 알파벳을 배치한다.
3번이 좀 어려웠는데 백트래킹과 DFS, BFS 이론을 찾아보고 해결하게 되었다. 어떤 기능을 구현함에 있어서 기능을 잘게 쪼개 보고 잘 알려져 있는 알고리즘으로 일반화하여 해결한다... 는 느낌을 대충 알게 되었다.
마을 꾸미기(구매 및 건설)
구매 가능한 건물들 리스트를 JSON에 저장하고 그것을 불러와 패널에 각각의 건물을 구매할 수 있는 버튼을 생성해 스크롤뷰를 만들었다. 마을은 Tilemap을 사용해서 Isometric 그리드를 배치했다.
건설된 건물을 어떻게 저장할건지가 문제였는데, 처음엔 Dictionary <Vector3, building>를 사용해 Vector3 좌표에 어떤 building이 건설되어있는지의 형태로 할까 고민했다. 그런데 이 방식은 JSON serial/deserialization을 추가적으로 구현해주어야 했기 때문에 사용하지 않고 대신 List <Building>을 사용했다.
예를 들면 (0, 0) 좌표에 id가 1인 건물을 건설하면 List에 { (0,0), 1}이 추가되는 방식이다. 이렇게 하면 딕셔너리는 그리드 크기가 커지면 같이 커지는 반면 리스트는 건물을 많이 건설해야 커지기 때문에 메모리 절약의 이점을 얻을 수 있다.
결론
컴퓨터 관련된 것 뿐만 아니라 커뮤니케이션, 문서 작성, 시장분석, 마케팅에 대해서 생각해보는 계기가 되었다. 게임 자체 퀄리티가 좋거나 재미있냐 묻는다면 자신있게 아니라고 대답할 수 있겠지만 이 프로젝트를 하면서 많은 것을 깨닫게 되었고 체감하게 되었다.
- 쉽고 잘 알아볼 수 있는, 그리고 디테일까지 겸비한 문서의 중요성(또는 그러한 문서를 작성할 수 있는 능력!)
- 개발할 게임의 방향 및 의도를 명확하게 제시하는 기획(또는 사람, 능력)
- 제삼자에게 프로젝트를 설명할 수 있는 커뮤니케이션 능력
- 요구사항을 분석해 그것을 구현해야 하는 기능으로 바꿔 기술하는 능력
- 협업 관련 도구의 유용함
- 구현할 때 큰 문제를 작은 문제로 쪼개 잘 알려져 있는 알고리즘으로 일반화해 차례로 해결하는 법
- 게임 개발 프로젝트의 여러 직군들의 필요성과 어떤 업무를 하는 지에 대한 대략적인 이해
- ...
당연한 것이지만 게임도 구매하는 소비자가 있어야 하는 상용 SW이다. 소비자들의 요구사항이 무엇인지 분석하고 그것들을 만족시키기 위해서 어떤 기능이 필요한지, 어떤 게임을 만들어야 하는지 생각한다. 그 후 제안서 또는 간단한 기획서를 작성해 피드백을 받고 개발을 진행한다. 개발 중에는 여러 개발 문서 또는 다이어그램을 통해 최대한 구체화하고 구현을 시작한다. 그렇게 해야 구현 중에 기획문서를 엎거나 설계를 수정하는 등의 일이 최소화된다. 구현이 다 되었으면 알파, 베타 테스트를 진행해본다. 테스트 완료 후에는 게임을 출시한다.
과거에는 단순히 '게임을 잘 만들고 재미있으면 잘 팔리겠지? 그런데 이런 재미를 어떻게 정의할 것이고 어떻게 잘 만들지?'라는 생각을 했는데, 재미를 막연하게 좇을게 아니라 이렇게 요구사항의 관점에서 분석해보는 것도 많은 도움이 된다고 느꼈다. 시장분석을 통해 수요를 파악, 코어 유저층의 입장에서 생각해보고 기능을 정의하는 것.
말은 쉽지만 직접 깨닫는데 꽤 긴시간이 걸린 것 같다. 허허...
