Yes its scary because only “clever” peoples can start searching for bugs in them and scarer then they found them. And that isn’t hygiene issue. ;D
P.S. I can’t stop laughing reading this topic especial last posts 
So there is difference between “programmer” and “Programmer”… I just know…
TheDailyWTF.com, dedicated to Programmers. I am in no way claiming to be a pro coder here. I just think it’s funny how incompetent some people are when it comes to computer stuff. I’ve gotta admit that I’ve learned a lot just from that site. xD Ahahaha…
You’re right, it is my opinion, nothing more - which is why I wanted to clarify it in my post.
Since the topic is solved I would like to slightly steer off-topic, :D, and explain my reasoing behind my opinion.
-
It looks complicated. The Brick class makes me think of a ‘struct’ from C. I hate structs, personally.
-
It seems the bricks are stored in the level class. The code iterates through every x and y coordinate - checking if there is supposed to be a brick there by calling level.getBrick(). Then checks the type of the brick and with this type asks the ResourceManager what image is supposed to be drawn - Frankly, the procedure confuses me
-
How would you move a brick?
moveBrick(x1, y1, x1, y2)
{
Brick brick = level.getBrick(x,y);
if (brick != null) {
level.setBrick( brick.copy(), x2, y2);
level.removeBrick( brick);
}
// Or something like that
}
- Which confuses me even more :/. Instead of simply
level.getBrick(x1,y1).move(x2,y2);
or something along those lines.
I wasn’t tyring to come off as a douche or a know-it-all - I apologize :(. I was just trying to promote good coding habits. I’m a pretty open minded guy but so far the method you preach seems confusing and convoluted to me. Makes me think of C :P.
I’d gladly hear reasons to why that method is better ( faster? cleaner? simpler? more efficient? ) other than the fact that someone might be used to coding that way and therefore prefers it. I was used to coding in C when I met Java. 
If you hate structs, OOP might not be for you. Just saying.
I’d call your second example far more OO than the first, since it’s comprised solely of high-level messages to objects. It does however require Brick (or at least what level.getBrick returns) to have a reference to its level so that .move knows how to update the level, so it does add some more complexity to Brick than the first approach.
Which method you use, if either, is up to what your needs are. If only Level is responsible for tracking Brick locations, then something like the first approach makes sense (I’m not sure I’d copy). If Bricks know their location and move themselves, the second API is the obvious approach.
Gotta disagree: structs are C and C isnt an OOP language to begin with
Yes, not all structs are objects. But all objects are structs, at least as syntax for fields goes. If you don’t like collecting your data into fields, then … oh forget it, there’s a point I can just say “you know what I meant”
One brick, is a small part of a static landscape. You do not move it. You may destroy it, and you may add to it, but you don’t move it.
If you want to move it, it’s not a brick.
That’s not what I dislike about Structs. Structs are fine in that sense. Structs are just a paint to work with. It’s like an extremely weak version of an object.
[quote]One brick, is a small part of a static landscape. You do not move it. You may destroy it, and you may add to it, but you don’t move it.
If you want to move it, it’s not a brick.
[/quote]
The move() method was just an example. What I’m trying to convey here is that it’s best to have methods that are supposed to alter a state of a specific object is best be defined within that object. . .
And secondly, deciding that the brick is never going to move feels like limiting your options to me - unnecessarily so.
The move() method was just an example. What I’m trying to convey here is that it’s best to have methods that are supposed to alter a state of a specific object is best be defined within that object. . .
And secondly, deciding that the brick is never going to move feels like limiting your options to me - unnecessarily so.
[/quote]
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.
- Is there a brick at ?
- if yes, check what type of brick it is
- with type, ask resource manager what sprite to use
- draw brick.
Instead of something like this:
loop through ArrayList of bricks
- 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.