[CT] 09. 新しいチームプロジェクトの始まり。 （INGAME 26-2 ショートトラベル）

つい先日、私はGAMMARUの夏コンテストに参加した。受賞には至らなかったものの、チームを組み、目標に向かって共に走り、初めてチームとして一つのものを完成させたことには、意味があったと思う。
だが、心残りがないと言えば、きっと嘘になる。

• あの企画をこう変えていたら、どうだっただろうか？
  
• 開発の中で、あの部分をもう少しうまく実装できたのではないだろうか？
  
• チームプロジェクトを進める中で、無駄にしてしまった時間が多かったのではないだろうか？
  

といったことだ。

だから今回は、自分でやってみることにした。最初から、リーダーとして。

ちょうど、新しく入ったINGAMEというサークルで、その機会を得ることができた。私は以前から温めていたアイデアをほかの人たちに見せ、同じ方向を目指せる仲間を募集した。

新しいチームプロジェクトの始まり

■ リーダー紹介
名前: キム・ジホン @김지헌
担当: 開発＆企画（必要に応じて、3Dアートも一部対応できます。）
自己紹介ページ: https://yunarang-dev.github.io/about/

■ 作りたいゲーム（話し合いの上で変更できます！）
個人的に最近プレイしているゲーム（興味のあるジャンル）:
『魔法少女ノ魔女裁判』（まのさば）
『異環』
『オーバーウォッチ』
『サイバーパンク2077』など...
（リズム／アクション／ビジュアルノベル／サブカルチャー系が中心だと思います。）

開発したいゲームのジャンルとコアとなるゲームプレイ:
タイトル: （仮称）TRAXX/ING!
ジャンル: サブカルチャー系2.5Dリズムアクションゲーム（まずはPC向け）
ゲームの簡単な説明:
さまざまな楽器を萌え擬人化したキャラクターを操作し、音楽のリズムに合わせて移動・攻撃・回避などのアクションを行う2.5Dリズムアクションゲームです。
各キャラクターのプレイスタイルに、モチーフとなった楽器の特徴を取り入れ、一般的なアクションゲームの操作感と、リズムゲームの判定・演奏の感覚を両立させる方向で考えています。
参考作品:
『Beat Saber』: 音楽のリズムに合わせて自ら動く、直感的なリズムアクション
『Hi-Fi RUSH』: 移動・攻撃・回避などの一般的なアクションとリズムを自然に組み合わせる仕組み
『プロセカ』/『バンドリ！』/『DJMAX』: リズムゲームのノーツ・判定などと、全体的なゲームプレイの構成
使用するエンジンとツール:
エンジン: 今のところ、Unityを考えています。
モデリング: 3DモデリングにはBlenderを使う予定です。
2Dアート: 使いやすいツールを自由に使っていただければと思います。
その他: AIも、必要な場合はチームの皆さんと相談した上で使う予定です。

現在、基本的なアイデアはある程度用意していますが、今ある企画をそのまま作るというより、チームの皆さんと話し合いながら、面白い部分は残し、プロジェクトの規模に合わせて一緒に修正していきたいです！
（メンバーの多くが希望する場合は、リズムゲーム以外のジャンルで進めることも考えています！）

今回のショートトラベルでは、何よりも、短くても遊びの中心がはっきりしていて、実際にプレイして面白いゲームを完成させることを目標にしています。

（また、今回のショートトラベルが終わった後も、一緒に開発を続けたい方がいれば、希望する皆さんと完成・リリースまで進めていくつもりです。）

■ 一緒に作業する方法
ミーティングが可能な曜日・時間: （相談して決める予定です！ 今のところ、週1~2回程度を考えています。）
オンライン・オフラインなど、希望するミーティングの形式: 主にオンライン（Discord）で行う予定です。

■ 現在のメンバー構成
- リーダーを含めて計1名
  - キム・ジホン / 企画・開発 / Lv.max

■ 募集中
- 企画担当 ○名: リズムゲームやアクションゲームに詳しい方だとうれしいです。
- 開発担当 ○名: Unityの経験がある方はもちろん、経験がなくてもゲーム開発に興味がある方なら歓迎です。
- アート担当 ○名: サブカルチャーに興味がある方、この分野に挑戦してみたい方なら歓迎です！

（経験やスキルの高さは、それほど重視していません！ 継続して一緒に参加していただければ大丈夫です。）

■ 一緒に参加する方に希望すること:
初心者の方も歓迎です！
サブカルチャーに親しみがある方、または抵抗のない方
リズムゲームやアクションゲームに興味があるとうれしいです。（モバイル、PC、コンソールは問いません）
そうでなくても、私とゲームの好みが近ければ、なおうれしいです！

