Take the 2-minute tour ×

I really enjoy programming games and puzzle creators/games. I find myself engineering a lot of these problems the same way and ultimately using similar technique to program them that I'm really comfortable with.

To give you brief insight, I like to create graphs where nodes are represented with objects. These object hold data such as coordinates, positions and of course references to other neighboring objects. I'll place them all in a data structure and make decisions on this information in a "game loop".

While this is a brief example, its not exact in all situations. It's just one way I feel really comfortable with. Is this bad?

share|improve this question
If you keep repeating yourself, why not create a reusable component? –  Kugel Dec 7 '10 at 13:54
Not necessarily, if it's a good way of solving them :) –  haylem Dec 7 '10 at 14:07
If you are repeating yourself all the time, then write a library. –  Job Aug 10 '11 at 14:13
@Bryan Harrington having faced the exact same problem myself, I must say that I working on different domains like from business logic(at work) to kernel programming(at home) and from working on C#(at work) to C++(at home) helped me a lot. I also have got into the habit of reading open source code here are some links :) Also, you can read GOF –  Wildling Mar 19 '12 at 6:01

10 Answers 10

up vote 25 down vote accepted

No, it's fine.

The point of practical programming is to find solutions that will possibly be useful in many similar developments. You just found one.

You can't and shouldn't be creating different solutions just for the sake of them being different. But you definitely should have a critical look at your solutions each time and ask yourself if they're still good or maybe the industry has progressed since and you need to align with it accordingly.

share|improve this answer
+1 for the last point "ask yourself if they're still good or maybe the industry has progressed". Too often you see good programmers become dated, and bad because they get stuck behind the curve and don't improve their skills –  CaffGeek Aug 10 '11 at 13:54

If it works well, call it a design pattern. If it doesn't, but you don't know better, it's the golden hammer antipattern.

share|improve this answer
This. It's only an issue if you find yourself forcing your solution on a problem where it doesn't work. If all your problems are nails, you should use a hammer, but if you find yourself trying to hammer in a screw, you should step back. –  Satanicpuppy Dec 7 '10 at 16:42
@Satanicpuppy ...sometimes we don't have a screwdriver and have a problem that needs fixing NOW. In which case a hammer is the best tool available at the given time. –  CaffGeek Aug 10 '11 at 13:55
@Chad - a disturbingly accurate analogy –  normanthesquid Aug 10 '11 at 16:25

Realistically in our day jobs we tend to get posed a fair number of pretty similar problems.

In these situations sticking with what you know can be good. I've seen more examples of bad solutions from people implementing something they didn't understand that someone using a non-ideal technique well.

If you know something well the chances are you can flex it as needed and that your implementation will be solid and effective. Those things probably won't be true from your first attempts at new techniques.

But the flip side is if all you have is a hammer, everything looks like a nail. You should be doing things to make yourself aware of alternatives and when you're perhaps pushing your favourites too far.

Perhaps pick a few non-urgent / non-critical changes and use them to get up to speed with alternative solutions?

share|improve this answer

Good question, and I have to admit this is something that haunts me too.

When is this fine? Do a performance analysis of your code -- if you see that you are in O(log n) or O(n) or O(n log n) and as such the problem is mappable to known data structures you are generally okay.

When is this not fine? Your time or space complexity is O(n ^ 2) or worse, or the problem by definition is NP complete. In these situations you need to apply a fair bit of heuristics, apply knowledge from other domains etc.

Quick example: In chip design, choosing how to arrange the gates in the circuit for minimal power is NP-complete. Just graphs alone won't do you much good although it's a must need. You need to read additional material, a lot of it inter-disciplinary at times and apply the knowledge in your domain. For e.g. genetic algorithms (algorithms that mimic genetic crossovers and mutation, as defined in biology 101) have a lot of application in designing hardware chips.

share|improve this answer


Usually when working on a "solution", I go for these things in order:

  • simplicity,
  • reusability,
  • and only last performance.

Not that performance doesn't matter: I design with performance in mind, but without pushing it too far (so if I need to do to calls to a utility method like StringUtils.isEmpty or something like that in the same flow, I won't mind). If performance is then needed (business case or user experience issue), then I go for a different approach than the simple and reusable one. Being pragmatic.

Strangely though, when coding in C, I care a lot more about performance than when coding in Java... Force of habit :))

share|improve this answer

As long as the problem is getting solved in efficient way, there is no need to worry.

share|improve this answer

I think graph is a suitable design for designing games to represent decisions\choices. Just keep in mind that probably this can be refined and made more efficient, and this may not be the best solution for other domains.

share|improve this answer

If it works, it's OK.

If you worry about overrelying on one single technique, try as an exercise to come up with variations of some solved problem that would make your solution unworkable. Extra points if you can generalize the changes to define the applicability space of your usual process.

share|improve this answer

If you solve problem it's good. And it's not matter what way till it not make more problems.

share|improve this answer

"Developer Art" actually has the correct answer if your goal is to produce a product. And if your "factory" produces the products that satisfy then cool.


If you ever want to learn new (and potentially better) ways of doing things you have to change things up. This will produce failures but only through failure does one actually learn. And through this new learning you may be able to produce even better and more compelling software.

This is actually backed up through neurological research. So there you go.

share|improve this answer

Your Answer


