すぐに使える本物の空 + テキストから 3D モデルへ

「見た目のよさ」と「使いやすさ」を1日で進化させる

この日のいくつかの主要な行は、作成のさまざまな段階に到達しますが、すべて「一般の人が見栄えの良いゲームを簡単に構築できるようにする」ことを指しています。箱から出してすぐの本当の空は、「第一印象は良い」と答えています。新しいゲームは単調なスタートを切るべきではありません。テキストから 3D モデルへの生成は、「資産がどこから来るのか」に対処します。モデル化できない人でも、文章から使用可能なモデルを取得できます。シーン定義を 1 か所に集めることで、「なぜ編集と再生が異なるのか」という古くて紛らわしい問題が解決されます。そして、エンジンのオフスクリーン レンダリングとネストされたシーンは、後でより高度な視覚効果とより複雑なレベル構成の基礎を築きます。これらを総合すると、明確な製品哲学が明らかになります。「始める」ためのハードルを継続的に下げながら、「達成可能なこと」の上限を継続的に引き上げることで、初心者が簡単に始められるようにし、本格的なクリエイターに十分な深みを与えます。

すべてのゲームは 1 つの空を共有しています - 新しいゲームは箱から出してすぐに見えます

この日は環境の空を 1 つの共有リソースに取り込んだため、すべてのゲームで同じ高品質の空が共有されました。以前の苦痛は具体的でした。新しく作成された空のゲームには空の合成グレー グラデーションしかないことが多く、アセットの欠落エラーが発生することもありました。一見すると粗雑で非現実的でした。新しいアプローチは、このハイ ダイナミック レンジ (HDR) 環境マップを 1 つの共有スポットに配置し、各ゲームがそのマップへの「参照を折り畳む」だけで、ランタイムが直接読み取れるコンパクトな形式にビルド時に 1 回ベイクすることで、実行時にコストのかかる変換を行わないことです。その結果は 2 つあります。1 つは、新しいゲームは箱から出してすぐに本物の空の雰囲気を備えた状態で出荷されるということです。空は本物の空であり、それが放つ環境光がシーン内のすべてのオブジェクトに自然に当たります。一方では、編集ビューは同じ空を使用するため、エディターに表示される環境光はプレイと正確に一致します。各ゲームが独自のコピーを保存するのではなく、なぜ「1 つを共有」するのでしょうか? 1 つのリソースが 1 か所に維持されるため、重複したストレージが節約され、すべてのゲームにわたって統一されたベースラインの外観が保証されます。単なる「新しいデフォルト背景」のように見えますが、実際には、すべての新しいゲームの出発点を「醜い」ものから「見栄えの良い」ものに直接引き上げます。

ストア内の新しいテキストから 3D モデルへのワークベンチ

この日、ツール ファミリは強力なワークベンチを獲得しました。言葉で何かを説明し、3D モデルを取得できます。ゲームを作りたい大多数の人にとって、「モデリング」は非常に高いハードルです。専門的なソフトウェアと長い練習が必要で、多くの良いアイデアが「そのモデルは作れない」という理由で止まってしまいます。このワークベンチはバーを平らにします。「苔むした岩」または「木箱」と書くと、対応する 3D モデルが生成されます。いくつかの外部 3D 生成サービスに接続して選択でき、ポーズの前処理 (生成されたキャラクター モデルをきちんとした標準的なポーズに保つ) が含まれ、使用後に結果を破棄せずにディスクに保存します。ワークベンチには Web 3D モデルと画像プレビューも組み込まれているため、ワークベンチ内で結果を回転させることができます。ワークベンチ全体が Studio ページ内に同じオリジンを埋め込み、生成されたモデルと画像をシームレスに使用して、ゲームに直接接続できます。その重要性は、「ツールが 1 つ増えた」ということをはるかに超えています。これは、従来最も時間がかかり、最もスキルが求められる段階であった「アセットの取得」を、文章を書くのと同じくらい簡単なものに変え、「アート スキルがなくてもゲームを作る」ことに大きな一歩を近づけます。

シーン定義が統合: 編集と再生が一致しなくなりました