ほかにも気になることがあれば、気軽にDMを送ってください！ ほぼ24時間、返信できます！

‼️ 私用のため、10月3日のOTには参加が難しそうです。その点をご考慮いただけますと幸いです！ ‼️

(実際の募集文の内容)

『TRAXX/ING!』の基本アイデア

『TRAXX/ING!』のアイデアは、まったく新しく考えたものではない。過去の記事「CT-01」を読んだことのある人なら、下の表に見覚えがあるだろう。

（これまでに企画・開発してきたゲームプロジェクト、2026-07-06時点）
（中止・中断したプロジェクトを含む）

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

実は『TRAXX/ING!』は、この中の「Python Game Contest」で中断した2.5Dリズムゲームの中心となるアイデアを取り入れ、今の自分の好みに合わせて作り直した企画である。

ただ、当時はきちんとした形で完成させることができず、細かな企画もほとんど残っていなかった。

そこで今回は、昔の企画をそのまま再現するよりも、当時気に入っていた中心となるアイデアだけを取り入れ、新しいゲームとして作り直すことにした。

こうして、プロジェクトの方向性を一文にまとめると、次のようになった。

ノーツが敵であり、演奏が戦闘であるリズムアクションゲーム。

この一文は、今も『TRAXX/ING!』の最も大切な基準となっている。

『TRAXX/ING!』の簡単な紹介

（以下の内容は企画の初稿に基づいており、企画が進むにつれて変更する可能性がある。）

6本のトラックを移動するリズムアクション

初期段階で最も悩んだのは、ゲーム画面と操作方法をどう構成するかということだった。

一般的なリズムゲームのように、ノーツが複数のレーンを流れてくる構造を保ちながらも、単にボタンを押すだけのゲームには見せたくなかった。
いくつかの視点を検討した結果、現在はバックビューに近い2.5D視点から、6本のトラックを見渡す構成にする方向で進めている。

（AIで生成した構図の初期案）

プレイヤーはA / S / D / L / ; / ‘の6つのキーを使い、それぞれのトラックへ移動する。

特徴的なのは、移動と攻撃を別々の行動に分けなかったことである。

トラックに対応するキーを押すと、キャラクターはその位置へ即座に移動し、同時に攻撃する。同じトラックのキーをもう一度押すと、移動せずに攻撃だけを行う。

つまり、リズムゲームにおける 「ノーツを叩く」 という行動を、『TRAXX/ING!』では 「敵のいるトラックへ移動して攻撃する」 という行動に置き換えたのである。

複数のキーがほぼ同時に入力された場合に備えて、キャラクターの分身がほかのトラックを処理する仕組みも考えた。キャラクター本体は、入力されたトラックのうち最も右側のトラックに移動し、残りのトラックには半透明の分身が現れて攻撃する。

初めは少し複雑なアイデアだと思っていたが、実際にプロトタイプを作ってみると、思っていた以上に『TRAXX/ING!』らしさにつながる部分だと感じた。

攻撃以外のリズムアクション

トラック移動と攻撃はゲームの基本だが、それだけで自分が考えているリズムアクションの感覚を十分に表現できるのか、悩んでいた。

画面に現れるノーツをタイミングに合わせて処理するだけなら、既存の鍵盤型リズムゲームの入力を、別の見せ方に変えただけで終わってしまうかもしれないと思った。

そこで、トラック移動と攻撃に加えて、パリィとジャンプ回避も考えた。

まず、LShift / RShiftを使ったパリィを取り入れた。

キャラクターが左側の3トラックにいる場合はLShift、右側の3トラックにいる場合はRShiftを使い、攻撃を弾き返す。

そして、Spaceにはジャンプ回避を割り当てた。

トラック全体を覆う障害物はジャンプで飛び越える必要があり、一部のトラックだけを塞ぐ障害物は、別のトラックへ移動して避けることもできる。ジャンプ中にトラックのキーを入力すると即座に着地して攻撃するようにし、ジャンプによってリズム入力が途切れないようにした。

このあたりから、最初に思い描いていた 「リズムゲームでありながら、実際にキャラクターを操作している感覚」 が少しずつ生まれ始めた。

ノーツを敵にする

ゲームの見た目の方向性も、この時期に整理し始めた。

『TRAXX/ING!』では、画面に現れるノーツを独立したUIオブジェクトで表現するのではなく、こちらへ走ってくる敵キャラクターとして見せようと考えている。

そして、この敵たちはゲームの音楽と結びつく。

現在は、音楽のパートを大きくドラム、ベース、ギター、キーボードに分けて考えており、敵もそれぞれの楽器をモチーフにデザインする方向である。

