ぱぴブログ

さんたろのブログ

ゲーム開発が好きな人のひとりごと

CATechChallenge「3days ゲームクライアント向け 開発型インターンシップ」に参加してきました

みなさんこんにちは。
さんたろです。

先日、サイバーエージェントさんのCATechChallenge「3days ゲームクライアント向け 開発型インターン」に参加してきました!

www.cyberagent.co.jp

インターンで制作したものをブラッシュアップしてunityroomに公開しました。
ブラウザ上で遊べますので、是非^^

unityroom.com

概要

サーバーサイドのインターン参加者も合流し、
ゲームクライアント3名、バックエンド1名の計4名でチームを組み、
2泊3日でUnityを用いてゲームを制作する、という内容でした。

チーム毎にゲームクライアント/バックエンドそれぞれメンターさんがついてくださいました。

オンライン開催で、基本の情報伝達手段はSlackとZoomでした。

事前打ち合わせ

開発チームは事前に公開されており、事前の打ち合わせをしても問題ありませんでした。

以前参加させていただいた「Akatsuki GAME JAM」で、作業計画を疎かにしたまま開発を始めると全体の作業量などが掴めず、完成できずに終わる危険性を感じていました。

papyrustaro.hatenablog.jp

そのため、Slackで連絡をとり、チームメンバーに多少無理言ってZoomを用いて事前打ち合わせをおこないました。(チームのみなさんありがとうございます)
また、いつでも情報を確認できるように、Scrapboxを利用して、各メンバーに簡単な自己紹介、得意なこと、苦手なことなどを記入してもらいました。

今回のテーマは「シューティングまたはパズル」でしたので、各々企画を持ち寄り、最終的に私が考案した「シューティングとホッケーを組み合わせたゲーム」を制作することになりました。

f:id:papyrustaro:20200927165744j:plain
企画決めの際に描いたイメージ

クライアント側は各々の得意分野を考慮し、
私がメインのゲーム部分を、
Aさんがエフェクトなどのグラフィックスを、
Bさんが敵の挙動、そしてバックエンドとの繋ぎ込みを、
と作業分担を決め、
Cさんがバックエンドの実装を担当する予定でした。

1日目

「1日目で一通り基礎を作り、2日目以降でブラッシュアップしていく」
これが事前打ち合わせで考えていた理想の動きでした。

自己紹介を行った後、早速事前打ち合わせによって分担された作業を...といこうとしましたが、メンターさんから「今日やる作業は決まっているの?」という質問に、明確に応えられず。
そうです。「エフェクトをつける」と言っても、どのタイミングで、どのようなエフェクトをつけるのかまで定義していませんでした。
そのため、Trelloを用いて分野ごとの必要作業を書き出し、時にはどのようなものにするのか相談し、各々実装していきました。
1日目でシューティングとホッケーの動きの基礎、被弾判定と被弾時処理、タイトルからgameSetまでの遷移、プレイヤーと敵のモデル、敵の基本的な動き等が完成しました。

夜の懇親会の後、チーム名の決定と、明日の各々の作業内容について確認し、解散。
その後、プレイヤーが指定範囲外に移動できてしまう事件が発生し、30分ほど唸っていました笑
子のGameObjectにRigidbodyをアタッチしてしまっていたことが原因でした。

ちょっとしたことで長時間唸ることはありますが、短期間のハッカソンでの発生は本当辛いです。
しかし、不測の事態が起こっても完成できるくらい、余裕を持ちたいですね。

バックエンドをどうするのか

バックエンド側の開発として、「ランキングの実装」だけが義務付けられていました。
3日間あるので、ランキング以外の機能も実装できたらいい、とチームで考えていましたが、クライアント側の3人は、実際どのようなことができるのか明確なイメージは持っていませんでした。
そこで、バックエンド担当のCさんが、自身が以前参加したインターンでどのような機能を実装したのか説明してくださり、具体的な追加機能を考える指標となりました。

最終的には、「PlayerPrefsを利用しtokenを保存することによって、端末ごとにアカウントを保持。アカウントごとに、ユーザー名や総プレイ数、ハイスコアなどの各データをサーバーに保持」という実装を目標にしました。

2日目

焦り

