기록을 해야지만 남을 수 있는 것이 있다고 생각한다. 특히나 프로젝트 하나를 마무리한 이후엔 더더욱 그렇다.
<팡팡포!>는 26/01/21부터 26/04/19까지, 2명의 개발자가 89일 동안 진행한 초단기 미니게임 개발 프로젝트다.
이 글에선 나의 첫 게임개발 팀장 프로젝트이자, 첫 Godot Engine(이하 고도엔진) 프로젝트였던 <팡팡포!> 작업에서 느낀 점과 함께, 앞으로 나아갈 방향에 대해 정리해보고자 한다.
여기서 잠깐! <팡팡포!>는?
고양이가 되어 거품총으로 청소하는 힐링-슈팅-클린 플랫포머 게임입니다.
귀여운 픽셀아트!
30분 내외의 짧은 플레이타임!
다운로드 없이 컴퓨터로 플레이 가능!
아래 링크에서 확인해 보세요.
https://www.game-ping.kr/games/pang-pang-paw
팡팡포! | 게임핑 (GamePing)
고양이가 되어 거품총으로 청소하는 힐링 슈팅 클린 플랫포머. 당신의 목표는 총을 쏠 때마다 닳는 '깨끗함 지수'를 관리해가며, 맵에 있는 모든 몬스터를 정화하는 것입니다. 더러운 오물 몬스
www.game-ping.kr
프로젝트 계기
직장에 다니며, 1인 개발로 제작하던 게임 프로젝트의 엔진을 옮기기 위해, 고도엔진 튜토리얼 시리즈 하나를 마친 시점이었다. 이제 진짜로 고도 안에서 프로젝트 시스템을 구현하기만 하면 되는 단계였다. 고도 튜토리얼은 TypeScript와 Python을 해본 입장에서 크게 어렵지 않았고, 에디터 조작도 어느 정도 익숙해진 것 같았다. 그래서 자신만만하게 새 프로젝트를 하나 생성했는데...! 텅 빈 화면을 보니 어떻게 진행을 해야 할지 감이 잡히질 않는 것이다. 유튜브를 따라 캐릭터 움직임까진 얼추 성공했지만, 정작 내가 생각하는 게임 시스템을 위해선 어떤 노드가 필요한지, 프로젝트 폴더 구조는 어떻게 해야 하며 코딩은 어떻게 해야 효율적일지... 무언가를 새롭게 만들려고 하니 머리가 백지가 되는 기분이었다. 특히나 이 프로젝트는 나의 드림 게임이기도 해서 욕심 내지는 부담감 같은 것도 갖고 있었으니, 생각만큼 진행이 안 되니 시간이 갈수록 점점 더 답답해져갔다.
그렇게 얼마간 삽질을 하고 난 뒤엔, 정면돌파를 포기하고 우회로를 찾았다. 바로 이 프로젝트를 미뤄두고 다른 '작은 게임'을 만들어보는 것. 단기간동안, 게임이라 부를 수 있을만한 것을 만들어서 사람들에게 공개까지 해보는 것이 목표였다. 일단 게임 전체를 한번 만들어보는 것이 중요했기 때문에 볼륨은 짧을수록 좋았고 재미도 없어도 됐다. 어디까지나, 내가 '고도엔진'의 시스템 자체에 적응하기 위한 프로젝트였으므로 말이다.
그런데 여기서 문제가 생긴다.
그럼 지금 하던 게임 말고 어떤 걸 만들 것인가?
마음에는 안 드는 작은 아이디어들을 떠올리긴 했지만, 문제는 그다음이다.
그럼 어셋은 어떡할 것인가?
거기까지 생각이 도달했을 때, 그 주 주말에 참여했던 독서모임에서 뵈었던 da0님 생각이 났다.
정확히 그 시점에 픽셀아트로 취업준비 중이라는 얘기를 들었기 때문이었다!
헐! 그럼 둘다 초보잖아? 이분은 프로젝트 경험 쌓고 나는 나머지 개발 다 하면 윈윈일 거 같은데?!
그리하여 내 쪽에서 무작정 연락해서 끌어들였다. 독서모임에서 만난 사이여서 서로 포트폴리오는 물론 성격이나 작업스타일도 잘 모르는 상태였는데 괜히 느낌은 좋았다. 감사하게도 da0님도 흔쾌히 이 프로젝트를 수락하셨고, 그리하여 이번 프로젝트의 여정이 시작되었다.
프로젝트 방향
이 프로젝트의 핵심 아이디어는 첫 회의 때, da0님의 아이디어로 결정되었다.
메이플+버블버블 2D 사이드뷰 플랫포머 청소게임.
움직임 자체로 즐거움을 얻을 수 있는. 플레이에 집중한 게임을 만들어보자.
가볍게 시작하고 끝을 볼 수 있는 게임을 만들자.
내 취향이 너무 확고한 편이라 da0님과 한 작업이 아니었다면 나오지 못했을 기획 방향과 아이디어였다. 특히나 사이드뷰 플랫포머는 예전 게임 프로젝트에서 여러 번 작업해 본 적 있어서 넘기던 장르였는데, 정작 이 키워드를 듣고 생각해 보니 그중에 내가 프로그래밍을 맡은 건은 하나도 없었다. 그래서 단번에 결정.
그 외에 사소한 것들은 주간 회의를 거쳐가면서 하나씩 결정되었다. 예를 들어 산신령이 등장한다거나, 스토리, 몬스터 컨셉 등...
이제와 돌이켜보면 내가 프로젝트 초기에 제안했던 방향은 원인-결과에 연연하는 심각한 스토리와 기획이었다.
회의 때마다 ㅇㅇ가 ㅇㅇ이 됐네요? 그러면 ㅇㅇ이 ㅇㅇ한 걸까요? 하고 은근슬쩍 원인결과 따졌는데, 꾸준히 화장실 청소게임이라는 방향을 유지해 준 da0님께 이 자리를 빌어서 감사의 말을 전하고 싶다.(...) 그 외에도 캐릭터 대화문이 지금보다 몇 배로 더 길었는데, 말끔하게 쳐내주신 것도 da0님 덕분이다!
현재의 가벼운 게임톤이 이 게임에 가장 잘 어울리는 방향이었다고 생각한다. 게임이 가진 가벼움과, 가볍다는 말의 부정적인 어감에 대해 다시 한번 돌아볼 수 있는 기회였던 듯.
고도 엔진 사용기
나름 유니티도 써보고 알만툴(RPG Maker)도 써보고 언리얼도 써본 입장에서, 고도엔진 최고의 장점은 역시 "가벼움"이다. 10초 만에 열리는 엔진. 20초 만에 되는 빌드. 여기에 더 다른 말이 필요할까? 물론 이 점에 있어선 알만툴도 빠르고 가벼운 엔진이지만, 엔진의 유연함과 엔진 내에서 조작할 수 있는 요소의 가짓수를 생각하면 이것만으론 비교될 수 없을 것 같다. (알만툴&고도에 대한 이야기는 조만간 쓰게 될 개인 프로젝트의 개발일지에서 다룰 예정...)
게임 메인로직 구현 자체는 쉬웠다. 장르가 장르인지라 유튜브에 다양한 튜토리얼이 있기도 했고, 이상하거나 오류가 나더라도 단순 구글 검색으로 해결됐다. 애초에 로직이 어려운 게임이 아니기도 하고.
플러그인은 최소로 사용했다. 지금 보니 몇 개는 삭제해도 되겠다 싶긴한데... 뭐 이것도 삽질의 흔적이라면 흔적일 듯.
몬스터 움직임 AI에 관련해서는 Beehave과 LimboAI 중에서 고민했다. 다만 움직임에 관한 행동을 하이라이키에 표시되는 노드로 몽땅 다 저장/표시해야하는 Beehave 특성 때문에, LimboAI로 결정했다.(위 사진 목록에는 없음) LimboAI에는 게다가 행동트리 외에도 StateMachine도 포함되어 있길래, 큰 고민 없이 이걸 플레이어의 움직임 input 처리용으로 사용했다. 어떻게 보면 LimboAI가 올인원 팩 같은 느낌. 동작을 추가하는 것도 쉬웠고, 유지보수 단계도 괜찮았고(한 번 공식문서 안 읽고 subtree 넣었다가 박살난 것만 빼고), 워낙에 잘 다듬어진 플러그인이어서 다음 프로젝트에도 쓰게 되지 않을까 싶다.
캐릭터 대사, Dialog 관련해서도 고도에는 양대산맥 같은 플러그인이 있다. Dialog Manager와 Dialogic이 그것인데, 원래는 Dialogic을 사용할 예정이었으나 GUI가 강화된 플러그인 특성상 대사문을 텍스트에디터로 수정하기 번거롭다는 점이 유지보수 면에서 너무 큰 마이너스 요소였다. 그래서 전자인 Dialog Manager를 사용하게 됐다. Dialog Manager는 기본 설치만 해도 잘 만들어진 예제가 포함되어 있지만, 공식 레포지토리에 다른 스타일의 말풍선 예제도 판매하고 있으니 그걸 사용해도 괜찮겠다 싶었다. 물론 이번 프로젝트는 간단했으니 직접 만들었지만.
Aseprite Wizard - 이 플러그인 얘기는 안 할 수가 없다. 확장성과 간편함이 말도 안 된다. 사용 중에 제일 놀랐던 건, Aseprite 파일에서 엔진으로 애니메이션을 임포트한 뒤에, 해당 애니메이션에 파티클 이펙트나 사운드 이펙트 등등 이것저것 트랙을 추가한 뒤, Aseprite 파일을 다시 재임포트하는 것도 가능했다는 것이었다. 심지어 파티클, 사운드 트랙이 완전히 보존된 채로!! 같은 애니메이션 파일 내에서 '스프라이트 트랙'만 수정되도록 말이다! 아트 분과 협업하면서 정말 큰 삽질을 줄여준 플러그인이다. 벅차올라서 주절댔는데 지금 찾아보니 이제는 유니티에도 지원되는 기능이라고. 시간이 너무 빠르다.
결국 고도엔진을 쓰면서 느낀 총평은 아래와 같다.
- 이 세상 모든 것은-심지어 기능까지도- 오직 노드다.라는 직관성
- 어떤 기능을 담당하는 노드에 새 기능을 추가하고 싶다면? 그 노드의 하위 노드로 새 기능을 '붙이면' 된다.
- 언어의 복잡함은 덜고, 구조에 집중할 수 있도록 만들어주는 GDScript
- 벡터 연산? 데이터 저장? 스크린샷? 굳이 몇 백 줄 코드 쓰지 않아도 엔진에 함수 하나로 미리 정해져 있는 간편함
- python의 단순함과 typescript의 적당한 명료함이 잘 배분되어 읽고 쓰기 편한 코드
- 결국 코드가 쓰기 편하니 게임의 아키텍처 자체와 게임만의 재미에 더 집중할 수 있게 되었다.
- 굳이 아쉬운 점이 있다면, 전용 에셋 시장의 부재
- 최근에야 고도 에셋 스토어가 정식 개장했다. 예전 고도 에셋 라이브러리 시절보다 훨씬 낫고(...), 의지는 보여주고 있으니 다행이지만, 가끔 유니티나 언리얼 에셋 스토어를 보면 배가 아픈 건 어쩔 수가 없다.
(그렇다고 살 것도 아닌데)
- 최근에야 고도 에셋 스토어가 정식 개장했다. 예전 고도 에셋 라이브러리 시절보다 훨씬 낫고(...), 의지는 보여주고 있으니 다행이지만, 가끔 유니티나 언리얼 에셋 스토어를 보면 배가 아픈 건 어쩔 수가 없다.
아주 특별한 이슈가 없는 한, 앞으로도 1인개발에 고도를 사용하게 될 것 같다. 시간 내서 배우길 정말 잘했다! 이 글을 읽는 당신이 당장 고도엔진으로 작업할 예정이 아니더라도, 게임 아키텍처를 배운다는 느낌으로 간단히 고도의 노드 개념만 접해보는 것도 추천한다. 어차피 오픈소스기도 하고 말이다. 아무리 쓸 일 없는 프로그램이라도 공식문서는 읽으면 읽을수록 도움이 되는 듯.
프로그래밍에 관해서
이번 프로젝트의 목표는 '고도 엔진에 적응'하는 것이었으므로, 당연히 프로젝트 전체에서 AI는 사용되지 않았다. 대신 이번에 처음으로 클로드에게 이 프로젝트에 대한 코드 리뷰를 맡겨봤는데 내상을 입고 며칠 째 코딩을 못하고 있다. (농담맞음)
엥? AI가 코드리뷰를? AI는 파일 하나 밖에 못 읽지 않나? 하는 3개월 전의 나 같은 사람을 위해 남겨두자면, 하나의 레포지토리를 AI-프랜들리하게 하나의 파일로 정리해 주는 툴이 있다. 아래 링크를 보시라. 둘 중 편한 데를 아무 데나 쓰면 된다.
Repomix | Pack your codebase into AI-friendly formats
Pack local or remote repositories into AI-friendly XML, Markdown, JSON, or plain text for Claude, ChatGPT, Gemini, MCP, and code review workflows.
repomix.com
Gitingest
Replace 'hub' with 'ingest' in any GitHub URL for a prompt-friendly text.
gitingest.com
그 외에는 github와 약간은 더 친해졌다. 예를 들면, 보통 나는 개인 작업만 진행하므로 깃허브의 push pull 외에 쓰는 기능이 없었는데 이번에 처음으로 버전 관리를 위해 tag도 써봤다. 근데 여전히 잘 모르겠긴 하다. 그래서 최근엔 레딧을 뒤적거리면서 남의 레포지토리를 훔쳐보는 취미가 생겼다. 보다 보니 일단 내적친밀감은 생긴 거 같다.
목표는 있다. 언젠가 branch로 좀더 직관적이고 확실하게 기능과 버전을 관리하고 싶다는 목표가... 그런데 하루 동안의 작업에 워낙 여러 곳을 손대는 타입이라 언제 즘 적용하게 될지는 미지수.
github tag 관련 참고 문서:
- https://inpa.tistory.com/entry/GIT-⚡%EF%B8%8F-태그-기능-및-사용법-tag
- https://docs.github.com/ko/enterprise-cloud@latest/desktop/managing-commits/managing-tags-in-github-desktop
팀 프로젝트를 위한 첫 노션
이렇게 본격적으로 팀 프로젝트에 노션을 사용해 본 적이 없었다. 단순 기록, 목표 공유, 기획서 공유, 레퍼런스 저장 등, 평소에 매번 쓰던 노션 기능이었지만 협업으로 진행하려고 생각하니 확실히 느낌이 달랐다. 간편하게 뽑아 쓸 수 있는 템플릿이 많아서, 세팅을 크게 신경 쓰지 않더라도 한 페이지 안에 다양한 정보를 다 집어넣을 수 있다는 점 역시 노션의 강점. 단기 프로젝트였던 만큼 노션의 기본기능 만으로도 충분히 이점을 많이 챙길 수 있었다.
다만 게임 개발에 있어서 노션이 최고의 프로젝트 관리 툴일지는 모르겠다. 예를 들어 게임 개발에선 하나의 기능이 여러 번 세분화되는 경우가 많은데, (예: '플레이어'를 플레이어 움직임과 플레이어 능력으로 세분화) 그게 어느 정도 진행되었는지 한눈에 볼 수 있는 기능이 노션에는 없다. 노션도 나름 하위 항목이나 상위 항목, 관계형, 롤업 등 '할일 쪼개기'를 위한 기능이 여럿 있긴 하지만, ui가 직관적이지 않을뿐더러 자칫하면 연결성이 꼬이기 십상이라 이번 프로젝트에선 쓰지 않았다. 덕분에 연결성 없이 너무 사소한 것도 다 적느라 터져버린 노션 투두리스트... (...)
언제는 이런 일도 있었다. 작업 중 시간관계상 포기하게 된 할일을 삭제할지 말지 고민하다가, 속성값을 넣어서 따로 "포기함" 테이블로 빼뒀다. 당장 보기엔 깔끔하고 괜찮아보였다. 근데 며칠 뒤에 다시 보니까, 원본 테이블에 써둔 할일이 "포기함" 테이블에도 똑같이 존재하는거다. 며칠 전에 이미 원본 테이블에 써두고 "포기함"으로 미뤄버린 일이었는데, 원본에 그 할일이 안보이니까 내가 까먹고 또 그 할일 항목을 새로 만들어둔 거다. 이번엔 기간이 짧은 프로젝트였으니까 이런 일이 한두 번으로 그쳤지만, 이런 일이 많아질수록 점점 꼬여가고 복잡해지는 노션 특유의 비직관성이 역시 나한텐 맞지 않는 것 같다. 일을 해야 할 시간에 노션 세팅 중독이 되어가는 건 덤.
그래서 다음엔 프로젝트 관리 툴을 바꿔볼까 생각 중이다. 후보는 옵시디언과 미로(miro). 옵시디언은 플러그인 쇼핑하다가 몇 번 엎었던 일례가 있어서 당장은 미로를 테스트해 보는 중. 또 하나 알게 된 간단한 툴 중에는 WorkFlowy와 Logseq도 있는데, 이런 아웃라이너 방식도 직관적이라 괜찮아 보인다. 또 쓰다 보니 Milanote도 아른거리는데... 이건 반드시 유료 구매를 해야 블록 수 제한이 풀려서 영원히 눈앞에서 아른거리기만 할 것 같다. 보드 안의 보드...? 모바일도 지원된다고...? 아른아른...
Miro 관련 참고 영상 : https://www.youtube.com/watch?v=Q1TzYZ6kf8U
연출과 게임 디자인에 관해
플레이어의 움직임 범위와 '깨끗함' 게이지 시스템 작동 원리, 몬스터의 구체적인 종류와 능력치, 난이도 조정 등의 레벨 디자인, 이벤트의 VFX 및 SFX는 내가 진행했다. 한 줄로 정리하자면, 엔진에서 작업되는 대부분의 요소는 내가 직접 진행했다.
시스템에서 가장 강조하고 싶었던 것은 역시 '청소 게임'이라는 컨셉이었다. '깨끗함' 게이지가 존재해서, 주인공이 공격할수록 깨끗함 게이지가 깎이고, 남은 깨끗함 게이지만큼만 공격이 가능하다는 컨셉은 내 아이디어였다! 기획 중에 깨끗함이라는 컨셉에 대해 다양한 아이디어가 나왔었는데 구현되지 못한 것도 많아 한편으론 아쉽기도 하다. 예를 들면 완전히 깨끗해져 '정화'된 몬스터들은 몬스터마다 다르게 움직이면서 맵을 깨끗하게 만들어준다거나... 플레이어가 쏜 거품이 더러운 곰팡이에 닿으면 그 곰팡이가 지워진다거나... 등등.
메인 로직에 대한 구현 자체는 얼마 걸리지 않았는데(대략 1.5개월), 오히려 예상 작업 시간을 훨씬 오버했던 건 연출과 사운드 이펙트였다. 특히나 사운드. BGM은 다행히 좋은 무료음원을 찾아서 금방 넘어갔지만, 사운드 이펙트는 정말 노가다 그 자체였다. 단순히 엄청나게 많은 사운드를 듣는 것 자체도 일이긴 한데, 특히나 이 게임은 레트로/8bit 풍의 사운드 위주로 찾느라고 비프음을 많이 듣느라 정신력도 덩달아 깎이니 체력 소모가 심했다. 내가 직전에 진행했던 애니메이션 프로젝트나 게임 제작 프로젝트에서도 필요한 어셋만 당장 검색해 넣는 것에만 급급했기 때문에, 자료폴더에 남아있는 어셋이 거의 없었던 이유도 컸다. 이 단계에 와서야 어셋 쇼핑의 중요성을 깨닫고 itch.io를 다 털었다는 후문 아닌 후문.
어찌 되었든 그렇게 얼추 사운드를 채우고 나니! 이게 웬걸. 게임 메인 로직이 다 구현되었으니 안심하고 있었는데, '메인로직 외의 나머지 요소'가 생각보다 너무 많았다. 예를 들면 타이틀씬, 문 조사 시 이벤트 및 이동, 이벤트 시에 캐릭터 애니메이션과 연동, 결과창 등등... 작업시간 자체가 많이 드는 일은 아닌데, 이런 요소는 게임이 정상적으로 돌아갔을 때에만 작동을 확인할 수 있어서 테스트가 예상보다 훨씬 더 까다로웠다. 이번엔 짧은 게임이니 어찌저찌 넘겼으나 게임 개발 과정에 슈퍼모드를 만드는 게 왜 중요한지 다시금 되새기게 됐다.
결국 게임개발 취미 팀 프로젝트에 필요한 것
이번 프로젝트에서 배운 것과 요즘 회사에서 배우고 있는 것을 적당히 짬뽕해서 나열해 봤다.
차기 게임개발 팀장들에게 도움이 되길.
- 반드시 구체적인 "마감일"이 존재해야 한다.
상업팀이면 공모전 마감 등 그나마 데드라인이 있겠지만, 취미팀은 아니므로. 해당 게임을 제출할 대회 출품 마감일 등이 제일 좋겠으나 그런 게 없더라도 약속된 마감일을 공유해야 한다. - 게임의 핵심재미 "우선순위"를 정하고, 그 순위별로 작업이 진행되어야 한다.
'다른 건 다 없어도 되지만 이것만큼은 있어야 한다'가 정해져 있어야 한다. 그리고 이 방향을 지정해 주는 것이 기획자/팀장의 역할이라고 생각한다. - 일단 내가 제일 열심히 일해야 한다. (특히 팀장이면 더더욱)
막말로 프로젝트가 엎어지더라도, 내가 열심히 한 작업물은 남는다. 기획이든 아트든 프로그래밍이든 결국 열심히 하는 사람이 승자다. 물론 팀원의 사기를 위한 것도 있긴 하다. - 업무의 분담은 명확해야 한다.
남이 맡은 일 내가 할 수 있다고, 시간 부족하다고 떠안다 보면 감정이 상할 수 있을뿐더러 효율성도 떨어진다. 결국 팀 굴리기는 팀원을 믿는 일 아닐까. 일단 믿고 기다리면 상상 이상의 엄청난 작업물이 도착할 때도 있다. 일종의 낚시류 가챠인 것이다! (!) - 재밌자고 사는 인생인데 너무 스트레스받지 말자
잊지 말 것. 망한 것도 경험이다. 물론 말이 쉽긴 하다.
내가 이 프로젝트를 통해 얻고 싶었던 것은 따로 있었으므로, 게임의 퀄리티가 낮아도 괜찮았다. 어차피 웹상에 무료 공개할 예정이었기 때문에 극단적으론 프로젝트가 무산되더라도 서로에게 불이익이 없는 환경이었다. '하면 좋고 아니면 말고'였던 것이다.
그러나 역으로 말하면, 프로젝트가 성공(?)한다고 해서 팀원에게 보상으로 줄 수 있는 것이 없었기 때문에 작업 페이스에 대한 고민은 좀 있었던 것 같다.
다행히 팀원이었던 da0님은 서로의 방향에 대해서 자주 궁금해하고, 작업 중 생긴 고민이 있다면 공유할 수 있는 분이셨다. 자주 대화하면서 두루뭉술했던 내 머릿속도 덩달아 깨끗해지는 기분이 들었다. 협업을 하면서 항상 좋은 마음만 들지 않았던 건 사실이지만, da0님과 같이 작업할 수 있어서 정말 다행이었다. 이런 팀플레이만 할 수 있다면 평생 할 수 있지 않을까... 생각까지 들었을 정도였다. 다음에 기회가 되면 또 함께 작업할 수 있었으면 좋겠다!
마치며
글쓰기는 여전히 정말 힘들다. 그러나 글을 쓸 줄 아는 사람이 되고 싶어서 여전히 글쓰기를 위해 ai를 사용하지 않는다. 이건 나의 아집일 수도 있을 것이다. 하지만 한 가지 확실한 건, 글쓰기는 힘든 만큼 정말 재밌다는 것이다. ai에게 굳이 이 즐거움을 양보하고 싶지 않다. 네가 재밌어서 어쩔건데!
비슷한 의미에서 게임개발도 나에겐 늘 재미있는 일이다. 물론 다음에 진행할 프로젝트는 장기 1인개발이 될 것이므로 ai의 도움을 받긴 하겠지만... ai한테는 재미없는 일만 시킬 것이다. 내가 만들게 될 그것(게임이든 뭐든)이 어떤 모습일지 기대된다. 기대하는 일을 멈출 수 없다. 그런 생각을 하면서 살고 있다.
벌써 2026년의 중반이 되어가고 있다. 이 글을 읽는 당신에게 좋은 일이 있길!