例えば、ドラム型の敵が攻撃してきたらパリィする必要があり、キーボード型やギター型の敵は通常の攻撃ノーツのように処理する、といった形だ。

さらに、通常のノーツだけでなく、ロングノーツ、パリィノーツ、一度攻撃しただけでは倒れずに戻ってくるノックバックノーツなどを組み合わせられるようにした。

こうすると、譜面そのものが敵の行動パターンになる。

そのため、『TRAXX/ING!』では、楽曲制作とレベルデザインを完全に切り離して考えることは難しい。

どの楽器がどのタイミングで演奏されるのかが、どの敵がどのような行動をするのかにつながるからだ。

個人的には、今の企画の中でこの部分が最も面白いと感じている。

共同作業の効率化

ゲームの基本的な方向性を決めることとは別に、今回のプロジェクトでは、最初から準備しておきたかったものがあった。

それが、共同作業の進め方である。

先ほど書いたように、前回のプロジェクトを終えた後には、ゲームそのものだけでなく、プロジェクトの進め方にも心残りがあった。

それぞれが担当する作業をしっかりこなすことも大切だが、その成果をどう共有し、一つにまとめるかも、初めから考えておく必要があると感じた。 誰かにとっては当たり前の作業手順でも、別の人にとっては初めて経験するものかもしれない。慣れていない人が、そのたびに誰かに聞かなければ次の段階へ進めないのであれば、作業を始めること自体が負担になってしまいそうだと思った。

そこで今回は、GitHubとUnityでの基本的な共同作業の進め方を、文書にまとめておいた。

誰でも手順を追える作業の流れ

ガイドではGitHub Desktopを使うことを前提に、リポジトリのCloneから、作業ブランチの作成、変更内容のCommit、そして最後のMergeまでを説明した。まずは基本的な作業の流れを示し、その後で各手順を追っていける構成にした。

全体の流れは、次の通りである。 mainを最新の状態に更新 → 作業ブランチを作成 → 個人のWorkspaceで作業・Commit → Push → PRを作成 → Merge

このとき最も重視した原則は、mainを直接変更せず、いつでも全員で実行・テストできる状態に保つことである。 それぞれの作業中には、機能がうまく動かないこともあれば、複数の実装方法を試して元に戻すこともある。そうした過程自体を制限するのではなく、試行錯誤する場所と、チーム全体が基準にするバージョンとを分けたかった。

ブランチ名やCommitのメッセージにも、簡単なルールを設けた。 ブランチは <種類>/<名前>-<作業内容> という形式で、例えば feat/jhkim-player-movement のように記述する。Commitには <種類>: <作業内容> という形式を使う。 名前を見ただけでも、誰がどのような作業を進めているのか、どの種類の変更なのかを、おおよそ把握できるようにするためである。

文書には、実際のスクリーンショットも載せた。 例えば、FetchとPullの違いについても、用語の説明だけでなく、どのボタンを押し、どの段階まで進めれば実際のファイルに変更が反映されるのかを併せて記した。 Gitの全機能を説明する文書ではなく、今回のプロジェクトで、一つの作業を始めてから共有するまでに参考にできるガイドを目指した。

個人の作業スペースと共有スペースを分ける

Unity内でも、それぞれの作業スペースを分けることにした。 基本的にはWorkspaceフォルダーの中に自分の名前のフォルダーを作り、その中で担当する機能を実装・テストする形である。移動、リズム判定、UIなどの機能も、まずは個人のテスト用Sceneで確認した後、PrefabやComponentに整理してから組み込むようにした。

狙いは単純だ。 最初から全員で一つの共有Sceneを編集するのではなく、それぞれが自分の機能を確認できる場所を、先に用意しておきたかった。 まだ実験中の機能を、ほかの人がそのまま使ってしまうような状況も、できるだけ減らしたかった。

ただし、個人の作業スペースで作ったものを、最後まで別々に保管しておくという意味ではない。 共有フォルダーへ移す基準は、「もう修正する必要のない完成品」ではなく、「ほかのメンバーが使っても問題のない程度に安定した状態」 とした。 機能の役割が決まり、テストを行い、大きな構造変更の可能性が低くなった段階で、共有スペースへ移す。まだ実験中のものはWorkspaceに置き、その状態でもPRで共有できるようにした。ただし、mainに取り込む際には、プロジェクトの実行に問題がないことを条件とした。

この基準が実際の共同作業にも合っているのかは、これから確かめていく必要がある。 各自の作業を分けることばかりに気を取られて、互いの進み具合がわかりにくくなっては意味がないからだ。作業スペースは分けても、どのような機能を作っていて、どの程度まで使える状態なのかは、引き続き話していく必要がありそうだ。

