Since i like to reinvent the wheel , i’m still working with awt-swing , studying 2d 3d mini-frameworks,toy games and so on (beside : not bad what you can do in pure java https://www.youtube.com/watch?v=ZV4Dsandc6w).
Long story short : looking for a Tetris tutorial , it seems that the mother of all tuts is the one at
zetcode , the other ones are a copy with some minor tweaks.
A part the fact that this is not a tutorial at all (it’s something like this : you enroll for a painting course , the teacher comes in , gives you a copy of the “Gioconda” , says :
<<Hello guys , here is how to paint>> , and suddenly sails to the nearest pub) i understood nearly all with help of a pencil , some paper and caffeine.
However , in my very humble opinion , the code is stacked in a too huge messy Board class .
I’m wrong ?
Thanks in advance for your opinion…and HAPPY 2018 !
The link :
http://zetcode.com/tutorials/javagamestutorial/tetris/
Hi
He wrote his own rasterizer but he made a wrong claim:
[quote]The game is developed with pure java thus it won’t lag on machines with low spec graphic cards.
[/quote]
A software rasterizer can hardly beat OpenGL even on low end graphics cards. You can reinvent the wheels if you want but I advise you to avoid using a wrong excuse to do so unlike the programmer you quote. Just have fun and learn. If you want better performance, use hardware acceleration, OpenGL, Vulkan, …
Good luck with Tetris.
Eh, the whole class is just under 300 lines of code. That’s not insanely large.
But if it feels too large for you, then by all means split it up into multiple classes. Code is a bit of an art: there isn’t just one way to do things. So if it makes sense for you to do things a different way, then do that.
I also recommend taking a step back and breaking the problem down into smaller steps. Instead of going off a tutorial that does it all for you, maybe try working through it on your own. Start by creating a smaller example program that just shows the tetris pieces without any interaction. Then make them fall down. Then make them rotate. Then think about how you’d stack them. Work forward in small steps like that, and if you get stuck on a specific step, it’ll be easier to get help. Good luck.
The number of code lines is not a measure of code quality on its own, of course. Long classes/methods (generally “unit of code”) only increase the likeliness of that code having multiple responsibilities and therefore multiple reasons to change. Mixing multiple responsibilities in the same unit of code in turn increases the probability of breaking the implementation of one responsibility when modifying another. So, it increases the “fragility” of the design (i.e. modifying one thing breaks another thing).
One could argue that the Board class has two responsibilities: One is the game logic (moving pieces around the board). The other is drawing, which is intertwined everywhere. So, as a consequence, when changing how the board is rendered (like even moving to a different rendering technology such as JavaFX), you would have to go over every method and rip out the UI/rendering aspect and hopefully not break anything of the game logic while doing so.
Therefore, yes, that Board class has a bad design because it combines multiple responsibilities. However, the fitness of a design can only be measured when knowing the requirements and assessing how the requirements are satisfied by the design. If there will never be a reason to change the rendering/UI responsibility, there is no problem.
I encourage you to read up on the S.O.L.I.D. principles. I tried to focus on the ‘S’ here.
When I made tetris, I was ALOT sloppier.
Although, I was using c++ with directX, looking back it was just absurd, the logic was ultimately similar but i think i was in the thousands of lines of code.
At a certain point, it seems nit picking to try and make something more effective, tetris should be a learning project, not a doctorate.