본문 바로가기
Project/Project Design

[해커톤] 미스터리 텍스트 게임 <Secret Chamber> 개발기

by 세이(Sayer) 2023. 7. 24.
728x90
[목차]

0. 들어가며
1. 사전 준비
2. 해커톤 진행 중
3. 나가며

 

0. 들어가며


MaKING JAM(메이킹잼) 게임 해커톤 참여

* 해커톤 일자 : 2022.11.11 - 2022.11.13
* 게임 이름 : 시크릿 챔버(Secret Chamber)
* 담당 포지션 : 게임 기획


"작은 방이 전부였던 소녀의 탈출기, 시크릿 챔버"

 

시크릿 챔버 데모 발표 PPT 일부

시크릿 챔버는 이야기를 따라가며 사건의 진실을 파헤치는 미스터리 텍스트 로그라이크 게임입니다.
과연 주인공은 자신이 누구인지를 기억해내고 방을 탈출할 수 있을까요?

***

2022년 11월 11일부터 13일까지 2박3일 동안 진행된 MaKING JAM 게임 해커톤에서 <시크릿 챔버>라는 게임을 만들었습니다!

게임 중에서도 스토리 기반의 미스터리 게임을 굉장히 좋아하는지라 언젠가 꼭 게임을 만들어보리라 다짐하고 있었는데, 좋은 기회를 얻게 되어 정말 재미있게 개발했습니다. 아무래도 스토리가 중심이 되는 '게임' 기획이다 보니 일반 서비스의 기획 과정과는 조금 다른 방식으로 작업이 진행되어서, 오늘은 그 과정에 대해 기록을 남겨보고자 합니다 :)

먼저 시크릿 챔버가 어떤 게임인지 간단히 살펴볼까요?

 

 

 

시크릿 챔버는 모바일(가로) 버전으로 제작되었으며, 주요 등장인물은 플레이어 캐릭터인 '나'와 '나'의 친구인 '전혜린'입니다.

(그래픽 디자이너님께서 제가 상상한 나와 혜린이를 너무 멋지게 구현해주셔서 감동의 눈물을 흘렸습니다.. 😭)

 

 

 

시크릿챔버는 텍스트 로그라이크 게임의 문법을 따르기 때문에 턴(turn)제로 진행되며, 매일 밤마다 플레이어는 방을 나설지, 혹은 방에 머무를지를 선택해야 합니다. 

플레이어의 선택에 따라 다양한 에피소드가 진행되며, 그에 따른 다양한 보상과 패널티가 주어집니다.

 

 

 

체력 방전으로 인한 사망을 포함한 엔딩은 데모 버전에서는 총 5개가 존재합니다. 엔딩을 보고 난 이후에는 모든 설정이 초기화 되어 처음부터 다시 플레이 할 수 있습니다.

이 게임, 2박 3일 동안 어떻게 만들었을까요?
이번 글에서는 챔버린 팀의 고군분투에 대해 다뤄보겠습니다 :D

 

 


 

 

1. 사전 준비

 

해커톤 전 작성했던 사전 기획서의 목차

2022 MaKING JAM의 경우 기획자들이 먼저 사전 기획서를 제출하면, 디자인/개발 참가자들이 기획서를 읽고 참여하고 싶은 팀에 지원하는 형식으로 팀이 구성되었습니다. 그래서 기획자 포지션으로 참가 신청을 했던 저는 사전 기획서를 제출해야 했어요.

게임을 좋아하기는 하지만 직접 만들어본 적은 없었던 터라 기획서를 어떻게 작성해야 할지 막막했어서 해커톤에 합격한 이후에 진행 스태프 분들께 문의를 드렸는데, 전체적인 게임의 무드와 진행 방식을 다른 참가자들이 이해할 수 있을 정도의 러프한 기획서를 제출하면 된다고 답변을 주셔서 위와 같은 구성으로 사전 기획서를 작성했습니다.


사전 기획서를 작성하면서 가장 고려했던 건 아래의 사항들이었어요. 하나씩 자세하게 적어보고자 합니다.

(1) 반드시 포함되어야 하는 주요 에피소드 내용 넣기 - 우선 순위 표기
(2) 게임의 형식적인 장르를 명확하게 정의하기



***


(1) 반드시 포함되어야 하는 주요 에피소드 내용 넣기 - 우선 순위 표기