ファイルの受け渡し方まで

機能を作る方法だけでなく、制作物を移動・共有するときに守ってほしい点もまとめた。 アセットの移動や名前の変更はUnityエディター内で行い、Finderやエクスプローラーでアセットだけを別に移動しないよう案内した。併せて、.metaファイルも一緒に扱われているか、コードに直接書かれたパスがないかも確認するようにした。

サイズの大きい元ファイルの管理方法も整理した。 ガイドではGit LFSを使わない方針を前提に、.blend、.psd、.wav、動画などの元ファイルをCommitする前に、サイズと必要性を確認するようにした。大きな元ファイルは別の共有スペースに置き、ファイル名、バージョン、ダウンロード先を記録しておく形である。

こうした内容は、ゲームの機能や画面のように目立つ部分ではない。 だが、受け取った人が使える状態になっているかまで考えることも、共同作業の一部だと思う。自分の手元では問題のなかったファイルでも、ほかの人の作業環境では、必要な情報が足りないこともあるからだ。

ルールを作ること自体が目的ではない

もちろん、ガイドを書いたからといって、すぐに効率よく共同作業ができるようになるわけではないだろう。 文書に書かれた手順が実際に進めやすいものか、説明の足りない部分はないか、むしろ必要以上に面倒な手順を作ってしまっていないかも、確認する必要がある。

初めから完璧なルールを作れるとは思っていない。 まずは一緒に使う基準を用意し、進める中で不便な点が出てきたら、修正していくつもりだ。 今回作った共同作業ガイドも、その意味では最初の草案に近いものだ。

いよいよ、1週目を前に

ここまでが、本格的な開発に入る前に準備した内容である。 ずっと前に中断したアイデアを再び取り出し、一緒に取り組む仲間を募り、企画を具体的にしてきた。そして、その企画を確かめるためのプロトタイプと、一緒に作業するためのガイドも用意した。

とはいえ、まだ準備段階である。 企画通りに実装したときに本当に面白いのか、決めた共同作業の進め方が実際のチームに合っているのかは、これから確かめる必要がある。 自分から提案したアイデアだからといって、今の形を最後まで守り続けなければならないとは思っていない。募集文にも書いたように、皆で話し合いながら面白い部分は残し、プロジェクトの規模に合わない部分は修正していきたい。

今回は、開発者として担当する機能を実装するだけでなく、リーダーとしてプロジェクト全体を見ていくことにも取り組もうと思う。 自分の作業がどこまで進んだかだけでなく、それぞれの作業をつなげるために何が必要なのか、誰かが次の作業へ進めずに困っているところはないかにも、目を向けていく必要がありそうだ。

きっと今回も、終わった後には心残りがあるだろう。 それでも、前回のプロジェクトを終えた後に浮かんだ問いを、今回は自分で試してみた経験をもとに、改めて振り返ることができたらと思う。

今回は、ゲームを完成させる過程だけでなく、「一緒に」完成させていく過程も記録していこうと思う。

바로 얼마 전, 나는 겜마루 여름 공모전에 참가했었다. 비록 수상은 하지 못하였지만, 팀을 이루고, 목표를 향해 함께 달려 나가고, 처음으로 팀으로서 무언가를 완성했다는 데에 의의가 있었다고 생각이 든다.
하지만 아쉬움이 남지 않는다는 것은 분명 거짓말일 것이다.

• 이 기획을 이렇게 바꿨다면 어땠을까?
  
• 개발 과정에서 이 부분을 조금 더 잘 구현할 수 있지 않았을까?
  
• 팀 프로젝트를 진행하는 과정에서 불필요한 시간 손실이 많지는 않았을까?
  

처럼 말이다.

그래서 이번에는 직접 해 보기로 했다. 처음부터, 팀장으로서.

때 마침, 새로 가입하게 된 INGAME이라는 동아리에서 그 기회를 얻을 수 있었다. 나는 내가 오래 전부터 가지고 있던 아이디어를 다른 사람들에게 보여주고, 나와 뜻이 맞는 사람을 모집했다.

새로운 팀 프로젝트의 시작

■ 팀장 소개
이름: 김지헌 @김지헌
직군: 개발&기획 (+필요한 경우 3D 쪽 아트도 일부 가능합니다.)
자기소개 페이지: https://yunarang-dev.github.io/about/

■ 만들고 싶은 게임(협의 후 수정 가능합니다!)
개인적으로 최근 하는 게임(관심 장르):
마법소녀의 마녀재판(마노사바)
이환
오버워치
사이버펑크 2077 등...
(리듬/액션/비노벨/서브컬쳐 위주인 것 같아요.)