本当は1日目にランキングに関する通信処理を、Unityエディタ上でおこないたかったのですが、間に合わず。
このゲームは、プレイヤーとホッケーの衝突など、エフェクトを派手にしたほうが楽しいと考えていたので、Aさんもグラフィックスの実装で手一杯になるかもしれない。
つまり、手の空いた人がする予定であったプレイヤーデータの表示やランキングの表示を誰かに任せられるかわからず、Unity独自の機能を利用する部分のバックエンドとの繋ぎ込み作業も、いつ発生するかわからない。
そして、メインのゲーム部分もまだまだ仮の実装である。

2日目の昼の時点で、生半可な作業量では満足のいくところまで到達しない、と薄っすら察していました。

認識の違い

夕会と呼ばれる夕方の打ち合わせで、クライアント間でのタスクの優先度が違う、あるいは優先度がわからない、といったことが発生していることが初めてわかり、お互い優先度のチェックをおこないました。
これは、タスクを与えた私が、そのタスクの優先度、あるいはそのタスクがこのゲームにおいてどのような効果をもたらすのか、といった部分をハッキリと伝えていなかったからでした。

進捗

夜になるにつれ、尚更間に合わない雰囲気を肌で感じ、焦りも増していきました。
昨日早く寝たことを悔やみながら、ただひたすらにメインゲームの実装、ランキングと実績の表示用の処理、制作されたエフェクトやモデルの繋ぎ込みをおこなっていました。
具体的には、データ保持用の撃墜数などのカウント、レベルに応じた敵のランダム出現、SE付け、などなど。

↓の動画を観てくださるとわかるのですが、まだ敵の種類は少なく、出現頻度や難易度の調整等レベルデザインも全く手を付けられていない状態でした。

youtu.be

ランキング表示の実装は、一応Unity上で確認できるところまでいきましたが、実績の保存・表示はまだできていませんでした。

3日目

3日目は、ひたすらに実装をしてました。
敵prefabの作成、簡単なレベルデザイン、モデル・エフェクトの繋ぎ込み、タイトル画面とゲーム終了時の処理、ホッケーがゴールに入った時の処理。
そして、作業終了時刻の2時間ほど前に、ついに実績周りのAPI作成が終了し、急いでUnity側に繋ぎ込みました。
しかし、レベルデザインは最初の仮のままであり、自身のHPも3のはずが1であったりと、ギリギリまで実装に追われた故の最終結果でした。

最終発表

作業終了後スライド作成の時間があり、その後チーム毎の最終発表がありました。
しかし、スライド作成の時間帯で、サーバーとの通信が上手くいかない問題が発生。
最終発表でも、他のチームと比較しても時間をかけた実績周りの実装をお見せすることができませんでした。
私はバックエンドの開発について余り関わっていなく、原因について詳しく知らないのですが、通信量が増えすぎたことが原因みたいです。

反省

今回は共同開発故の学びがとても多かった気がします。
事前打ち合わせやツールの利用など、初めての試みばかりでした。
初めて会った人同士、とても短い開発期間、という特徴はありますが、今後の共同開発に活かせる点がたくさんあると思います。

今後も続けていきたいこと

メンバーができることを、お互い確認する

ゲームの企画を考える際に、それぞれの得意分野が活かせるものにしようと、メンバーの(不)得意分野を訊きましたが、企画が決まった後のタスクの割り振りなどでも、とても役に立ちました。
また、バックエンド担当のCさんが、Cさんがしてきた実装を見せていただき、より実装のイメージが湧きました。
ただ、〇〇ができる、というのではなく、こんなものを実装しました、というほうがわかりやすいかもしれません。

視覚的に伝える

リモートだと猶更、情報の共有が難しいですが、テキストや音声での伝達と、視覚情報での伝達ではわかりやすさが圧倒的に違った気がします。
特に、想像している処理などの「意識の共有」には、図やデモ動画がかなり効果的でした。
また、画面共有を利用したエディタ操作なども、より速く正確な伝達に役立ったと思います。

タスクの依頼先が「誰か」はダメ

最初から最後まで、みなさんそれぞれ作業をしていましたので、何か依頼を出すときに依頼先を決めないと誰もやってくれないこともあります。
誰がやるのか受け手側で判断している手間も惜しいので、できるだけ依頼主が特定の依頼先に頼むようにしました。
もちろん全員に確認してほしいようなことは、全員にお願いします。

管理ツールを利用する

