次のリストは、Duvall Drive の謎 に取り組んでいる間に考えた主な技術デザイン要件の概要を提供します。これらの要素の視覚デザインに関する詳細は、Duvall Drive Showcase の謎 を参照してください。これは、没入型環境を作成するために使用した Studio のさまざまな機能とツールを強調しています。
ミッション
プレイヤーが経験を進めるには、回転プラットフォームの連続をナビゲートする など、経験を進めるために解決する必要がある複数のタイプのミッションがあります。特別なアイテムを回収するか、拡張パントリーで異なる材料を見つけて鍋に入れる など、異なる材料を見つけて鍋に入れる。ミッションの作成とデバッグプロセスを整理するために、ミッションフレームワークとデバッグバージョンを作成しました。
ミッションフレームワーク
エクスペリエンス全体でミッションの各ステップを統一するために、パズルの開始と終了のホック、構成データの読み込み場所、およびパズルをデバッグするためのボタンを含む シンプルなパズルミッションフレームワーク を各ミッションに設計しました。このプロセスとパラメータに関する詳細情報は、ミッションロジック を参照してください。
シールとゲーム状態
プレイヤーが特定の部屋に入ると、ミッションをトリガーするために、 シール と呼ばれる特別な小さなオブジェクトと相互作用することを望んでいました。ミッションを解決した後、全体のゲームプレイを進めるために、シールを捕まえて、フォイヤー内の事前定義された場所に配置したいと考えました。シールを正しい場所に配置した後、家の他の部屋に移動して特定のオブジェクトをクリックして次のミッションを開始できました。
これを実装するために、 ゲーム状態 を作成し、プレイヤーがプロセスを開始できる期間を指定するようにしました：
- 部屋で「破損した」印章を検索してミッションをトリガーする
- ミッションを解決すると、「復元」された印章を拾う。
- 印をフォイヤーサークルに置きます。
ゲーム状態は、ほとんどの場合、エクスペリエンスのフローと、プレイヤーがエクスペリエンスの ナレーション と対話する方法を制御します。詳しくは、ゲーム状態マネージャーを参照してください。
ノーマルと破損の部屋
家には 6 部屋の 2つの状態を持ちたかった：普通の状態と損傷した状態。プレイヤーがルームの破損した状態をトリガーするために、ルームの破損したシールに触れると、環境は修正された照明、環境オブジェクト、および特殊効果でより暗い雰囲気に変わります。プレイヤーはその後、部屋の通常の状態に戻るためにミッションを解決する必要があります。
これを実装するために、家から非常に遠い特別なスペースをエクスペリエンスに準備し、 X 方向の約6,500スタッドで、部屋の破損した状態を容納できるようにしました。プレイヤーが任意の破損状態をトリガーすると、特定のルームの破損状態が ServerStorage から TempStorage/Cloned フォルダにクローンし、プレイヤーがそのルームに テレポート します。小さな Parts は、ルームに入ったり出たりするときにプレイヤーのスポーンポイントとして機能する各普通のルームと汚れたルーム内に存在します。ミッションを解決した後、同時にプレイヤーを部屋の通常の状態にテレポートし、破損した状態の部屋のすべてのオブジェクトを破壊します。このテレポートプロセスを制御するゲーム状態に関する詳細情報は、GameStateManager を参照してください。
デバッグ版
定期的にミッションをデバッグするのを助けるために、ロビーやカットシーンを待つ必要がないバージョンのエクスペリエンスを作成しました。このバージョンには、キーボードベースのチートとボタンがあり、ミッションを自動的に完了させることができ、エクスペリエンスの側面を迅速にテストできました。私たちは定期的に、適切なゲームプレイフローを持つバージョンをリリースする予定のバージョンにこのバージョンをコピーして公開します。これらの 2つのバージョンを区別するために、 DemoGlobalSettings スクリプトを作成して、placeIDをチェックし、Studioで実行されているかどうかを確認し、さまざまなゲームプレイのチートとボタンを有効化/無効化しました。詳しくは、ミッションロジック と 構成スクリプト を参照してください。
テレポート
エクスペリエンス内で発生する 3種類のテレポートがあります：
- シンプルなロビーからメインのゲームプレイエリアにプレイヤーをテレポートする 予約サーバー 。
- 部屋の通常状態から破損状態にプレイヤーをテレポートし、カットシーン を表示しながら、再び戻ります。
- パズル内のプレイヤーをテレポートするか、ゲームプレイエリアから落ちた後に リスポーンする。
予約済みサーバー
我々は、シンプルなロビーで、プレイヤーを5グループに分けて、家のメインのゲームプレイエリアにテレポートする前に、予約サーバーに移行することを決めました。ロビーは、追加のプレイヤーが参加して一緒にプレイする時間を提供し、予約されたサーバーは、追加のプレイヤーがゲームプレイとストーリーの側面を見逃すのを防ぎました。このテレポートは 1回だけ起こります。
カットシーン
ゲーム中に、シールに触れたり、ミッションを完了したりするなど、特定のタスクを達成したときにプレイヤーを輸送できるようにしたいと考えました。これを実装するために、 イベントマネージャー というスクリプトベースのツールのシンプルなバージョンを開発し、様々なプロパティと属性を制御し、スクリプトとオーディオを実行し、時間の期間にカメラシェイクを行いました。これにより、プレイヤーを移動しつつ、特殊効果を使用してプレイヤーからこのプロセスを隠しながら、異なる部屋をストリーミングできました。詳しくは、イベントマネージャーを参照してください。
プレイヤーをリスポーンする
実装したかった3番目のテレポートタイプは、パズル内でプレイヤーの CFrame 座標変更のみの短いテレポートと、プレイヤーが落ちてリスポーンするときでした。前の 2 種類のテレポートとは異なり、この種類は明示的にアスクローンストリーミングをリクエストしません。
ゲームプレイスクリスクリプト作成
スクリプトにより、フェードする UI 要素、キーイベントのトリガーボリュームの作成、プレイヤーのカーソルで焦点にあったオブジェクトを強調するなど、特定のゲームプレイ要素を実行できました。これらのシステムの多くは、タグ付きオブジェクトを使用してカスタム動作を実行し、エクスペリエンスの設定ポイントで発生する必要のあるアクションに応じて、さまざまなクライアントまたはサーバースクリプトを使用して特定のワークフローを含めました。これらのシステムを実装した方法に関する詳細は、基本ゲームシステム と サポートシステム を参照してください。
タグ付きのカスタム動作
私たちは、ドアをロックしてプレイヤーがアクティブなミッションを完了するまで部屋内に留まらなければならないなど、オブジェクトにカスタム動作を追加する方法を望んでいました。これを実装するために、特定のオブジェクトにタグを使用することにし、次に CollectionService を使用してこれらのオブジェクトを見つけ、対応する Scripts を追加してカスタム動作を追加しました。各タグカテゴリがマネージャーとして機能し、そのカテゴリの下でタグ付けされたすべてのオブジェクトを処理するために 1 つ Script があったので、Script を 1 場所に保つことができ、それを複数回コピーするのではなく、DataModel で複数回コピーすることができました。詳しくは、ドアマネージャ、マスターアニメーター、ドロワーマネージャ、キルボリューム、プレイヤーミッションリスポーン、およびピアノマネージャを参照してください。
「マネージャー」 は、エクスペリエンスが開始されたときにタグ付けされたオブジェクトを見つけ、カスタム動作を接続します。例えば、DoorManager は ドア でタグ付けされたオブジェクトを見つけ、ドアオブジェクトに正しい動作を付け加えます (クリックするとドアが開き、ドアのスウィング効果音を再生するなど)。しかし、プレイヤーが損傷したシールと対話した後に損傷した部屋に追加されたオブジェクトなど、実行時に追加または削除されるすべてのオブジェクトは、この初期呼び出しを見逃し、期待される動作を得ることがありません。これを解決するために、CollectionService.GetInstanceAddedSignal と CollectionService.GetInstanceRemovedSignal を使用して、それぞれタグ付きおよびタグなしの新しいオブジェクトに同じ動作を付与します。
クライアントとサーバースクリプト
パフォーマンスで高価になるゲームプレイの異なるアスペクトの帯域を減らしたいと考えました。オブジェクト機能が他のプレイヤーにシミュレーションに影響を与えると決めたとき、衝突でオブジェクトを移動するなど、他のプレイヤーにシミュレーションに影響を与える可能性があると、これを サーバー で実行することにしましたが、環境デザインに関連するもの（ライト、環境アニメーションがゲームプレイ、特殊効果、オーディオに影響しないなど）は、 クライアント で実行します。これにより、バンド幅が減少し、ユーザーデバイスでの移動と環境変更がスムーズに保たれます。