プロトスプリントリーグのすゝめ

はじめに

note初投稿になります、Haruです。

今回は、株式会社サイバーエージェントが開催している
「3days ゲームクライアント向け 開発型インターンシップ～プロトスプリントリーグ～」
に参加し、様々な学びを得ることができたのでそのメモ代わり、そしてタイトルにあるとおり勧めて行きたいと思います。

前半は、見てくれているかもしれない参加を躊躇している学生が見て、その背中を押せるような内容。

後半は、メモとして個人的な反省点をひたすら書いていきますので読むことは推奨できません…

とにかく「前半」を見てもらえれば嬉しいです！

＜前半＞

概要

まず、プロトスプリントリーグがどんなイベントなのかを簡潔に説明していきます。

このインターンは３日間のチーム開発でテーマに沿ったゲームを作り上げ、他チームと競い合うといった主旨です。

事前準備期間も設けられており、開発開始１週間前のチームメンバー発表後、コードを書くことは禁止で企画の打ち合わせや設計について話していきます。

つまり、

「実質３日（メンターさんからの手厚い対応付き）＋一週間（学生同士のプライベート）」

の開発型インターンという感じです。

良かった点👌

・初対面の人と短期間で作るのはコミュ力（特に、分からないことをチームメンバーに聞く、やりたいことを相手に分かりやすく伝える）が鍛えられた。

・同じ業界を目指す学生のレベルを肌で感じられた（自分に足りていないものが分かるのはもちろん、逆に「ここは強みとして出せる」という部分も分かる）

・メンターさんはどの方も本当に技術的に強いので、どんな質問をしても的確なアドバイスを貰える。

・メンター、参加学生全員が（アバウトな表現だが）良い人だったので気持ちよく開発することができた。（インターン終了後の二次会で他チームの学生と話せたりと楽しかった）

・メンターさんとの距離が近いので、普段聞けないような話も聞ける

全体としてとにかく最高に楽しい3日間でした！😆

自分はもう就活を始めるので、多分開催されるであろう来年度のプロトスプリントリーグに出られないことがとても悲しいぐらいもう一度出たいです😭

次に、冒頭で話したとおりプロトスプリントリーグの参加を迷っている学生が見て、背中を押せるような内容にしたいので、初参加にあたって想定される懸念点とそれに対する感想を話していきたいと思います。

想定される懸念点とその答え

・技術的に未熟で不安

→自分は2回このインターンに出ていて、1年前である前回の時の自分はほぼ初心者レベルでした。でも、そんな自分を笑ったり、馬鹿にしてくるチームメイトはいません。（英単語Circleの綴をCirculと３日間ずっと打ち間違えていた時は笑われましたが😂）

「周りについていけないかも...」と思って躊躇しているなら絶対に出るべきです。

確かについていけない可能性はあります。

実際、前回の自分はついていけているとは到底言えないような状況でした。Gitもまともに使えないし、プログラムも書き方が適当すぎて読んでも理解不可能なレベル…

しかし、分からないことはチームメイトに聞き、メンターさんに聞き、なんとか３日間やりきった。そのおかげで、大きく成長できたと思います。

それに、それが苦だったかといえばそうではなく、もう一度出たい！と思わせるものでした。

（こうやって２回目の参加をしているので当たり前ですね笑）

・Gitが使えない

→運営の方からわかりやすい初期設定の資料などがもらえます。別チームにGitを使い慣れていない人はいましたが、３日間のうちにマスターしていったように見えたので大丈夫です！

・初対面の人と話すのが苦手…

→想像してみてください。このインターンに参加するのは、間違いなくゲームが大好きで仕方ないあまりゲームクリエイターを目指している人達です。

ゲームの話を出して「やーい、ゲームオタク〜〜〜！」などと馬鹿にしてくる人は当然いません😂

つまり、究極的に趣味が合う人しかいないんです！！！

普段苦手でも絶対大丈夫です、安心してください！

＜結論＞

再度になりますが、めちゃくちゃ楽しかったです！

反省点は後半に書いていくのでとりあえず手放しに「最高だった！」といって良いのではないでしょうか笑

