チーム結成の出発点
これまで私はさまざまなゲームプロジェクトを企画・開発してきたが、そのほとんどは一人で進める個人プロジェクトであった。
（これまで企画・開発してきたゲームプロジェクト、投稿日現在）
（廃棄・中断したプロジェクトを含む）
| Project | Period | Project Type | Genre | Result |
|---|---|---|---|---|
| Project S | 2020. 10. ~ 2021. 12. | Solo Project | Hero Shooter | ⏸️ Interrupted |
| Astral Days! (Project AD) (Project A) | 2020. 10. ~ (Ongoing) | Solo Project | Story-based Action RPG | 🔄 In Progress |
| Project R | 2020. 12. ~ 2021. 1. | Solo Project | RPG | ⏸️ Interrupted |
| Project F | 2020. 12. ~ 2022. 1. | Solo Project | Action RPG | ⏸️ Interrupted |
| Python Game Contest | 2023. 06. ~ 2023. 07. | Team Project | 2.5D Rhythm Action | ⏸️ Interrupted |
上の表からも分かる通り、これまで進めてきた、あるいは現在進行中のプロジェクトの中で、チームプロジェクトはたった一つしかなかった。それすら最後まで完成させることができず、中断してしまった。
そんな中、大学に入学した私はゲーム開発中央サークルGAMMARUに合格し、最初は準会員として入部することになった。
（GAMMARUでは、入部時は準会員として始まり、その後コンテストに参加することで正会員へ昇格できる。もし一学年以内に昇格できなかった場合は、自動的に退部扱いとなる。）
私はGAMMARUに入部してからさまざまな活動に参加してきたし、これからも活動を続けていきたいと考えていた。そのため、私にとって正会員へ昇格する機会であるコンテストへの参加は、ほとんど必須に近いものだった。
正会員昇格のためのコンテストは年に二回行われる。新入部員のみが参加できる夏コンテストと、全部員が参加できる冬コンテストである。しかし、個人的な学業計画として冬にはJLPT資格の取得と大学の冬季学期の準備をしなければならなかったため、冬コンテストまで並行して参加するのは難しいと判断した。 こうして私は夏コンテストに参加することを決めた。
基本的にGAMMARUのコンテストには、チームの人数制限が存在しない。つまり、一人で参加することも可能なのである。しかし今回だけは、一人でコンテストに参加するのではなく、チームを組んで一つのプロジェクトを一緒に作ってみたいと思っていた。
これまでほとんどすべてのプロジェクトを一人で進めてきたし、過去に一度チームプロジェクトへ参加した経験はあったものの、そのプロジェクトも最後まで完成させることはできなかった。そのため、複数人で役割を分担し、一つのゲームを最後まで作り上げていく本格的なチーム開発は、事実上初めてと言ってもよかった。 それだけでなく、この機会を通してGitなどを活用した実際の共同開発を経験し、複数人で一つの目標を共有しながらプロジェクトを最後まで完成させてみたいとも考えていた。
そこで複数のチームの募集投稿を確認した後、その中で最も魅力的に感じた「ERROR CODE: H」プロジェクトに参加することを決めた。
(プロジェクト応募時の会話記録の一部 1)
(プロジェクト応募時の会話記録の一部 2)
こうした過程を経て、私を含む計4人で「Team RHEO」が結成された。
小さな問題の連続
役割分担の問題
チームを結成した後、最初に直面した問題は役割分担であった。
今回のプロジェクトのメンバーは全員、ゲーム開発に関するチームプロジェクトをきちんと最後まで完成させた経験がなく、さらに4人全員の得意分野がプログラミングであった。 実のところ、これはある程度自然なことでもあった。
GAMMARUは現在、ゲーム開発の中央サークルであるが、もともとはソフトウェア学部所属の小規模サークルとして始まったからである。こうした背景もあってか、現在でもプログラミングを主分野とするメンバーの割合が最も高く、その反対にアートやサウンド分野の人数は比較的少ない。
私たちのチームも、この問題の例外ではなかった。
プログラミングができるメンバーは4人全員だったが、企画ができるメンバーは2人、アートとサウンドはそれぞれ0人と1人に過ぎなかった。 結局、誰かが自分の得意分野ではない役割まで担当しなければならなかった。
何度かのオンライン・オフライン会議を重ねた結果、私を含む3人がプログラミングを担当し、そのうち私ともう1人がアートも兼任することになった。企画とサウンドはそれぞれ1人ずつ担当する形で、最終的な役割を決めた。 こうして互いに足りない分野を兼任する形で、役割分担の問題はひとまず解決することができた。
しかし、役割を決めることと、その役割を実際にきちんとこなせることは、まったく別の問題であった。
経験値不足
メンバー全員の得意分野がプログラミングだったこともあり、プログラミングそのものには大きな問題はなかった。 特に、ゲームプロジェクトではないものの、別のプログラミング関連のチームプロジェクトを経験した先輩がいたため、Gitなどを活用した共同開発の手順や基本的なルールも比較的早い段階で整理することができた。
問題は、それ以外の分野であった。
一つ目は企画である。
「ERROR CODE: H」の企画は、チームリーダーを担当した先輩が以前から準備していた企画案をベースに進められた。ただし、一つの企画案が存在することと、実際の開発過程でその企画を作業単位に分けることは別の問題であった。
どの作業を最初に進めるべきなのか、それぞれの作業をどの程度の大きさに分けるべきなのか、そしてそれを誰にどのように割り振るのか、その基準から新たに決めなければならなかった。
初期段階ではこうした基準が十分に定まっていなかったため、作業の優先順位や分担方法を決めるだけでも予想以上に時間が必要となった。 当然ながら、プロジェクト初期の進行速度も多少遅くならざるを得なかった。
サウンドにも似たような問題があった。
最近ではAIなどのツールによって簡単なゲームサウンドを制作しやすくなったが、メンバーの中には本格的なサウンド制作を経験した人がいなかった。 簡単なゲームBGMであればAIを活用してある程度対応できたものの、それ以外のSFXまでしっかり制作するのは簡単ではなかった。
その結果、サウンドもまた、プロジェクトを進めながら継続して解決していかなければならない課題として残ることになった。
しかし、本当の問題は別にあった。
それが、アート分野であった。
チーム内には、本格的なアート制作を経験した人が一人もいなかった。
私自身も、簡単な絵を描いたり、3Dモデリングを少し触ったりした程度の経験しかなかった。 しかし「ERROR CODE: H」は、2Dドット絵スタイルのゲームであった。
一言で言えば、私を含むアート担当者たちは何も分からないまま、アートという深海へそのまま投げ込まれたようなものだった。 それどころか私は、2Dドット制作に使うアートツールすら持っておらず、自費で新しく購入しなければならなかった。
問題は、ツールを一つ用意すれば終わるようなものでもなかった。
Pixel Perfectをどのように適用するのか、全体的な解像度をどう設定するのか、さらにキャラクターやオブジェクトのドットサイズをどの程度に統一するのかなど、初めて直面する問題が波のように押し寄せてきた。
それでも私は、アート担当として任された役割を果たさなければならなかった。
理由は単純である。自分が引き受けると決めた役割だったからだ。
最終的には、アート制作を一緒に進めていく中で、自然と役割を再調整することになった。
私よりもドットアニメーション制作に慣れていった別のメンバーがキャラクターのドットアニメーションを担当し、私はUIをはじめとする各種デザイン作業を担当する形である。 最初に決めた役割分担がそのまま維持されたわけではなかったが、それぞれが少しでも得意な分野を見つけながら、役割を調整していった。
それぞれのスケジュールの衝突
いくら長期休暇中に進めるプロジェクトとはいえ、全員が休暇のすべてをプロジェクトだけに使えるわけではなかった。
資格試験の準備をしなければならない人もいれば、アルバイトの予定によって特定の時間帯には会議への参加が難しい人もいた。 そのほかにも旅行の予定や家族の看病など、それぞれにさまざまな事情があった。
そのため、4人全員が参加できる会議の時間を決めることさえ、想像していたより簡単ではなかった。 ただし、スケジュールの問題についてはチームメンバー全員が理解している部分でもあった。
そこで、基本的な会議は毎週日曜日に行い、やむを得ず予定を変更する必要がある場合には事前に共有し、互いのスケジュールを調整する形で進めることにした。
プロジェクトの始まり
プロジェクトが始まる前からさまざまな問題が続けて発生したものの、私たちはついにスタートラインに立った。
複数人がそれぞれの役割を分担し、一つのゲームを最後まで完成させることを目標に本格的なチーム開発を進めるのは、私たち全員にとって事実上初めてと言ってもよかった。 だからこそ、これからもきっと数え切れないほどの試行錯誤が待っているだろう。
実際、プロジェクトを始めるための準備段階ですら、予想していなかった問題が次々と現れたのだから。
しかし、それぞれが得意な部分を最大限に活かし、互いに足りない部分を補っていけば、少なくとも今回こそは一つのプロジェクトを最後まで完成させることができると思っている。
最初から完璧なチームである必要はない。 互いの足りない部分を一つずつ補いながら、最後まで作り上げればいい。
こうして2026年7月5日、私たちにとって初めての本格的なゲーム開発チームプロジェクトである「ERROR CODE: H」が始まった。
Project「ERROR CODE: H」、ここに始動！
팀 결성의 출발점
지금까지 나는 여러 게임 프로젝트를 기획하고 개발해 왔지만, 그 대부분은 혼자 진행하는 개인 프로젝트였다.
(지금까지 기획·개발해 온 게임 프로젝트, 게시일 기준)
(폐기·중단된 프로젝트 포함)
| Project | Period | Project Type | Genre | Result |
|---|---|---|---|---|
| Project S | 2020. 10. ~ 2021. 12. | Solo Project | Hero Shooter | ⏸️ Interrupted |
| Astral Days! (Project AD) (Project A) | 2020. 10. ~ (Ongoing) | Solo Project | Story-based Action RPG | 🔄 In Progress |
| Project R | 2020. 12. ~ 2021. 1. | Solo Project | RPG | ⏸️ Interrupted |
| Project F | 2020. 12. ~ 2022. 1. | Solo Project | Action RPG | ⏸️ Interrupted |
| Python Game Contest | 2023. 06. ~ 2023. 07. | Team Project | 2.5D Rhythm Action | ⏸️ Interrupted |
위 표에서도 알 수 있듯, 지금까지 진행했거나 현재 진행 중인 프로젝트 가운데 팀 프로젝트는 단 하나뿐이었다. 그마저도 끝까지 완성하지 못한 채 중단되고 말았다.
그러던 중 대학에 입학한 나는 게임 개발 중앙동아리 GAMMARU에 합격했고, 처음에는 준회원으로 입부하게 되었다.
(GAMMARU에서는 입부 시 준회원으로 시작한 뒤, 콘테스트에 참가하면 정회원으로 승격할 수 있다. 한 학년 안에 정회원으로 승격하지 못하면 자동으로 퇴부 처리된다.)
나는 GAMMARU에 입부한 뒤 여러 활동에 참여해 왔고, 앞으로도 계속 활동하고 싶다고 생각하고 있었다. 그렇기에 내게 있어 정회원으로 승격할 기회인 콘테스트 참가는 사실상 필수에 가까웠다.
정회원 승격을 위한 콘테스트는 매년 두 차례 열린다. 신입 부원만 참가할 수 있는 여름 콘테스트와 모든 부원이 참가할 수 있는 겨울 콘테스트다. 하지만 개인적인 학업 계획상 겨울에는 JLPT 자격 취득과 대학의 겨울 계절학기 준비를 해야 했기 때문에, 겨울 콘테스트까지 병행해서 참가하기는 어렵다고 판단했다.
그렇게 나는 여름 콘테스트에 참가하기로 결정했다.
기본적으로 GAMMARU 콘테스트에는 팀 인원 제한이 없다. 즉, 혼자서 참가하는 것도 가능하다. 하지만 이번만큼은 혼자 콘테스트에 참가하기보다, 다른 사람들과 팀을 꾸려 하나의 프로젝트를 함께 만들어 보고 싶었다.
지금까지 거의 모든 프로젝트를 혼자 진행해 왔고, 과거에 한 번 팀 프로젝트에 참가한 경험은 있었지만 그 프로젝트 역시 끝까지 완성하지 못했다. 그렇기에 여러 사람이 역할을 나누고 하나의 게임을 마지막까지 완성해 나가는 본격적인 팀 개발은 사실상 이번이 처음이라고 해도 좋았다.
그뿐만 아니라 이번 기회를 통해 Git 등을 활용한 실제 협업 개발을 경험하고, 여러 사람이 하나의 목표를 공유하며 프로젝트를 끝까지 완성해 보고 싶다는 생각도 있었다.
그래서 여러 팀의 모집 글을 살펴본 뒤, 그중 가장 매력적으로 느껴졌던 「ERROR CODE: H」 프로젝트에 참가하기로 결정했다.
(프로젝트 지원 당시 대화 기록 일부 1)
(프로젝트 지원 당시 대화 기록 일부 2)
이러한 과정을 거쳐 나를 포함한 총 4명으로 「Team RHEO」가 결성되었다.
작은 문제들의 연속
역할 분담의 문제
팀을 결성한 뒤 가장 먼저 마주한 문제는 역할 분담이었다.
이번 프로젝트의 멤버들은 모두 게임 개발 팀 프로젝트를 제대로 끝까지 완성해 본 경험이 없었고, 게다가 네 명 모두 가장 자신 있는 분야가 프로그래밍이었다.
사실 이는 어느 정도 자연스러운 일이기도 했다.
GAMMARU는 현재 게임 개발 중앙동아리이지만, 처음에는 소프트웨어학부 소속의 소규모 동아리로 시작했기 때문이다. 이러한 배경 때문인지 지금도 프로그래밍을 주 분야로 삼는 부원의 비율이 가장 높고, 반대로 아트나 사운드 분야의 인원은 비교적 적다.
우리 팀 역시 이 문제에서 예외는 아니었다.
프로그래밍이 가능한 멤버는 네 명 전원이었지만, 기획이 가능한 멤버는 두 명이었고 아트와 사운드는 각각 0명과 1명뿐이었다.
결국 누군가는 자신의 주특기가 아닌 분야까지 맡아야 했다.
몇 차례의 온라인·오프라인 회의를 거친 끝에, 나를 포함한 세 명이 프로그래밍을 담당하고 그중 나와 다른 한 명이 아트까지 겸임하기로 했다. 기획과 사운드는 각각 한 명씩 담당하는 형태로 최종적인 역할을 정했다.
이렇게 서로 부족한 분야를 겸임하는 방식으로 역할 분담 문제는 우선 해결할 수 있었다.
하지만 역할을 정하는 것과, 실제로 그 역할을 제대로 해내는 것은 전혀 다른 문제였다.
경험치 부족
멤버 모두의 주 분야가 프로그래밍이었던 만큼, 프로그래밍 자체에는 큰 문제가 없었다.
특히 게임 프로젝트는 아니었지만 다른 프로그래밍 관련 팀 프로젝트를 경험한 선배가 있었기 때문에, Git 등을 활용한 협업 개발 절차와 기본적인 규칙도 비교적 이른 단계에서 정리할 수 있었다.
문제는 그 이외의 분야였다.
첫 번째는 기획이었다.
「ERROR CODE: H」의 기획은 팀 리더를 맡은 선배가 이전부터 준비해 오던 기획안을 바탕으로 진행되었다. 하지만 하나의 기획안이 존재한다는 것과, 실제 개발 과정에서 그 기획을 작업 단위로 나누는 것은 전혀 다른 문제였다.
어떤 작업부터 진행해야 하는지, 각각의 작업을 어느 정도 크기로 나누어야 하는지, 그리고 그 작업을 누구에게 어떤 방식으로 배분할지까지 그 기준을 처음부터 새로 정해야 했다.
초기에는 이러한 기준이 충분히 정립되지 않았기 때문에, 작업의 우선순위와 분담 방식을 정하는 것만으로도 예상보다 많은 시간이 필요했다.
당연히 프로젝트 초반의 진행 속도 역시 어느 정도 느려질 수밖에 없었다.
사운드에도 비슷한 문제가 있었다.
최근에는 AI를 비롯한 여러 도구 덕분에 간단한 게임 사운드를 제작하기가 예전보다 쉬워졌지만, 팀원 중 본격적인 사운드 제작을 경험한 사람은 없었다.
간단한 게임 BGM이라면 AI를 활용해 어느 정도 대응할 수 있었지만, 그 이외의 SFX까지 제대로 제작하는 일은 쉽지 않았다.
결국 사운드 역시 프로젝트를 진행하면서 계속 해결해 나가야 할 과제로 남게 되었다.
하지만 진짜 문제는 따로 있었다.
바로 아트 분야였다.
팀 안에는 본격적인 아트 제작을 경험한 사람이 단 한 명도 없었다.
나 역시 간단한 그림을 그리거나 3D 모델링을 조금 다뤄 본 정도의 경험밖에 없었다.
그런데 「ERROR CODE: H」는 2D 도트 그래픽 스타일의 게임이었다.
한마디로 말하면, 나를 포함한 아트 담당자들은 아무것도 모르는 상태로 아트라는 깊은 바다에 그대로 던져진 셈이었다.
심지어 나는 2D 도트 그래픽 제작에 사용할 아트 툴조차 가지고 있지 않아, 사비로 새로 구매해야 했다.
그렇다고 도구 하나를 준비하면 끝나는 문제도 아니었다.
Pixel Perfect를 어떻게 적용해야 하는지, 전체적인 해상도는 어떻게 설정할지, 그리고 캐릭터와 오브젝트의 도트 크기를 어느 정도로 통일할지 등 처음 접하는 문제들이 파도처럼 밀려들었다.
그래도 나는 아트 담당으로 맡은 역할을 해내야 했다.
이유는 단순했다. 내가 하겠다고 맡은 일이었기 때문이다.
결국 아트 작업을 함께 진행하는 과정에서 자연스럽게 역할을 다시 조정하게 되었다.
나보다 도트 애니메이션 제작에 빠르게 익숙해진 다른 멤버가 캐릭터 도트 애니메이션을 담당하고, 나는 UI를 비롯한 각종 디자인 작업을 담당하는 형태였다.
처음 정했던 역할 분담이 그대로 유지된 것은 아니었지만, 각자가 조금이라도 더 잘할 수 있는 분야를 찾아가며 역할을 조정해 나갔다.
서로 다른 일정의 충돌
아무리 방학 동안 진행하는 프로젝트라고 해도, 모두가 방학의 모든 시간을 프로젝트에만 사용할 수 있는 것은 아니었다.
자격시험을 준비해야 하는 사람도 있었고, 아르바이트 일정 때문에 특정 시간대에는 회의에 참가하기 어려운 사람도 있었다. 그 밖에도 여행 일정이나 가족 간병 등 각자 여러 사정이 있었다.
그렇기 때문에 네 명 모두가 참석할 수 있는 회의 시간을 정하는 것조차 생각했던 것만큼 간단하지 않았다. 다만 일정 문제는 팀원 모두가 충분히 이해하고 있던 부분이기도 했다.
그래서 기본 회의는 매주 일요일에 진행하고, 부득이하게 일정을 변경해야 할 경우에는 미리 공유해 서로의 일정을 조정하는 방식으로 진행하기로 했다.
프로젝트의 시작
프로젝트가 시작되기도 전부터 여러 문제가 연이어 발생했지만, 우리는 마침내 출발선에 섰다.
여러 사람이 각자의 역할을 나누고 하나의 게임을 마지막까지 완성하는 것을 목표로 본격적인 팀 개발을 진행하는 것은 우리 모두에게 사실상 처음이라고 해도 좋았다.
그렇기에 앞으로도 분명 셀 수 없을 만큼 많은 시행착오가 기다리고 있을 것이다.
실제로 프로젝트를 시작하기 위한 준비 단계에서조차 예상하지 못했던 문제들이 계속해서 나타났으니까.
하지만 각자가 잘하는 부분을 최대한 살리고, 서로 부족한 부분을 보완해 나간다면 적어도 이번만큼은 하나의 프로젝트를 끝까지 완성할 수 있을 것이라고 생각한다.
처음부터 완벽한 팀일 필요는 없다.
서로 부족한 부분을 하나씩 채워 가며 끝까지 만들어 내면 된다.
그렇게 2026년 7월 5일, 우리에게 있어 첫 본격적인 게임 개발 팀 프로젝트인 「ERROR CODE: H」가 시작되었다.
Project 「ERROR CODE: H」, 여기서 시작!