I've redone the whole code and made a prototype file exclusively for testing. I still need to do more testing but I'm going to try my hardest to have code up for review. I'm still alive.

In my opinion the most important thing you need to tell yourself while coding(at least the one that bothers me the most) is that your code won't ever be perfect.

Personally if I don't end up rewriting lots of code or second guessing myself I at least THINK about doing it. A lot of people preach a lot of best practices here, and they are good to follow, but in reality the only real rule about coding a game is that the game has to work. Its a thing that a lot of us tend to forget and get hung up a lot on specifics. A lot of code for AAA games that seem all professional and nice are tangled webs of awfulness sporting every bad coding practice you ever have seen.

So basically, even if it nags at you crazy that you are being a bad coder, just try to focus on making it work and then thinking of ways to improve it later on.

Personally if I don't end up rewriting lots of code or second guessing myself I at least THINK about doing it. A lot of people preach a lot of best practices here, and they are good to follow, but in reality the only real rule about coding a game is that the game has to work. Its a thing that a lot of us tend to forget and get hung up a lot on specifics. A lot of code for AAA games that seem all professional and nice are tangled webs of awfulness sporting every bad coding practice you ever have seen.

You still have to think about why this is happening. Most AAA games have a very thight deadline, and lots of money depends on fulfilling it. Also, there are probably people with that much experience in such an AAA-gamedev-team, that can work with this horrible code just like most other people do with "good" one. Even I notice with growing practice how much easier it gets to read and understand other peoples code, no matter how badly is is written. Also, in such an AAA-environement, probably most of the code in the end is hidden under some toolset, using an editor & scripting/visual scripting, so its not that bad.

I just feel that just "getting things to work" is, depending on the aims of the OP a little waste of time. He isn't part of any company and doesn't have any restrictions. Why not spend a little time getting to know how to create better code? I always try to view the cost/gain of things. If I spend an afternoon thinking about and refactoring my game object system, so that creating a new game object takes significantely less time, is less prone to error and thereby saves time spent on debugging strange errors, and also increases readability, why not? I already said in a previous post, I also worked under the motto "just get things done", and after ~6 months of work I ended up with a mario-clone I just couldn't work on any further. I would have liked to add powerups, etc... but the code was so badly broken... (3k LOC player class etc...). Why should a beginner, that just codes for a hobby, really try to "sh*t" code/features out as fast as he can? I think that improving your way of working with creating games is far more valueable. If you know how to create good code, you can still throw out badly coded pieces of work to get stuff done quickly, in a much more efficient way. If you don't, you will even struggle with what some people might declare "just get it done"-type of code.

In my opinion the most important thing you need to tell yourself while coding(at least the one that bothers me the most) is that your code won't ever be perfect.

Personally if I don't end up rewriting lots of code or second guessing myself I at least THINK about doing it. A lot of people preach a lot of best practices here, and they are good to follow, but in reality the only real rule about coding a game is that the game has to work. Its a thing that a lot of us tend to forget and get hung up a lot on specifics. A lot of code for AAA games that seem all professional and nice are tangled webs of awfulness sporting every bad coding practice you ever have seen.

So basically, even if it nags at you crazy that you are being a bad coder, just try to focus on making it work and then thinking of ways to improve it later on.

This is a thing all programmer must struggle with, even if its not in their nature. When is it "good enough"?

Some people thing too little is good enough, coming short of having something that works within acceptable parameters. Others have their own quality standards which far exceed what would be sufficient, thus never actually releasing.

If you are programming for yourself, it may be complex to assess the 'good enough' and live by it (you don't have someone else QA-ing your code and saying 'that's fine'). Though the OP may indeed require more experience in the field, the above remains relevant to other individuals (if not all).

"Write games, not engines" :)

Also, there are probably people with that much experience in such an AAA-gamedev-team, that can work with this horrible code just like most other people do with "good" one. Even I notice with growing practice how much easier it gets to read and understand other peoples code, no matter how badly is is written.

Not sure where you get that idea, bad code is harder to read than good code, thats kind of a generic point that relates nothing to how good you are at reading code. It's also not a good excuse. That's like saying you serve worse and worse food in your restraunt because the customers have progressively gotten used to bad taste. Your teammates are customers to your code, they're the ones that have to swallow it when they work with it.

Also, in such an AAA-environement, probably most of the code in the end is hidden under some toolset, using an editor & scripting/visual scripting, so its not that bad.

