2回生向け：何を勉強すればいいか迷ってるコーディング課の後輩へ
はじめに
昨日のアドカレに引き続き3回生コーディング課リーダーのにしちゃんです！ささっと本題に入ります！
RiG++2回生のコーディング課の人！！
そろそろコーディングのあれこれについて悩み始めた人が多いんじゃないでしょうか？
現コーディング課リーダー兼この記事の著者の私は、2回生になってからガチの迷走期に入ってました。作りたいものはいくらでも思いつく、でも形にする能力がない。かといって何を勉強したらいいのか分からない。
言ってしまえば、ゲームプログラミングが本当につまらない時期でした。
が、普段からよく話す人には十分バレてると思いますが現在のにしちゃんは変態的なまでにゲーム制作が好きです。ドン引きされるレベルで部室にいます。大抵ゲームを作っています。もう最近は授業なくても1限の時間から部室にいます。変人ですね。
一応安心してもらえるように言っておくと、ただの変人ではありません。公の場でもちょこっとだけ認められてる変人です。
▼コンテストでベスト12に選ばれました。力及ばず賞は逃した。悔しい。
Indie Games Contest 学生選手権 | 「Indie Games Contest 学生選手権 2025」公式サイト
また今現在も懲りずに他のコンテストに挑戦している最中です。現在は結果を待っている段階です。
今日のアドカレでは、ガチ迷走期からここまでの1年ちょっとの間で私がどんな道を歩んできたか、反省文がてら書き残しておこうと思います。ほぼエッセイです。
端的にどんな技術を勉強すればいいか？（にしちゃんは何を勉強したか？）を知りたい人は、一番最後の章まで飛んで大丈夫です。
著者にしちゃんの炎上プロジェクト
私は2回生春学期の活動で企画発表を行いリーダーになりました。
その企画は…！
留年麻雀！！
明らかに変なゲームですねほんまに。
簡単に要件を書いておきます。
- 大学生主人公が麻雀ゲームで遊びます
- 良い役で上がるほどどんどん単位を落としていきます（なんで？）
- 和了タイミングでパチンコみたいな派手な演出が出ます
- 落単しまくって目指せ夢の4留退学！！
ほんとに変なゲームでしたね。
加えて本当に恥ずかしいですが、当時の雑仕様書の一部をここに供養しておこうと思います。
色々頑張って書いてますね。懐かしいです。要は変な麻雀ゲームが作りたかったわけです。
ゲーム画面のイメージなんかも頑張って作りましたね。企画自体はちょっと（だいぶ）変なものでしたが、準備やら書類作りは真面目にやってた記憶があります。
さてこのまあまあちゃんと作りたいものが決まってる留年麻雀企画ですが、
秋学期中盤まで制作続行の末炎上し解散
という、目も当てられない悲惨な最期を迎えました。
大反省です。今となっては考えられない「やってはいけないこと」をいくらもやった結果です。
とはいえ、実は今の自分のスタートラインはこのプロジェクトだと思っています。
この章では留年麻雀プロジェクトについて、なぜ炎上したか反省・分析しつつ、そこから現在の私に至るまで何を勉強したか書こう（懺悔しよう）と思います…。
留年麻雀はなぜ炎上した？
今でもこの企画自体は個人的にすごく気に入っていて、企画発表時に集まってくれた制作仲間たちについても一切の力不足はなかっただろうと思っています。が、無事炎上しました。
解散後しばらくは私個人で開発を進めたりもしたのですが、やはり最終的には制作中止を決断しました。
なぜこのプロジェクトは炎上したのでしょうか？
私としては、以下の3つの要因があっただろうと自分で解釈しています。
「そもそも企画の規模が大きすぎた」
大前提このゲームの基礎の基礎部分として、一般的な麻雀を完璧に実装する必要がありました。留年要素だとか、演出をこだわりたいだとかは、その後やっと手を付けられる部分でした。この時点で大きなミスでした…。RiG++の活動の形式上、基本的には1学期すなわち半年で制作を終える必要があります。さらにこのプロジェクトに関しては、メンバー全員が当時の2回生だったことも起因して、とても完成まで持って行ける規模ではありませんでした。
「技術的にコーディングの仕事の振り方が分からなかった」
当時は2回生といっても春学期だったため、ゲーム制作を始めてちょうど1年が経つころでした。リーダー経験もこのプロジェクトが初めてで、特にコーディングについては上手い仕事の振り方が分かりませんでした。より具体的に言えば、「それぞれが作ったものをどうやって結合すればいいのか？」「そもそも担当箇所をどう分ければいいのか？」「他人が製作途中のものが自分のコードで今必要になったらどうするのか？」などなど…。そんな悩みの結果そこまで大きな仕事を振り分けられず、自分のもとに膨大な量のコーディングの仕事が残りました。
「仲間に頼る前に自分で何とかしようとしすぎた」
前項の事柄にも関連しますが、仕事の振り分けが上手くいかなかった延長線の末にたどり着いてしまった思考が、「リーダーの自分が全部なんとかしなきゃ」でした…。「コーディングの仕事頼むより自分で書いた方が早いのでは？」「仮置きモデルだと後から再調整するのめんどくさいからもう自分で作っちゃえ」などなど…。技術的な問題のみでなく、悪意は無いにしてもチーム開発とは程遠い思考に陥っていました…。
留年麻雀の炎上後にやったこと
留年麻雀の制作中止を決断した2回生秋学期中盤、秋学期から同時進行で参加していた他企画（こっちはリーダーじゃない）の仕事を進めつつ、「このままじゃだめだ…！企画規模は抑えればいいとしても、人に頼れる方法を確立しなければ一生ひとりでゲームを作ることになってしまう…！」とかなり焦っていました。
そうです、このときやっと「仲間にちゃんと頼る大切さ」と「頼るためには技術が必要」だということに気づきました。
このタイミングで私のコーディング修行が始まりました…。参加していた他企画はちゃんとやることをやりつつ、一度ゲーム制作から離れた、普遍的なプログラミングの勉強を始めました。やったこととしては、
- C#言語およびオブジェクト指向の普遍的な勉強
- アーキテクチャやデザインパターンなど（今もまだまだ勉強中）
- git/GitHubなどを使った管理/共有手法
あたりだったかと思います。
要は、
といった感じです。
適切にクラスを分けれるようになって、複雑な構造から脱却して、柔軟なプログラムが書けるようになれば、自分も安全に仕事をお願いできるし仲間も安心してプログラムできるだろうという考えからでした。
仲間に頼るためのプログラム設計
勉強したことの中でとりわけ今の自分の基盤になっていると感じているのは、「インターフェースを介したモジュール分離」でした。
▼実は去年の今頃、アドカレ2024でインターフェースの記事を書いたぐらいには勉強しました。
【Unity】インターフェースって結局いつ使うの？ – RiG++ – 立命館大学情報理工学部プロジェクト団体
詳しくは奥深すぎるので割愛しますが、インターフェースという当時理解不能だった存在についてかなり勉強しました。当時はインターフェースと継承の違いがわからなかったもんです…。たぶん皆が通る道だろうなと思います…。
このインターフェースについての理解がある程度深まってきたあたりで、自分の中でなにかが覚醒しました。大げさに聞こえるかもしれませんが、結構本当にこのタイミングで色々な事柄が結びつき始めたなと思ってます。
この流れで「モジュールを分離する」という思想と、それを実現する技術を手に入れました。例えばデータベース関連のシステムやプレイヤー関連のシステムは、適切に分離できれば丸ごと仲間にお願いできるやん！と気づいたり…。もっとちゃんと設計できればお互いに依存させず、個々の開発もその後の結合も簡単にできるやん！と気づいたり…。
一度ゲーム開発から離れてソフトウェア開発全般に共通するプリンシプルを学んだことで、普遍的なチーム開発の手法が少しずつ身についてきました。
炎上後の勉強を経た新プロジェクト
こうして勉強を続けて、気づけば2回生秋学期が終わり春休みに入っていました。
ここで新たなチーム開発が始動します。それが…
新歓ゲー！！
です！
現1回生がRiG++に入ってくれたタイミングで行われた新入生歓迎レクリエーションで遊んでもらった「RiG LEAGUE」というゲームです。
ちょうどこのタイミングで私はコーディング課リーダーという役職に就き、このプロジェクトのリーダーにも任命されました。
このプロジェクトでは先の勉強で得た知識をフル活用して運用しました。今見ればまだまだだなと感じる箇所も多々ありますが、最終的にこのプロジェクトは大成功でした！
新歓本番では100人を超える後輩に遊んでもらい、かなり盛り上がってたなと自負してます。
RiG LEAGUEはなぜ成功した？
ほんの数カ月前にとんでも大炎上を引き起こした私が、なぜこのプロジェクトは大成功まで走りきれたのでしょうか？
前述の留年麻雀の炎上理由に当てはめつつ、自分は以下のように考えています。
「適切な開発規模感だった」
RiG LEAGUEでは「RiG++に関するクイズ」と「ワンボタンのミニゲーム」を交互に遊びます。クイズの正誤に応じて、ミニゲームの内容が少しだけ変わるという仕様です。ここで大切なのは、ゲームの規模感を簡単に変えられる設計にした点です。（単純計算ですが）一度クイズフェーズとミニゲームフェーズを作り切ってしまえば、あとはクイズを量産すればそれだけでゲームの規模を大きくできる設計にしました。「1カ月ちょっとの期間でNintendo SwitchのJoy-conを使った最大8人のローカルマルチゲームを作る」という一見怪しいプロジェクトでしたが、適切な開発規模に抑える努力によって実現できたと考えています。
「適切なモジュール分割ができていた」
先の勉強を経て、このプロジェクトではゲームの管理に利用する様々なパーツをインターフェースを挟みあらかじめ分割していました。DB、プレイヤー、タイマー、各種演出などなど、全てインターフェース経由でメインシステムからアクセスするように設計していました。ここで仲間にはインターフェースのスクリプトを渡すことで各種モジュールの開発をお願いしました。その後メインシステム担当の私は各モジュールのモック版（Debug.Logだらけ）でゲームをほぼコンソール上で作成、反対に各モジュール担当の仲間はインターフェース越しにメソッドを呼ぶだけのドライバを利用してモジュールを作成、という形で待ち時間なしで開発が進められました。
「仲間に頼る体制が整っていた」
コーディングに関する技術的な成長もあり、とにかく仲間にお願いできる体制が整っていました。技術的には前述したように適切な割り振りができるようになっており、またそれに伴ってメンタル的にも「どんどんお願いしていこう！」「自分でやるより仲間にやってほしいことをちゃんと伝えてお願いしたほうが早い！」と自信を持って思えるようになっていました。これにより、コーディング課以外の仲間も含めて全員で開発が進められました。
RiG LEAGUEの成功後にやったこと
プロジェクトは大成功でしたが、反省点は大量に見えてきました。大成功後ではありますが、ちゃんと反省点は受け止めていきます。
- メインシステム（GameManager）に柔軟性がない
- ロジック組みと見た目制作が前後してやりにくい
この2点が大きかったです。前者はいわゆる神クラスというアンチパターンにたどり着いてしまったこと、後者はいわゆるロジック/ビュー分離ができなかったことです。
これらの反省点を改善するべくやったこと、それはもちろん「ゲームを作る！」です！
前までの自分と違って断片的な技術力は多少持っているため、次はゲーム全体の設計レベルをどんどん磨き上げていこうと考えました。
反省しつつコンテストへ挑戦
こうしてまたまた新たなプロジェクトが始まります。
今回は明確に改善したいポイントが定まっていたこと、勉強メインの制作だったこと等もあり、個人での開発になりました。またタイミングが良かったこともあり、コンテストへの挑戦も含めた個人開発が始まりました。
これが私の代表作の前身となる
Perfect Back Parker
です！
これまた私のコーディング人生の大きな分岐点でした。この作品から私のクラス設計が大きく進化します。
▼コード公開してます。後程出てくるリンクの方が自信ありますが…
Portfolio-Nishida-Ryu/★_Perfect Back Parker at main · omame0608/Portfolio-Nishida-Ryu
▼UnityRoomで遊べます。
Perfect Back Parker | フリーゲーム投稿サイト unityroom
ここから「pureC#」という概念が私の設計に取り入れられます。またここでは完璧には保守できなかったものの、「ロジックレイヤーとビューレイヤーの分離」が意識され始めました。
さらにこのプロジェクト、実は超短期間で完遂されました。なんと10日とちょっとで完成まで漕ぎ着けました。コンテストの締め切りがかなーりやばかったからです。
こうして反省すべき箇所を改善しつつスピード開発の末に完成したPerfect Back Parkerですが、ありがたいことにコンテストでベスト12に選出されました！
東京ゲームショウにも展示いただいて、本当に貴重な経験をさせていただきました。
が！力及ばず、賞までは手が届きませんでした。ということでまだまだ挑戦は続きます。
今現在も審査中の代表作が完成
夏休み中にゲーム会社へ就業型インターンにお邪魔したこともあり、モチベーションばり高の状態で今年9月末、新たなプロジェクトが始まります。
これが現状の私の代表作である、
Perfect Back Parker Rev!
です！
前章のPerfect Back Parkerについて、色んな場所で様々なフィードバックを頂きました。その結果遊ぶ人目線でも開発者目線でも、直したいものや加えたいものがたくさん出てきました。
よって、続編という形を取りまた1から作り直しました。結果的に前作とは全く異なるものになりました。
▼コード公開してます。
Portfolio-Nishida-Ryu/★★_Perfect Back Parker Rev! at main · omame0608/Portfolio-Nishida-Ryu
▼UnityRoomで遊べます。
Perfect Back Parker Rev! | フリーゲーム投稿サイト unityroom
ここでは「ロジック⇒ビューの処理の流れ」「より明確なレイヤー構造」「インターフェース経由のインタラクション」などなど、さらなる進化を遂げています。
またこのプロジェクトでは、将来的なステージの追加に柔軟に対応できる設計になっています。実際ステージ3までの実装で一旦は完成としましたが、ステージ2,3を作るに当たってほぼ追加のスクリプトを作成していません。今後のステージ追加も簡単にできるだろうと思います。
このゲームについてもコンテストに提出しました。記事を書いている今現在審査を受けている最中なのでこれ以上のことが書けないのですが、きっと良い結果を背負って帰ってきてくれると思います。
まとめ：私たちは何を勉強すればいい？
やっと今現在までたどり着きました…。長かった…。
結局、現コーディング課リーダーが「プログラミングつまらない」から「ゲーム制作だいすき」になるまでにどんな勉強をしたか、思いつく限り書き連ねておこうと思います。
いろいろ書きましたが、最終的には一番最後に挙げた「どんどんゲームを作った」が一番効果があったと思います。
やっぱりアウトプット大事だと思います。
とはいえ何も考えずに漠然と手を動かすのもあれなので、何を勉強したらいいのか分からなかったら上記のうちから気になるものを試しに勉強してみてはどうでしょうか？
あとにしちゃんがRiG++にいるうちは雑に使ってもらって大丈夫です。気になることがあったらどんどん聞きに来てください。大変喜びます。RiG++引退してもまあ雑に使ってもらって大丈夫です。
ではこの辺で終わろうと思います。
就活で話すエピソードの整理にもなったので自分としてもこの記事を書いてよかったです。
