Opinions of games engines

General Discussions
#61

Isn’t the word you are searching for called “code optimization”? (Which is technically building on something that is already built.)

“Code tinkering” by definition is casually messing around with the code to see what else can be done. Yes, they both are similar with one difference. Optimizing usually reaches the same result faster, while tinkering diverges into new ways to solve a problem. To make a quick example…

Redoing the bubble sort method… Optimizing.
Programming pacman, then attempting to do it again differently… Tinkering.
Refactoring your program… Mostly tinkering, tiny bit optimizing.

Optimizing and tinkering are close, but they are not always the same thing. Tinkering can actually broaden your thinking and make a better programmer. For business, obviously this is bad because you are on a strict time limit. In hobbyist projects not controlled by time, programmers should be given a little slack.

It really goes back to the whole needs thing though. All examples I’ve laid out above create 0% productivity. As far as a program is concerned, there is no gain from optimizing, tinkering, or refactoring except the time data takes to hit the user. Or, is it the fact that the result isn’t tangible a good reason not to pursue these methods.

I think that we know there are more factors than just tinkering that contribute to a program not being finished. Especially something as difficult as game making. When tinkering crosses the border into optimizing, I think that is the real problem that needs to be addressed. Of course, it is a problem that needs to be dealt with on a case by case basis and really a whole other bag of worms I don’t want to get into here. :persecutioncomplex:

#62

Optimising something that’s already fast enough is tinkering, and it’s something nearly everybody does, to no useful end. I do it all the time.

Cas :slight_smile:

#63

As long as you understand what you’re doing it can, but it’s not a very effective way. A high percentage of people don’t even understand that they are tinkering and it makes them into worse programmers. From my days of working for the man…tinkerers, especially very skilled ones, was my biggest nightmare. Joe average that’s willing to stick his nose to the gridstone and work on what he/she’s suppose to and at the right time and writes the worst possible code that’s still to spec…loved those people.

(edit: code tag -> quote tag)

#64

That’s because those guys hate working for the man!
Most people here would fit into that category.
Chances are that they’re bored with their jobs and the best part of their day is finding a little tinkering challenge that they can struggle with to make the perfect API or the most efficient code.

#65

Oh I know I am a tinkerer. Well…only on some things. When i have something I want to get done I do it and say screw everything else until it is working.

I am more about code readability. I hate languages that are just hard to look at. Why do we need to use every single possible key on the key board for programming? Java can be very pleasant to look at.

#66

And like I’ve said…there’s nothing wrong with that if you understand what you’re doing. I’m not attempting to dictate how people should spend their time. But if you think you’re writing a game, then you’re racing toward a brick wall…sooner or later you’ll daunted/bored and quit.

#67

[quote]Why do we need to use every single possible key on the key board for programming? Java can be very pleasant to look at.
[/quote]
Finally someone that understands why I hate looking at any C* language…

#68

Definitely. I don’t know if this is just me, but IMHO “SomeClass extends AnotherClass” looks better than “SomeClass : AnotherClass”. The same with long class/variable names, for example “WindowClassExtended” against “WNDCLASSEX”.

#69

Agreed.

Actually, I face similar challenges on the project that I’m working on. To be honest, the open source world and the business world co-existence is baffling, but both have its fair share of tinkerers and optimizing gurus. I know from my experiences, it depends on the approach that you have towards it.

A lot of our current problems have to do with our outdated business model and business practices. Information has reached a point in where our business tracking methods can’t keep up with the speed that users can destroy credibility. We have technically been using the same model that has been around since our grandparents time, and those guys did not even consider the vast speed of the internet’s information highway. Instant gratification is deadly, and it is the real death blow to businesses today. Those who fail to keep up with changing technology, fail completely.

What does this have to do with tinkering?

Everything. There is a reason why we programmers must continuously tinker. Updates and information actually happens on a minute-to-minute basis on the internet. It is survival. As I’m typing now, my code is already becoming outdated with the new methods and libraries that are coming out today. We can’t code something today that’ll remain relevant in the next 50 years.

I know we programmers shun change. Hell, I even do. I still am in disbelief on how fast Java is becoming irrelevant when just barely 5 years ago it was practically on every (Android) mobile device. As much as I hate to see people rewrite the same code over-and-over again, I realized something. It actually has its place in the programming world, even if it isn’t on purpose.

I don’t think businesses are ready to get into that level of thinking yet. It just isn’t cost effective to have a group of programmers re-invent the wheel. However, with the rate of speed the information highway is churning out new data, it is those same people who are going to open up new doors and gateways. Anyway, I’ll leave it up to the business model to catch up. If they don’t, well… it’ll just have to end up expiring like everything else that isn’t relevant.

#70

Just make games and solve every problem well(you can even tinker with it when you are it) that comes ahead of you. Just don’t stop solving same problem again and again and forget your real goal. Those people who never get anything done neither invent or innovate anything.

#71

Or he would have ended up in fucking India.

