完全なバイリンガル UI + 完全な開発ツール パネル
この日は徹底的な国際化が行われました。スタジオのインターフェイス全体がバイリンガルになり、ワンクリックで切り替え可能になり、ウィンドウ間でライブ同期され、エディターも完全にバイリンガルになりました。コンソール / ネットワーク / ログ devtools パネルは空のシェルから実際の機能になりました。 UI のスタッキング、フォームのコントラスト、アクセシビリティのタイトルが整理されました。エンジンの数日間にわたる指向性シャドウのバグがついに修正されました。ゲーム ロジックは宣言型システム スケジューリングを獲得しました。そしてエンジン リソースは規律あるライフサイクルと障害の分離を実現しました。
世界と向き合い、デバッグと向き合う
この日は二つの方向を向いていました。 1 つは外側への取り組みです。インターフェース全体を完全に二言語化することで、中国ユーザーのみにサービスを提供するのではなく、全世界に向けて対応できるようになります。これは、製品をより幅広いユーザーに届けるために必要なステップです。もう 1 つは内部的なものです。開発ツールを完成させて、自分のゲームをデバッグしているクリエイターがコンソール出力、ネットワーク リクエスト、ランタイム ログを明確に確認できるようにすること、つまり「何をしているのかを確認できる」という自信を得ることができます。外見と内面は無関係に見えますが、本質は同じです。どちらも「見えない/理解できない」という障壁を取り除くことです。言語の壁がインターフェースを壁にします。デバッグする方法がないため、問題は霧の中に残ります。この日はその両方の壁を一気に打ち破った。一方、エンジンは複数日にわたるシャドウの問題を根本的に修正し、ゲーム ロジックをスケジュールするためのより秩序ある方法を追加し、独自のリソース管理に対してより厳格なルールを設定しました。外側はより届きやすく、内側はより透明で、その下はよりしっかりしています - これらがこの日の 3 つの側面です。
ワンクリックでインターフェイス全体を英語と中国語に切り替えます
この日は徹底した国際化を丁寧に行いました。ステップ 1 は軽量の多言語コアです。ベースライン ソースとして英語 (すべて英語で正式なコピー)、オーバーレイとして中国語 (存在する場合は英語を置き換えます)、いつでも切り替え可能です。ステップ 2 では、トップ バー、ダッシュボード、チャット パネル、設定ドロワー、サイドバー、さまざまなスイッチャー、多数のパネルとコンポーネントを含め、インターフェース全体をファイルごとにバッチでこのシステムに移行しました。なぜ一度にではなく「ファイルごと」なのでしょうか?なぜなら、ハードコードされたコピーはインターフェイス内の何百、何千ものスポットに散在しており、それぞれを通過するだけで何も見逃さないからです。移行後、インターフェイスはデフォルトで英語になり、システム言語に自動的に従い、さらに思慮深い詳細が追加されました。ライブクロスウィンドウ同期 - 1 つのウィンドウで言語を中国語に切り替えると、開いている別のウィンドウがすぐに続き、それぞれを切り替える必要はありません。エディターも完全なバイリンガル化を完了し、実行時検証に合格しました。世界中のクリエイターに利用してもらいたいプラットフォームのためには、まず言語の壁を取り払う必要があります。そしてこの日、それは完全に取り壊されました。
完成した開発ツール パネル: コンソール + ネットワーク + ディスク上のログ
以前の開発ツール領域には、空のパネルまたはクリックできないプレースホルダーのパネルがありました。この日はそれらを一気に本格的なものに仕上げた。コンソール パネルは、ゲームとエディターの完全な出力ストリームを接続します。ゲームが出力するすべてのログと、ゲームがスローするすべてのエラーがリアルタイムでここに流れます。 [ネットワーク] パネルは死んだプレースホルダーから本物になり、プレイテストされたゲームが行うさまざまなネットワーク リクエスト (通常のリクエスト、非同期リクエスト、長時間存続する接続がすべて表示されます) をキャプチャしました。さらに、コンソール、ネットワーク、情報ストリームはパネルに表示されるだけでなく、後で確認できるようにローカル ログ ファイルにミラーリングされます。問題をライブで把握する必要はありません。後でログから再生できます。同じものを 2 か所に表示する混乱を避けるために、モニタリング ビューで冗長なタブが削除されました。意義:デバッグは制作において避けられない部分であり、デバッグの前提条件は「見える」ことです。ゲームの動作が間違っている場合、完全なコンソール エラーとネットワーク トラフィックをパネルで直接確認できるため、デバッグが「感覚による推測」から「証拠との照合」に変わります。
UI の洗練: スタッキング、コントラスト、アクセシビリティ
この大きな変更を機に、長年の UI の問題がまとめて解決されました。 1 つは積み重ね順序です。以前は一部のダイアログ、ドロップダウン、言語セレクターが誤って上部のバーを覆い尽くしたり、ダイアログの下に隠れたりしていましたが、今回は階層化の順序が明確に再設定されたため、上部にあるべきものがしっかりと上部に留まります。 2 つ目は、フォーム コントロールのコントラストです。以前は、特定のネイティブ入力ボックスとボタンでは、スタイルが設定されておらず、暗い背景ではほとんど読めなかったため、ブラウザのデフォルトの黒いテキストが表示されていました。この日は読みやすいテーマカラーを与えられました。 3 つ目はアクセシビリティです。プロンプト ダイアログには標準で要求されるタイトルが付けられ、アクセシビリティ エラーが排除され、補助リーダーを使用しているユーザーがダイアログの内容を正しく理解できるようになります。これらはそれぞれ小さく、ほとんどの人が特に気付かないほど小さいです。しかし、彼らは協力して 1 つのことを決定します。インターフェイスがどこでも「普通」に感じられるかどうかです。随所にぎこちないインターフェースが継続的かつ微妙にユーザーの忍耐力を消耗させます。一つ一つ滑らかにしていくことで、「どれも使い心地が良い」という確かな感覚が得られます。
指向性シャドウの修正 + 宣言型システム スケジューリング
このエンジンは、数日間悩まされていた問題、つまり指向性ライトの影を根本的に修正しました。ここ数日間サンプル ゲームを構築している間、シャドウを確実にキャストするために「シャドウのカスケード数を 4 から 1 に変更する」という一時しのぎ以外に選択肢はありませんでした。それは症状を回避しただけで、エンジンに実際の病気がありました。この日、それは完全に治りました。特定の構成でカスケード シャドウが失敗する根本原因と、単一レベルでの位置ずれの根本原因がまとめて解決されました。アップストリームの安定版を使用すると、すべてのダウンストリーム ゲームの指向性シャドウが適切に機能し、症状のみの回避策はなくなります。同じ日、ゲーム ロジックには、宣言型システム スケジューリングという貴重な機能が追加されました。ゲームは多くの「システム」(移動、衝突、AI など、それぞれが 1 つの分野に特化したロジック モジュール)で構成されており、その実行タイミングや順序はかつては手作業で調整されていました。条件別、ラベル別、現在の状態別に宣言的にスケジュールできるようになりました。「このシステムのセットを戦闘状態でのみ実行する」「これらのシステムを 1 つのラベルの下でまとめてスケジュールする」などです。これにより、複雑なゲーム動作ロジックをより秩序正しく記述できるようになり、混乱が起こりにくくなります。その下には、グラフィックスのデバッグをよりスムーズにするために、障害分離 (低レベルのクラッシュを自動再試行によって回復可能なエラーに変換する) とオフライン レンダー フレーム ビューアが追加されました。
エンジンはリソースを制御します。完了したら再利用し、壊れてもクラッシュしません。
この日、このエンジンは、長時間実行されるプログラムで最もトラブルが発生しやすい「リソース管理」にも本格的な取り組みを行いました。 1 つは GPU とオーディオ リソースのライフサイクルです。ビデオ メモリのすべてのチャンクとすべてのサウンド チャネルは、何も参照されなくなったときに、静かに積み重なるのではなく、正確に識別され、時間内に再利用されます。この日は特に、「参照されなくなったリソースを解放する」メカニズムを構築し、長時間実行されるストレス テストで、それが膨張するのではなく安定した制限された使用レベルに実際に保持されることを検証しました。もう 1 つの部分は障害の分離です。深刻な低レベルのエラーが発生した場合、エンジンはそれを大規模にクラッシュさせるのではなく、適切に処理可能なエラーに変換し、必要に応じて再試行します。どちらも「長期間安定して動作できるかどうか」に直結する、ユーザーにはまだ見えていない内部の作業です。ゲームは連続して数時間実行され、リソースの作成と破棄が絶えず行われることがあります。 「終わったら戻る、壊れても耐える」をしっかりとさせることによってのみ、長時間プレイでのラグや不可解なクラッシュを避けることができます。
この日が意味するもの
この日のキーワードは「障壁を取り除く」。バイリンガル化により言語の壁が取り除かれ、プラットフォームに初めて世界中のユーザーに対応するための基本的な条件が与えられます。ツールがどこまで機能するかは、まず何人の人がそれを理解し、使用できるかによって決まります。開発ツールを完成させるとデバッグの壁がなくなり、問題が発生したときに作成者がブラック ボックスに悩まされることなく真実を確認できるようになります。エンジンの影を修正すると、「症状の治療」から「根本の治療」までの障壁が取り除かれ、回避するしかなかった再発する病気を根本から解決します。また、宣言的なスケジューリングとリソース管理により、より複雑で長時間実行されるゲームの可能性の壁が取り除かれます。これらの障壁を 1 つずつ取り壊すことで、プラットフォームは同時に到達しやすく、透明性が高まり、信頼性も高まります。広く使用され、長期的に信頼されることを本当に望んでいるツールは、多くの場合、まさにこの単純なことを実行します。つまり、継続的に障壁を見つけては、それを熱心に取り壊すことです。