I need to break an addiction to organization...

Miscellaneous Topics
#1

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 :P!

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?

#2

Make your own library, which, you already have your own engine.

#3

The only time I ever go back and fix something is when it starts to slow my progress on actual work to the point where I have no choice but to go back and refactor.

It’s inevitable that the code you write as a novice will drag you down later, and that’s why small projects are good.

#4

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.

#5

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 :confused:

#6

Meanwhile, I’m sitting here enjoying the little things.

When I heard Slick used OpenGL, I completely nerdgasmed and started porting all of my code. LibGDX seems like a step too far for me.

Though for smaller games, like in Ludum Dare, I recently wrote my own library, so I’ll be using that.

  • Jev.
#7

Have you looked at Agile or Extreme Programming methodologies? Both are considered under the topic of “Iterative and incremental development”.

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.

#8

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.

#9

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

#10

(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).

#11

That’s not an example of “making it as flexible and organized as possible”.

#12

XKCD is always relevant:

#13

Well, if we’re posting pictures…

#14

This is just killing my productivity, so I am going to take a shot at breaking it.
[/quote]
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.

#15

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.

#16

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.

#17

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.