`Black and White Jam` というゲームジャムに参加した話
Postmortem of `black and white jam` game jam
先日ゲームジャムに一人で参加し、ゲームを期限内に（雑ながらも）完成させて投稿する事が出来た。それについての振り返りと反省点を記録する。
Note for English speaker
this article is deliberately written in a way such that google translate produces somewhat sensible result while minimizing the loss of subtle nuance throughout the article. please consider the fact that this is still a best effort and not a perfect translation.
note: some sentences produces pronouns such as “he” or “him”. the original article is all written in first-person. there are no participants other than myself.
前置き
2022年4月1日に開催されたBlack and White Jam #8というゲームジャム1に一人で参加し、試行錯誤しながら一週間で一つゲームを仕上げた経験を振り返る。
Raylib フレームワークを使用してC/C++で書かれ、WebAssemblyにコンパイルした物を公開している。
色々と厳しい道のりだったけど、結果としては「C言語系列を使って１つゲームを作り、公開する」という目標が達成できたので自分は成功体験だと捉えている。とても楽しかった。
この記事には主に技術面で学べたこと・次に参加するとしたらどのような事に焦点を当てるべきか等の反省について書く。
事の始まり
主なモチベーションは自らのポートフォリオにゲームを追加したかったから。ゲームジャムに参加しようという意欲そのものは一年ほど前からあったものの、過去に二度参加を試みてどちらも完成させられず頓挫した経験があり、そのせいか消極的になっていた。
ある日、itch.io2を眺めていると今回のジャムが目に止まり、そのまま何気なく勢いで参加した。自分は開催から３日遅れの参加だった（開催は4月1日、参加したのが4月4日）
経過の全体像
参加したジャムの制限は"可能な限りゲーム内には２つの色のみを使用すること（黒と白、赤と青など）“で、ゲームのテーマは"Loop （繰り返し）“だった。
C/C++を使ったゲームの開発経験を得るのが目的だったので、既に何度か使用経験があったRaylibフレームワークを使用することに決めた。またC++のSTLコンテナは使用せず、空き時間でちまちま作っていた自作の汎用ライブラリを代替として使用することにした。
最初の２日ほどでゲームの基礎が完成し、残った時間はひたすらバグ修正と試行錯誤に費やした。イラストや音楽に凝ろうとも考えていたが上手くそちらに割く時間が確保できず、最終日一歩手前で諦めて全部ミニマルなデザインに入れ替えを行った。
上手く行ったこと
Discord server and communication / socializing
自分が完遂させられた最大の理由はおそらくDiscordサーバーに参加してコミュニティと交流を取ったことだと思う。超ハイレベルな技術者が専門用語だけで会話しているような世界を想像していたが、蓋を開けてみると割と和気あいあいとしていて、思っていたものと全然違った。
Deadline and “Make it work” mindset
期限が設けられていたことで実装する処理や行うべき作業を取捨選択する必要に迫られた。結果として、どれだけ設計がズタボロで目も当てられない状態になっても「まずは動作させる」まで持っていくことがゲーム開発においてとても大事だと学んだ。
これは「まず計測」というパフォーマンス最適化の概念に通じるものがある。大抵の「これは良くない」という感覚は自分の主観が歪んだ意見を述べているだけな可能性もあるので、本来はもっと現実主義な考え方をするべきなのだろう。
What I want is not what I need
アーキテクチャの設計に割く時間が無かったため一つの関数内にひたすら処理を書き加え続ける形で開発を進めたが、結果としてデータが重複していてどういう風に切り出せばいいかが自然と浮かび上がるタイミングがあり、シンプルな切り出しができる瞬間があった。「こういうのがほしい、こうあるべきだ」ではなく「これが必要だ」という考えで新しいインターフェースやオブジェクトを作ると非常に分かりやすい。
振り返りと反省点
Plan is important
計画立ては非常に大事。今回のプロジェクトは飛び入りだったので一切計画立てはしなかったけど、今振り返れば最初の半日ぐらいで最低限の計画立てをした方が良かったように思える。
何が未完成なのか・何が必要なのかを一切追跡しなかったので、作業を行いながら「この作業は本当に重要なものなのか」というのが何も分からなかった。最後までイラストや音楽に時間を割かなかったのはこれが原因だと思う。
setting boundary
これは「一つの関数に全てをまとめる」というやり方の副作用だと思うが、気が付かない内に色々な処理がお互いに依存しあっていて、一切の分離が出来ないような構成になっていた。
今書いている処理が何に依存しているかというのを気にかける癖を付けるべきだと実感させられた。
Scope creep
ゲームを作っている最中、本当にその機能が必要かも分からないのに、明確な理由もなく「そういうものがあるから」という理由でシステムを作ろうとしてしまっていた。
明らかな例に、途中で何故か追加してしまったイベントシステムがある。「攻撃を受けたらそのイベントを発行して、それを受け取ったら音とエフェクトを出すようにしよう！」という考えで作り始めたもの。自分の知るイベント処理といえばwhile文を使ったポーリングぐらいしかなかったのであれと同じAPIにしたものの、全く用途も違うし何処でイベントを処理するかも考えずに実装を行ってしまった為、実際に使用することが出来ず直ぐに削除してしまった。
buzz-word architecture
これは上のScope Creepに通ずるものがある。おそらくUnrealやUnityなどを先に触った経験があるからか「○○システム」や「○○コンポーネント」など抽象化された概念を前提にゲームエンジンのアーキテクチャを考えてしまう。これは典型的な「ゲームではなくエンジンを作る」で、本来必要な機能からではなくバズワードのみを組み合わせてアーキテクチャを考えてしまっている。おそらく今回のジャムも、無駄な設計を考える時間を代わりにゲーム機能の実装に費やしていれば、多少は完成度を上げられたかもしれない。
改善点
join a team
イラストや音楽まで自分で担当するのは少し厳しいなと感じた。 コミュニケーションを取る練習もしたいので、次に参加するとしたら他のチームに所属すると思う。
planning first
ゲームが何をするのか、何が必要なのかを事前に洗い出し、それを実現するための計画を建てる作業を最優先に行う。
何にどれだけ時間を割くかを明確に割り出せなくても、作業の優先度を事前に知っておくだけで大きく作業効率が向上する筈。
small scope
いらないものは実装しない。出来ないと分かっている事を無理にやろうとしない。無理に自分を過大評価しない。
終わり
とても良い経験になった。全体的なゲームステートの実装や音楽アセットの処理などに時間をかけたので、次に参加する時はそこに時間を取られると承知の上で挑むと思う。
ゲームを完成させて投稿した瞬間はとても気持ちが良かった。機会があればまたすぐに参加すると思う。