1번은 게임 내용에 대한 팀 전체의 이해도를 비슷한 수준으로 맞추는 것과, 그래픽 디자이너에게 우선 순위를 명확히 전달하기 위한 항목이었습니다. 결국 이 게임이 말하고자 하는 의도가 무엇인지, 등장하는 캐릭터는 누구인지, 이 이야기를 사랑하게 되어야 하나의 팀으로 굴러갈 수 있는 거라고 생각했거든요. 내가 만드는 게임이 재밌어야 디자인도 개발도 즐겁게 할 수 있으니까요.

 

사전 기획서의 스토리 설명 일부

시크릿 챔버는 미스터리 텍스트 게임인만큼 이야기의 매력도가 중요한 요소라고 생각해서 다른 팀의 기획서보다 스토리를 설명하는데 많은 페이지를 할애했습니다! 빠르게 완성해야 하는 해커톤 특성상 다른 팀들은 점핑 액션 게임이나 단순한 아케이드 게임 형식의 모바일 타이쿤 게임을 만들었기 때문에 스토리가 중요하지 않았거든요.

그래서 스토리에 대한 설명 페이지가 있는 제 기획서가 다른 팀들의 기획서보다 조금 분량이 길어서 이게 맞는지 걱정이 되기도 했어요. 하지만 사전 기획 단계에서 이 게임을 가장 잘 이해하고 있는 건 저라는 확신을 가지고, '시크릿 챔버라는 게임을 만들기 위해서 최소한 이 정도의 스토리에 대한 이해는 필요하다!'라고 생각한 만큼 스토리에 대한 설명 페이지를 넣어서 제출했습니다. (나중에 팀원들의 이야기를 들어보니 스토리를 보고 흥미를 느껴서 우리 팀을 골랐다고 하더라고요😁)

주요 캐릭터와 게임의 배경이 되는 메인 스토리는 어떤 내용인지, 플레이어가 달성해야 하는 목표(이야기의 결말)는 무엇인지에 대해 명확히 제시하기 위해 노력했습니다. '프랑켄슈타인'과 '방탈출'이라는 대중에게 익숙한 모티프를 사용해 스토리를 만들었기 때문에 시놉시스처럼 문장 형태로만 이야기를 제시하고 인물 소개 페이지를 추가하여 이해를 돕도록 했어요.

 

 

그리고 그래픽 디자이너가 그래픽 무드를 참고할 수 있는 레퍼런스 그래픽 작업이 필요한 우선 순위를 명확히 이해할 수 있도록 정리한 페이지를 넣었습니다. 게임의 경우 장르에 따라서 일러스트의 느낌이 매우 다르기 때문에 어둡고 선이 거친 느낌의 그래픽 작업을 해보고 싶으신 디자이너 분들이 우리 팀을 선택하셨으면 했어요! 디자이너별로 작업해보고 싶은 느낌이 다를테니까요 ;)

가장 중요한 것은 무드 참고용 레퍼런스를 제외하고는 그래픽 디자이너의 상상을 방해하지 않도록 최대한 간단한 도형과 단색만을 이용해서 기획서를 작성했습니다! 해커톤이기 때문에 팀원들과 함께 게임을 만들어가고 싶었거든요.

기획서를 보고 어떤 작업이 필요한지 미리 감을 잡으실 수 있도록 우선 순위를 나누어 정리했습니다. 캐릭터와 관련된 일러스트, 게임 시스템(체력 등)과 관련된 일러스트, 그리고 이벤트별로 필요한 장소 일러스트 등 항목별로 분류하여 작업량을 가늠하기 쉽도록 했어요.



***


(2) 게임의 형식적인 장르를 명확하게 정의하기


2번은 개발자를 고려한 항목
이었습니다. 게임의 경우 장르별로 개발 방식이 상당히 다를 것이라고 예상했기 때문에 정확히 '텍스트 로그라이크 게임'이라는 장르를 명시하고, 어떤 방식으로 플레이어의 선택이 이루어지는지 그 과정을 명확히 표기해서 개발자들이 기획서를 읽고 대강의 개발 방향을 정리해볼 수 있도록 했어요.

 

가장 플레이 방식이 비슷한 게임을 레퍼런스로 먼저 제시한 이후에 시크릿 챔버에 대해 설명하면 이해도가 더 높을 것이라고 생각했어요. 그래서 텍스트 게임 <별들 사이>를 레퍼런스로 제시했습니다. 그리고 그 다음 페이지에 플레이어가 나의 방에서 매일 탐험과 휴식을 선택해야 한다는 것, 그리고 그에 따라 다른 결과가 발생한다는 것을 간단하게 시각화해서 담았습니다.

