私たちの現状と今後の方向性について説明します。ここでは、私たちのスタックのこのレベルを「ゲームエンジンのエンジン」と呼びたいと思います。このスタックを使えば、誰でもゲームエンジンを作成することができます。私たちには作成できる能力があり、その意思があります。読者の皆さんも同じです。私たちのゲームエンジンに不満がある場合は、自作したり、好みに合わせて変更したりしてください。コンポーネントシステム私たちが次に作ろうとしているレイヤーは、新しいコンポーネントシステムです。中心には常に、コンポーネントの概念があります。コンポーネントをゲームオブジェクトに追加すると、ゲームオブジェクトは落下するようになります。コンポーネントをゲームオブジェクトに追加すると、光を放出するようになります。コンポーネントをゲームオブジェクトに追加すると、音を出すようになります。簡単に作ることができます。この発想は、非常に驚くべきことにとてもよく成熟しています。その成熟度合いは、そのまま利用し続けたいほどです。コンポーネントシステムの実装方法はそれほど成熟していません。コンポーネントシステムは、オブジェクト指向の考え方で開発されました。C++」オブジェクトです。グローバルリストを変更するために、ミューテックスロックが必要となります。すべてのゲームオブジェクトには名前があります。ラッパーオブジェクトを取得します。オブジェクトは、メモリ内であればどこでも存在する可能性があります。オブジェクトもメモリ内であればどこでも存在する可能性があります。キャッシュミスがたくさん発生します。私たちはこのような症状をできる限り軽減しようと試みていますが、一方で、開発者にできることは限られています。データ指向の考え方をすると、もっとよい対応ができます。コンポーネントを追加すると物が落下する)、素晴らしいパフォーマンスと並列処理も実現します。System(ECS)です。非常に大まかに言うと、現在ゲームオブジェクトを使って行っていることを、新しいシステムではエンティティを使用して行います。コンポーネントは引き続きコンポーネントと呼びます。何が違うのでしょうか。データのレイアウトです。従来の方法を使って一般的なコンポーネントを記述すると、以下のようになるでしょう。//この演算は半端なので無視してください。Update(){//この演算は半端なので無視してください。SomehowSteerTowards(currentPos,targetPos)}}このパターンは繰り返し使われます。以上検索し、そのコンポーネントの値の読み取り/書き込みを行わければなりません。このコードには多くの誤りがあります。コンポーネントに対して呼び出されます。別のコンポーネントに対して呼び出される場合があります。コンポーネントに対してこのフレームが実行される可能性があります。コンポーネントに留意する必要があります)。操作中の他のコンポーネントがメモリ内のまったく別の場所にあります。使用するデータレイアウトでは、これが非常によく見られるパターンであることを認識し、メモリのレイアウトを最適化してこのような操作を高速化します。同じ一連のコンポーネントをメモリ内に集めたエンティティすべてをグループ化します。そのようなセットをアーキタイプと呼びます。Collider」です。チャンク単位で行われます。各チャンクに含まれるのは、単一のアーキタイプのエンティティのコンポーネントデータだけです。インスタンスごとに次のように静的に宣言すればかまいません。コンポーネントを持つすべてのエンティティに対して、ある操作を実行したい」と。そのようなエンティティを見つけるには、特定の「コンポーネント検索クエリ」に一致するすべてのアーキタイプを検出するだけです。各アーキタイプには、そのアーキタイプのエンティティが格納されているチャンクのリストがあります。そのチャンクをすべてループ処理し、各チャンク内で密度の高いメモリに対して線形ループを実行して、コンポーネントデータの読み取りと書き込みを行います。ベクトル化を行う格好の対象にもなります。近いコア使用率で実行されます。よって行われるため、開発者が行う必要があるのは、各エンティティで実行するコードの指定だけです(必要に応じて、チャンクの反復処理を手動で行うこともできます)。エンティティでコンポーネントを追加/削除したりすると、アーキタイプが切り替わります。該当するコンポーネントを現在のチャンクから新しいアーキタイプのチャンクに移動し、前のチャンクの最後のエンティティをもう一度スワップして「穴埋め」します。ReadWrite)。ジョブをより効率的にスケジュールできます。コンポーネントから読み取りを行う他のジョブも、待機しなくてよくなります。このデータレイアウトによって、長年にわたって不満であった、ロード時間とシリアル化パフォーマンスに関しても対処できるようになります。バイトをロードしてそのまま使用するのとほとんど違いがありません。『Megacity』デモがスマートフォンに数秒でロードされるのはこのためです。うれしい「アクシデント」エンティティでは、現在ゲームオブジェクトで行える処理と同じ処理が可能です。エンティティは軽量なので、ゲームオブジェクトよりもできることが広がります。実際のところ、エンティティとは何なのでしょうか。このブログ記事のドラフトでは当初、「エンティティはチャンクに格納されます」と説明していましたが、後から「エンティティのコンポーネントデータはチャンクに格納されます」に変更しました。ビットの整数であることをはっきりさせるうえで、重要な違いです。エンティティに関して、そのコンポーネントのデータ以外に格納したり、割り当てたりするものはありません。エンティティは非常に負荷が軽いので、ゲームオブジェクトが適していなかったシナリオに利用することができます。パーティクルシステムの個々のパーティクルにエンティティを使用するようなシナリオです。HPC#、Burst、ECS。素晴らしいが、ゲームエンジンはどこに?次に構築する必要があるレイヤーは、非常に巨大です。ネットワーク」、「入力」、「アニメーション」などの機能で構成されます。言えば、これが私たちの現状です。それら構成要素に取り組み始めていますが、それらを一晩で準備できるわけはありません。残念に思われるかもしれません。ある意味ではそのとおりですが、別の意味では違います。内で実行することができます。コンポーネントを記述することができます。メッシュ描画システムはありません。記述することができます。『Megacity』デモでは、まさにこの手法を利用しています。処理/アニメーションは行われますが、最終的な描画は行われません。そこで、うまく組み合わせることで対処できます。パフォーマンスのメリットをすぐに享受できることです。つの異なる世界を繋ぎ合わせて使用している」というちぐはぐさを感じる可能性があります。サブシステムのソースコードすべてをパッケージに含めて配布する予定です。これにより、各サブシステムを調査、デバッグ、変更できるほか、どのサブシステムをいつアップグレードするかをより詳細に制御できます。サブシステムパッケージだけをアップグレードして、他のサブシステムはアップグレードしないようにできます。ゲームオブジェクトの今後ゲームオブジェクトはなくなりません。ゲームオブジェクトを利用して、今後もずっと素晴らしいゲームを配布することができます。その基本事項はどこにも行きません。改善のためにエネルギーを注ぐ先です。世界だけにエネルギーが注がれるようになります。ついて説明するときによく指摘される、文句を言いたいのも当然な点は、タイピングする量が非常に多いことです。開発者が、達成しようとしている目的を果たすには、さまざまな定型コードを入力する必要があります。ほとんどの定型コードを不要にしたり、開発者が意図を表現しやすくしたりするために、多数の改善が行われる予定です。私たちが現在注力している対象は基本的なパフォーマンスであるため、予定されている改善の多くはまだ実装していません。記述するよりもかなり多くの手間がかかったりしてよい理由はないと考えています。それについて紹介しましょう。ベースにして配布されます。大きなマイルストーンとなります。専用の環境で実行できる。新しいプレイヤーは過去の環境から何の影響も受けません。サブシステムすべてを搭載する必要があることを意味する。編集に導入する予定である。スタックに関するさまざまな職務で人材を募集しています。バーバンクとコペンハーゲンのオフィスで勤務できる方の応募をお待ちしています。フォーラムにもぜひ参加して、実験的機能やプレビュー機能に関するフィードバックをお寄せください。フォーラムでは、そのような機能に関する情報を入手することもできます。ニュースを受信し始めるには、あなたのメールアカウントにお送りしたリンクをクリックしてください。おっと...何らかの支障がありました。一度やり直してください。PolicyCookies。