>   >  新人講師がゼロから挑むUnityによる人材教育:No.06:あそびのデザインとMDAフレームワーク
No.06:あそびのデザインとMDAフレームワーク

No.06:あそびのデザインとMDAフレームワーク

ゲーム専門学校の新人講師がUnityを勉強しながら、「ゲームのおもしろさとは何か」について授業を行う泥縄式レポートの第六弾。水先案内人になるのがユニティ・テクノロジーズ・ジャパン(以後、ユニティ)から提供中の無料教材「あそびのデザイン講座」だ。今回はゲームオーバーの実装で、ゲームのプレイ体験がどのように変化するか観察するまでの模様をレポートする。

TEXT&PHOTO_小野憲史 / Kenji Ono
EDIT_尾形美幸 / Miyuki Ogata(CGWORLD)

Unityの演習内容をどのように評価するか

CEDEC東京ゲームショウという秋の二大イベントが終了し、ぐったりしている今日この頃ですが、皆さんいかがお過ごしでしょうか? ゲームジャーナリスト兼、専門学校東京ネットウエイブ非常勤講師の小野憲史です。自分も両イベント向けにゲーム業界志望の学生を選抜し、会場を引率するボランティア活動を行なっていますが、年々体力の限界を感じています。学生はほんとに元気ですね。うらやましいかぎりです。

さてさて、本連載でもすでに触れたとおり、東京ネットウエイブでは前期14回のうち、夏休みを挟んで11回と3回の授業を行う、変則的なカリキュラムを採用しています。途中で1ヶ月も間が空いてしまうのは残念ですが、休み明けの3回分で振り返りとまとめができる側面もあります。特に教科書がない授業では、学生も予習が難しいため、いかに復習を組み込むかが重要だと感じています。スライドを使って、つるつるーっと講義するだけでは、せっかくの知識も右から左に抜けちゃいますからね。

そこでUnity演習でも夏休みを利用して、ちょっとした課題を出してみました。本連載の第4回で実施した「Roll-a-Ball-Custom-1stDev-2018」ワークショップをベースに、オリジナルのステージをつくって提出するというものです。専門学校デジタルアーツ仙台の志村 淳先生が作成されたUnityプロジェクトで、初心者でも簡単にオリジナルのステージをエディットできる、優れた内容です。GitHubで公開されており、誰でも自由に活用できます。

ところが、休みあけに学生からメールで提出されたUnityのプロジェクトフォルダをチェックしたところ、頭を抱えることになりました。ほとんどが満足に起動しない、または起動しても思ったように動かない、という事態に陥ったのです。夏休み前に演習途中の内容を提出してもらった際は、大半が普通に起動したので、ちょっと舐めていましたね(連載 第5回参照)。チェックする側としても、内容の確認のためだけにUnityを起動しなおすのが、少々非効率なように感じられました。

そこで休み明けの最初の授業では演習内容を入れ替え、作成中のプロジェクトフォルダをビルドして、学内サーバ上に提出するやり方について解説しました(「あそびのデザイン講座」では第11回で収録)。もっとも、ここでも「自宅で作成したデータが学校のPCではうまく動かない問題」が一部で発生したため、自宅でビルドしての提出を許可。それでもうまく動かない学生に対しては、動作中のデスクトップ画面の模様をスマートフォンで録画し、動画ファイルで提出してもらいました。


こうしたトラブルの背景には様々な要因が絡まっており、一概に解決できません。そのためコンテストなどでは、実行ファイルに加えて動画ファイルの提出を義務付けることが一般的です。動画審査で予選を行い、最終審査のみ実際にプレイするというわけです。就職活動でも近年では、自分がつくったゲームを動画キャプチャして、スマートフォンやタブレットにコピーして持ち歩く学生がいるほど。どれだけすごいゲームをつくっても、採用担当者のPCで動かなければ意味がありませんからね。