(레퍼런스로 <별들 사이>를 선택한 이유는 해당 게임이 MaKING JAM 주최측인 이화여대 게임 개발 동아리 KING에서 제작된 게임이기 때문이었어요. 동아리에서 개최하는 해커톤 특성상 해당 동아리 부원인 참가자가 많기 때문에 참가자들에게 익숙한 게임을 레퍼런스로 제시하는 것이 가장 효과적이라고 판단했습니다.)

 

 

다음 페이지에는 탐험 이벤트별 발생할 수 있는 결과와 휴식할 경우 발생하는 이벤트에 대해 페이지 별로 설명을 나눠서 보다 자세하게 내용을 작성했습니다. 게이지 바와 화살표 등을 이용해서 게임 별로 어떤 이벤트가 발생할 수 있는지를 명확히 보여줄 수 있도록 했습니다.

이외에도 플랫폼, 해상도, 가로/세로 여부 등과 같은 기본 게임 정보와 게임 엔딩 가짓수 및 간략한 설명 등에 대한 설명까지 사전 기획서에 담아서 제출했고, 해커톤 당일 팀이 구성되었습니다!

 

 


 

 

2. 해커톤 진행 중

 

 

(1) 첫째 날


수업이 모두 끝난 이후 해커톤이 시작되어서, 첫 날엔 개회 행사와 함께 짧게 인사할 수 있는 시간이 주어졌습니다.

첫 날에 팀원들과 함께 어느 정도까지 개발하는 걸 목표로 삼을지 논의하기 위해서 조금 더 보충된 자료를 만들어 갔어요. 해커톤의 경우 짧은 시간 안에 빠르게 완성하는 것이 가장 큰 목표이기 때문에, 사전 기획서보다 실제 개발에 참고할 UI 와이어프레임 작업 우선순위를 중심으로 내용을 보충했습니다.

 

 

먼저 개발팀에서  대략적인 UI 위치를 잡고 먼저 기본 개발을 시작할 수 있도록 와이어프레임을 포함한 전체 플로우 차트 페이지를 추가했습니다. 해커톤의 경우 디자인과 개발이 동시에 이루어지기 때문에 미리 자리를 잡아두고 개발하고 있다가 디자인 작업물이 나오는대로 교체하는 방식이 가장 효과적이기 때문입니다.

첫 회의 시간에 전체적인 게임 진행 방식을 모든 팀원이 제대로 이해할 수 있도록 하기 위해서 팀원들과 함께 가상 시나리오를 읽어가며 플로우 차트를 확인했어요. 진행 방식에 어색한 부분은 없는지, 추가적인 의견이 있는지, 개발 목표를 어디까지로 잡을지에 대해 함께 논의하고 결정했습니다.

 

 

와이어프레임 상세 페이지

이어프레임의 경우에는 역시 그래픽 디자이너와 아직 만나기 전이었기 때문에, 그래픽 작업에 방해되지 않도록 단순하게 UI만 확인할 수 있을 정도로만 준비했습니다. 그림과 같이 각 페이지 별로 어떤 내용이 들어가는지 상세하게 확인할 수 있도록 설명 페이지도 추가했고, 게임 시나리오를 한 바퀴 돌기 위해 필요한 필수 기능을 제외하고는 2순위로 표시해두었습니다.

 

 

선택에 따라 발생할 수 있는 에피소드별 보상/패널티도 카테고리(체력, 자신감, 지성)별로 수치화해서 정리했고, 엔딩도 팀원들과 논의하여 가짓수를 6개에서 5개로 줄였습니다. 첫째 날에는 이렇게 전반적인 게임 진행 방식과 스토리에 대해 다시 한 번 이해도를 점검하고 함께 목표를 수립하는 것으로 마무리했어요!

 

 

회의 내용 및 진행 상황은 노션을 사용해 정리했습니다 :)



***


(2) 둘째 날


첫째 날은 사실 사전 기획의 연장선에 가까워서 본격적인 기획 작업은 둘째 날(이라고 적고 첫째 날 밤샘 작업이라고 읽는다)부터였어요.