개발하고자 하는 게임의 장르와 핵심 플레이:
제목: (가제) TRAXX/ING!
장르: 서브컬쳐계 2.5D 리듬 액션 게임(PC 우선 타겟)
게임 간단 설명:
여러 악기를 모에화한 캐릭터를 조작하며, 음악의 리듬에 맞춰 이동・공격・회피 등의 액션을 수행하는 2.5D 리듬 액션 게임입니다.
캐릭터마다 모티프가 된 악기의 특징을 플레이 스타일에 반영하고, 일반적인 액션 게임의 조작감과 리듬 게임의 판정・연주 감각을 함께 살리는 방향을 생각하고 있습니다.
레퍼런스 작품: 
비트 세이버: 음악의 박자에 맞춰 직접 행동하는 직관적인 리듬 액션
하이파이 러쉬: 이동・공격・회피 등 일반적인 액션과 리듬을 자연스럽게 결합하는 방식
프로세카 / 뱅드림 / 디맥: 리듬 게임의 노트・판정 등과 전반적인 플레이 구성
사용할 엔진 및 도구: 
엔진: 일단은 Unity를 생각하고 있어요.
모델링: 3D 모델링은 Blender를 사용할 예정이에요.
2D 아트: 편하신 툴 자유롭게 사용하시면 될 것 같습니다.
기타: AI도 필요한 경우 팀원분들과 협의 후에 사용할 예정이에요.

현재 기본적인 아이디어는 어느 정도 준비되어 있지만, 지금 있는 기획을 그대로 만드는 것보다는 팀원분들과 이야기하면서 재미있는 부분은 살리고, 프로젝트 규모에 맞게 함께 수정해 나가고 싶습니다!
(팀원 다수가 원하는 경우 리듬 게임이 아닌 타 장르 게임으로 진행할 의향도 있습니다!)

이번 숏트래블에서는 무엇보다 짧더라도 핵심 플레이가 확실하고 직접 플레이했을 때 재미있는 게임을 완성하는 것을 목표로 하고 있습니다.

(또한 이번 숏트래블이 끝난 뒤에도, 계속 함께 개발을 이어나갈 분이 있으시면 희망하시는 분들과 계속 완성・출시까지 이어나갈 생각이 있습니다.)

■ 함께 작업하는 방식
회의 가능한 요일·시간: (협의 후 결정할 예정입니다! 일단은 주 1-2회정도 생각 중이에요.)
온라인·오프라인 등 선호하는 회의 방식: 주로 온라인(디코)으로 진행할 생각이에요.

■ 현재 구성
- 팀장 포함 총 1명
  - 김지헌 / 기획・개발 / Lv.max

■ 모집 중
- 기획 직군 ○명: 리듬 게임이나 액션 게임에 대해 잘 아시는 분이면 좋을 것 같아요.
- 개발 직군 ○명: Unity 경험이 있거나, 그게 아니더라도 게임 개발에 관심 있으신 분이면 환영이에요.
- 아트 직군 ○명: 서브컬쳐에 관심이 있거나, 이 분야로 도전해 보고 싶으신 분이라면 환영입니다!

(경험이나 숙련도는 크게 중요하게 생각하지 않습니다! 꾸준히 함께 참여해 주시면 됩니다.)

■ 함께할 분에게 바라는 점:
초보자 분도 환영입니다!
서브컬쳐 문화에 익숙하거나, 거부감이 없으신 분
리듬 게임과 액션 게임에 관심이 있으면 좋을 것 같아요.(모바일, PC, 콘솔 무관)
그게 아니더라도 저와 게임 취향이 비슷하면 더 좋습니다!

그 외에 궁금하신 부분 있으시면 편하게 DM 주세요! 거의 24시간 답변드릴 수 있습니다!

‼️ 제가 개인 사정으로 10월 3일 OT에 참석하기 어려울 것 같습니다.  이 점 고려해 주시면 감사하겠습니다! ‼️ 

(실제 모집 글의 내용)

TRAXX/ING!의 기본 아이디어

TRAXX/ING!의 아이디어는 아예 새롭게 기획한 아이디어는 아니다. 내 과거 글 CT-01을 읽어 본 사람이라면 아래의 표가 익숙할 것이다.

(지금까지 기획·개발해 온 게임 프로젝트, 2026-07-06 기준)
(폐기·중단된 프로젝트 포함)

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

사실 TRAXX/ING!은 이 중, 중단되었던 Python Game Contest에 해당하는 2.5D 리듬 게임의 핵심 아이디어를 가져와 지금의 나의 취향에 맞게 개조한 기획이다.

