Whenever I try coding something simple, I find myself having an uncontrollable need to make it as flexible and organized as possible. This is good in some cases, but for a simple game that should only take up a few files, I make 5x as many so that everything will work no matter what the circumstances. It is getting to the point where I am getting less efficient because I am trying to be more efficient !

Anyone else had this feeling to go back and make everything organized and flexible, despite it not ever paying off or being worth it? Have you broke it?

No offense, but that's very ignorant. Using an engine/package/library/framework that is already proven useful is a major factor in being efficient with your software. You'll never find a company/studio or whatever that isn't using libraries to get their work done.

None taken. I do plan to use it for when I want to get used to box2d. I know it is really ignorant, but whenever I use libraries that I did not write, it just kills me. I just have a really bad habit of having to re-invent the wheel. Working on it though!

I get the same way. I know that I need to use libraries to help me so I can actually finish a game sometime, but then I just feel so bad when I actually do use it. I hate using others' code simply because I didn't think of it first. Its a dumb way to think as a programmer, but unfortunately its how I am :/

If you haven't read about them, perhaps reading the rationale for the theory will give you a better basis of the pros and cons of how you are now doing things, and that would be sufficient to rebalance your efforts.

Committing to following one of these methodologies for a project, to try it out, might be a way to "break the habit" if simply absorbing the ideas from reading about them isn't enough.

Surely it's good to be organised and more efficient. The hard part is starting the project. If you feel that way, like I always do, you spend hours on the core set-up. Once you've completed it once though, you can copy it for the next project and tweak it to your needs.

(With an overzealous generalization) There are 2 groups of people here: the tinkerers and the content providers.

The tinkerers are those, that are more interested in the engines and technology. They are those that write everything from scratch and are less likely to use framework and libraries already present. The good side is having a good knowledge of the system and processes. The con, however, is that there is less likely a finished product (a game in this context), since all the effort goes into "optimizing" and "making things better". Make no mistake, however, there are very impressive tinkering results scattered on this boards. For example the shader based particle engine was my favorite.

The content providers are those, that are interested in making something workable. Coding, as such, is just the means and often, an annoying step. They are more interested in getting the game out, as such they use all the libraries and frameworks that make them do the least work for the most profit (in the efficiency sense). Those are the ppl that pop up from somewhere, demo a game, that's already in the Android market place, at the same time being new to java and LibGDX. (which is, once again, very impressive, seeing how many finished games I have )

The question is, are those 2 groups mutually exclusive, static or transitional states. Are they 2 parts of the same, personal, evolution tree. Or maybe the transitional state is actually a 3rd group?

If they are transitional states, then You just need time and experience. At one point, You will organize Yourself into more productive and less obsessed with side/meta issues. I, myself, have gone from "I must write everything myself" to "I wish I wouldn't have to write so much code".

Also, when ppl are suggesting libraries and frameworks, then those suggestions are come from the content providing part, since they really ease Your workload and give You more resources (Your time) for making a game (making content vs tinkering).

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

..having an uncontrollable need to make it as flexible and organized as possible. This is good in some cases, ...

There are no good cases...you can't even make a realistic hypothetical situation (include a tutorial) where this is good.

Well, not very many cases, but I can think of some cases where this would be useful. Like when I was writing a batcher: It was a little bit too big for me to read well, so I just deleted, and rewrote it. Now it is 2x as fast as it was, and is used in less lines of code, for the same results!

If you haven't read about them, perhaps reading the rationale for the theory will give you a better basis of the pros and cons of how you are now doing things, and that would be sufficient to rebalance your efforts.

Committing to following one of these methodologies for a project, to try it out, might be a way to "break the habit" if simply absorbing the ideas from reading about them isn't enough.

Martin Fowler is a good author on the subject.

Oh, and thanks. I am going to use this for Horde (rewriting it in my engine ).

This is just killing my productivity, so I am going to take a shot at breaking it.

Speaking for the "devil": the "tinkering" you do here might delay you in creating a product, but it may also be very valuable in learning how to write good code. So if I were you I'd not blame myself for not being "productive" or something, just be happy you learned something well and see if you can do the next bit of code a bit more pragmatic.

Learning experiences are great. However trying to build "uber-awesome-library-for-X" is almost always pretty poor way to learn. The time spent writing one junk library could have been spent writing lots of junk code covering more areas. If you look back at code you wrote 2 years ago and don't think it's awful...then you're probably not learning enough.

Also "good code" is context dependent. Minimally it's to spec and completed in the minimal amount of time. Beyond that..it depends.

Excessive code "gardening" or "architecting" is really just a form of procrastination, which is a knotty psychological issue to get to the bottom of. I have a book called The Procrastination Equation that has a pretty good analysis on procrastination. I bought it over a year ago, and haven't finished it. Scribit se iocus, I know.

Procrastination: never thought of it but it rings true. Also I think there's a lot of people trying to prove something to someone (how clever, knowledgeable, etc.)...and the most dangerous is when you're attempting to prove something to yourself without realizing it.

Something to always remember is that you never hear people talking about awesome code, design, etc in sucky or never completed projects. And if you take a good look at some very successful or simply good-to-excellent programs you'll find alot of downright terrible stuff. And that's actually desirable if doing so got the project completed on time and to spec. The end result is really all that matters.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org