L. Spiro

Uhm you sound angry to me. Is there a root for this? I just ask for advice. I know i have to go through this but the question is from a "Beginner". Im not here asking whats my next move. I'm here asking what are the thoughts of others. What did they do when they were stating up. I know will get a lot of mistake. Think about this way if you develop a habit of blinking your eye often do you think its easy to just remove that habit? subconsciously you will often do that.

A quote to live by:

"You must learn from the mistakes of others. You can't possibly live long enough to make them all yourself." - Sam Levenson

You sound like you are more affected than me on this question. Could it be that you see yourself back when you were a beginner who knows. But im thankfull you give your thoughts for this. Maybe I am afraid

peace

Uhm you sound angry to me. Is there a root for this?

I am not angry, I simply speak directly. Some might call it, “tough love”.

Im not here asking whats my next move.

You’re just messing with the phrasing.
However you put it, the general idea behind what you are asking is, to me, best answered by not answering it, and instead pointing you in the direction of self-discovery.

Anytime someone asks, “Is it too early for me to…?”, the correct answer is usually, “I don’t know. Do you feel that it is too early for you to…?”. No one should ever answer this question for someone else (unless we are talking about cases in which failures result in death, disfigurement, or spontaneous urination).

Think about this way if you develop a habit of blinking your eye often do you think its easy to just remove that habit? subconsciously you will often do that.

That’s not even an analog for an analogous analogy.
When you are learning programming, knowing that what you are currently coding is part of a learning process and may not be the best code or method etc., why would you “learn” it as a “habit”? A habit when coding is something like where you apply your whitespace and braces. It is absolutely unrelated to actual coding practices such as the use of globals or abusing inheritance etc.
That’s like saying you’re exploring a cave and you come to a fork, and because you took the left fork you are forever bound to take the left fork every time you revisit the cave. No. You take the left path to learn where it goes, and then if you don’t like it (or if you are just curious) you come back and take the right path. Using globals is not a habit, it is a conscious decision you make, and then you learn from that mistake as it bites you in the ass until you retreat back down the cave and then you go down a better path, with all of the experience and understanding of failure recorded on your map.

If you just ask people what to do (however you want to phrase it) and they tell you not to take the left path so you blindly listen and only take the right path, your map will never show that little tiny special place down the left path where you can drink cool refreshing pure water. Even if the left path is mostly ugly, you still have to explore it so you can understand what really lies down it.

It’s just like how you thought ECS was good just because it uses composition.

You found advice online where people said to mark a path off your map so you just blindly did it. You have no idea when and why you should use composition over inheritance because you didn’t explore those for yourself.

People often over-generalize in saying that composition is better than inheritance because inheritance is easy to abuse. On the other hand, one could argue that ECS is literally the abuse of composition. Neither one is always better than the other, and both can be abused. And the only way you are ever going to truly learn their delicate dance is to start walking down those paths and making your own maps.

L. Spiro

However you put it, the general idea behind what you are asking is, to me, best answered by not answering it, and instead pointing you in the direction of self-discovery.

L. Spiro

See this is the benefit of asking. although i should have change my question for "what are the difficulty face by " or something like that. its too late now.

Thanks btw. That "tough love", hits me right in the face.

If you don't want to be stuck in deep thought mode get the cork out and start coding!

I admit that I tend to over-think and over-engineer and that really prevents me from just program the damn thing already..

Sometimes (read: almost all the time) I get frustrated because there are so many so-called "best practices" in programming..

And then I get paralyzed instead of productive.

We need to remember that when we write code, we are not carving it in stone, so we can always rewrite it.

And then we realize that we have to stop rewriting the code after a while so that we can get the program/game done.

And the next programming project will be better.

My observation is that a structured course on coding in a particular language is an important way of discovering bad coding habits in the first place. Going directly into making games has little accountability toward preventing bad coding habits.

On the other hand, if this is going to remain a hobby, then satisfaction would be the most important aspect.

If somebody wants a real future in game development, then good coding habits are a must from the start.

I admit that I tend to over-think and over-engineer and that really prevents me from just program the damn thing already..

Sometimes (read: almost all the time) I get frustrated because there are so many so-called "best practices" in programming..

This is where I am right now. Just as others have pointed out. I should just head on. Learn from mistakes.

If somebody wants a real future in game development, then good coding habits are a must from the start.

And this is what Im aiming at. A real future in game dev.

We need to remember that when we write code, we are not carving it in stone, so we can always rewrite it.

This is an important point that jacmoe makes...

Most of the time its better to hack together bad code that works, test if the feature it implements really works and is fun, and only when you are sure that the feature must stay, refactor the code to a quality you feel can stay in the codebase. Instead of finding the optimal way to implement the feature through theorycrafting and whatnot, only to find out that feature sucks and has to be ripped out again.

Often, the best way of implementing a feature will only hit you after some time. Maybe you wrote something in a crude way that works... you could go insane over how to improve the code to make it more stable, more elegant, better to understand... maybe you would waste a lot of time but the results wouldn't satisfy you.

Or you mark the code with a "TODO" comment that tells your future self "before you ship... fix. that. part. of. the. code. I don't care how you do it"... you turn to other parts of the code, you continue to build your game, and one day, one of 3 things happen:

1) The enlightenment hits you like a freight train, you get the best idea how to fix that part of the code in the shower, or while reading an article on coding habits, and you go back and fix it.

2) The shipping date comes closer, and while going through your list of TODOs, you stumble over this bad code part again. Either you spend some time now, maybe 6 months wiser, to try and come up with a better solution, or your remove the TODO, make your peace with the fact you will have to ship the game with an ugly part of code in the codebase, and just move on.

3) 3 months later, you give up on the project. Whatever the reason, fixing that part of the code becomes just a personal learning expierience. Instead of fixing it, take a note for your next project to write better code.

In my opinion, you are ready to learn an advanced design topic when you are fully aware of the problems it solves.

As has been said, the best way to become aware is to make the mistakes.

We seem to have a lot of people lately who are looking for shortcuts to expertise. "Expertise" has the same root as "experience" for a good reason.

"Expertise" has the same root as "experience" for a good reason.

A year and a half ago, I discovered that experience comes from Latin roughly meaning "from peril/danger". That really drove home to me that experience is just learning by means of taking action that carries with it a significant risk of making mistakes. So much so that I named my new company Experilous, as a derivative. (Too bad it has some poor branding qualities, such as the fact that most people's first impression is that it is a complicated word that they could never expect to spell or pronounce correctly. But at least, being an unused made-up word, the domain name was available, hehe!)

Thanks everyone for giving your thoughts about my question. Did learn a lot. If anyone wants to add theirs thoughts its okay. I think this will benefit every beginner struggling in game dev. or some people questioning their direction on game dev. :D