コアエディタパネルの登場 + Windows サポート

「骨格」から「肉体」へ: 編集者が記入を開始します

前の 2 日間で、ドッキング可能なパネル システム、変換ツール、元に戻す/やり直しといったエディターの「スケルトン」が確立されました。しかし、骸骨だけでは仕事をすることはできません。実際に座ってゲームを構築できるのは、そのスケルトンに掛けられたフィーチャー パネルです。この日の作業は、まさにその骨格に肉付けすることです。ゲーム エディターに不可欠な 3 つのコア パネルを一度に埋めていくことで、最も基本的な編集フロー (「オブジェクトの表示、選択、プロパティの変更、アセットの取り込み」) が初めてエンドツーエンドで実行されます。一方、このエンジンは 2 つの方向に拡張しました。2D ゲームプレイのタイル マップ カテゴリ全体のレンダリング基盤を追加し、Windows の互換性問題のバッチを修正して、より多くの人が実行できるようにしました。インポートされたモデルが実際にサンプル ゲームに接続され、バックエンドが障害時に適切にデグレードされることから、この日のテーマは明確です。それは、数日間にわたって構築されたフレームワークを、スポットごとに真に使用可能なものに埋め込むことです。

主要なエディターのトリオ: 階層 / インスペクター / アセット

この日、編集者はゲーム編集の最も重要な 3 つのパネルに記入しましたが、それぞれが独自の領域を考慮しており、必須のものはありませんでした。階層パネル: シーン内のすべてのオブジェクトを親子関係によってツリーに配置し、誰が誰の子であるかを一目で明らかにします。クリックして選択します。これは、シーン内の「オブジェクトを見つけて構造を把握する」場所です。インスペクターパネル: オブジェクトを選択すると、そのすべてのプロパティが右側に表示されます。位置、回転、マテリアル、あらゆる種類のパラメーターが直接編集可能です。ここで「1 つのことを調整」します。 [アセット]パネル: プロジェクトのすべてのマテリアル (モデル、テクスチャ、シーン パックなど) を参照して取り込み、必要なものをドラッグします。ここで「マテリアルをフェッチ」します。これら 3 つは、すべてのゲーム開発者が 1 日に何百、何千回も繰り返す中心的なフローを形成します。「すべてのオブジェクトを表示 → 1 つ選択 → パラメーターを変更 → アセットから何かをドラッグ」 — 最終的に Studio で完成します。これらが「トリオ」であるのは、編集の本質が「全体的な視点、単一オブジェクトの詳細、素材のソース」の間を際限なく行き来しているためです。この 3 つがすべて揃って初めて、編集者は真に仕事ができるようになります。

エンジンは 2D タイルマップ レンダリングを獲得します

このエンジンは、今日のゲームプレイのカテゴリ全体、つまり 2D タイルマップ レンダリングの基礎を築きました。タイル マップは古典的な 2D ゲームのアプローチです。世界を正方形のセルのグリッドに切り取り、各セルに小さな絵 (「タイル」) を配置し、それらを組み立てて全体のマップを作成します。草、壁、川、道路はすべてこれらの小さな正方形から舗装されています。古典的な横スクロール、トップダウン、ピクセルアート ゲームのほぼすべてがこの上に構築されています。この日、エンジンはタイル マップとタイル レイヤーの基本コンポーネントを導入し、一般的なタイル マップ ファイル形式を読み取ることができました。つまり、専用のマップ ツールで描画したレベルを、手動ですべてのセルを再配置することなく、エンジンに直接読み込んでレンダリングできることを意味します。重要性: これはプラットフォームの範囲を、これまで 3D 寄りだったシーンから 2D の広大な領域に正式に拡張します。多くのクリエイターが作りたい最初のゲームはまさに 2D ゲームであり、この道が開かれることで、大勢の 2D クリエイターに扉が開かれます。

Windows との互換性: より多くのマシンで適切に動作します

この日は、Windows の互換性に関する一連の問題に焦点を当てました。クロスプラットフォーム ソフトウェアの最も一般的かつ最も潜行的な落とし穴は、多くの場合、機能自体にあるのではなく、システム間の微妙な規約の違いにあります。オペレーティング システムが異なれば、使用するテキストの行末が異なり、ファイル パスの区切り文字が異なり、ワイルドカード ファイルの一致の動作が異なります。そして、どれかが一致していないと、あるシステムで正常に動作したコードが別のシステムでは不可解なエラーが発生します。この日は、これらの違いによって引き起こされる一連の障害を 1 つずつ修正し、テキストの行末規則を統一して、すべてのファイルがプラットフォーム間で一貫して動作するようにしました。 Windows ユーザーにとって、これは、OS の違いに悩まされることなく、開発環境とテストが自分のマシン上で適切に実行されることを意味します。ツールをできるだけ多くの人に使ってもらうためには、クロスプラットフォームのサポートは避けられない基礎工事です。クロスプラットフォームのサポートは新しい機能を追加するものではありませんが、「玄関にさえ入れない」人の数を直接決定します。この互換性を強化することで、より広範なユーザー ベースに対する最初の障害がクリアされます。

「インポートされたモデル」を実際のゲーム + より堅牢なバックエンドに接続する

前日は「モデルをドラッグするとシーンになる」機能をオープンしました。この日は、実際の例を使用してそれを実行しました。「モデルのインポート → プレイアブル シーンの組み立て」パスの実世界の例として、完全なシーン モデルがシューティング サンプルに組み込まれました。新しい機能は単に実行するだけでは十分ではありません。実際のエンドツーエンド フローで機能することを検証するには、実際の使用例が必要です。このサンプルはまさにそれを行います。また、バックエンドは予期せぬ事態に対しても優れた耐性を備えています。依存しているサブサービスがまだ起動していない場合、関連するリクエストは、インターフェイス全体をダウンさせる一般的なサーバー エラーの山をスローするのではなく、明確な「一時的に利用不可」ステータスに正常に低下するようになりました。この「正常な機能低下」は堅牢なシステムの特徴です。1 つのコンポーネントがダウンしてもシステム全体が麻痺することはありません。 「この部分は現在利用できません」と明確に表示し、残りを実行する必要があります。以前のバイナリ アセット アップロード チャネルと組み合わせることで、外部マテリアルの取り込みと実際のゲームでの使用の完全なチェーンがこの日より完全なものになりました。

この日が意味するもの

この日は、天地を揺るがすような画期的な出来事はひとつもありませんでしたが、製品が「フレームワークから実用性へ移行する」プロセスをうまく表しています。編集者トリオの登場は、Studio のビジュアル編集が初めて「実証可能な」レベルから「実際に座って作業できる」レベルに到達したことを意味します。 2D タイル マップの追加により、プラットフォームの領域が 3D から 2D に拡張され、古典的な 2D ゲームを作りたい大勢のクリエイターが集まりました。また、Windows 互換性修正プログラムは、より多くの潜在的なユーザーの参入障壁を事前にクリアします。総合すると、これら 3 つは同じ方向を向いています。つまり、より多くの人が、より多くの方法で、より多くのデバイスでこのプラットフォームを真に利用できるようになります。ツールの成熟とは、決して目まぐるしい機能が誕生することではなく、このような「カバー範囲」や「使いやすさ」が日々確実に広がっていくことです。