다만 당시에는 제대로 된 형태로 완성하지 못했고, 세부 기획도 거의 남아 있지 않았다.

그래서 이번에는 옛날 기획을 그대로 복원하기보다, 그때 마음에 들었던 핵심 아이디어만 가져와 아예 새로운 게임으로 다시 만들기로 했다.

그렇게 프로젝트의 방향을 한 문장으로 정리하면 다음과 같았다.

노트가 곧 적이고, 연주가 곧 전투인 리듬 액션 게임.

이 문장이 지금까지도 TRAXX/ING!의 가장 중요한 기준이 되고 있다.

TRAXX/ING!의 짧은 소개

(이하의 내용은 기획 초안을 베이스로 하며, 기획이 진전됨에 따라 수정될 수 있다.)

6개의 트랙을 움직이는 리듬 액션

초기에는 게임 화면과 조작 방법을 어떻게 구성할지가 가장 큰 고민이었다.

일반적인 리듬게임처럼 노트가 여러 레인을 따라 내려오는 구조를 유지하면서도, 단순히 버튼만 누르는 게임처럼 보이고 싶지는 않았다.
여러 시점을 고민한 끝에 현재는 백뷰에 가까운 2.5D 시점에서 6개의 트랙을 바라보는 구조로 방향을 잡고 있다.

(AI로 생성한 구도 초안)

플레이어는 A / S / D / L / ; / ’ 여섯 개의 키를 이용해 각 트랙으로 이동한다.

특이한 점은 이동과 공격을 별개의 행동으로 나누지 않았다는 것이다.

트랙 키를 누르면 캐릭터가 해당 위치로 즉시 이동하고, 동시에 공격한다. 같은 트랙의 키를 다시 누르면 이동 없이 공격만 수행한다.

결국 리듬게임에서의 “노트를 누른다” 라는 행동을 TRAXX/ING!에서는 “적이 있는 트랙으로 이동해 공격한다” 라는 행동으로 바꾼 셈이다.

여러 키가 거의 동시에 입력되는 경우를 대비하여, 캐릭터의 분신이 다른 트랙을 처리하는 시스템도 구상했다. 실제 캐릭터는 가장 오른쪽에 입력된 트랙으로 이동하고, 나머지 트랙에는 반투명한 분신이 나타나 공격한다.

처음에는 조금 복잡한 아이디어라고 생각했는데, 직접 프로토타입으로 만들어보니 생각보다 TRAXX/ING!만의 특징을 만들 수 있는 부분이라고 느꼈다.

공격 이외의 리듬 액션

트랙 이동과 공격은 게임의 기본이지만, 그것만으로 내가 생각한 리듬 액션의 느낌을 충분히 살릴 수 있을지는 고민이었다.

화면에 나타나는 노트를 타이밍에 맞춰 처리하는 것에 그친다면, 기존 건반형 리듬게임의 입력을 다른 모습으로 보여주는 데 머무를 수도 있다고 생각했다.

그래서 트랙 이동과 공격에 더해, 패링과 점프 회피도 함께 구상했다.

먼저 LShift / RShift를 이용한 패링을 넣었다.

왼쪽 세 트랙에 있는 캐릭터는 LShift, 오른쪽 세 트랙은 RShift를 이용해 공격을 받아친다.

그리고 Space에는 점프 회피를 배정했다.

트랙 전체를 덮는 장애물은 점프로 넘어가야 하고, 일부 트랙만 막는 장애물은 다른 트랙으로 이동해서 피할 수도 있다. 점프 중 트랙 키를 입력하면 즉시 착지하면서 공격하도록 해, 점프 때문에 리듬 입력이 끊기지 않도록 했다.

이때부터 조금씩 내가 처음 생각했던 “리듬게임인데 실제로 캐릭터를 조작하고 있다는 느낌” 이 나기 시작했다.

노트를 적으로 만들기

게임의 비주얼적인 방향도 이 시기에 정리하기 시작했다.

TRAXX/ING!에서는 화면에 등장하는 노트를 별도의 UI 오브젝트로 표현하기보다는 직접 달려오는 적 캐릭터로 보여주려고 한다.

그리고 이 적들은 게임의 음악과 연결된다.

현재 음악 파트는 크게 드럼, 베이스, 기타, 키보드로 나누어 생각하고 있고, 적 역시 각 악기를 모티브로 디자인하는 방향이다.

예를 들어 드럼 형태의 적이 공격해오면 패링해야 하고, 키보드나 기타 형태의 적은 일반적인 공격 노트처럼 처리하는 식이다.