Not sure where this one comes from either, plenty of companies still code their own engines, even those using stuff like Unreal will still end up having to write a bunch of code generally, there will be plenty of programmers out there dealing with code that isn't hidden under a fascade of a tool.

I just feel that just "getting things to work" is, depending on the aims of the OP a little waste of time. He isn't part of any company and doesn't have any restrictions. Why not spend a little time getting to know how to create better code?

Because it isn't a little code, proper programming practices are often a lot of learning and practice and hard calls to make without having written the same kind of "thing" a hundred times before. A lot of people(including myself) got a lot of spiel from places like here where everyone was basically going "No you have to do it THIS way, otherwise it sucks." It stuck, many a time I sat there staring at code thinking "I know this is wrong, but how do I fix it?" Days and weeks and months of wasted time trying to be 'correct' when in reality I should have just been putting code to keyboard.

If anything there should be a rule that whenever you code something new, the first two or three times you make a similar thing, you forget all coding good practices and just make the code work, see what it actually does and what it needs and ignore generic advice.

I always try to view the cost/gain of things. If I spend an afternoon thinking about and refactoring my game object system, so that creating a new game object takes significantely less time, is less prone to error and thereby saves time spent on debugging strange errors, and also increases readability, why not?

Except I would bet money that you spend much more than an afternoon on it, if you work on a game for a month you might spend days of time just worrying about refactoring. If I had to be logically accurate the only real way that better code is ever worth more money is when it saves more effort in the future.

Everything past that is just being nice for the coder, and although I'm a stickler for pretty code, the reality is that you're going to be working with a lot of slobs or people being rushed to get things put together, so its worth learning how to deal with it and not just be used to everything being neat and perfect.

Why should a beginner, that just codes for a hobby, really try to "sh*t" code/features out as fast as he can?

Because it is one of the only feasible ways you can learn. For instance people on these forums often demonize the concept of a singleton or any kind of global managers. Problem is those things usually simplify code, they simplify it enough to where a lot of developers use them religiously for things like engine subsystems. For a beginner or just for a small project they are probably time savers more than anything else, but I was taught to avoid them like the plague.

If anything that just points out that "there is no golden rules in programming" should apply to best practice advice as well.

From my own experiences with design of software in general I found a lot of good advice here that is valuable.

1. If you are unhappy with the code (you hate it) it is a good starting point to change it.

2. Creating a well formed structured software has something todo with experience and is nothing you learn within a day.

3. Using singletons or not depends on how good this concept serves the needs.

4. The same with KISS.

There is no golden rule. Only your experience will help you to decide when to use what kind of structure or what kind of language and all the like. You can get some ideas how to solve a specific problem. But if it serves your needs must be shown by usage.

One thing I do not find said in the other posts. Start document things you do latest if you dont understand it yourself.

Not sure where you get that idea, bad code is harder to read than good code, thats kind of a generic point that relates nothing to how good you are at reading code. It's also not a good excuse. That's like saying you serve worse and worse food in your restraunt because the customers have progressively gotten used to bad taste. Your teammates are customers to your code, they're the ones that have to swallow it when they work with it.

You are misinterpreting a lot in my statement. First of all, of course "good" code is easier to read then "bad" one. Of course this depends on what you see as "good" and "bad" code, but I'm talking about good code in terms of sane code with seperated concerns, whereas bad code would be 3-4k+ LOC god classes with tons of sphaghetti code. You wouldn't really want to argue that latter one can even be remotely as readable as the first one. Also, the second point about reading code was a seperate one, in that you will, with experience and practice be able to work more efficientely, beginning at even understanding code in the first place. But this comes only if you sometimes challange yourself and get to work with things that you don't already know. Its like in math, if all you ever do is solve additions and subtractions, you are never going to understand something like integration. At the time you've mastered intergrals, you'll be looking back at the firmer stuff and think "what, that was once challening?". Of course there is a path between those two, but thats my whole point. Practice, get your hand on stuff that might seem challenging and even time-wasting for now. Hobby-programming is a safe environemnt, there is nothing to lose.

Not sure where this one comes from either, plenty of companies still code their own engines, even those using stuff like Unreal will still end up having to write a bunch of code generally, there will be plenty of programmers out there dealing with code that isn't hidden under a fascade of a tool.

Sure, but thats exactly the point - even if a company writes their own engine, the gameplay-related stuff, level design etc... all ends up being done via some sort of tool. Sure this tool has to be programmed, but thats where it ends - the user of the tool won't care how the code is written, all he does is insert data, which is processed & displayed. If you, however, write a whole game without any engine or toolset, and have to use your own classes to program even gameplay, it does matter in case of productivity if you have classes that do the work in a sane way, or if you have a cluttered mess where for every type of enemy you add, you have to insert dozens of if-conditions at 50 places in your application.