もし、プロトスプリントリーグに出ようか迷っていたら絶対に出てみてください！

あまりに推しすぎてステマを疑われているかもしれませんが違います😊

そのくらい、自分にとって今回と前回のインターン２回ともが大きな分岐点になったのでこの体験を他の人にもシェアしたいという一心です。

以上で前半の内容を終わります。

ここまで見ていただきありがとうございました！

＜後半＞

冒頭で伝えたとおり、ここからは個人的な反省なので完全に自己満足です。

反省点は多々ありますが、大きく2点を挙げていきます。

１．クラス設計がゴミだった

今回、自分が完全にゲームシステム部分を作り上げ、つまり最も重要な基盤の部分を作ったのですが、反省点がかなり多かったです。

まずは、今回作った最終的なものからクラス図を書いたものがこれです。

クラス図の書き方があっているかはかなり怪しいんですが、大体の参照関係ぐらいだと思ってください。

一番の反省点は

ZoomTextManagerの結合の多さです。

そもそも作ろうとしていたものが、Zoomの授業中にYoutubeやTwitterでサボるというなんとも反抗的なゲームなのですが、そのZoomの授業の実装が今回の問題です。

この図ではわかりませんが、ZoomTextManagerにより画面内に授業内容が定期的にTextとして表示、たまにリアクションを求められることがあって、その場合はReaction関連処理を行う。また、Text表示時にそのTextの直前の内容をアンケートとして答えさせるというシステムでした。

つまり、画面を見ていればリアクションもアンケートもしっかり答えられるのでスコアUP！！！ということです。

ここで、私は最初ZoomTextManagerがTextの生成（表示）を行うので、

「文章の内容や対応する答え、直前の答えやどのリアクションが求められているか全てこのクラスに入れてしまおう！」

と考えてしまったわけです。

すると、どうなるか...

 ZoomTextManager次第でリアクション機能であるZoomReactionとQuestionManagerはかなり影響されてしまいます。

そのせいで2日目明らかに自分のタスクが重くなっていることに薄々気づきながら、しかし他の人に頼るとなるとZoomTextManagerとの相互関係を常に意識しないといけないという地獄の状況になっていました

メンターさんに「困っている時はちゃんと他の人に頼った方がいい」と最後のFBとして言っていただいたきました。確かにおっしゃるとおりなのですが、実際の心境としてはチーム仲もよく、チームのみんなの技術力をリスペクトしていたので頼ることも、メンターさんに聞くことも抵抗は無かったです。むしろ、頼れるなら頼りたかったです。

しかし、とんでもない化け物（クラス）を生み出してしまい、半ば途中まで作り上げた後にそれに気づいてしまったので、

「どんな汚くてもほぼ完成間近なのでこの調子で作りきっちゃった方が早い」

という要するにもったいない症で最後まで一人で作りきってしまいました。

あと、作ってるときはずっとコード書いてるのが楽しくて時間を忘れて無我夢中になってしまったことが敗因です…

6割ぐらい完成してた状態でこの絶望的な設計に気づいたんですが、一度全て破壊して作り直し、メンターさんに設計を手伝ってもらいチームメンバーに分担してもらったほうが確実に早く終わったと思います。これがまじで反省点です。

 今ゆっくり考えてみるとこうすればよかったのでは？というものがあったので挙げてみます。

大きく変わったのはZoomTextManagerには本当にテキストだけ変えてもらう形になっていることです。（本来はこれがあるべき姿）

あと外部データという非常に抽象的なものがあるのですが、これはScriptableObjectや他の何かにテキストデータなど入れておけばそれを各自参照してお互いに影響のないようにできたはずというものです。

テキストの変更をZoomQuestionManagerとZoomReactionManagerが監視し、変更した場合その値を取得して各自成功判定失敗判定を行います。

この場合、ネックになるかなと思っていたのは、Zoomのテキストはリアクションを要求するTextを出したい時、本来出したかった文章を無視してリアクション要求用の文章を出さないといけない点でした。

