ハッカソンでリードデベロッパーをやった話

こんにちは、2023春ハッカソンでチーム5班「最強(大嘘)」に所属していた cobalt です。めちゃくちゃ記事を書くのが遅いですが理由は後述するので許してください。新入部員なのに人より C# 歴が10年長かったというだけで筆頭プログラマーみたいな立ち位置になってしまったので、なんとか奮闘した過程とそこを基にした主張を記事に書きたいと思います

制作物「絶起 & run」

選べるスキルを駆使して最速クリアタイムを目指す2Dプラットフォーマーアクション絶起 & RUN

タイトルの英語が間違っているのはロゴが書かれているとき誰もレビューする余裕がなかったからです。全員英弱のチームというわけではない。

筆者のポジション

ゲームのアイデア、画像や音声の素材、Git周りの管理は基本的にチームメイトに任せて、私はコードをどう書くかやチームメイトのプログラマにどのようなコードを書いてもらうかを主に考えていました。

発表スライドに乗せる一言コメントを求められたとき、あまりに目の前の実装が重かったので半分冗談で「リードデベロッパーをやっています」とコメントしました。しかし自分の役割を改めて思い返すと、これは結構的確な表現かもしれないなと思っています。目の前のスキルやキャラの動きをどう実装するかよりも、処理同士をどう分かりやすく構造化するかということを考えていることが多かったです。

Disclaimer

今回のハッカソンは、経験者と未経験者が入り混じったチームで行われ、2日間という短期間で動くものを作る必要がある、というかなり特殊でシビアなシチュエーションです。そのためコードの綺麗さや運営などに関して、妥協せざるを得ない部分がありました(実際私も終盤は「このコード書くの嫌だ……」って言いながら書いてました)。

私自身、設計もチームマネジメントも完全に成功したとは思っていません。それでも一定の成功を収めることに成功し、この知見を共有したいと思って記事を書いています。

GMTKはいいぞ

まずはゲームのプランがなければ始まりません。チームメイトの良質なアイデアを、どのように膨らませて、どのようにハッカソンのテーマと関連付けるかを2回に分けて話し合いました。

面白そうなゲームのアイデアというのはゲームをプレイする人であれば割と思いつけます。しかしそのアイデアが実際に面白いかどうかを予想する、もしくは面白くないと感じた部分を適切に修正するために有効なのは、プレイ時間よりも分析と理論です。

分析や理論を培うための座学をするのは機会も少なく、そう簡単ではありません。そこで私が勧めたいのは、YouTube チャンネルのGame Maker's ToolKitです。このチャンネルの動画をいくつか見ているだけでもゲームの持つ「プレイヤーを楽しませる構造」への洞察がぐっと深まると思います。自分が作りたいゲームジャンルに関する動画だけでも見ておくと役立つと思います。

エディタ拡張を愛す

他班の人が覗きに来た時に「エディタ拡張を書いている」と言ったらめちゃくちゃびっくりされましたが、私はハッカソンでエディタ拡張を書くことはおかしいことではないと思っています。むしろエディタ拡張は積極的に書くべきです。

書いたことがある人ならわかってもらえるかと思うんですが、エディタ拡張は一回書いたことがあれば結構簡単に書けます。私は今回のハッカソンで、レベルデザイン用の簡単なエディタ拡張を20分ほど使って書きました。20分で作るエディタ拡張でレベルデザイナーの作業が30分減るなら、単純計算で10分のアドなわけです。短期間の開発だからこそ、作業効率を上げるための作業は惜しまないほうが良いでしょう。

序盤で環境整備

キャラを動かしたり弾を撃たりすることは、Unityを多少経験していれば比較的簡単に行うことができます。しかし次々と機能が足されていくゲームのロジックを、最低限のメンテナンス性を保って実装するというのは経験を必要とする高度な技能です。

経験を積んだデベロッパーは、実装がスムーズに進むよう事前に設計を考える必要があります。互いに相談する余裕がある通常の開発ならば、現状を見つつ適切に設計を実装に落とせばいいのですが、時間に余裕がないハッカソンではそういうわけにもいきません。

よってハッカソンでの経験者の最初の仕事は、設計を最低限実装に起こすことだといえます。ここでの「実装に起こす」というのはコードとして書くということに限らず、継承関係などを日本語で説明するというものでも構いません。他者が身を委ねて実装できる枠組みを提供できれば良いのです。

設計と実装難度

私は当初設計を思い描いたとき、abstract やプロパティを活用した「美しい」クラスで各種のスキルを表現していました。しかし初学者の関わるチーム開発ではこのような設計は望ましくありません。

この部分の設計にはかなり悩みましたが、動的な AddComponent と event キーワードを用いた難しいコードの側から、普通の MonoBehavior と同じように書ける各種スキルのコードを呼び出すという方針にしました。通常のカプセル化などにおける実装の隠蔽とは、安定したインターフェースと契約に依存することでコードの変更の影響を排するという考えのことです。しかし今回は難しい実装を一か所に押し込むことで、他の人の実装難易度を下げる、という方針で活用しまた。

ハッカソンに特有の話になりますが、スキルレベルの異なるプログラマにレベルにあった実装をしてもらうためには、負荷やメンテナンス性を犠牲にしても難易度の切り分けを優先することを検討するべきかもしれません。

ハッカソンはレビューを以て完成する

チームメイト各位の尽力もあって無事ゲームが完成しました。嬉しいことに試遊会でも好評を博し、優秀賞を受賞することができました。

しかしリードデベロッパーの仕事はこれで終わりではありません。せっかく多くの人が同じ目的に向かって懸命にコードを書いたのですから、レビューまでしないともったいないでしょう。今回はたった2日間のハッカソンで開催期間中にその時間をとるのは難しかったので、レビューはハッカソン終了の数日後にまとめて行いました(この記事の投稿がハッカソン終了から大きく遅れている最大の要因がこれです)。

コードの形式的な誤りは形式的な検証が可能なので、コンパイラが積極的に指摘してくれます。しかし意味論的な誤りやパフォーマンス上不利な書き方は、誰かに指摘されるという機会が比較的少なく、また指摘しようとする第三者もコンテキストやバックグラウンドが無いと誤りかどうか判断しにくいです。よって初学者は形式的誤りと比べて、意味論的誤りを認知する機会がどうしても少なくなってしまいます。

ハッカソンというのは、比較的少量のコンテキストとバックグラウンドを導入し同じ目標に向かって一気にコードを書く貴重な機会です。レビューをして知見や理解を共有するのにこれ以上の好機はないと思うので、初学者の成長のためにも経験者の方々は是非ハッカソン後にレビューをしていただきたいです。

おわりに

偉そうにいろいろと書いてきましたが、私はあくまでも一介の新入生であり、このような素晴らしいゲームを完成まで持って行くことが出来たのはチームメイトの尽力あってこそです。ありがとうございました。

私は短時間の開発イベントをゲームジャムくらいしかやってこなかったので、ハッカソンという新鮮な経験はとても楽しかったです。夏になるのか冬になるのかわかりませんが、次のハッカソンでは自分の残したこの文章を手掛かりとしてよりよいパフォーマンスを発揮したいです。

しょうがない部分はあるのでしょうが、新入生は記事を書くという行為にハードルを高く感じてしまいがちです。私の記事をきっかけに少しでも新入生の記事が増えることを願っています。