모바일 타워디펜스 개발일지: 디자인과 준비 과정

들어가며

끝내 완성되지 못한 게임 ‘행선지’

직전 프로젝트의 경험으로부터 배운 것 중에 하나는 무언가를 장기간 시간을 두고 개발하는 것은 한편으로는 제가 어떤 거대한 맥락에 연루된다는 겁니다. 자칫하면 개발하는 과정이 피곤하고 고통스러운 경험으로 남을 수도 있고, 따라서 주제는 심사숙고해서 신중히 정할 필요가 있습니다.

그래서 이번에는 준비기간을 따로 편성했습니다. 처음부터 어느정도의 체계가 갖춰지기 전까지는 유니티 프로젝트를 생성하지 않겠다는 마음으로 시작했고, 1~2달가량 아이디어 브레인스토밍과 디자인 초안 제작, 문서 작성, 클래스 설계 등 사전작업을 거쳤습니다. 프로젝트를 지금이라도 취소하고 다른 것을 만드는 것이 낫지 않냐는 고민도 거쳤고, 이런저런 과정 끝에 지금은 새 프로젝트를 열었습니다.

조금 거창하게 들리는 느낌이 있는데, 사실 타워디펜스라는 장르 자체가 최근에는 크게 매력적으로 느껴지지 않는 부분도 있고, 아이디어 역시 아직 완전히 정교하지는 않습니다. 작성한 문서에도 구멍이 몇몇군데 보입니다. 하지만 완벽함만을 추구하다 보면 준비만 계속하게 될 것 같아 어느 정도 준비가 갖춰졌다고 판단한 시점에 과감히 프로젝트를 시작하기로 했습니다. 지금은 그 과정을 정리하며 글을 남기고 있습니다.

타워디펜스를 만들자

주제가 타워디펜스인 것은 약간의 도박입니다. 이미 출시된 타워디펜스 게임들이 많아 참고할 만한 사례가 풍부하고 개인적으로도 애착을 갖고 지속성 있게 개발할 수 있을 것 같아 선택했지만, 그만큼 경쟁이 치열하고 장르 자체가 최근에는 다소 낡고 정적인 인상을 주기도 합니다. 전통적인 타워디펜스 구조로는 게임의 종료 조건을 인상적으로 제시하기 힘들고, 마찬가지로 게임을 창의적으로 이끌어가기도 어려워보입니다.

이런 문제를 어떻게 보완할 수 있는지가 당분간의 관심사입니다. 특정 라운드까지를 보상의 최대치가 정해지는 한 판으로 간주하고 플레이어에게 지금의 게임을 마무리짓고 새 게임을 열 선택지를 제시하는 방향으로 게임을 구성할 예정입니다.

디자인이 오래 걸렸습니다

디자인을 하면서는 크고 작은 난관을 겪을 때마다 이쪽 분야에 재능이 부족한가 하는 식의 고통을 느끼고 있습니다. 그리고, 실제로 예상과 달리 난관이 많습니다.

제 디자인에는 크게 보았을 때 최소주의와 실용주의라는 두 가지 원칙이 있습니다. 디자인 코드의 통일과 개발 비용 절감 때문에 미니멀리즘을 우선시하고 있기는 하지만, 그렇다고 실용주의를 무시하는 것은 아닙니다. 그런데 이 둘이 충돌하는 경우가 굉장히 잦습니다. 대개 기능을 절감하면 실용적이지 않고, 역으로 여러가지 정보를 함께 표시하면 보기가 난잡해집니다.

가장 큰 고생을 겪었던 타워 정보 패널 디자인 과정. 다 문제가 있다.

주로 위와 같은 식입니다. 포탑의 스펙을 전달하는 창을 디자인할 때 수치를 상세히 표시하면 영수증처럼 정보 밀도가 과도하게 높아집니다. 반대로 간략하게 제시하면 직관성이 크게 떨어집니다. 이 문제는 제가 생각하기로 포탑 데이터 자체가 복잡하기 때문에 표시할 정보가 많을 수밖에 없는 것이 근본적인 원인인데, 다른 수많은 UI를 디자인할 때에도 비슷한 문제가 있었습니다. 예쁜 정보 표시를 위해 게임시스템을 덜어낼 순 없으므로 대신 다음의 자체적인 원칙을 따라 최선책을 세웠습니다.

• 시각적 정보의 밀도와 시간적 정보의 밀도 모두 일정하게 유지될 수 있어야 합니다. 두 가지 관점 모두에서 정보는 너무 많이, 또는 너무 적게 주어져서는 안 됩니다.
• 플레이어의 선택이 직관적으로 체감될 수 있어야 합니다. 작은 행동에도 여러 겹의 애니메이션과 효과 등으로 UI는 동적으로 반응해야 합니다.
• 흥미 유도와 함께 지루함은 방지될 수 있어야 합니다. 모든 것을 동적으로 구성할 순 없지만, 지루함을 유발하는 정적인 상황을 최대한 피하기 위해 맵이나 게임 시스템이 허용된 범위 내에서 유동적으로 기능해야 합니다.

피그마로 완성된 디자인 예시. 아이콘은 Fontawesome에서 가져왔습니다.

대부분의 UI 기능과 화면상의 배치를 이러한 흐름을 따라 결정했습니다. 게임 분위기 자체가 흑백 계열의 모노톤이라거나 UI 디자인 대부분이 아무런 시각적 효과도 없고, 정적으로 배치되어있다는 점이 앞으로 개선이 필요한 부분입니다.

이외에 현재 고민중인 부분이 있는데, 원래는 단순한 색상반전을 넘어 USS나 스크립터블 오브젝트를 활용해 다크&라이트 모드를 함께 제공하려고 했으나 제 욕심인 것 같아 현재는 보류중입니다. 우선은 다크&라이트모드를 염두해둔 상태로 개발을 진행하고, 나중에 차후 업데이트 등으로 제공하려고 합니다.

다른 준비는 좀 익숙합니다

어느정도 정리되면 아예 공개해버릴까도 고민중인 노션 페이지.

반면에, 이번의 기술적 목표는 거창하지 않습니다. 이제 명명 규칙이나 SOLID 원칙 등 원활한 프로젝트 관리를 위한 전략, 싱글톤이나 이벤트 주도적 프로그래밍과 같은 디자인 패턴, 안드로이드 앱 핵심 품질 기준 등 낯설지 않은 개념은 다듬어서 구현하고, 여유가 될 때마다 다음중 하나를 새로 사용해보는 것이 목적입니다.

• GPGS
• 오브젝트 풀링
• 멀티스레딩
• 유니티 애널리틱스
• 안드로이드 토스트 알람
• ISO/IEC 25010 품질특성

이번에는 우연찮게 Awesome Lists를 알게 되었는데 그 중에서 유니티와 관련된 항목, 또 특히 자세히 참고할만한 오픈소스 프로젝트로 Nodulus를 발견했습니다. 실제로 프로젝트가 어떻게 관리되는지에 대한 감이 부족해 어려움이 있었는데 스크립트 구조나 에셋 관리 등에서 크게 참고할 예정입니다.