If you want to see Java code redundancy, then imagine how our each class would look if you couldn't write the "extend" clause. Every "Object" has the exact same functions... pretty redundant if you ask me.
Then you would even more build an architecture from object composition instead of inheritance.
Can't see the relation to redundancy here, maybe I just don't get what you mean.
Do I follow it? No way. Once you leave the confines of the classroom you realize that always following convention results in ridiculously slow code and Java Heap Space errors.
I don't know any convention leading to heap space errors or generally slow code.
When I started with Java, I think it was on Java 1.4. I thought the class structure was awesome and attempted to solve every by just using Objects. However, when you go crazy with the idea and try to make simple things, like each car in a busy street, its own object. You end up with 1000 objects and code that ends up breaking down at the seams.
My definition of redundant code is variables and functions within a class that are written over and over if you can obviously use a loop, or functions that repeat from class to class that are not conventionally used. I like inheritance and extending code a lot, but it ends up a lot of times giving me functions with empty brackets.
I think you have a valid point Riven.
However, the people who come looking for help in a gaming development forum come for ideas on how to make their game code better. The most interesting part about JGO is that it is one of the best Java development forums even if you are not doing gaming. Eventually, they will end up trying the code that makes the code run better, and head toward re-factoring perfection.
I believe the community should strive to help users within the confines of the framework they are in. If a user in working in Java2D, help him/her make the program in Java2D. Don't try and tell them to convert to Slick2D or LWJGL. Same for those users working with Slick2D, we shouldn't try to convert them to LibGDX. If they had a problem grasping the concept within Java2D, changing to a new framework (or language) is going to cost them even more time. The saddest part is the problem they had in the first place will just follow them to the new framework. (It is the same reason why it doesn't make sense to fix a bug by changing from Java to Python.)
Creating games is another layer of difficulty beyond just being a good programmer who is using the right tools. We really have some really powerful tools when it comes to game development on this forum. However, the key to building any structure is knowing what tools would get the job done. Do you need 1000 FPS and 3D graphics to develop Pong, for instance? Probably not, so why over-complicate it.
I realize all programmers are good at building tools. We like to have classes that do specific tasks and do them well. Somewhere in all of that, we lose the ability to convert the tools we write into games. We feel that since we spent "X hours" on this tool, it has to fit in the game somewhere. We never sit down and ask ourselves, "What is the core idea of this game? What is my game about?"
If we did that more often, we'd realize that our code is expendable. That we don't have to use every single tool we write (or every framework we come across). We would realize that trying to fit a square peg into a round hole is a big waste of time. You write code to build your game. You don't write games around your code.
Building games is the ability to realize that your code isn't perfect. You will have to dump code to get your game running. If your code looks like an unreadable jungle, keep going and hacking away at it. No one gets it right the first time. As a gaming community, I wish that this notion was the defining factor... but, I think we are just way to preoccupied for writing the best tools to get any real games done.
I think the only thing that is to be avoided at all cost is *gasp* that the paying user/player runs into a bug.
Anything else affecting your code should be avoided, but never at all costs. Trying to refactor an existing codebase into a better design, over and over again, is exactly the reason the developers on this forum are barely productive. We have so few finished game releases per month that it's a bit shameful. Sometimes not having a fancy IDE is what makes you productive, because you simply have to move on with what you have and you just want to get it over with. The next game will have a better design, not this one.
Yes, we are not very productive. But that is because lots of the people here are still learning Java game programming and need to know what works and what doesn't. Therefore, they will go through a lot of refactoring and restarting until they get something that works. Then, at a certain stage, they will realise their capabilities and resources and settle down on a project that they can achieve and that they find fun. (I myself just reached this stage a few weeks ago then I started Far From Home)
My ideas on the types of people using these forums:
- n00bs who aren't trying hard to learn and are looking for code to copy-paste. Then they quit programming because something goes wrong and everyone tells them to fix it themselves but they can't because they don't know what's wrong
- n00bs creating n00b magnet projects which fail right away for obvious reasons...
- n00bs who are trying hard to learn, and progressing
- Amateur developers who are working on some of their first real projects
- Professional developers who are working, and working, and working...
- People that create Awesome code with epic performance (that is of no use to anybody) because they can
Half of the types of people are n00bs. Two Thirds of the types of n00b are wasting everyone's time.