この日は、「シーン」データ レイヤーの定義を 1 か所に収集するという重要な内部収束も行われました。事前の危険は、この「シーン」記述がエディター、ゲーム、エンジンに独自のソースを持っているということでした。これらは本質的に同じものですが、複数のコピーとして保持されています。その結果、デバッグ中に編集と再生が一致しないことがよくありました。双方が同じ定義をまったく読んでいなかったため、エディターで配置したものが再生では異なって見えました。この日、そのスタンドアロン中間パッケージは全面的に廃止され、そのコンテンツは統合ランタイムに折り返され、「シーン オブジェクト」がシステム全体にわたって 1 つの正式な定義を持つようになりました。また、「編集と再生」状態の同期に二重の安全装置を追加し、スイッチ上で状態が確実に渡されるようにしました。この背後には、プロジェクト全体を貫く核となる信条があります。それは、単一の事実には信頼できる情報源が 1 つだけあるべきであるということです。一度複数のコピーが存在すると、遅かれ早かれ静かに分岐し、その分岐が追跡するのが最も困難なバグの温床となります。シーン定義を 1 か所に集約することで、「編集中に表示されるものが再生される」という信頼性の高い一貫性が直接得られます。

エンジン: オフスクリーン レンダリング + ネストされたシーン、複雑なエフェクトと大きなレベルへの道を開く

この日、エンジンにはさらに 2 つの重要な機能が追加されました。 1 つはオフスクリーン レンダリングです。簡単に言えば、エンジンが最初に画像を「目に見えないキャンバス」にレンダリングし、全体として処理してから表示します。これは、あらゆる種類のフルスクリーン ポスト エフェクトの基礎です。ぼかし、ブルーム、トーン調整、さまざまなフィルターのほぼすべてで、「フレーム全体を手に取って作業する」機能が必要です。この日、エンジンはオフスクリーン レンダリングとフルスクリーン処理のパスを介して接続され、視覚効果のカテゴリ全体への扉を効果的に開きました。もう 1 つはシーンのネストです。シーンに別のシーンを埋め込み、再利用可能なインスタンスとして配置できるようになりました。これは非常に実用的です。「家」や「街灯のセット」を独立した小さなシーンとして作成し、それらを大きなマップ上に繰り返し配置することができ、パーツの山をコピー＆ペーストすることなく、1 つを編集するだけですべてが更新されます。大規模なマルチマテリアルの複雑なシーンの完全な読み込みも同時にサポートされました。どちらもユーザーが直接タップする機能ではありませんが、両方とも「より高度なゲームプレイを可能にする」基礎的なサポートであり、このプラットフォームが将来どれだけ複雑で洗練されたものを作成できるかを決定します。

より復元力の高いプレビュー: クラッシュから単独で回復できます。

この日は、右側のライブ プレビューに「回復力」のレイヤーも追加しました。何らかの理由でプレビューがクラッシュしたりブラックアウトした場合、システムはイベント駆動型でそれを検出し、黒い画面に直面したままにするのではなく、自動的に回復を試みます。アンビエント スカイ ライトもプレビューに正しく配線され、誤警報を減らすために「失速検出」時間のしきい値が調整されました。この種の「問題が発生した場合に自動的に回復できる」回復力は、試行と編集を繰り返し行う作成ツールでは特に重要です。作成は本質的に試行錯誤に満ちており、試行すると必ず問題が発生するエッジケースに遭遇します。あらゆる事故が発生して手動でやり直す必要があると、クリエイティブなフローが何度も中断されてしまいます。ツールに障害から回復する機能を与えると、こうした中断が静かに吸収され、「ものを作る」こと自体にもっと集中できるようになります。

この日が意味するもの

この日のキーワードは「ハードルを下げる」と「基礎を築く」。バーを下げると、次の 2 つの点がわかります。箱から出してすぐの本物の空は、誰の新しいゲームでも一目見ただけで見栄えよく見えます。テキストから 3D への生成により、モデリングのスキルを持たない人でも文からアセットを取得できるようになります。どちらも、「見栄えの良いゲームを構築する」際に必要な専門スキルを軽減します。基礎を築くことは他の場所で示されます。シーン定義の収束による一貫性、エンジンのオフスクリーン レンダリングとネストされたシーンによる可能性、プレビューの自己回復による回復力、これらは天井を決定する目に見えない基礎です。 「誰でもゲームを作れる」ことを心から望むプラットフォームは、その両方を同時に推進する必要があります。誰もがステップアップできるように入り口のステップを十分に平らに削り、本格的な制作の重みに耐えられるほどしっかりとした内部基盤を確立することです。この日は両者の取り組みがシンクロして進んだ。