13

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?

Improve this question
4
  • If you keep repeating yourself, why not create a reusable component?
    – Kugel
    Dec 7, 2010 at 13:54
  • Not necessarily, if it's a good way of solving them :)
    – haylem
    Dec 7, 2010 at 14:07
  • 4
    If you are repeating yourself all the time, then write a library.
    – Job
    Aug 10, 2011 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
    – Chani
    Mar 19, 2012 at 6:01

10 Answers 10

Reset to default
26

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.

Improve this answer
1
  • +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, 2011 at 13:54
12

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.

Improve this answer
3
  • 1
    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, 2010 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, 2011 at 13:55
  • @Chad - a disturbingly accurate analogy
    – normanthesquid
    Aug 10, 2011 at 16:25
5

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?

Improve this answer
4

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.

Improve this answer
3

Not necessarily, if it's a good way of solving them :)

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

Improve this answer
2

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

Improve this answer
2

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.

Improve this answer
2

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.

Improve this answer
2

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

Improve this answer
0

"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.

But...

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.