0

私は現在、ブレイクアウト スタイルのゲームに取り組んでいますが、これまでのところ、次の方法を使用して 1 つのレベルをハードコーディングしただけです。

for (int i = 0; i < 6; i++) {
            for (int j = 0; j < 7; j++) {
                int y_coordinate = (i * (blockHeight + spacing)) + topOffset;
                int x_coordinate = j * (blockWidth + spacing);

基本的に、画面の幅全体に7つのブロックを配置し、次に6つのレイヤーを下に配置して、「ブロックの正方形」を作成しますが、これはユーザーにとって興味深いものでも魅力的なものでもありません。ある種のレベル進行を実装しますが、これは外部ファイルを介して行う必要がありますか? そして、アイテムが画面のサイズ/密度に関連して正しい座標で画面に配置されるようにするにはどうすればよいでしょうか。次に、私の主な質問は、ブロックを使用して特定の形状、つまり顔を作成する方法です。すべての画面の個々の座標をハードコーディング??

1 つの質問に 2 つの言い方がありますが、あいまいすぎて申し訳ありません。

4

1 に答える 1

1

レベルを変えたいだけなら、ランダムに生成できます。ブロックの位置ごとに、そこにブロックが存在する可能性がランダムにあります。同じレベルが 2 回 (多かれ少なかれ) になることはありません。顔のようなブロックの特定のパターンが必要な場合は、レベルのブロック レイアウトをファイルに保存する何らかの方法を考え出す必要があります。その後、レベルが開始すると、ゲームはそのファイルをロードします。現在のレベル、ブロックの位置を読み取り、正しい配置でそれらを作成します。レベル シェイプを記述するための数式を思いつき、それを使用してプロシージャルに生成しない限り、それ以外の方法は実際にはありません。

[編集] 座標の問題に関しては、デバイスが異なれば画面解像度やピクセル密度などが異なるというのは正しいことです。しかし、これは必ずしもゲームにそれほど影響を与える必要はありません。

これを回避する一般的な方法は、ゲームの世界内のオブジェクトの位置を表す「ワールド」座標と、オブジェクトが存在する場所を表す「スクリーン」座標の 2 つの座標セットを使用することです。描かれています。すべての物理およびゲーム ロジック コードは、任意の縮尺でよいワールド座標を使用する必要があります (ゲームが表示される最大の画面のピクセル寸法よりも大きいサイズを選択することをお勧めします)。前述のレベル ファイルも、もちろんワールド座標にある必要があります。画面座標に関心があるのは、画面に何かを描いているときだけです。その時点で、ある座標セットを別の座標セットにマップする小さな関数ができました。通常は単純な倍率です。そのため、ゲームの起動時に、携帯電話やタブレットに画面の解像度を尋ね、この特定のインスタンスに必要な倍率を計算して保存します。描画するときにそれを調べて、それを使用して変換するだけです。たとえば、ゲームが 10,000 ポイントの座標セットを使用していて、ゲームが 768 ピクセルの画面で実行されている場合、ゲームは倍率を 10,000 / 768 = 13.021ish と計算します。次に、ボールを描くたびに、そのスクリーン x 座標が実際の x 座標を 13.021ish で割ったものであることがわかります。ゲームが 768 ピクセルの画面で実行されている場合、ゲームは倍率を 10,000 / 768 = 13.021ish と計算します。次に、ボールを描くたびに、そのスクリーン x 座標が実際の x 座標を 13.021ish で割ったものであることがわかります。ゲームが 768 ピクセルの画面で実行されている場合、ゲームは倍率を 10,000 / 768 = 13.021ish と計算します。次に、ボールを描くたびに、そのスクリーン x 座標が実際の x 座標を 13.021ish で割ったものであることがわかります。

Not only does this make your game independent of screen size, it also means you can work with more accurate positions internally, allowing for more accurate behaviour (collision detection etc). As long as your internal "world" co-ordinate set is bigger than the number of pixels on your screen, but not so big that it requires huge amounts of memory (if you have to store data about each position) or processing power (if you're doing continuous collision detection over many positions per loop) then it'll work fine. For an Android game, taking into account the power of the average Android device and the kind of screens they tend to have, I'd say you should be fine with a "world" co-ordinate set of two or three thousand points across. The only thing you have to decide then is what to do when the proprotions don't match - for example, your game has a grid with side lengths in a ratio of 4:3, and it's being played on a phone with a 16:9 screen. You can either cut the edges off (and remember to add a barrier there so that the ball doesn't go off-screen) or just distort it to match (which doesn't work with some things but might well be unnoticeable in a Breakout-style game). Maybe try both and see which you like best.

于 2013-01-18T14:51:58.240 に答える