皆様こんにちは。
インターンシップ～接触編～の指導責任者をやっています、
サイバーコネクトツーの曽我と申します。

前回の私のブログから一ヶ月近く経ちましたが、その間に行ってきたことをお伝えしたいと思います。

コードレビューの実施

制作に入って少し経った段階で、ゲームプログラマー志望のメンバーとコードレビューを行いました。

コードレビューとは

「ソフトウェア開発工程で見過ごされた誤りを検出・修正するために
ソースコードの体系的な検査（査読）を行うこと。（出典：Wikipedia）」

とのことです。

かなり簡単に言ってしまうと
「ソースコードを書いた人と、それ以外の人とで、
　より良くするために議論すること。」
でしょうか。

コードレビューで指摘されたことは、修正必須としたり、勉強の意味を込めて議論だけで終わったり、
人数も、上司と2人だけだったりチームのプログラマー全員参加だったりと、やり方は様々ですね。

今回は、私とインターン生４名の計５名で行いましたが、私の分のソースコードはないので、４名分です。

それぞれレビューして欲しい、自慢の(？)ソースコードを１つ用意して、私の方が見ながら意見を出しつつ、
他のインターン生にも意見を求める、という方法で進めました。

インターン生がそれぞれのPCで、対象のソースコードを見ながらレビューを行いました。

4人分のレビューとなると時間が掛かりますので、
今回はクラス設計に関する部分を中心にレビューすることとしました。

学生の方々は、普段あまり設計に関する話をする機会が少ないだろうと考えたからです。
折角、インターンに来ているので、弊社でしか得られない経験を増やしたいですよね。

クラス設計とは
「プログラムをどのようなパーツ（部品）に分けるか」
と言うことと考えてください。

よく車などで例えられますが、“エンジン”や“タイヤ”と言ったパーツに分けたり、もっと細かく分けたり、
もしくは複数のパーツを1つとして管理したり、します。

また、それぞれのパーツがどのような“機能”や“パラメータ”を持つべきなのか、というのも決めます。

“エンジン”には“排気量”以外にどんなパラメータを用意しようか、
“動かす”“止める”という機能だけでも良いのか、といった感じです。

この作業の精度によって他のプログラマーの作業効率が変わってきますし、
場合によってはバグが出にくくなったりもする、重要な工程です。

レビュー中は多くのことを話しましたが、全てをここに記載するのは難しいので、
私が意識して見たポイントを２点紹介します。

（※ここからは内容が少しプログラマー寄りなので、その他職種を志望される方には分かりにくいかもしれません。）

１． 名前と実態が合っているか？

プログラムを記述するうえで、クラス・変数・関数、といった様々なものに名前を付けます。
この名前に相応しい内容であるか、という事をチェックします。

例えば、“Player”というクラスに“MoveEnemy()”という関数が入っていたら、
「プレイヤーのクラスなのに、敵の処理？」といった違和感がありますよね。

開発の現場では何人ものプログラマーが一緒に作業しますので、
こういった名前と実態が異なっていると誤解を招き、バグの原因にもなります。

２． “継承”を適切に使用しているか？

C++言語を覚え始めた時、“継承”という機能に感銘を受ける人は少なくないと思います。
私も勉強を始めた頃は、とにかく継承をよく使っていた覚えがあります。

ですが、闇雲な継承は大抵悪い状況を引き起こします。

ある子クラスに機能を追加したい為に親クラスに手を入れ、また別の子クラスに機能を追加したい為に親クラスへ…
という事を繰り返した結果、肥大化してメンテナンス出来ない巨大クラス群が完成！という経験はありませんか？

継承の設計ミスは大量のソースコードの場合は特に厄介な相手となるので、慎重になって欲しいところです。

実際にはもっと多くのポイントを見ますし、
設計だけでなく実装面に関しても効率化や安定性を考えたコードになっているか、
なども見ていくことになるのですが、ボリュームの問題もありポイントを上記のようにポイントを絞りました。

とはいえ、レビュー中には他の指摘もたくさん挙がりましたし、
C++を本格的に勉強し始めたばかりのインターン生もいますので、
「クラスを作る時のコツ」のような話をしたり、
内容は豊富だったように思います。

インターン生にとっては良い経験になったのではないでしょうか。

さて、今回は私のお話はこの辺にしておきまして、
ここからはゲームデザイナー志望の方に指導をした者から、お話させていただきたいと思います。

