メタデータ

コース: Design Educational Games (CMU 05-418).

担当講師: Erik Harpstead 教授

チームメイト: Christina(Qianou) Ma

YouTube デモ: こちら

プロジェクト概要

4年生の時、Erik Harpstead 教授の Design Educational Games (CMU 05-418/818) を履修しました。

このプロジェクトでは、2〜3人のチームを組みました。教育的な game を design することが課題で、3D game を実装しない限り、大きな制限はありませんでした（もし 3D で制作できる能力があれば、教授に相談することも可能でした）。そのため、このプロジェクトでは、brainstorming、リサーチ、実装、prototyping、script 執筆、iteration という有効な game design の制作プロセスを通じて、チームメイトと円滑に協力することが求められました。MVP を完成させるまでの期間は1ヶ月足らずだったため、プログラミングに時間がかかる digital game は避けるよう推奨されていました。

しかし、私たちのチームは自分たちに自信があったため、digital game を選択肢から外しませんでした。これが結果として、「このコースの歴史の中で最も印象的な digital game」と称賛される作品を作る土台となりました。

準備段階

準備段階で、チーム内での役割を決めました。私は game design の経験が豊富だったため、gameplay design、プログラミング、game arts の大部分を担当し、チームメイトの Christina は game リサーチ、アンケート調査、ストーリーの script 執筆を担当しました。ここでは私の担当部分を中心に記述します。Christina の仕事に興味がある方は、彼女のページをこちらから参照してください。

最初の仕事は、何を作るかを決めることでした。Miro board を使って game のテーマについて brainstorming を行いました。

そして、すぐに親向けの教育 game を作ることに決めました。金融、環境、プログラミングなどを選ぶ人が多いため、このコースでは比較的斬新なトピックでした。

トピックが決まった後、初期の brainstorming を開始しました。以下の図は、このプロジェクトの初期提案です。

ピアレビューからのフィードバックを統合し、最終的に2番目の提案である chat simulator を最終プロジェクトのトピックとして選択しました。

ストーリーの Script

game の形式を chat simulator に決めたため、しっかりとしたストーリーを書く責任が生じました。プレイヤーである親がストーリーの異なる結末から学べるよう、このストーリーは branching（分岐）に対応させる必要がありました。一方で、期間は約1ヶ月しかないため、ストーリーを極端に長くすることはできませんでした。

当初は特定のキャラクターの生涯を描きたいと考えていましたが、すぐに野心的すぎると気づきました。そのため、キャラクターの人生の一部のみを切り取ることにしました。選択された期間の中で、プレイヤーは比較的複雑な親子間の interaction を体験することになります。また、ターゲットとする親のグループについても考慮する必要がありました。例えば、アメリカの親と中国の親では考え方が全く異なる可能性があるからです。

最終的なシナリオの決定は以下の通りです：

子供が重要な試験の準備をしています。精神的にプレッシャーがかかるこの時期、子供と親の interaction は困難で複雑なものになります。

ここから prototyping を開始しました。ストーリー制作のプロセスをここで全て語ると長くなりすぎるため、ストーリーがどのように iteration されたかについては game document を参照してください。

中国語でのストーリーの iteration に興味がある方は、こちらをご覧ください。 Playtesting Story - CHINESE version.pdfOpen ↗

User Interface

一般的な UI design プロセスに従いました。game のプロセスは比較的シンプルなので、描画すべき UI 要素はそれほど多くありませんでした。

以下のリストは、必要なすべてのシーンを示しています。

• Starting page
• Loading page(s)
• 親のオフィス
• 自宅（リビングルーム）
• 自宅（寝室）
• 自宅（子供の部屋）

接続ロジックは game プロセスによって決定されます。この chat simulator の 1日は、プレイヤー（親）がオフィスに行くところから始まります。オフィスでは、プレイヤーはコンピュータ画面上のソフトウェアを介してメッセージに返信したり、NPC と会話を開始したりします。その日の会話が終わると帰宅します。金曜日であれば子供も帰宅します（それ以外の日、子供は全寮制の学校にいます）。プレイヤーはリビングルームから寝室へ移動し、そこで 1日を終えます。翌日は自宅からオフィスへの loading page から始まります。

以下のページは、ページレイアウトの 最初の lo-fi バージョン です。これらをテストした結果、playtesting を通じて直感的であることが証明されました。

その後、インターフェースを磨き上げ、視覚的な art 要素を追加しました。最初は、1ヶ月以内に制作しやすくリラックスした雰囲気の Persona 5 を style の参考にしました。これが 2番目の UI バージョン です。