Slack、Scrapbox、Trello、スプレッドシート等によって、テキストデータとして残すことはとても大事です。
相手が不在のときの連絡、決定事項の共有、タスク・仕様・進捗状況等の確認など、本当に大切です。
メンバー間の各ツールの使用の仕方に違いがあったので、予めツールの使い方の方針等は決めた方がいいかもしれません。

今後は見直したいこと

作業計画

「Akatsuki GAME JAM」での反省を踏まえ、できるだけ実現可能な作業計画にしたつもりでしたが、いざ振り返れば、まだまだタスクの量が多かったと思います。
つまり、企画の段階で、もっと作業量が少ない方向に仕様を決める必要がありました。
作業計画の時点で上手くいっていないと、どうあがいても問題が発生しますし、短期開発なら尚更大事ですね。

積極的に、最後まで相手の意見を訊く

自分の中での考え・気持ちを相手に伝えられないときもあります。
しかし、共同開発において全員が一丸となることが大切ですし、自分の中では無意味だと思ったものが、実はとても大切なこと、ということもあります。
今回の開発での話をしますと、私がAさんが3Dモデルとエフェクトを1から自作しているのを見て、AssetStoreから取れるものは取ってこよう、と言いましたがAさんは自作したかったのです。
自分で作りたい、というAさんの気持ちを訊かずに、効率だけを考え実装方法を指摘してしまいました。
こちらから相手の意見を、途中で口を挟まずに最後まで訊き、それから自分の考えも共有して一緒に考える姿勢が大切だと思いました。

要件をまとめてから伝える

自分は以前から、何かを簡潔に伝えることが下手ということを気にしていましたが、今回の開発でもこの良くない部分が出てしまったと感じています。
自分が考えていることをそのままダラダラと話してしまうのです。
相手からしたら、結局何が言いたいのかよくわからない。
この自分の欠点は、今後のコミュニケーションでも致命的な問題点だと思うので、自分の考えを要約してから伝えるように意識して話そうと思います。

タスクだけ渡さない。認識も一緒に渡す

クライアント側のタスクの割り当ては基本私がおこなっていたのですが、「どのような機能が必要か」だけを伝え、「その機能が、このゲームにおいてどのような効果をもたらすのか」について伝えていませんでした。
企画の発案者が私だったこともあり、他の方にとって、「このゲームの何が一番大事なのか」といったものが明確になっていなかったかもしれません。
タスクだけ渡した結果、優先度がわからず、大事な機能の実装を後回しにしてしまうということが起こりました。
認識を全て共有するのは大変かもしれませんが、少なくともタスクの優先度はハッキリと決めて、伝える必要があると思いました。

タスク管理を任せる

今回の開発では、事前打ち合わせの段階から私がまとめ役的立ち位置でしたが、最後までタスクの管理を私がする必要性は無かった気がします。
ハッカソン終了後に聞いた話ですが、マネジメントに興味がある学生もメンバーにいましたし、3日目は手が空いている人も居ました。

焦らない。そして寝る

上に書いた反省点も、焦りの感情と睡眠不足がなければ、もう少し改善できたかもしれません。
仮にタスクが多かろうと、焦ったら負けです。
焦ってもタスク消化が速くなるわけではないですからね。
寝る時間を削らないと終わらないタスクは、タスク量が多い、そして実装スピードが遅いということです。
メンターさんからは実装スピードは褒めていただきましたが、躓いた点は多かったので、精進あるのみです。
体調崩して、後日作業できない...なんて話になりませんからね。
本当に健康第一です(しみじみ)。

おわりに

インターンのブログで一番言いたいことは、メンターさんからのフィードバックが本当に素晴らしいものだったということです。
以前からCAさんのフィードバックが凄く参考になる、という話を何度も耳にしていましたが、実際にフィードバックを受けると想像を超えて的確かつ深くて感動しました。
今まで個人開発が多く、技術的側面ばかり気にしていたので尚更、社会的側面のフィードバックは自身を見直す大きなきっかけとなりました。
インターンに向けた準備・運営をしてくださった社員のみなさん、本当にありがとうございました!!!

参考になりませんが、私のScriptだけGitHubにあげています。

github.com

また、今後の見直しに、以下の結城浩さんの記事がとても参考になりました。

www.hyuki.com

Java言語で学ぶデザインパターン入門」などの書籍のイメージが強かったのですが、「数学ガール」等他のものも読んでみたいです。