私の一般的なアドバイス: デフォルトの anchorPoint (0.5f, 0.5f) は、それが何をするのか、それがどのように物事を達成するのに役立つのかをよく理解していない限り、絶対に変更しないでください。それ以外の場合は、position プロパティを変更します。
特にバウンディング ボックスまたは半径ベースの衝突検出を行う場合、アンカー ポイントを変更すると逆効果になります。
長方形のスプライト画像が、テクスチャの中心にあるデフォルトのアンカー ポイントを使用しているとします。
._______.
| |
| |
| * |
| |
| |
°-------°
* は、テクスチャのアンカー ポイントを示します。このスプライトを位置 (250, 100) に配置すると、スプライトの anchorPoint は座標 (250, 100) になります。
anchorPoint を (0.1f, 0.1f) に移動するとします。
._______.
| |
. | . |
| |
| |
| * |
°-------°
° °
スプライトの位置は (250, 100) のままです。anchorPoint の位置も変わりません。変更点は、テクスチャがそのポイントを中心にどのように配置されるかです。フローティング ドットを見ると、アンカー ポイントを変更する前の画像の位置を確認できます。実際には、アンカーポイントを変更することによって行うことは、ノードの位置を基準にしてノードのテクスチャが描画される場所を移動 (オフセット) することだけです。
上記の場合、テクスチャは左下隅がノードの位置の中央に配置されます。スプライト画像の中心をマークするスプライトの位置に頼ることはできなくなりました。ゲーム内のすべてのノードの anchorPoint を任意に変更すると、ノードの視覚的表現とその位置の間に相関関係がなくなります。したがって、ゲームプレイ オブジェクトの anchorPoint を変更するのは不適切な設計です。
さらに、回転またはスケーリングは常に anchorPoint を中心に行われます。anchorPoint を変更すると、ノードの回転またはスケーリング時に望ましくない動作が発生する可能性があります。
奇妙で最悪のケースを想定してみましょう。ただし、アンカー ポイントがテクスチャ内に存在しなくなる完全に可能なシナリオを考えてみましょう。
._______.
| |
| |
| |
* | |
| |
°-------°
つまり、そのスプライトの位置は、実際の画像が表示されている場所の左側にオフセットされています。これにより、衝突チェックの不一致が発生する可能性があります。特に、上記の状況では、半径ベースの衝突チェックが完全に無効になります。これは、開発中に混乱する状況でもあります。
スプライトの位置が、デバッグ描画の助けがなければ見ることさえできない任意のポイントではなく、常にそのテクスチャの中心にあると確信できれば、ゲームの開発ははるかに簡単になります。
問題は残ります:
アンカー ポイントを変更する必要があるのはいつですか?
私は次の状況でのみそうしましたが、他のすべてのシナリオでは避けました。
- アニメーション化されていないテクスチャを画面/ウィンドウの境界線などに揃えるため
- ラベル、ボタン、または画像を右/左/上/下に配置
- ノードの位置を変更せずに、変更されたイメージ (つまり、アーティストの更新) を整列します。
1) 説明しやすい。フルスクリーンの背景画像があるとします。画面全体を覆うようにするには、次の 2 つの方法のいずれかを実行できます。
- 位置を次のように変更します: (画面の幅 / 2、画面の高さ / 2)
- anchorPoint を (0, 0) 別名 CGPointZero に変更します
後者の方がやりやすいと想像できます。背景を動かさないのであれば、それで問題ありません。ただし、スクロールする背景の場合は、アンカーポイントを変更しません。
2) さまざまなボタンと画像を画面の右端に正確に揃えるメニュー システム コールを想定します。すべてのボタンと画像は幅が異なります: つまり、ゲームをプレイ、クレジット、設定、その他のクールなゲーム!
各画像/ボタンの個々の位置を把握する代わりに、anchorPoint を (1.0f, 0.5f) に変更して単純に右揃えにし、画像/ボタンを正確に画面幅 (および変数画面) に配置する方が簡単です高さ): 位置 = (画面幅, 100).
次の画像の位置が (画面の幅、画面の高さ / 2) で、デフォルトの anchorPoint (0.5f, 0.5f) であるとします。画像の右半分が画面領域の外にあることがわかります。
__________.
|
.___|___.
| | |
| | |
| * |
| | |
| | |
°---|---°
|
----------°
(1.0f, 0.5f) の変更された anchorPoint を使用すると、テクスチャの幅に関係なく、画像を右の画面/ウィンドウの境界線に合わせてきれいに右揃えにすることができます。位置は同じままです: (画面の幅、画面の高さ / 2)。
__________.
|
._______.
| |
| |
| *
| |
| |
°-------°
|
----------°
比較のために、アンカーポイントを変更せずにこの画像、メニュー ボタン、またはラベルを右揃えにする場合は、次の式に従って位置を設定する必要があります。
(screen width - contentSize.width * anchorPoint.x, screen height / 2)
式はまだ非常に単純ですが、ノードの contentSize が変更された場合は雑用になります。これはラベルの場合によくあることです。たとえば、スコアは 1 桁から始まり、時間の経過とともに 2、3、4 桁に増加します。このような場合、ノードの contentSize が変更されるたびに位置を再計算する必要がなくなるため、アンカーポイントを変更してノードを右揃えにすることが正当化されます。
3) まれに、アーティストがゲーム オブジェクトの更新されたイメージを提供してくれることがあります。画像サイズが変更されたため、ゲームのグラフィックに自然に収まらなくなりました。一方、オブジェクトの位置は、ゲームプレイのテストを通じて既に十分に確立されているため、ゲームの再テストを避けるために変更しないでください。
このような場合、ゲームプレイに影響を与えることなく、新しい画像が他のグラフィックスとうまく整列するように anchorPoint を微調整することが保証されます。これは安全な土壇場での変更です。本番段階でこれを開始しないでください。そうしないと、プロジェクトの存続期間中、アンカーポイント調整地獄に陥ります。そこに行かないでください!
要約すれば:
ノードを他のノードまたは画面/ウィンドウの境界に合わせやすくする場合、またはゲームプレイに影響を与えずに最終的なアートを微調整する場合にのみ、anchorPoint を変更してください。
それ以外の場合はすべて、位置を排他的に使用してノードを移動します。