時間が非常に限られていたため、この iteration では背景のイラストの一部が完成しておらず、代わりに Google の写真を使用しました。しかし、この iteration は playtester から良い評価を得た一方で、UI style が game の雰囲気とどこか合わないという意見も多く寄せられました。この game はポップな UI style を必要とするような内容ではなく、ストーリーは学校で起こるものであり、多くの playtester（40〜50代）はこの style を好みませんでした。そのため、3番目の UI style を作成しました。今回は描画にかなりの時間を費やしました。

Game Design

これが game の closed loop と game system の図です。

これらは game system がどのように機能するかをよく説明していると思います。システムに補助的な機能をどのように追加していったか、その全プロセスを読みたい場合は、このウェブサイトでは長くなりすぎるため、game document を参照してください。

プログラミング

いよいよプログラミング段階です。プログラミング部分は、より高度な工夫が必要でした。最初に直面した大きな課題は、ストーリーの branching をどのように保存するかでした。当初は、Unity3D にストーリーを一行ずつ手動で入力したくなかったため、利便性を考えて tree 構造をデータ構造として使うことを検討しました。txt ファイルに記述し、parse() 関数を書いて自動的に txt ファイルを tree node に変換することを考えました。それは以下のようなものでした：

区切り文字として & を使用し、各 node にはメッセージグループ、レスポンスグループ、および子のインデックスを保存します。しかし、ストーリーの branching は実際には tree 構造ではなかったため、これはすぐに失敗に終わりました。

多くの node が収束するため、複数の親 node が同じ子 node を共有することがあります。また、この単純な parser では game の数値を組み込むことが非常に困難でした。選択肢ごとの閾値や、選択によって得られるボーナスを設定しようとすると、node が非常に読みにくくなってしまいます。最終的に、Unity で TextGroup として指定されたデータ構造を構築することで、ストーリーの node を実装しました。TextGroup は以下のようになります：

各 TextGroup は IncomingMessages[] で指定された受信メッセージを把握しており、各 IncomingMessages は WaitTime（プレイヤーの返信を受け取ってから入力を開始するまでの経過時間）と TypingTime（メッセージの入力にかかる時間）を保持しています。これらの変数により、インスタントメッセージの高精度なシミュレーションが可能になります。また、各 TextGroup は Answer[] で指定されたプレイヤーの選択肢を把握しており、各 Answer は min_mh、min_int（最小のメンタルヘルスと親密度）、MH_buff、Int_buff（選択によって得られるボーナス）などの情報を保持しています。また、選択後にプレイヤーにヒントやアドバイスを与えるための tip や warn も備えています。最も重要なのは、NextGroup と NextAvailable によって node が一意の子を認識できることです。根底にある線形性が tree 形式のストーリー保存の基礎となっており、これらのテキストグループは非常に堅牢に機能します。

2番目の課題も似ていますが、根本的に異なります。対面式の chat simulator です。基本的なロジックは似ていますが、今回は 1つの対話に 2人以上の話し手が関与する可能性があります。そのため、キャラクターの切り替え方法に細心の注意を払う必要があります。また、キャラクターは「入力中」や「待機中」にはならないため、インスタントメッセージシミュレーターの基本ロジックはここでは適用できません。全く異なるデータ構造の方が役立つと思われました。時間制限のため、この部分は完全に自作したわけではなく、4.99ドルの Unity Asset である DDSystem24 を使用して対面式の chat simulator を構築しました。特に、キャラクターを自動的に作成して割り当てるための調整を行いました。例えば、元のアセットでは inspector でキャラクターを作成する必要がありますが、これではプレイヤーが子供を娘ではなく息子と定義した場合などに、娘のキャラクターが表示されてしまうという問題が発生します。他の大きな課題に比べれば、ここでの課題は解決が容易でした。

scene management においても、いくつかの課題がありました。プロジェクトの開始時に、game のシーンフローを以下のように決定しました：

1. 月曜日から木曜日：オフィス -> Load（オフィスから自宅） -> 寝室 -> Load（睡眠） -> Load（自宅からオフィス） -> オフィス
2. 金曜日：オフィス -> Load（オフィスから自宅） -> 対面チャット -> 寝室 -> Load（睡眠） -> 対面チャット
3. 土曜日：対面チャット -> 寝室 -> Load（睡眠） -> 対面チャット
4. 日曜日：対面チャット -> 寝室 -> Load（睡眠） -> Load（自宅からオフィス） -> オフィス

そのため、カレンダーを追跡することが重要であり、日付を曜日に変換する処理が必要でした。しかし、数学的な関係を確認するだけで、この課題もすぐに解決されました。

残りの課題は、プレイヤーがカスタマイズした変数の置換、render pipeline の最適化、font shader、button/toggle/InputField の rendering など、細かな debug と実装でした。この game にはほぼ間違いなく潜在的な bug が残っていますが、限られた時間を考えれば、課題はスムーズに処理され、期待通りのものになりました。