텍스트 게임이었기 때문에 에피소드별로 어떤 대사가 필요하고, 각 대사별로 어떤 인물 일러스트(대사의 감정마다 다른 일러스트를 보여줘야 했음)가 필요하고, 에피소드를 마친 이후 어떤 보상과 패널티가 주어지는지 정확히 수치화한 결과를 정리하는 작업이 필요했습니다.

 

 

에피소드별 혜린과의 대화 정리본

플레이어가 화면을 클릭할 때마다 다음 대사로 넘어가는 것을 기본 매커니즘으로 정했고, 에피소드에서 각 대사마다 어떤 감정에 해당하는 인물 일러스트를 출력해야 하는지를 정리했어요. 혜린이의 경우에는 '기본' 표정과 '기쁨' 표정 두 가지만 만들기로 결정했기 때문에 두 가지만 활용했습니다.

또한 해당 에피소드가 종료될 경우 체력, 자신감, 지성이 어떻게 변화하는지 수치로 정리해서 개발자들이 참고할 수 있도록 했습니다.

 

 

시크릿 챔버에는 플레이의 긴장도와 흥미를 높이기 위해서 메인 스토리인 혜린과의 만남 이외에도 랜덤하게 발생하는 이벤트가 있었어요. 랜덤 이벤트 역시 선택지에 따른 대사들과 보상/패널티에 대해 정리해두었습니다.

 

 

당연히 엔딩에 대해 정리한 시트도 있었습니다. 엔딩 제목과 대사 내용, 해당 엔딩을 달성하기 위한 조건을 정리했어요. 이렇게 그래픽팀과 개발팀에게 넘겨줄 세부 자료를 모두 작성해 간 후 각 팀의 진행 상황을 체크하며 적절히 목표를 쳐내고 스케쥴을 조정하는 작업을 계속했습니다.

작성한 시트를 개발팀에 넘겨주고, 그래픽팀과 무드에 대해 계속해서 논의하며 우선 순위대로 일러스트를 그리고, 사용할 폰트와 bgm을 찾고, 중간 중간 해커톤의 미션을 제출하는 일을 반복했습니다. 점심/저녁을 먹는 시간마다 중간 작업 진행 상황을 파악하고 도움이 필요한 팀에 손을 보탰어요. (저는 그래픽 디자이너님처럼 고퀄의 일러스트를 뽑아내는 능력은 없기 때문에 주로 개발팀이 난관에 봉착하면 함께 해결했습니다 😁)



***


(3) 마지막 날


마지막 날 오후가 마감&시상식이었기 때문에 사실상 둘째 날 밤샘 작업에 대한 내용입니다. 그래픽팀의 경우 배경 몇 컷과 인물 무드를 잡은 이후에는 자잘한 수정사항밖에 없어서 주로 개발팀 오류에 함께 대응하거나, 최종 발표용 PPT를 제작하는데 품을 들였습니다. 그래픽 디자이너님께서 고퀄을 위해 멋진 욕심을 내주셔서, PPT는 제가 우선 만들고 혹시나 디자이너님께서 수정하고 싶으신 부분이 있다면 손봐주시는 방향으로 진행했어요 😁

최종 발표용 PPT는 이 글 가장 상단에 게임 소개 부분에서 이미 첨부했기 때문에 게임 그래픽 자랑을 하겠습니다.

완성된 시크릿 챔버의 일부 장면들입니다. <분위기상>을 수상할만 하죠? 만드는 2박 3일 내내 정말 멋지다는 말과 함께 오열하느라 바빴습니다. 정말 너무 멋지지 않나요. 이걸 어떻게 2박 3일(사실상 하루)만에 다 만들지. 정말 최고입니다.

시크릿 챔버 말고도 모든 팀에서 정말 완성도 높은 게임을 만드셔서 감탄했어요. 그리고 역시 해커톤에 가장 적합한 게임 형태는 아케이드(특히 점핑 액션)이 최고라는 교훈을 얻었습니다. 하지만 전 시크릿 챔버를 만드느라 정말 재미있었거든요. 후회는 없다😎

 

 

해커톤에서 가장 중요한 건 결국 팀원이라고 생각해서 팀원 소개 페이지를 대문짝만하게 넣었습니다.

여러분 덕분에 정말 즐겁게 해커톤을 끝낼 수 있었어요. 최선을 다해 의견 나눠주시고, 밤을 새면서도 웃음을 잃지 않고 열정적으로 함께해주셔서 정말 감사했습니다. 이때 너무 즐겁게 작업해서 챔버린은 해커톤 이후에도 종종 모이는 모임이 되었어요. 정말이지 최고의 팀, 챔버린.

 

 


 

 