여기에 일반 노트뿐만 아니라 롱 노트, 패링 노트, 한 번 공격해서는 쓰러지지 않고 다시 돌아오는 넉백 노트 등을 섞을 수 있도록 했다.

이렇게 하면 채보 자체가 곧 적의 패턴이 된다.

그래서 TRAXX/ING!에서는 곡을 만드는 작업과 레벨 디자인을 완전히 따로 생각하기 어렵다.

어떤 악기가 어느 순간 연주되는가가 곧 어떤 적이 어떤 행동을 하는가와 연결되기 때문이다.

개인적으로 이 부분이 현재 기획에서 가장 흥미롭다고 생각하고 있다.

협업의 효율화

게임의 기본적인 방향을 잡는 것과 별개로, 이번 프로젝트에서는 처음부터 준비해 두고 싶었던 것이 있었다.

바로 협업 방식이다.

앞에서 이야기했듯이, 지난 프로젝트를 마친 뒤에는 게임 자체뿐 아니라 프로젝트를 진행하는 과정에 대해서도 아쉬움이 남았다.

각자가 맡은 일을 잘하는 것도 중요하지만, 그 작업물을 어떻게 공유하고 하나로 합칠 것인지도 처음부터 생각해 두어야 한다고 느꼈다. 누군가에게는 당연한 작업 순서가 다른 사람에게는 처음 접하는 과정일 수도 있다. 익숙하지 않은 사람이 매번 물어보아야만 다음 단계로 넘어갈 수 있다면, 작업을 시작하는 것부터 부담이 될 것 같았다.

그래서 이번에는 GitHub와 Unity에서 사용할 기본적인 협업 방식을 문서로 정리해 두었다.

누구나 따라 할 수 있는 작업 흐름

가이드에서는 GitHub Desktop을 기준으로, 저장소를 Clone하는 것부터 작업 브랜치를 만들고, 변경 사항을 Commit하고, 최종적으로 Merge하는 과정까지 설명했다. 기본 작업 흐름을 먼저 보여주고, 이후에 각 단계를 따라갈 수 있도록 구성했다.

전체 흐름은 다음과 같다. main 최신화 → 작업 브랜치 생성 → 개인 Workspace에서 작업 및 Commit → Push → PR 생성 → Merge

이때 가장 중요하게 잡은 원칙은 main을 직접 수정하지 않고, 항상 함께 실행하고 테스트할 수 있는 상태로 유지하는 것이다. 각자의 작업 도중에는 기능이 제대로 동작하지 않을 수도 있고, 여러 구현 방법을 시도하다가 되돌아갈 수도 있다. 그런 과정 자체를 막기보다는, 실험하는 공간과 팀 전체가 기준으로 사용하는 버전을 구분하고 싶었다.

브랜치와 Commit의 이름에도 간단한 규칙을 두었다. 브랜치는 <종류>/<이름>-<작업 내용> 형식으로, 예를 들면 feat/jhkim-player-movement처럼 작성하도록 했다. Commit은 <종류>: <작업 내용> 형식을 사용한다. 이름만 보더라도 누가 어떤 작업을 진행하고 있는지, 어떤 종류의 변경이 이루어졌는지 대략적으로 파악할 수 있게 하기 위해서다.

문서에는 실제 화면 캡처도 함께 넣었다. 예를 들어 Fetch와 Pull의 차이도 용어만 설명하는 대신, 어떤 버튼을 누르고 어느 단계까지 진행해야 변경 사항이 실제 파일에 반영되는지를 함께 적었다. Git의 모든 기능을 설명하는 문서보다는, 이번 프로젝트에서 작업 하나를 시작하고 공유하기까지 참고할 수 있는 가이드를 만들고자 했다.

개인 작업 공간과 공용 공간을 나누기

Unity 안에서도 각자의 작업 공간을 구분하기로 했다. 기본적으로 Workspace 폴더 안에 자신의 이름으로 폴더를 만들고, 그 안에서 담당 기능을 구현하고 테스트하는 방식이다. 이동, 리듬 판정, UI 같은 기능도 우선 개인 테스트 Scene에서 확인한 뒤, Prefab이나 Component로 정리해서 가져오도록 했다.

의도는 단순하다. 처음부터 모두가 공용 Scene 하나를 수정하기보다는, 각자의 기능을 확인할 수 있는 공간을 먼저 마련해 두고 싶었다. 아직 실험 중인 기능을 다른 사람이 곧바로 사용하게 되는 상황도 가능한 한 줄이고 싶었다.