同様に授業でも学生が提出した課題の評価方法について、遅まきながらその重要性がわかってきました。そこで効果を発揮するのが動画ファイルです。Unityのプレイ画面を動画キャプチャするだけなら、アセットストアから「Recorder」をインストールすると便利ですし、OSがWindows Xなら、OS標準の録画機能を使用する手もあります。ただし、動画ではプレイ感覚がわからないので、やはりビルドによる提出があるといいなと思います。

ただ、そもそも動画をキャプチャしたり、ビルドしたりするには、作成中のプロジェクトがきちんと動作する必要があります。そして、そのためにはスクリプトがバグなく動作しなければなりません。授業時間ぎりぎりまで作業して、焦ってビルドしようとすると、たいていエラーが出てビルドが止まってしまうことに......。ほかに、せっかくビルドができても、サーバ上の保存先フォルダを間違えるといったケアレスミスも見られました。どのように評価すると楽なのか、ぜひほかの事例を知りたいところです。

授業のフローを再構築

また、前回説明したように、授業では「あそびのデザイン講座」の各回ごとに、こちらからサンプルのプロジェクトフォルダを学生に提供するようにしました。(これには後述するメカニクスとレベルデザインの関係も影響しています)。その上で各回ごとにプロジェクトフォルダをコピーして保存してもらい、いつでも前回の作業に戻れるようにしました。本講義では各回を2コマに分けて実施しているため、学生の演習内容は次のようになります。

08月31日 夏休み課題のプロジェクトフォルダをもとにビルド演習

09月07日 あそびのデザイン講座07回 演習実施【スクリプト編】
※あそびのデザイン講座06回で作成したプロジェクトフォルダをコピーし、今回用の作業フォルダとしてリネーム後、演習開始

09月14日 あそびのデザイン講座07回 演習継続【レベルデザイン編】
※あそびのデザイン講座07回のサンプルプロジェクトフォルダを配布。学生は前回自分が作成したものをベースに作業を継続してもいいし、サンプルフォルダをもとに演習してもいい。授業終了後、作業内容をビルドして提出


このフローを守ると、2コマごとに学生から新しいビルドが提出されるので、進捗が確認可能になります。1コマ目の授業では各自でスクリプト作成に挑戦してもらい、そこでうまく動けばよし。動かなくても2コマ目ではレベルデザインのみを行うため、ビルドに支障はないはずです。ただ、実際にやってみると、なかなか理屈通りにはいきませんでした。エラーを残したまま、サンプルでの作業に移行したくない学生がいたためです。結果として、ビルドができずに時間切れ......というケースが見られました。

ただ、エラーの修正は単にエラーが出た箇所を見ているだけでは、わからないことが多々あります。変数名のタイプミスなどは好例で、最初に定義した変数名が間違っていたら、エラーが出た行をいくらチェックしてもミスは見つけられません。時にはUIで定義したオブジェクト名がちがっていて、エラーの原因になっていた......なんてことも。プログラマー志望の学生ならバグトラッカーなどのしくみを使って徹底的にデバッグするやり方を学ぶと思いますが、どこまで教えるか悩ましいところでもあります。

その一方で、中にはサクサクと先に進められる学生がいることも事実です。詳細は後述しますが、すでに第13回までの演習課題が公開されたこともあり、PDFファイルとプリントアウトを全て学生に配布することにしました。その上で、興味があれば自由に独習してかまわないとしたのです。実際に2コマの授業で、どれくらい演習課題を達成できたか確認したところ、およそ半数の学生が完了。中には第8回の課題内容に進んでいた者もいました。

こんなふうにビルドについては検討課題になりそうですが、後期では進捗の早い学生は自由に進めてもらい、進捗が遅い学生には2コマに1回、サンプルフォルダを配布することで対応。その上で1コマ目はスクリプトの作成を進めてもらい、2コマ目にはレベルデザインを体験してもらう......というサイクルで進めていく予定です。なお、運用面の詳細については、学校ごとのカリキュラムやコマ数などにもよりますので、各自の実情にあわせて修正していただければいいかと思います。

次ページ:
全15回のうち13回目までの内容が公開

その他の連載