I’m currently working on a breakout style game, however i’ve only thus far hardcoded one level using the following method:
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);
so essentially its placing 7 blocks across the width of the screen and then 6 layers down, making a ‘square of blocks’ however this is far from interesting or engaging for the user, i’d like to be able to one. implement some sort of level progression, should this be done through external files? and how would i go about making sure the items are placed on screen in the right coordinates in relation to screen size/density, and secondly, my main question, how could i go about making certain shapes with the blocks, i.e. a face, without hard coding individual co-ords for every screen??
Sort of one question just two ways of saying it really, sorry if this is too vague?
If you just want the levels to be different, then you could randomly generate them. For each block position, have a random chance that there will be a block there. Never the same level twice (more or less). If you want specific patterns of blocks, like a face, then you’ll have to come up with some way of storing the block layout of a level in a file, and then when the level starts, the game will load the file for the current level, read in the block positions and create them in the correct arrangement. There’s no real way to do it otherwise, unless you fancy coming up with mathematical formulae to describe your level shapes and use those to procedurally generate them.
[EDIT]
As for the co-ordinate issue, you’re right in saying that different devices have different screen resolutions, pixel densities etc. However, this doesn’t necessarily have to affect your game all that much.
A common way around this is to have two co-ordinate sets: “world” co-ordinates, which represent an object’s position within the world of the game, and “screen” co-ordinates, which represent the location at which the object is being drawn. All your physics and game logic code should use world co-ords, which can be any scale you like (I recommend picking a size that’s larger than the pixel dimensions of the largest screen your game will be shown on). The level files I mentioned earlier should of course be in world co-ordinates too. The only time you’re interested in screen co-ordinates is when you’re drawing something to the screen. At that point, you have a small function that maps one co-ordinate set to the other. Usually it’s just a simple scale factor. So, when your game launches, it asks the phone or tablet for its screen resolution, calculates what the scale factor should be for this particular instance, and stores it, and then you just have to look that up when you draw things, and use it to convert. For example, if your game is using a co-ordinate set that’s 10,000 points across, and your game is running on a screen that’s 768 pixels across, the game would calculate the scale factor to be 10,000 / 768 = 13.021ish. Then whenever you draw the ball, you know that its screen x co-ord is its actual x co-ord divided by 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.