그렇다고 개인 공간에서 만든 작업을 끝까지 따로 보관하겠다는 의미는 아니다. 공용 폴더로 옮기는 기준은 “더 이상 수정할 일이 없는 완성품”이 아니라, “다른 팀원이 사용해도 될 만큼 안정화된 상태” 로 잡았다. 기능의 역할이 정해졌고, 테스트를 해 보았으며, 큰 구조 변경 가능성이 낮아졌을 때 공용 공간으로 옮기는 방식이다. 아직 실험 중인 작업은 Workspace에 두되, 그 상태에서도 PR로 공유할 수 있도록 했다. 다만 main에 합칠 때는 프로젝트 실행에 문제가 없어야 한다.

이 기준이 실제 협업에서도 적절할지는 앞으로 확인해야 한다. 각자의 작업을 나누는 데만 집중하다가 정작 서로의 진행 상황을 알기 어려워져서는 안 되기 때문이다. 작업 공간은 구분하더라도, 어떤 기능을 만들고 있고 어느 정도까지 사용할 수 있는지는 계속 이야기해야 할 것 같다.

파일을 전달하는 방법까지

기능을 만드는 방법 외에도, 작업물을 옮기고 공유할 때 지켜야 할 사항을 함께 적었다. 에셋을 이동하거나 이름을 바꿀 때는 Unity 에디터 안에서 처리하도록 하고, Finder나 파일 탐색기에서 에셋만 따로 옮기지 않도록 안내했다. .meta 파일이 함께 처리되는지, 코드에 직접 적은 경로는 없는지도 확인하도록 했다.

용량이 큰 원본 파일을 관리하는 방식도 정리했다. 가이드에서는 Git LFS를 사용하지 않는 방향을 기준으로, .blend, .psd, .wav, 영상 같은 원본을 Commit하기 전에 용량과 필요 여부를 확인하도록 했다. 큰 원본은 별도의 공유 공간에 두고, 파일명과 버전, 다운로드 위치를 남기는 방식이다.

이런 내용은 게임의 기능이나 화면처럼 눈에 띄는 부분은 아니다. 하지만 작업물을 받은 사람이 다시 사용할 수 있는 상태인지까지 생각하는 것도 협업의 일부라고 생각한다. 나 혼자 가지고 있을 때는 문제가 없던 파일도, 다른 사람의 작업 환경에서는 필요한 정보가 빠져 있을 수 있기 때문이다.

규칙을 만드는 것 자체가 목적은 아니다

물론 가이드를 작성했다고 해서 협업이 곧바로 효율적으로 이루어지는 것은 아닐 것이다. 문서에 적혀 있는 순서가 실제로 따라 하기 쉬운지, 설명이 부족한 부분은 없는지, 오히려 불필요하게 번거로운 절차를 만든 것은 아닌지도 확인해야 한다.

처음부터 완벽한 규칙을 만들 수 있다고 생각하지는 않는다. 우선 함께 사용할 기준을 마련하고, 진행하면서 불편한 부분이 생기면 수정해 나가려고 한다. 이번에 작성한 협업 가이드도 그런 의미에서 첫 번째 초안에 가깝다.

이제, 1주차를 앞두고

여기까지가 본격적인 개발에 들어가기 전 준비한 내용이다. 오래전에 중단했던 아이디어를 다시 꺼냈고, 함께할 사람을 모집했고, 기획을 구체화했다. 그리고 그 기획을 확인하기 위한 프로토타입과 함께 작업하기 위한 가이드도 준비했다.

다만 아직은 준비 단계다. 기획대로 구현했을 때 정말 재미있을지, 정해 둔 협업 방식이 실제 팀에 잘 맞을지는 앞으로 확인해야 한다. 내가 먼저 제안한 아이디어라고 해서 지금의 형태를 끝까지 유지해야 한다고 생각하지는 않는다. 모집 글에서도 이야기했듯이, 함께 이야기하면서 재미있는 부분은 살리고 프로젝트 규모에 맞지 않는 부분은 수정해 나가고 싶다.

이번에는 개발자로서 맡은 기능을 구현하는 것뿐 아니라, 팀장으로서 프로젝트 전체를 살펴보는 일도 함께 해 보려고 한다. 내 작업이 어디까지 진행되었는지만이 아니라, 서로의 작업을 연결하기 위해 무엇이 필요한지, 누군가 다음 작업으로 넘어가지 못하고 있는 부분은 없는지도 신경 써야 할 것 같다.

아마 이번에도 끝나고 나면 아쉬운 부분은 남을 것이다. 그래도 지난 프로젝트를 마치고 떠올렸던 질문들을, 이번에는 직접 시도해 본 경험을 바탕으로 다시 돌아볼 수 있었으면 좋겠다.

이번에는 게임을 완성하는 과정뿐 아니라, ‘함께’ 완성해 가는 과정도 기록해 보려고 한다.