3. 나가며


기획자로 해커톤에 참여해보는 게 처음이었고, 게임을 만들어보는 건 더더욱 처음이어서 고민이 많았는데 정말 좋은 팀원들을 만나 즐거운 경험을 할 수 있었음에 감사한 시간이었습니다. 개발자가 아닌 기획자로 해커톤에 참여해보니 또 다른 점들을 배울 수 있었어요. 그 점에 대해서 기록으로 남겨두고 싶어서 이 글을 시작했는데요. 간략히 정리해보려고 합니다.


(1) 프로젝트에 참여하는 전 직군의 작업 방식에 대한 정확한 이해가 필요하다.

게임 해커톤이었기 때문에 그래픽 디자이너와 개발자의 작업 방식을 정확히 이해하는 것이 정말 필수적이었습니다. 제가 이제껏 개발자로 프로젝트에 참여했었던지라 개발자들이 어떤 방식으로 반복되는 형식의 게임을 구현할지 미리 예측 가능했기 때문에 그에 맞춰서 사전 기획 자료와 와이어프레임/플로우 차트를 준비했던 게 큰 도움이 되었어요.

해커톤의 경우 짧은 기간 안에 완성하는 것이 목표이기 때문에 디자인과 개발 작업이 동시에 시작/진행될 수밖에 없어서 각 팀의 작업 방식에 대해 정확히 이해하고 제작 계획을 관리하는 것이 필수적입니다. 제가 작성한 기획 문서들이 정답이라고 할 수는 없지만, 이만큼 세분화해서 팀별로 필요한 자료를 미리 준비했기 때문에 비교적 볼륨이 큰 게임을 기한 내에 완성할 수 있었다고 느꼈습니다.


(2) 팀원들의 의견을 최대한 반영하되, 아이템에 대한 확신을 가져야 한다.

프로덕트에 대해 모든 팀원이 충족해야 할 최소한의 이해도를 설정하고, 직군에 상관 없이 모든 팀원이 그 부분까지 동일하게 이해할 수 있도록 설명하는 초기 작업이 정말 중요하다고 느꼈습니다. 짧은 시간 안에 게임을 완성해야 하기 때문에 팀별로 필요한 부분만 이해하는 것이 효과적이라고 느낄 수도 있으나, 결국 프로덕트에 대한 (시크릿 챔버의 경우에는 전반적인 게임 스토리와 시스템이 이에 해당합니다.) 이해가 부족하면 개발 과정에서 길을 잃기 쉽습니다.

그래서 초기에 함께 전반적인 게임 기획에 대한 의견을 나누고, 세부적인 요소들을 함께 정해가는 과정을 통해서 팀원 모두가 함께 만들어가는 게임이라는 느낌을 받을 수 있도록 노력했어요. 랜덤 이벤트의 경우에는 팀원들이 던져준 아이디어를 발전시켜서 만들기도 했고, 스토리나 게임 진행 방식에 대한 질문 및 건의 사항도 활발하게 공유했습니다. 확실히 첫째 날에 이 과정을 제대로 지나오고 나니 둘째 날부터 흔들림 없이 개발에만 몰두할 수 있었어요.

특히 이번 해커톤의 경우 기획자가 만들고 싶은 게임을 먼저 공개하고 팀이 그에 맞춰서 구성되었기 때문에 어떻게 보면 '기획자가 만들고 싶은 게임'을 구현하는 작업이기도 했습니다. 그래서 반드시 사수해야 하는 저만의 게임 키 포인트를 정했어요. 팀원의 건의 사항들을 모두 수용하는 것도 프로젝트의 방향성을 잃어버리는 일이라고 생각해서, 이 게임의 정체성을 잃지 않도록 양보할 수 없는 요소들을 정해두었고, 시크릿 챔버에서는 '나'의 정체가 괴물이라는 반전과 등장인물 2명의 설정, 그리고 체력/자신감/지성이라는 스탯 카테고리가 그 부분이었습니다.