しかし、例えば生成判定のランダムだけ先にZoomTextManager側から実行して生成するときだけZoomReactionManagerに送るか、これだとObserverパターンに反している気がするので、素直にテキストの変更を受け取ってZoomReactionManager側でリアクションを要求するか決定。その場合既存のテキストを消す処理をZoomTextManager側に関数で用意しておいて、その上でリアクション用のテキストを配置すれば解決するのではないかと思います。

ZoomQuestionManagerの方は動作自体本来ZoomTextManagerと完全に離れていても動作するべきだったのでもちろん大丈夫です。

以上のようにできていたら、ZoomのQuestionの方はチームメイトに、Reactionは自分が作るといった形で分業できたことでしょう...

上の設計が正しいかはわかりませんが、このような設計をすぐに思いつき、息を吸うように自然に書けるようにするのが今後の課題ですね👍

2.こだわるところとこだわらないところの取捨選択

突然ですが、実際のゲームプレイ画面はこちらです（発表スライドから取ってきたので変な文字入ってるけど）

これ下のタスクバーも含めて全てゲーム画面です。

ゲーム内で実際のPC画面を再現するということにこだわった結果、かなりそれらしいものを3日間で作ることができました。

これは、「こだわるべき点として良かった」と喜びたいんですが、この再現度の裏で犠牲になったのはゲーム性、ゲームとしての面白さです。

これはゲームとして成り立っていないわけではなく、とにかく面白みがなかったということです。

ゲームの面白さの定義は日夜多くのゲーム開発者の中で議論され、私がここでそう簡単に結論を出せるものではありません。ただ、一つだけ言えるのは

「プレイヤーの心を動かす」

という点は面白いの共通要素にあると思います。

・タッチしたときの素早いレスポンスによって心地よさを感じる。

・某壺に入ったおじさんが山を登るゲームで、落ちた時プレイヤーは絶望し、なぜか開発者のウンチクを聞かされてさらに腹が立つ。

・ヒロインが死んでしまうようなゲームで涙をこらえきれない。

などなど、世の中で面白いと言われているものはどんな形であれ大きくプレイヤーの感情を揺さぶってきます。

今回はその視点が足りていなかったと思います。

PC画面とウィンドウ、その他アプリの再現度は3日間という制作期間において自他ともに認める完成度でした。

しかし、これをプレイしたプレイヤーの感想は

「おー、ウィンドウの再現凄い」

「ちゃんとアイコンタッチしたらウインドウ出てくる！」

ぐらいのものでしょう。

これらが前述したものと大きく違うのは、既存のものを模倣するだけでは

感心はするものの感動はしないのです

その点、今回優勝したチームは正直最初操作性が悪すぎて、

めちゃくちゃイライラしました笑

ただ、アイテムを集めることによりレベルアップでその操作性がよくなったり、より多くの場所にいけるようになったりと、プレイ中にも予想できない体験を与えようとしてきます。

優勝発表当時は悔しかったのでこんな冷静ではありませんでしたが、今思うとそのチームが優勝したのも納得だなと思います。

要するに、ここまでの話で何を言いたいかというと

感心を与える部分にこだわりすぎて、

感動を与える部分にこだわれなかったということです。

今回のゲームの改善案で言えば、

ただ単調に授業とサボりをこなしていくのではなく、

「突然ウイルスによるハックでまじで現実のPCが壊れたと錯覚させるレベルのイベント」

をいれるなどがあってもよかったかもしれません。

これならプレイヤーは本気で焦るだろうし、再現度を高めたことも活きてきます。

兎にも角にも、これは今後の制作にも必ず生きる考え方を得られたなと私は思います。

今後は、まずユーザーを納得、感心させるユーザビリティの部分と、肝であるユーザーの感情を揺らす、感動させる部分を切り分けて考えるところから始める。

もちろんどちらも大事でどちらかに肩を入れ込みすぎてはいけないのでその平衡感覚を意識しながら作業を勧めていく。

といったことを心がけていきたいですね！

結びに

もしここまで見てくれた方がいましたら、本当にありがとうございます！

反省点の文量の多さから、このインターンがいかに多くのものを得られるか伝わったことでしょう😂

今回学んだことを活かして、就職活動も頑張っていきたいと思います！！！

それでは、ここまでご精読ありがとうございました。