libgdxでアクターを使用するのはいつですか？短所と長所は何ですか？
私は簡単な太陽系シミュレーターを書いています。これは私の最初のlibgdxプロジェクトです。メインメニューにステージとアクターを使用しており、特にタッチイベントの処理に非常に便利です。しかし...例を見ると、実際のゲームロジックでアクターを使用している人は誰もいないことがわかります。アクターを惑星クラスの親として使用するか、それとも自分のクラスを作成するかを迷います。惑星はタッチ可能ではなく、フレーム間でのみ移動するため、アクションMoveByの3番目のパラメーターはフレーム間の時間である必要があります。それが短所です。アクターを使用することの長所は何ですか？
アクターの主な長所は、アクション、ヒットテストとタッチイベント、およびアクターのグループです。
ゲームロジックで必要な場合、アクションを使用すると、すばやく簡単にトゥイーンできます。
いつでもstage.hit（x、y）を呼び出して、作成したヒットロジックにtrueを返す最初のアクターを返すことができます（通常、x、y、width、heightで境界をチェックします）。このアクターまたはnullを返すと、ヒットアクターを探してアクターのヒットメソッドを繰り返し処理し続けます。アクターがヒットしなかった場合、Nullが返されます。
ヒットはステージのタッチイベントに使用されます。アクターのタッチメソッドにはローカル座標が渡され、ステージはオブジェクトのオーバーラップを処理します。アクターが別のアクターをカバーしていて、他のアクターがtouchDownを受け取らないようにする場合は、カバーしているアクターでtrueを返し、「下」のアクターに対するtouchDownの呼び出しを停止します。これにより、trueを返すアクターに「フォーカス」が設定され、アクターのtouchUpが呼び出されます。
アクターをグループ化して、アクターのグループ全体に対してアクションやタッチイベントなどを1つのユニットとして実行できます。
いくつかの短所：アクターには、機能をいくらか制限するステージが必要です。多くのコーダーは、scene2dアクション（box2dなど）ではなく、他のロジックを使用してゲームオブジェクトの状態を決定します。ゲームオブジェクトにアクターを使用する場合、おそらくui用とゲームワールド用の2つのステージが必要になります。それらを使用しない場合でも、おそらく独自のSpriteBatchとCameraを使用することになります。また、アクターには抽象的なDrawメソッドしかないため、とにかく描画ロジックを作成する必要があることに注意してください。おそらく、アクターのプライベートフィールドとしてTextureRegionまたはSpriteを保持します。独自の更新ロジックを使用する場合は、act（float delta）メソッドをオーバーライドして、デルタ時間を取得できます（アクションを使用する場合は、super.act（delta）を呼び出します）。
したがって、独自のロジックがあり、Stageが提供するものの多くを使用しない場合は、リソースを節約して、独自のアプリケーション固有のソリューションを展開してください。必要な機能を制限せずにいくつかのプロを使用できる場合は、ゲームロジックの第2段階に進んでください。