Because it isn't a little code, proper programming practices are often a lot of learning and practice and hard calls to make without having written the same kind of "thing" a hundred times before. A lot of people(including myself) got a lot of spiel from places like here where everyone was basically going "No you have to do it THIS way, otherwise it sucks." It stuck, many a time I sat there staring at code thinking "I know this is wrong, but how do I fix it?" Days and weeks and months of wasted time trying to be 'correct' when in reality I should have just been putting code to keyboard.

That is called "analysis parallysis" and is nothing that comes exclusively with trying to code properly. Yeah, I have this happend to me sometimes, but thats when I sat down and try to make it the easiest way possible, but still in a somehow sane way. Surely there is a certain point where you should just go on with coding away, but that doesn't mean you should just be like "nah, f*ck it, I don't want to think about how to pass that class down, let's make it singleton". I already said so, its a thing about cost/reward, if you spend a month trying to design one tiny class, its wasted. If you could have thought about it 10 minutes more and turned out with a design that would let you be much more productive, it pays out. And the thing is, learning takes time, of course you are going to "waste" a day learning this pattern or that code style, but after you've got it, if you can apply it and it safes you time & hassle, it is in fact time won.

If anything there should be a rule that whenever you code something new, the first two or three times you make a similar thing, you forget all coding good practices and just make the code work, see what it actually does and what it needs and ignore generic advice.

This is not something that belongs to an objective discussion in my opinion, but you do realize that you suggest people to ignore generic advice while you yourself are giving and even so generic piece of advice to them? Apologies, couldn't resist.

Except I would bet money that you spend much more than an afternoon on it, if you work on a game for a month you might spend days of time just worrying about refactoring. If I had to be logically accurate the only real way that better code is ever worth more money is when it saves more effort in the future.

Yeah, but thats the thing. Some people don't look past the immediate effect of their actions. Some people just judge gain by what it gives them now. Its like, I save 5 minutes of typing here, when in reality you just lost countless hours in the future with debugging, wondering why stuff doesn't work as it intents too, extending, maintaining, etc... thats a bit broad statement for sure, its always a matter of judging input/outcome, but as a whole, not just what you gain in the next half our of the day.

Everything past that is just being nice for the coder, and although I'm a stickler for pretty code, the reality is that you're going to be working with a lot of slobs or people being rushed to get things put together, so its worth learning how to deal with it and not just be used to everything being neat and perfect.

My whole point was that someone who knows how to code properly will have it easier being forced to write dirty hacky kind of code that might be required, than somebody who never ever cared remotely about proper coding. Its not about having to apply it everywhere, again, its about knowing about it, being able to use it and knowing where to use it. You might say this is a generic statement, but thats just how human learning processes work.

Because it is one of the only feasible ways you can learn. For instance people on these forums often demonize the concept of a singleton or any kind of global managers. Problem is those things usually simplify code, they simplify it enough to where a lot of developers use them religiously for things like engine subsystems. For a beginner or just for a small project they are probably time savers more than anything else, but I was taught to avoid them like the plague.

While the following is again heavily based on opinion: There is nothing a singleton saves you. Nothing. You can just as well create your d*mn class, and pass it down. It saves you a) having to write a ctor or method argument here and there and b) having to think about where your responsiblities belong. Thats it. You can now access your manager everywhere you want. Now all the sudden the physics-code will call a sound-effect directly on collision, the sound-system will create a particle effect in the stop-method, the particle-system will tell the AI to stop attacking. Now most of those example are exagurated, but I had at least one of them happen to a fellow student (collision-system directly emitting sound-effect midways in collision code). It simple, if you think this is things that should happen, you can do them w/o singletons by passing your manager down. However, you will notice that this is not practical, because you'll suddenly have to pass the sound-manager down 10 layers to the audio-system. With singleton, its a free-for-all, ll that is so easy, everyone will easily do that. If you want to ask whats the downside? E.g. breaking physics code by altering the audio-layer, having to even possibly modify code in the physics-system by altering the audio-system at all. You gain virtually nothing, and can lose everything, so thats why singleton for almost all cases is a waste, and IMHO shouldn't even be thought.

You know, I feel this is getting a little opininozed and off-topic, please somebody complain if this should be discussed somewhere else.