では早速どうぞ！！

 

 

---

皆様こんにちは。
サイバーコネクトツーでゲームデザイン部門の統括をしている磯部と申します。

今回はインターンシップ～接触編～で活動されている皆さんに、
主に企画書制作について働く者の視点からアドバイスをさせていただきましたので、
そのことについて書かせていただきたいと思います。

企画書作成について

インターンシップのメンバーの皆さんが考えた企画アイデアの中から一つが選ばれ、企画書化されました。

最初に見せていただいた企画書は、なかなか楽しそうで良いとは思ったのですが、
いくつか気になる所もありました。

特に１P目と２P目が全く雰囲気の違う書類になっていたり、ゴチャゴチャした印象があったり。

また、ゲームデザイナーの眞鍋さんのノートに書かれているアイデアラフのイメージと比べると
ちょっとさみしいなぁ……と感じる書面でした。

▲初期の企画書P1~2

このゲームの面白いところは、“りんくる”を繋げて、特徴的な攻撃すること、なわけですから、
その２点が良く伝わるようにしなければなりません。

そのためには、繋がることの気持ちよさ、攻撃が面白そうか、を伝える必要があり、
特にその点に関しては紙面場で”面白そうに演出”する必要があります。

方法は色々です。例えば…

・魅力的なアオリ文句、文章。
・いきいきと動きのあるイラスト。
・迫力を演出し刺激的に見せるエフェクト。
・楽しそうな雰囲気に見せる配色やレイアウト。

などなど。

とにかく手を変え品を変え、面白そうに伝える。
そういうことを意識して調整してみてはどうか？とアドバイスをしました。

眞鍋さんは元々アーティスト出身ということで絵がとても達者です。
企画書は絵の力がかなりものを言います。

また、仕様書の制作や、作業指示する場合にも絵が描けるととても便利です。

簡単でもいいので、絵で物事を説明できるレベルの画力があれば、
ゲームデザイナーとしても仕事がやりやすいと思いますよ！

また、“見やすく”も重要なポイントです。

企画書は雑誌に載っている無数の広告ページの中の一であると想像すると分かりやすいでしょう。

見る相手が初めから興味を持ってじっくり見て、
全てを理解してくれようと努力をしてくれる、なんて
期待してはいけません。

なので、可能な限り読み手にポイントが伝わるように余計な情報は排除します。

余計な情報とは、例えばよくありがちなのが、

・同じような情報を別の所にも記載してる
・伝えなければいけないことを説明するのには、必要のないレベルの細かい情報を記載している

といったことです。
その点、最初の企画書は少々情報を整理する必要があったと思います。

以上のようなやりとりがありましたが、インターンのみなさんは、
少ない指摘で自分たちが何をすべきかを考えて対処できていたと思います。

▲修正後の企画書P1~2

仕様書制作について

企画書の制作が終わり、ゲームデザイナーの作業は今まさに仕様書の制作に移っています。

いくつか制作中の書類を確認させていただきましたが、
加藤さんは学校でチーム制作を経験したこともあってか、
必要そうな書類やそのフォーマットも自分で考えて決めて用意できていました。

現時点では一言だけアドバイスをしています。
加藤さんもブログの中で書いている

「仕様書を受け取った人の身になって作ることが一番重要」

ということです。

そう考えると“どうすべきか”ということが、自ずと分かってくると思います。

当然、わかりやすく見やすい書類がいいでしょうし、そのためには、文章も正確で、簡潔であり、
情報が分散しないようにしたり、修正変更がしやすいフォーマットにしたり、
データとしてプログラマーが扱いやすいフォーマットにしたり…。

色々工夫はあると思います。

さて、これからゲーム制作も山場です。

仕様書制作、作業指示、ゲーム調整、ゲームデザイナーの仕事もより忙しくなって行くと思います。

ゲームデザイン担当の加藤・眞鍋の両名が、どのような立ち回りで仕事をしていくのか楽しみです。

最後に

企画書制作は読み手の事を想像しながら、
仕様書制作はそれを見て作業する人の事を想像しながら、
ゲーム制作はプレイしてくれるお客様のことを想像しながら制作する。

どれも、受け取る人の事を想像して、その人がどう思うか、
どう感じるかを想像し、どうすれば良いのか、を考える。
その連続がゲーム制作に大切なことなのだと、私は思います。

このインターンシップを経て参加者のみなさんには、その事をしっかり感じて欲しいと思っています。