It is a data structure, and bricks are designed to sit in a grid, forming a landscape. They can only move inside this grid. Think of Minecraft.
... what does this have to do with anything? Every 'map' is a data structure of some kind. Minecraft as an example is horrendous. Sure, you place bricks within a "grid" of sorts, but there's other ways of limiting bricks to 'sit inside a grid'. I haven't directly looked into Minecraft's code but I can't see how it would use your way of representing the bricks. Ie looping through the whole [ x][y][z] plane checking every iteration if there's a brick there, and if there is, look up that bricks specific type, and further now that we know what type it is, ask the resource manager for it's sprite, and only then draw it on the screen.
That's a maximum of 4 actions to draw a brick.
1) Is there a brick at <insert position here>?
2) if yes, check what type of brick it is
3) with type, ask resource manager what sprite to use
4) draw brick.
Instead of something like this:
loop through ArrayList of bricks
1) while (list.hasNext()) list.next().draw(g).
I mean, it's not wrong. Just seems to me you're making it unnecessarily complicated. Feel free to prove me wrong, I just can't see the Pro's in your method - could you clarify?
You are going to check if there is a brick present, or you will have a nullpointer, the way you just presented it.
If the brick is going to draw itself, it will need what to draw.
Either, it will hold the texture itself. This makes large maps very memory consuming. Asking for the texture however, is using much less memory. In my opinion, having each brick holding its own texture is a waste of memory, if they are all the same anyway. Unless they are all unique, asking is less memory consuming.
You could ofcourse have the brick ask itself. In that case, it would be a matter of opinion of where to put the logic.
Since this is a data object only, I choose not to have logic in it. It just helps my productivity to keep logic in one place. If a player hits a brick, should the brick check if the player has hit it, or should the player check if he has hit a brick? In my case, I can just check if the two collided, and notify them.
Ahh, minecraft. See, I'm presenting my map, in a similar way to minecrafts map. I have a grid, that holds bricks. Each brick is defined by its place in this grid. Not in the world. I can remove it on the index, if the player dug it up.
If I want a brick, that can move around freely, I would create an entity that is placed by world coordinates. It will also need collision detection, and update every tick. This is cpu intensive, if every brick should be able to do that.
Also, if they should be sitting in world cordinates, it would take up a lot more memory, in just basic data types.
Imagine 16000 shorts, turning into ints. Maybe even doubles, for small amounts of speed, that doesnt move a pixel a tick.
Also velocities would need to be defined, also in doubles.
Right now, I can have fairly large maps loaded in memory ready to be used, all the time. I dont need to the extra features, and if I do, Ill make a different entiry for it. Minecraft does this, for instance.
I would rather have less loading time, and a little more challenged coding, than a bad user experience and easy programming.