주의! 본 개발 일지는 제 입장에서 제가 생각하고 느낀 바대로 작성되었습니다. 혹여 껄끄러운 내용이 있더라도 팀의 의견이 아닌 개인의 의견이라는 점 유의해주세요 :)
04월 개발 계획
4월의 개발 목표는 '스마일게이트 멤버십 지원 준비'였다. 이에 따라 지원 계획을 세우고, 이행하며 한 달을 보냈다.
프로젝트 진행 타임 라인
04월 02일, 정규 회의 (대면) | : 페이퍼 프로토타입, 2차 테스트 |
04월 06일, 비정규 회의 (대면) | : 스마일게이트 멤버십 지원 계획 논의 |
04월 09일, 정규 회의 (비대면) | : SGM 지원 일정 정리 |
04월 11일, 비정규 회의 (비대면) |
: 기획 진행 상황 공유 (일정) |
04월 13일, 비정규 회의 (비대면) | : 기획 진행 상황 공유 (데이터테이블) |
04월 16일, 정규 회의 (비대면) |
: 작업 진행 상황 공유 |
04월 18일, 비정규 회의 (비대면) | : 기획 진행 상황 공유 (캐릭터, 역할 능력, UI/UX) |
04월 20일, 비정규 회의 (대면) | : 기획 진행 상황 공유 (플로우차트, 배경) |
04월 22일, 비정규 회의 (대면) | : 기획-플밍 크런치 |
04월 23일, 정규 회의 (비대면) | : 작업 진행 상황 공유 |
04월 25일, 비정규 회의 (비대면) | : 기획 진행 상황 공유 (데이터테이블, 타일) |
04월 30일, 정규 회의 (비대면) | : 작업 진행 상황 공유 |
… 이상 정규 회의 5회, 비정규 회의 7회로 회의를 총 12회 진행했다.
이슈
이번 달에는 스마일게이트 멤버십(이하 SGM) 지원을 위해 기획서, 프로토타입, 플레이 영상을 만드는 데 집중했다. 제출 마감인 5월 9일까지 계획을 세우고, 기획을 하며, 플로우차트를 그리고, 데이터테이블을 만든 뒤, 통합 기획서에 정리하는 등의 다양한 활동을 했는데, 이번 개발 일지에는 4월에 진행한 계획, 기획, 플로우 차트, 데이터테이블에 대해 적어보려고 한다.
목차를 살펴보자.
- SGM 지원 계획 세우기
- 낮 턴 로직 기획
- 플로우 차트 작성
- 데이터테이블 작성
이렇게 총 4가지 이슈에 대해서 정리할 예정이다. 그럼 같이 한번 살펴보자.
SGM 지원 계획 세우기
지난 개발 일지에서 4월 2일에 페이퍼 프로토타입 2차 테스트를 진행했다고 언급했다. 우리 팀은 2차 테스트 이후, 식사를 하러 갔는데 식사 과정에서 SGM 15기에 지원하는 게 어떻겠냐는 의견이 나왔다.
너무 좋았다. 솔직히 3월 중순에 SGM 15기 모집 요강이 나왔을 때, 내심 지원을 고려했으나 당시 상황에서 지원을 하게 되면 팀원 모두 제출 마감까지 과한 일정을 소화해야 했기에 마음을 접어둔 상태였다. 이런 상황에 팀원분이 먼저 나서 제안해주셔서 감사했다.
지원을 결정한 이후로는 현재 상황을 되돌아보고 계획을 세워야 했다. 먼저 우리는 기획을 탄탄하게 한 뒤 개발을 진행하기로 해서 인게임 개발이 진행되지 않은 상황이었는데, 제출 마감인 5월 9일까지는 인게임 프로토타입을 개발해야 했다.
따라서, 지금까지 나온 기획을 세세하게 다 구현하기보다는 우리 게임의 컨셉만 보여줄 수 있도록 일부 기능만 구현하기로 결정했다. 그리고 이 일부에 포함되는 것들과 아닌 것들을 구분하기 위해 우리에게 남아있는 작업을 나열해 봤다.
그 뒤에는 시급함 여부와 중요도에 따라 구분하는 사분면(찾아보니까 아이젠하워 매트릭스라고 한다!)을 변형해 정리했는데, 시급함 여부는 그대로 두고 중요도를 '컨셉을 보여준다.'는 목표에 적합한 지 여부로 바꿔 정리했다.
대부분이 급하면서 목표에 맞는 일이다. 저 때는 지금까지 해놓은 핵심적인 기획과 게임 흐름만 눈에 들어왔던 때라 저렇게 작성했다. 아마 지금 추가한다면 급하지만 목표에 맞지 않는 일에 데이터 구조 정리와 BM 모델 정리를, 급하지는 않지만 목표에 맞는 일에 카드 컨셉 추가 등을 고려할 수 있을 것 같다.
아무튼 이렇게 위의 PPT를 팀 구글 드라이브에 올려놓고, 첫 주차에 전체적인 계획을 세운 뒤, 매주마다 작업 진행 상황을 보고 조정하는데 활용했다.
이런 식으로 SGM 지원 계획을 세우고 이행해 봤다.
낮 턴 로직 기획
이전 개발 일지에서 전투 규칙 기획서를 작성했다고 올린 적이 있다. 해당 문서는 밤 턴 로직을 정리한 문서인데, 이번 프로토타입을 준비하면서 낮 턴 로직에 대한 정리도 필요하다고 생각했다. 낮 턴 로직에 대한 전반적인 개요를 다룬 적은 있어도 상세하게 다룬 적은 없어 더더욱 정리가 필요한 상황이었다.
낮 턴 로직을 정리할 때는 2가지 작업에 신경 썼다.
- 데이터 구조를 정리하자.
데이터 구조를 정리한 이유는 단순하다. 구현을 위해서다. 프로그래머가 구현을 하고, 테스트를 하려면 명확한 기준이 필요한데, 데이터 구조가 이러한 기준의 역할을 할 수 있을 거라고 생각했다. 따라서, 우선적으로 지난 ERD를 참고하여, 낮 턴에 필요한 플레이어, 지역, 역할 등의 데이터 구조를 정리했다. - 플로우 차트를 작성하자.
플로우 차트를 작성한 이유 또한 구현을 위해서다. 플로우 차트는 데이터를 다루며 로직의 흐름을 전개하는 과정을 정리하고 전달하기 위해 작성했다.
위의 2가지 작업 모두 아이디어를 창발 하기보다는 기존 아이디어를 정리하고 설계하는 등의 구현을 위한 작업이다. 지금 보면 나는 '바로 구현을 할 수 있는 기획을 해야 돼!'라고 계속 생각했던 것 같다. 이래저래 힘들긴 했어도, 성과도 있겠다, 목표에 적합한 바람직한 생각이었던 것 같다.
기획이 이번 SGM 제출용 프로토타입에 전부 반영되지는 않았지만, 앞으로도 유용하게 참고될 것 같아서 만족하는 중이다. 무엇보다 기획을 하며 작성한 플로우 차트와 데이터테이블에 크게 만족하기에 기획을 위한 기획으로도 좋은 역할을 한 기획이었다.
플로우 차트 작성
이제까지 플로우 차트를 여러 번 작성해 왔다고는 하지만 아직까지는 플로우 차트가 어렵다. 플로우 차트를 세세하게 작성하자니 알량한 지식으로 프로그래머의 영역을 침범하는 느낌이라 꺼려지고, 단순하게 작성하자니 어떤 식으로 구현될지 감이 안 와서 집중이 안 된다.
이전에 내가 나를 일컬어 '확실함을 쌓는 기획자'라고 말한 적이 있는데, 확실함이라는 것 자체가 아직까지는 모호하지만, 적어도 모호하다고 망설이는 것이 확실함은 아니라는 걸 깨달았다. 그래서 일단 고민하고, 행동하며, 그 결과를 개인적으로 기록해 나가면서 나의 확실함을 쌓아가고 있다. 이번 플로우 차트도 그 과정의 일환이다.
일단 세세하게 작성을 해보고, 프로그래머(이하 플머) 분들에게 참고만 해달라고 부탁드렸다. 지금 내가 플머의 영역을 침범한다고 느끼는 이유는 내가 작성한 플로우 차트가 그대로 구현돼도 문제가 없을지 확신할 수 없기 때문으로 짐작된다. 따라서, <Lost In Hope> 프로젝트 이후에 플머 분들께 말씀드린 뒤 개인적으로 코드 리뷰해 보면서 그 괴리를 조정해보려고 한다.
이야기가 샜는데 그래서 결국 작성한 플로우 차트는 아래와 같다.
이전의 'Gitmind'는 사용하기가 불편해서 'Draw.io'로 작성했다. 크게 노드들이 어떤 역할을 하는지와 참고 사항을 적어둘 memo와 데이터 구조를 정리한 ERD, 게임의 컨셉을 정리한 concept, 그리고 게임의 메인과 인게임으로 나눠 플로우 차트를 작성했다.
이번에는 플로우 차트의 가시성을 신경 써봤다. <뚜두 농장> 때처럼 플로우 차트를 길게 작성하면 보는 사람이 따라가다가 지치기 마련이다. 따라서, 플로우 차트에서 자주 사용되는 부분이나 복잡한 부분은 메서드처럼 따로 묶어서 처리했다.
이게 전부다. 이 외의 특이 사항이라고 하면 아래와 같다.
첫 번째로 ERD를 수정했다. 이전의 ERD는 누락된 부분도 몇몇 있고, 관계선이 있다고 해도 머릿속에 명확히 들어오지는 않았다. 그래서 관계선을 없앤 뒤, 게임의 흐름을 기반으로 관계되는 데이터를 묶어 재구성해봤다. 이제는 ERD가 아니게 되어버린 ERD였다.
두 번째로 컨셉 플로우 차트를 추가했다. 게임의 컨셉을 쉽게 이해할 수 있게, 게임의 흐름에 기존 게임을 레퍼런스로 소개하며 시스템을 정리하는 방식으로 플로우 차트를 구성했다. 특별한 건 없다. 딱히 만족스럽지는 않아서 다시 한번 정리해보고 싶다.
여기까지가 플로우 차트에 대한 내용이다. 글을 작성하면서 든 생각인데, 내가 플로우 차트를 좋아하는 이유는 내 생각이 항상 복잡했기 때문이 아닐까? 내 스스로 복잡한 생각에 많은 에너지를 할애하다가 플로우 차트라는 형식으로 기록하고, 정리하게 되면서, 이전보다 가볍고 명료하게 사고를 확장할 수 있으니 내가 미치는 거라는 생각이 든다.
내가 시스템을 좋아하는 이유도 이와 비슷한 것 같다. 내 자신의 생각을 범주화하고 제어하기 위한 도구이며, 이를 통해 명료하게 사고를 확장할 수 있기에 좋아하는 것이다. 마치 옛 시절 장군들이 지도를 소중히 여겼던 이유를 머리가 아닌 몸을 통해 진정으로 알 것 같은 느낌이다.
괜스레 오글거리는 느낌이 들긴 하는데, 맞는 것 같다.
데이터 테이블 작성
4월에 한 활동 중에 가장 가치 있는 것을 골라보라고 하면 그게 데이터 테이블 작성이다. 데이터 테이블은 단순히 SGM 제출용 프로토타입에만 쓸 용도로 작성한 게 아니라, 앞으로 두고두고 쓸 수 있게 작성했다. 데이터 테이블을 만들면서 몇 가지 VBA 매크로도 만들었는데, 이번 데이터 테이블을 만들며 진행한 작업은 아래와 같다.
- 데이터 테이블 : 구조 설계
- VBA 매크로 : 이미지 불러오기
- VBA 매크로 : 텍스트 키 찾기
- VBA 매크로 : JSON 변환
원래는 하나씩 살펴보려고 했는데, 글을 적다 보니 길어지기도 하고 충분히 따로 다룰 가치가 있는 것 같아서 테이블이 어느 정도 정리되면, 이전 페이퍼 프로토타입 테스트 글들처럼 별도의 글로 작성해보려고 한다.
간단하게만 정리하자면 데이터 테이블은 기획자가 게임 전체에서 사용될 로직을 정의하고, 플머 분들이 이를 구현해 주시면, 다시 기획자가 '~Logics' 시트에서 이를 조립해서 어떤 동작을 구현할 수 있도록 작업했다.
이 과정에서 가시성을 높이기 위해 이미지 불러오기 매크로를 추가했고, 작업 편의성을 위해 시트끼리 수식으로 연결하고 텍스트 키를 찾는 매크로를 만들었으며, 마지막으로는 엑셀 시트를 JSON으로 변환하는 매크로를 추가했다.
이후 일정 : 스마일게이트 멤버십 준비 및 휴식
5월의 목표는 '스마일게이트 멤버십 준비 및 휴식'이다. 나도, 팀원들도 한 달 동안 너무 열심히 잘해주었다. 현재(23년 05월 18일) 기준, 제출을 마치고 약 일주일 가량 휴식을 하고 있다. 내일 SGM 서류 결과 발표가 나는데 부디 좋은 결과를 얻을 수 있으면 좋겠다. <RIP> 팀은 결과 발표 이후, 다시 활동을 재개할 예정이다.
이번 SGM 준비를 하면서 기획적인 부분에서 부족함을 많이 느끼기도 했고, 어떤 식으로 진행하면 될지 감도 확실히 잡았다. 앞으로는 '본격적인 개발', '전체적인 그림' 같은 것에 연연하지 않고, 생산적으로 팀 활동을 할 수 있을 것 같다.
자체 피드백
나는 인정에 대한 욕구가 매우 강하다. 그리고 이런 인정 욕구의 충족 여부에 따라 낼 수 있는 퍼포먼스의 기복이 크게 좌우된다. 이러지 말아야지 하면서도 다시금 사람들의 인정에 매달리게 된다. 사람들과 만나 내가 한 것들을 소개할 때, 좋은 반응을 얻는다면 열정이 샘솟으며, 반응을 얻지 못한다면 쉽게 슬럼프에 빠진다.
흔히들 프로와 아마추어의 차이는 기복이 있느냐 없느냐로 좌우된다고들 하는데, 이런 면에서 나는 아직 아마추어인 것 같다. 그래서 다시 한번 내가 인정을 받으려는 이유를 고민해 봤다.
나는 왜 사람들의 인정을 받으려 하는가?
이전의 나는 [프로젝트/Lost In Hope] - Lost In Hope - 중간 발표 (+ 블로그 공백기 정리) 글에서 이 질문에 대한 답으로 인성적인 측면에서 자존감과 연결하여 답을 지었다. 틀린 말은 아니다.
그러나, 최근의 나는 관점을 조금 틀어 결과론적인 측면에서 답을 내려봤다. 결론부터 말하자면, 나는 사람들의 인정으로 나아갈 힘을 얻고 있었기 때문에 이에 집착했다. 칭찬 한 마디에 내 이상이 가치 있다고 증명된 느낌을 받았으며, 이로 인해 더 힘차게 나아갈 수 있었다. 나쁜 건 절대 아니다. 다만, 나는 칭찬 한 마디에 힘을 얻기도 했지만, 반대로 무반응 하나에 길을 잃기도 했다는 게 문제다.
차라리 비판이라도 했으면 좋겠다는 생각을 자주 한다. 비판이 타당하지 못하다면 반박하며 증명하면 되고, 타당하다면 개선에 노력을 기울이고 발전할 수 있으니 말이다. 나는 무반응에 대처할 방법을 몰라서 문제였다.
그래서 결론을 내렸다. 내게 필요한 건 이거다.
알빠노. 그래서 어쩌라고!
실상은 이기적인 말의 끝이라 이 말이 필요하다는 게 정말 이상한데, 아이러니하게도 이 말이 나한테 큰 도움이 됐다 ㅋㅋㅋ.
나는 내 작업물에 기준이 있다. 만약 내 작업물을 내가 만족할 수 있는 수준으로 끌어올려 전달했을 때 상대가 반응하지 않는다면 그건 문제없다는 뜻일 거다. 문제가 있다면 말을 하겠지.
상대의 반응을 신경 쓰지 않아도 된다는 생각 덕분일까? 요즘은 마음이 평온하다. 이전에는 침묵이 이어지거나 분위기가 가라앉으면 안절부절못하면서 되지도 않는 말을 꺼내며 광대짓을 했는데 요즘은 그냥 별생각 없다. 평소에도 머리가 복잡한데 괜히 더 복잡하게 받아들여 괴로워할 필요 없다.
생각이 많고 복잡한 나에게는 생각할 것과 생각하지 않아도 되는 것을 구분하는 게 정말 중요하다는 느낌이 든다. 아니, 중요한 수준이 아니라 생존을 위해 필수다. 내가 예민한 건 어렸을 때부터 이런 눈치를 봤기 때문인 것 같은데, 어렸을 때야 인간관계가 좁았기에 큰 문제가 없었지만, 조금은 더 많은 사람들과 만나게 된 지금은 무심함도 필수라는 생각을 한다.
무심함으로 통제되지 않는 인정에 대한 의존을 끊자.
마지막으로 사람은 각자 나름의 고유한 특성이 있다.
사회가 보여주는 이상적인 인간의 모습이 나와 다르다고 괴로워하지 말자. 사회가 말하는 이상적인 인간, 이상적인 리더라는 틀에 자신을 끼워 넣지 말자. 억지로 맞추기도 힘들뿐더러, 맞춘다 하더라도 틀과 어긋나는 고유한 특성을 버리지 못한다면 괴로움만이 남을 뿐이다. 그렇다고, 일반적인 것을 위해 내 고유함을 버리는 건 너무 아깝지 않은가.
내가 추구하는 내 이상이 사회에 이로움을 더할 수 있다면, 걱정하지 말고 나아가자. 나아가고, 증명하는 삶을 살자. 현실은 공유된 이상의 집합, 나는 거기에 내 이상을 더할 것이다.
나는 과거에는 이상한 사람이었으며, 현재에는 특이한 사람이고, 미래에는 특별해질 사람이다. 무아(無我), 나아가기 위해 나를 규정짓는 한계를 잊고, 나아가기 위해 나 자신을 잊으며, 나아가기 위해 이상의 나를 그리자.
나는 나아감이다.
'프로젝트 > Lost in Hope' 카테고리의 다른 글
Lost In Hope - 06월 개발 일지 (0) | 2023.07.29 |
---|---|
Lost In Hope - 05월 개발 일지 (2) | 2023.07.02 |
Lost In Hope - 페이퍼 프로토타입, 2차 테스트 후기 (0) | 2023.05.13 |
Lost In Hope - 03월 개발 일지 (0) | 2023.05.11 |
Lost In Hope - 02월 개발 일지 (0) | 2023.03.13 |