'나'와 '전혜린'이라는 인물의 대화를 통해 '나'의 정체가 밝혀지는 구간까지는 반드시 스토리가 진행될 수 있도록 개발이 완료되어야 하며, 스탯 수치에 따라 엔딩이 정해지는 기본 매커니즘을 갖춰야 한다는 것이죠. 결국 반드시 구현해야 하는 1순위 기능을 적절하게 추리는 과정이라고도 할 수 있겠습니다. 끝없는 고민을 통해 나온 저의 결과물에 확신을 가졌기 때문에 남들과는 조금 다른 사전 기획서를 작성하고, 팀원들에게 정확한 가이드를 제시하고, 멋진 게임을 완성할 수 있었던 거라고 생각합니다 😁


(3) 기획자는 팀의 대표로서 팀원 관리를 잊지 말아야 한다.

사실 저는 이제껏 참여했던 해커톤들에서는 결과물을 완성해야 한다는 압박감이 강해서 과정 자체를 즐겨본 적이 없었습니다. 그래서 이번 해커톤에서는 모든 팀원이 정말 재미있게 이 과정 자체를 즐길 수 있었으면 좋겠다는 생각을 했어요. 팀원들이 완성에 대한 압박을 적게 느끼게 하기 위해서는 개발을 위한 충분한 시간을 줄 수 있어야 했고, 그러기 위해서는 기획자가 필요한 것들을 최대한 빠르고 자세하게 넘겨줘야 한다는 결론을 내렸습니다.

그래서 첫째 날 회의 이후 개발 전 과정에 필요한 문서를 꼼꼼하게 모두 준비했습니다. 앞부분만 먼저 작업해두고 뒷부분은 개발 상황을 보고 난 후 맞춰서 작업했어도 됐겠지만, 둘째 날 작업해야 하는 일이 남아있을 경우에 그래픽/개발팀의 상황을 면밀히 체크하기 어려울 것 같다는 생각이 들었어요. 그래서 조금 과하다 싶을 정도로 모든 에피소드별 대사와 선택지별 보상/패널티 결과를 정리해서 가져갔습니다. 그 결과 둘째 날에 게임 개발이 빠르게 진행되었음은 물론, 기획과 관련해서 작업할 일이 거의 없었기 때문에 팀원들을 살피는데 많은 시간을 할애할 수 있었어요.

챔버린에는 해커톤이 처음인 팀원도 있었고, 이제 막 해당 분야에 발을 들인 팀원도 있어서 작업이 계획대로 되지 않는 상황이 당연히 발생했고, 그에 따라 분위기가 정말 급격히 다운되는 경우가 종종  있었어요. 그때 옆에 앉아서 문제 상황을 함께 해결하고, 충분히 잘하고 있다고 다독여주고, 작업 상황에 따라 얼마든지 목표를 수정할 수 있으니 걱정 말라고 팀원들을 안심시킨 후 실시간으로 스케쥴을 조정해가며 팀을 매니징했습니다. 당이 떨어질 때면 열심히 간식을 사와서 팀원들의 사기를 북돋우려고 노력하기도 했고요 😎 이러한 효과 외에도 시간적 여유가 있었기 때문에 bgm과 같은 추가 자료들도 미리 찾아둘 수 있었고, 최종 PPT도 미리 만들어서 전체 팀원의 검토를 받을 수 있었기 때문에 좋은 선택이었다고 생각합니다.

물론 이것은 챔버린의 핵심 가치를 '과정의 즐거움'으로 두었기 때문에 취했던 방식이었습니다. 새로운 사람을 만나서 빠르게 의견을 교환하고 생각보다 괜찮은 결과물을 만들어서 뿌듯함을 느끼는 게 해커톤의 묘미라고 생각하고, 팀원들이 모두 이 즐거움을 누릴 수 있었으면 좋겠다고 생각했거든요. 그 덕분에 기획자가 꼼꼼하게 설득력 있는 기획을 준비하고 시간을 할애하여 팀원들을 살필수록 팀원들이 더 안정적으로 작업에 몰두하게 되어 빠르고 정확한 개발 사이클을 돌 수 있다는 걸 직접 체감할 수 있었습니다.



거창하게 적었지만 이 모든 것이 가능했던 건 정말 좋은 팀원들을 만난 덕분이었습니다. 많이 배우고, 많이 웃는 시간이었어요. 즐거운 기억을 남겨주셔서 정말 감사합니다. 조만간 또 만나요, 챔버린!

 

 

GitHub - 22MaKINGJam/SecretChamber: 시크릿 챔버 : 그곳엔 아무도 없었다

시크릿 챔버 : 그곳엔 아무도 없었다. Contribute to 22MaKINGJam/SecretChamber development by creating an account on GitHub.

github.com

 

댓글