주의! 본 개발 일지는 제 입장에서 제가 생각하고 느낀 바대로 작성되었습니다. 혹여 껄끄러운 내용이 있더라도 팀의 의견이 아닌 개인의 의견이라는 점 유의해주세요 :)
03월 개발 계획
최근 개발 일지를 작성하지 못했다. 팀 내부에서 4월 초에 스마일게이트 멤버십에 지원하기로 결정하고, 지원 마감까지 한 달가량을 바쁘게 지냈기 때문인데, 이틀 전 제출을 끝내서 결과 발표까지 약 일주일 정도 숨을 돌릴 수 있게 됐다. 따라서, 이 기간 동안 밀린 글들을 작성해보려고 한다.
3월의 개발 목표는 '프로젝트 매니징'이었다. 2월에 계획했던대로 어느 정도 작업 결과물이 나오기 전까지는 프로젝트 매니징을 하기로 했고, 이에 따라 새로운 기획을 하기보다는 기존 기획을 확정하고, 전달하는 작업을 했다.
프로젝트 진행 타임 라인
03월 02일, 비정규 회의 (대면) | : 원탁 시스템 개선, 세계관 정립 |
03월 04일, 정규 회의 (대면) | : 신규 아트 인터뷰 준비, 진행 상황 공유 |
03월 07일, 신규 아트 인터뷰 (비대면) |
: 신규 아트 합류! (캐릭터 및 배경 디자인) |
03월 19일, 비정규 회의 (비대면) | : 데이터 매니징 방식 논의 |
03월 19일, 정규 회의 (비대면) |
: 팀 회칙 재공유, 작업 진행 상황 공유 및 작업 할당 |
03월 21일, 비정규 회의 (비대면) | : 세계관 정립 |
03월 23일, 비정규 회의 (대면) | : 세계관 정립, 페이퍼 프로토타입 2차 테스트 계획 공유 |
03월 28일, 비정규 회의 (대면) | : 아트 역할 분배, 작업 방식 논의 |
03월 30일, 비정규 회의 (비대면) | : 낮 턴 3D 타일 레퍼런스 논의 |
… 이상 정규 회의 2회, 비정규 회의 6회로 회의를 총 8회 진행했다.
이슈
앞서 언급한대로 3월에는 프로젝트 매니징에 집중했다. 이전과는 다르게 내 의견을 먼저 말하기보다는 일단 묻고 들어보고자 했고, 내 생각과 팀원 의견을 비교했을 때 기대 효과 면에서 큰 차이가 없다면 작업자의 취향에 맞춰 작업을 할당했다. 실제로 어떻게 보였는지는 모르겠지만 적어도 먼저 들어보려고 노력한 한 달이었다.
이에 더해 이전보다 조금 더 침착하고 명확하게 말해보려고 노력했다. 지금까지 돌이켜보면 회의 때 마음을 침착하게 유지하지 못했던 것 같은데, 그 이유를 생각해 보면 '잘 말하고 싶어서'가 가장 큰 것 같다. 생각은 이미 저 멀리 나가있는데 말로 설명이 안 되니 괜히 조급해지고, 말은 꼬여 상대방이 이해하지 못하는 상황이 자주 있었다.
말로 표현되지 않는다는 건, 정리가 안 됐다는 것이다. 3월은 이를 인정하고, 이전처럼 말로 설명이 안 될 때 혼자 답답해하기보다는 부족함을 인정하고 도움을 구하는 그런 한 달이었다.
3월의 감상은 이쯤 하고, 목차를 살펴보자.
- 피드백 : 원탁 및 전투 규칙 수정
- 데이터 기획
- 디스커버G 기고문 작성
- 페이퍼 프로토타입, 2차 테스트
이렇게 총 4가지 이슈에 대해서 정리할 예정이다. 그럼 같이 한번 살펴보자.
피드백 : 원탁 및 전투 규칙 수정
3월 초, 이미 원탁과 전투 규칙에 대한 기획이 나와있는 상황이어서, UX/UI 작업을 기다리고 있었는데, 다른 기획자분이 UX/UI 작업을 하시다가 시스템 개편에 대한 이야기를 하셨다.
처음에는 왜 이걸 지금 말하나 싶어서 당황했는데, 내 기획서가 읽기 좋은 모양새가 아니기도 하고, 직접 작업을 하시면서 새로운 아이디어가 떠오를 수도 있겠다 싶어서 시스템을 수정하기로 했다.
기존의 원탁은 원탁을 리볼버처럼 회전시키며 대상을 지정하는 방식이었는데, 이렇게 하면 원하는 플레이어를 찾기가 어려우니 화면 구성을 변경하기로 했다.
우선, 화면에서 원탁이 회전하는 기능을 삭제하고, 공격자/수비자 쌍을 보여주는 2인 화면과, 본인이 공격자/수비자 일 때 상대를 보여주는 1인 화면으로 밤 턴을 구성하기로 결정했다. 추가로, 이를 전체적으로 확인할 수 있게 '시점 변환'이라는 기능을 추가하여 밤 턴의 흐름을 전체적으로 관조할 수 있게 했다.
이렇게 기획서를 수정해서 가져갔는데, 이번에는 시점 변환 화면에 대해서 피드백이 들어왔다. 기획서를 수정한 이유가 편의성을 개선하기 위함인데, 시점 변환 화면에 대한 피드백은 오히려 수정 기획 의도에 어긋나는 상황이었다. 그래서 이 부분에 대해서 또 충돌이 생겼다 ㅋㅋ
피드백도 피드백이지만, 나는 작업이 늘어지는 것에 스트레스를 받는 상황인데 밤 턴 기획이 나오고 UX/UI 디자인을 시작한 지 한 달이 지나서야 피드백을 하고 수정을 한다는 게, 그리고 그 수정의 세부적인 부분에 대해 계속 논의하는 상황 그 자체가 너무 답답했다.
근데 그렇다고 다른 기획자분의 잘못이냐? 그건 또 아니다. 내가 나서서 피드백하고 논의하자고 말을 했고, 다른 기획자분은 그 말을 따라줬을 뿐이며, 실제로도 이게 옳다. 다만, 작업 프로세스가 적절하지 않았을 뿐이다. 작업 프로세스에 대한 내 패인은 크게 3가지로 나뉜다.
- 기획서를 제대로 공유하지 않았다.
이제까지 나는 기획서를 던져놓고, 읽기만을 바랐다. 하지만 이건 적절하지 않다. 같은 기획이라면 시간이 걸리더라도 기획서를 전달할 때 한 페이지씩 리뷰하며, 피드백을 가능한 완벽히 처리하고 넘어갔어야 한다. 하지만 그러지 않았기에 뒤늦게 확인하고, 뒤늦게 피드백이 나오는 일이 생겼다고 생각한다. - 수정을 거부했어야 했다.
완벽한 작업물이란 존재하지 않는다. 어떤 작업물이더라도 시간이 지나면서 허점이 보이기 마련인데, 치명적이지 않다면 넘어가는 것이 옳다고 생각한다. 이미 정리한 기획이 마음에 들지 않는다고 계속 수정한다면 프로젝트는 절대, 절대로 진행되지 않는다. 그렇기에, 피드백이 들어왔을 때 '반영하겠다'라는 답변보다는 '프로토타입 이후, 전체적인 개선 작업 때 다시 논의해 보자'라는 답변을 하는 게 더 적절했다. - 수정 작업을 맡겼어야 했다.
수정을 거절하지 못한 경우, 그 작업은 내가 아닌 제안자에게 맡기는 게 옳다. 나는 제안자에게 전체적인 개선의 기획 의도를 들었지만, 어떤 이미지를 그리고 있는지는 정확하게 알지 못한다. 그렇기에 해당 파트가 내가 맡은 부분이라고 하더라도 제안자가 수정을 한 뒤, 내가 피드백하는 방식이 옳다.
결국, 우리는 애자일의 스프린트처럼 기획 과정을 아이디어 구상 기간, 피드백 기간, 디자인 기간으로 나눠서 피드백 기간 이후에는 수정을 요구하지 말자고 약속하고 상황을 정리했다.
조금 더 명확하고 현명하게 판단할 필요가 있다고 느낀 이슈였다.
데이터 기획
이전 개발 일지에서 ERD를 작성했다고 올린 적이 있다. 하지만, 이걸 그냥 '작성했어요!'하고 갖다 던지니, 잘 읽히지 않는 것 같았다. 그래서 각각의 데이터가 무엇을 의미하는지 해석을 첨부한 데이터 기획서를 작성했다.
지금(23년 05월)에 와서는 이것도 두루뭉술하게 작성됐다는 생각이 들지만, 이 당시에는 나름대로 만족하면서 전달했다.
디스커버G 기고문 작성
블로그 글들을 보면 알겠지만 나는 글 쓰는 걸 좋아한다. 복잡한 생각이 글이라는 형태로 정리되는 과정에서 느껴지는 카타르시스가 나에게 나아갈 힘을 부여하기 때문이다. 그렇기에, 여유가 되면 이것저것 기록하고 정리해놓곤 한다.
지금 작성하는 개발 일지도 이런 느낌으로 정리하는 것인데, 문득 이전에 동아리 카페에 올라온 디스커버G 장기 기고 작가 협력 공지가 생각났다. 디스커버G는 게임을 주제로 한 글과 만화를 기고할 수 있는 사이트인데 글을 쓰는 것도 좋아하겠다, 개발 일지를 올릴 수 있다면 홍보도 되고, 원고비도 받고, 여러모로 좋을 것 같았다.
디스커버 G
게임의 새로운 발견
discoverg.net
그래서 사이트를 확인해 보니 이미 다른 게임 개발 연합 동아리 'GameMakers'에서 제작 중인 게임의 개발 일지도 올라오고 있는 상황이어서, 우리의 고민 과정과 페이퍼 프로토타입과 같은 다양한 경험을 전달하면 재미있을 것 같다는 생각이 들었다.
그래서 팀원분들에게 말씀드렸고, 다들 긍정적인 반응이어서 신청에 제출할 기고 계획과 1회 차 기고문을 작성해 봤다.
그런데 결론부터 말하자면 현재 기준(23년 5월 11일)으로 아직 신청하지 않았다. 1회 차 기고문을 작성하고 팀원 피드백을 받았을 때, 3회 차인 '페이퍼 프로토타입을 디자인하고, 테스트하여, 재미를 검증해 보자.'까지 작성하고 제출하면 좋을 것 같다는 의견이 있었고, 이에 따라 준비를 하려던 찰나, 스마일게이트 멤버십에 지원하게 되면서 차일피일 미뤄지게 됐다.
이틀 전에 스마일게이트 멤버십 지원을 끝냈으니, 이번 주쯤에 3회 차까지 작성하고, 다음 주 중으로 신청하지 않을까 싶다. 좋은 결과를 얻을 수 있으면 좋겠다.
페이퍼 프로토타입, 2차 테스트
<RIP>에 신규 아트분이 합류한 이후, 게임에 대한 비전 공유 겸 페이퍼 프로토타입 2차 테스트를 진행하기로 결정했다. 1차 테스트 때는 낮 턴 탐색, 밤 턴 전투라는 컨셉이 재미있는지를 테스트하고자 했다면, 이번에는 역할과 카드 연계가 재미 있는지를 테스트하고자 했다.
덱을 구상하며, '어떤 컨셉인가?', '어떤 경험을 줄 것인가?', '어떤 키워드로 묶을 수 있는가?'라는 질문에 초점을 맞춰 카드를 디자인했는데, 이전에 <Slay the Spire>의 재미 요소를 분석했던 경험이 크게 도움이 되었다.
덱 컨셉 디자인의 핵심은 뛰어난 효과와 부작용이 공존하는 특수 효과를 몇 가지 두고, 두루두루 사용 가능하며 부작용을 완화하거나 제거하는 일반 효과들 몇 가지를 섞어, 다양한 시너지를 창출하는 것이었다.
결과적으로, 아래의 5가지 컨셉 덱을 디자인할 수 있었다.
- 카드를 내는 행위의 재미를 강화한 콤보 덱
- 칩을 독점하고 생산력으로 밀어붙이는 자본 덱
- 상대의 덱에 상태 이상 카드를 넣어 방해하는 훼방 덱
- 초반에는 약하지만 점점 방어력이 올라가는 방어 덱
- 입은 피해를 상대에게 돌려주는 복수 덱
이러한 컨셉에 맞게 효과를 디자인했고, 효과에 맞게 카드를 디자인했다.
그리고, 이전과 같이 <midjourney>의 도움을 받아, 아래와 같은 프로토타입을 만들고, 테스트를 진행할 수 있었다.
하지만 결과를 정리하자면, 이번 프로토타입은 실패했다. 이유는 단순하다. 룰이 너무 복잡했다. 물리적인 한계를 극복하고자 역할 능력 사용을 카드로 처리하며 룰이 복잡해졌고, 개인적인 욕심에 다양한 덱 컨셉과 효과를 한 번에 테스트하려다 보니 더욱 복잡해졌다. 거기에 캐릭터, 체력, 칩, 행동력, 공격권 등의 인지 요소도 많다 보니 2시간 안에 배우고, 재미를 테스트하기에는 무리가 있었다.
거기에 용어도 '가다 듬기', '무방비'와 같이 직관적이지 않다 보니 여러모로 '실패했다'는 평가가 적합한 프로토타입이었다.
추가로, 이전에 디스이즈게임에서 '주사위의 신 페이퍼 버전으로 게임 룰 설계하기 강연 정리' 글을 보고 퀄리티를 최대한 끌어올렸는데, 이것도 생각 없이 가성비 고려하지 않고 퀄리티만 무조건 끌어올리려고 하다 보니 재미를 테스트하기 위해서 프로토타입을 만드는 게 아닌, 프로토타입을 만들고자 재미를 테스트를 한다는 느낌이 들었다.
결과적으로 많이 아쉬운 테스트였다. 이와 관련해서는 이전처럼 이번 테스트의 목적과 설계 과정, 후기와 실패 요인을 정리해서 따로 글을 작성하려고 한다.
테스트는 4월 2일에 진행하긴 했는데, 준비 기간 생각하면 애매해서 3월 개발 일지에 묶어봤다.
이후 일정 : 스마일게이트 멤버십 준비
4월의 목표는 '스마일게이트 멤버십 준비'다. 원래는 이전과 마찬가지로 '프로젝트 매니징'이었는데 4월 2일 프로토타입 테스트 이후, 스마일게이트 멤버십에 지원해 보기로 해서 목표를 수정했다.
현재(23년 05월) 기준으로 나는 잘하고 있는 것 같다. 불과 며칠 전까지만 해도 예민함을 품은 채 방황했지만, 무관심함도 어느 정도 필요하다는 걸 깨달은 이후에는 조금은 편하고 의연하게 반응할 수 있게 됐다. 이게 내가 그토록 바라던 진중 하되 가벼운 마음의 실마리라는 생각이 든다.
부족한 점도 정말 많이 찾았지만, 그만큼 시야가 트이고 성장을 할 수 있는 4월이었다. 4월 개발 일지는 기대해 봐도 좋을 것 같다.
자체 피드백
항상 고집과 신념의 차이에 대해 생각해 왔다. 그리고, 나름의 기준을 세웠는데, 그 기준은 '타인의 의견을 듣고, 자기 자신을 돌아볼 수 있는가?'이다. 고집에 갇힌 사람은 타인의 의견을 듣고 무시하지만, 신념 있는 사람은 타인의 이야기를 듣고 자신의 방식을 되돌아보며 방식이 잘못됐다면 이를 바로 잡는다.
하지만, 이런 해석은 여전히 명확하지 않다. 신념 있는 사람이 신념을 꺾을 때는 명확하지만, 만일 의견을 검토하고, '그럼에도 옳다.'라고 외치는 경우, 고집과 신념은 어떻게 구분할 수 있는가? 남들이 보기에 고집과 신념은 같아 보일 뿐이다.
그렇다면, 이 둘의 차이는 어떻게 구분해야 할까? 아니, 애초에 구분할 필요가 있을까? 답이 모호하다면, 질문이 명확한지 살펴볼 필요가 있다. 우리는 고집과 신념을 꼭 구분해야만 할까?
아니다. 신념이라는 건 추상적인 개념이기에 주관적으로 해석될 수밖에 없다. 따라서, 누군가는 신념이라 칭송할지라도, 누군가는 고집이라 비난하게 될 것이다. 결국, 신념과 고집은 한 뿌리에서 나온 개념이며, 그 뿌리는 어떠한 '의지'일뿐인 것이다.
나는 답도 없는 질문에 답을 찾겠다 괴로워하고 있었던 건 아닐까? 애초에 삶이란 세상에 나를 고집하는 것. 세상을 살아감에 있어 한두 가지 고집 정도는 필요하다는 생각마저 든다.
결국, 중요한 건 생각하기를 포기하지 않는 것. 시간은 많으니, 고민하고 또 고민하자. 답을 찾으려 고민하는 게 아니라, 나의 옳음을 찾기 위해 고민하자.
고민하고, 또 고민하자. 언제나 나를 버릴 준비가 되어있다면, 언제든 새로운 내가 될 수 있으니 나를 찾기 위한 고민을 아끼지 말자. 이는 괴로운 것이 아닌 축복된 것이다.
'프로젝트 > Lost in Hope' 카테고리의 다른 글
Lost In Hope - 04월 개발 일지 (0) | 2023.05.18 |
---|---|
Lost In Hope - 페이퍼 프로토타입, 2차 테스트 후기 (0) | 2023.05.13 |
Lost In Hope - 02월 개발 일지 (0) | 2023.03.13 |
Lost In Hope - 01월 개발 일지 (0) | 2023.02.12 |
Lost In Hope - 최종 발표 (0) | 2023.02.10 |