Library)を使わないのですかなぜGodotは例外処理を使わないのですか?GodotがRTTI(実行時型情報)を強制しないのはなぜですか?GodotがユーザーにDoD(データ指向設計)の実装を強制しないのはなぜですか?Godotの開発をサポートしたり、貢献したりするにはどうすればいいですか?誰がGodotで働いていますか。以下では、Godotの高レベルネットワークと低レベルネットワークの違いといくつかの基本事項について説明します。スキップしてください。後で残りも読んでください!Godotは、UDP、TCP、およびSSLやHTTPなどの一部の高レベルプロトコルを介した標準の低レベルネットワークを常にサポートしてきました。これらのプロトコルは柔軟性があり、ほとんどすべてに使用できます。ゲームの状態を手動で同期するためにそれらを使用すると、多大な作業が必要になる場合があります。バックエンドでカスタムサーバー実装を使用する場合など、その作業を回避できない場合や、そうするほうが価値がある場合があります。ほとんどの場合、使いやすさを高めるために低レベルネットワークのきめ細かな制御の一部を犠牲にしてでも、Godotの高レベルネットワークAPIを検討する価値があります。これは、低レベルプロトコルの固有の制限によるものです:TCPは、パケットが常に確実に順序どおりに到着することを保証しますが、一般に、エラー修正のために待ち時間が長くなります。手順に「接続(connection)」を必要とし、マルチプレイヤーゲームのようなアプリケーションには向かない目的に合わせて最適化されているので、非常に複雑なプロトコルでもあります。パケットはより大きなバッチで送信されるようにバッファリングされ、パケットごとのオーバーヘッドが少なくなり、待ち時間が長くなります。これはHTTPのようなものには便利ですが、一般的にはゲームには役立ちません。この一部は、(例えば、TCP接続の「Nagleのアルゴリズム」を無効にすることによって)設定および無効にすることができます。UDPはより単純なプロトコルであり、パケットのみを送信します(「接続」の概念はありません)。エラー修正を行わないので処理がかなり速くなりますが(低遅延)、パケットは途中で失われたり、間違った順序で受信されたりする可能性があります。それに加えて、UDPのMTU(最大パケットサイズ)は一般的に小さい(数百バイトのみ)ため、大きなパケットを送信することは、パケットを分割し、再編成し、一部が失敗した場合に再試行することを意味します。一般に、TCPは信頼性が高く、順序があり、低速であると考えることができます。それに対し、UDPは信頼性がなく、順序がなく、高速であるといえます。パフォーマンスが大きく異なるため、多くの場合、ゲームに必要なTCPの部分(オプションの信頼性とパケット順序)を再構築し、不要な部分(輻輳/トラフィック制御機能、Nagleのアルゴリズムなど)を回避することは理にかなっています。このため、ほとんどのゲームエンジンにはこのような実装が付属しており、Godotも例外ではありません。<class_SceneTree>`に基づいた高レベルAPIを使用するかです。これは、一般的に最適化された方法で、シーンの後ろで重い処理を引き受けます。注釈Godotがサポートするプラットフォームのほとんどは、言及された高レベルおよび低レベルのネットワーク機能のすべてまたはほとんどを提供します。ネットワークは常にハードウェアとオペレーティングシステムに大きく依存しているため、一部のターゲットプラットフォームでは一部の機能が変更されたり利用できない場合があります。顕著ものとしてHTML5プラットフォームは、現在、WebSocketサポートのみを提供しており、TCPやUDPのような低レベルのプロトコルへの未加工のアクセスだけでなく、より高いレベルの機能の一部も欠いています。Gamesには、ゲームのネットワーキングに関する多くの有用な記事があります(ここ)。<https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/>`__。https://github.com/PerduGames/gdnet3警告ゲームにネットワークを追加するには、ある程度の責任が伴います。間違って実行すると、アプリケーションが脆弱になり、チートや悪用につながる可能性があります。攻撃者がアプリケーションを実行しているマシンを危険にさらし、サーバーを使用してスパムを送信したり、他のユーザーを攻撃したり、ユーザーがゲームをプレイしている場合にユーザーデータを盗んだりすることもできます。これは、ネットワーキングが関係する場合に常に当てはまり、Godotとは関係ありません。実験はできますが、ネットワークアプリケーションをリリースするときは、考えられるセキュリティ上の問題に常に注意してください。中レベルの抽象化¶ネットワークを介してゲームを同期する方法に入る前に、同期のための基本のネットワークAPIがどのように機能するかを理解しておくと役立ちます。拡張されるため、データのシリアル化、送信、受信に役立つすべてのメソッドを継承します。ピア、転送モードなどを設定するメソッドを追加します。ピアが接続または切断したときに通知する信号も含まれています。このクラスインターフェイスは、ほとんどの種類のネットワーク層、トポロジ、およびライブラリを抽象化できます。デフォルトでは、GodotはENet(NetworkedMultiplayerEnet)に基づいた実装を提供しますが、これを使用してモバイルAPI(アドホックWiFi、Bluetooth用)またはカスタムデバイス/コンソール固有のネットワークAPIを実装できます。ほとんどの場合、Godotはさらに高度なネットワーク機能を提供するため、このオブジェクトを直接使用することはお勧めしません。それでも、ゲームに低レベルAPIの特定のニーズがある場合に利用できます。高レベルのネットワークを初期化するには、SceneTreeにNetworkedMultiplayerPeerオブジェクトを提供する必要があります。そのオブジェクトを作成するには、最初にサーバーまたはクライアントとして初期化する必要があります。ピアを取得します:get_tree().get_network_peer()ツリーがサーバーまたはクライアントとして初期化されているかどうかを確認します:get_tree().is_network_server()ネットワーク機能の終了:get_tree().set_network_peer(null)(ゲームによっては、接続を閉じたりタイムアウトしたりするのではなく、他のピアに自分が離れることを知らせるために、最初にメッセージを送信することは理にかなっています。)接続の管理¶いつでも接続を受け入れるゲームもあれば、ロビーの段階で接続するゲームもあります。関連メソッドを参照)。id)上記のシグナルは、新しいピアが接続または切断したときに、サーバーに接続されているすべてのピア(サーバー上を含む)で呼び出されます。1は常にサーバーです。1未満は無効として処理されます。これらのIDは、主にロビー管理に役立ち、接続されたピア、つまりプレイヤーを識別するため、通常は保存する必要があります。IDを使用して、特定のピアにのみメッセージを送信することもできます。クライアント:connected_to_serverconnection_failedserver_disconnected繰り返しますが、これらの機能はすべて、主にロビー管理やその場でのプレイヤーの追加/削除に役立ちます。これらのタスクの場合、サーバーは明らかにサーバーとして機能する必要があり、既に接続されている他のプレイヤーに、新しく接続されたプレイヤーに関する情報(名前、統計など)を送信するなどのタスクを手動で実行する必要があります。ロビーは任意の方法で実装できますが、最も一般的な方法は、すべてのピアのシーンで同じ名前のノードを使用することです。一般的に、自動ロードされたノード/シングルトンはこれに最適で、常にアクセスできます。"/root/lobby"。RPC¶ピア間で通信するための最も簡単な方法は、RPC(リモートプロシージャコール)を使用することです。関数呼び出しは何があっても到着しますが、失敗した場合は再送信されるため、時間がかかる場合があります。関数呼び出しが到着しない場合、再送信されません。それが到着した場合、すぐにそれを実行します。ほとんどの場合、信頼性が求められます。Unreliableは、オブジェクトの位置を同期するときに主に役立ちます(同期は絶えず発生する必要があり、パケットが失われた場合でも、その後に新しいパケットが到着し、その間にオブジェクトがさらに移動したために、失われたパケットの情報は古くなっている可能性があるため、無くなってもさほど問題はありません。これは再送と同じ結果です)。関数があり、これを使用してRPCを送信したピア(またはピアID)を確認できます。ロビーに戻る¶ロビーに戻りましょう。サーバーに接続する各プレイヤーが、そのことを全員に伝えることを想像してみてください。register_player(info):このキーワードには主に2つの用途があります。1つ目は、この関数をRPCから呼び出すことができることをGodotに知らせることです。キーワードが追加されていない場合、Godotはセキュリティのために関数を呼び出す試みをブロックします。これにより、セキュリティが非常に簡単になります(したがって、クライアントは別のクライアントのシステム上のファイルを削除する関数を呼び出すことができません)。2番目の用途は、RPCを介して関数を呼び出す方法を指定することです。呼び出しがネットワークを経由してリモートで実行されることを意味します。呼び出しがネットワーク経由でリモートで実行されることを意味しますが、ローカルでも実行されます(通常の関数呼び出しを行います)。その他については、さらに下で説明します。RPC呼び出しを行ったかを確認することもできます。これにより、ロビー管理について多少説明する必要があります。ゲームを開始したら、セキュリティを追加して、クライアントがおかしなことをしないようにします(時々、またはゲーム開始前に送信する情報を検証します)。話を簡単にするため、また各ゲームは異なる情報を共有するため、ここでは具体例を示していません。十分な数のプレイヤーがロビーに集まったら、サーバーはおそらくゲームを開始するはずです。これ自体は特別なことではありませんが、この時点であなたの人生をもっと楽にするためにできるいくつかの素晴らしいトリックを説明します。プレイヤーシーン¶ほとんどのゲームでは、各プレイヤーが独自のシーンを持っているでしょう。インスタンス化する必要があることに注意してください。4プレイヤーゲームの場合、各ピアは4プレイヤーノードをインスタンス化する必要があります。Godotでは、ノードに一意の名前を付ける必要があります。プレイヤーがどのノードを各プレイヤーIDを表すかを比較的簡単に判断できる必要があります。いう名前を付けるだけです。呼び出しを変更する必要がある場合があります。ゲームの開始を同期する¶プレイヤーのセットアップには、遅延、ハードウェアの違い、またはその他の理由により、ピアごとに異なる時間がかかる場合があります。now!ゲームの同期¶ほとんどのゲームでは、マルチプレイヤーネットワーキングの目標は、ゲームをプレイするすべてのピアで同期して実行することです。RPCとリモートメンバー変数セットの実装を提供することに加えて、Godotはネットワークマスターの概念を追加します。ネットワークマスター¶ノードのネットワークマスターは、そのノードに対する最終的な権限を持つピアです。したがって、サーバーにはデフォルトですべてのノードに対する権限があります。ネットワークマスターは同様にノードのすべての子ノードに再帰的に設定されます)。Scriptの同等のもの)で使用する場合です。too.上記の例では、爆弾がどこかで爆発します(おそらく、マスターである人によって管理されます)。関数を含んでいることをチェックします。キーワードがあります。これは、そのインスタンスのマスターであるプレイヤーのみが実際に関数を取得することを意味します。メソッドを呼び出し、puppetとして設定されているインスタンスのみを呼び出して、すべてのピアでプレイヤーをびっくりさせます(および現在のマスターも)。メッセージを送信することもできます。これは、爆弾のような影響範囲の場合にはあまり意味をなさないかもしれませんが、他の場合では、単一のターゲットにダメージを与えるなどに使えます。