Pardon the severe digression, but everybody here understands why it is we mistakenly call Native Americans “Indians”, right? Columbus was a boob.

#72

But he never would have…unless he followed the tired existing route.

#73

The thing about analogies is that they’re always a tad wrong. That’s why they are analogies, or they’d be exactly the thing we’d be talking about - invalidating the use of analogies all together.

To prove my point I’m going to argue that if Columbus truely was a tinkerer, he’d have invented something we’d still be using today to wash our laundry and feed our kids.

That’s why I tinker, because of the potential!

I think it’s clear what Roquen meant, so let’s not slowly drift off towards Godwin territory, as Columbus wouldn’t have stumbled on it either. (Pardon the bad puns)

#74

I’ve been in this argument before, and I’ve learnt that there are two (main?) types of programmer.

There is the tinkerer/hacker*, that does things their way because they want to learn how things work so they can apply their skills in different areas.
And there is the get-it-done programmer, that gets things done because that’s all they want to do.

Neither is superior to the other, they just have different goals with their programming. They both get the job done when needed.
The main difference you’ll notice is that the former type of programmer are focusing on what comes next, while the latter are focusing on getting things done now.

I suspect that in the case of the Myer-Briggs types, this is simply Perceiving against Judging.

  • Not cracker.
#75

Personally I make a clear distinction between experimentation/research and tinkering. In the former the person understands what they are doing and why, in the latter they do not. So what I call tinkering statistically never results in anything of any use. Tinkering is procrastination and isn’t focused. Tinkers virtually never do their homework. Newton said: “If I seen farther than others, it’s because I stood on the shoulders of giants”. Tinkers try to build a car and one step in that is (obviously) the “improved tire”, but they have no clue how a modern tire is designed and they don’t go and find out. More to the point, they’re very unlikely to need an improved tire anyway…and sadly they end up with a 3 ton square tire.

This is often repeated and is BS. The danger (if you will) of this kind of thinking is that it promoted unsound programming practices. You can be knowledgeable, get things done and not be a monkey programmer. As I’ve said above, what I call thinkers don’t expand their skill set in an efficient manner.

#76

Unless you are trying to achieve something practical and measurable, how do you know your tinkering has had any positive effect? For all you know you have just gone in circles. I find I can only think effectively about programming when I have a specific problem to solve.

#77

Tinkering at the very least gives you practise and also experience. Even if it’ snegative experience, when your tionkered solution has grown too unmaintainable and you see that you need more planning ahead next time.

Graphics artists at times make dozens or more sketches before they feel proficient with a scene or technique.

Also children learn a lot just by experimentinmg and exploring. Sure there are domains where teachers and books are a better way to learn, but for the more practical skills tinkering isn’t the worst approach.

And quite often a “good enough” solution is really just that - good enough. No more work or perfection needed. You just need to get a feel what is appropriate to your problem. Quite often very simple solutions will do the job.

Actualy I consider it an important skill to find simple and yet good enough solutions. It usually saves time, money and material.

#78

That I agree with. I also develop web content and I have yet to learn JQuery because of this. I hate API atrocities which you constantly need to look at documentation to figure out what a method does. Any good programmer spends more time figuring out what code to write than writing code.

#79

I spend all my time working out what I HAVE written :slight_smile:

#80

These are all pretty good points. Actually, experimentation is something that works very well when you specifically know what the problem is. Chemists do experiments all the time. They plan for a problem then take calculated steps toward the solution. Sometimes they pass, and sometimes they fail, but the result is always planned. Experimentation guarantees that no matter who you are, you can get to the same conclusion no matter what.

For anyone who has done programming for games, there are those moments in games where you have to do something that “feels right”. These moments fall directly under the “tinkering” category. There is no clear-cut solution to a problem. You are just messing around with values until you get something close. The answer isn’t necessarily “correct” or “wrong”, it is just what feels right to you at the time.

It is also why “tinkering” is not always a bad thing. The people who do the most “tinkering” would be artists and musicians. Sometimes, you can’t really calculate what the right note for a chord would be. Sometimes, you can’t get that tree leaf to look correct. It is not something that many people can “experiment” with and come up with the same solution, it is just something that you “tinker” with until it feels right to you.

For games, this specific aspect happens a lot and it is something that separates good games from boring ones. Sometimes, there is just no solution to a game problem. You have to “tinker” with the values until you get something close. The people who do well at this are the ones that know when “good enough” is “good enough”. In other words, they know when to stop “tinkering” and move on.

There is a place for “experimentation” in gaming when it comes to the mathematics, don’t get me wrong. There are solutions for how to properly sort arrays, deal with Perlin Noise, and finding the best hashing method. You can be sure that my results and your results will always match in those cases. However, when you want to find out what is the perfect jump height, if your pistol is as balanced as your shotgun, or if there is enough challenge in this section of your game…

“Experimentation” fails and “tinkering”, doing what feels most right to you, prevails.