12 hours ago, LuridRequiem said:

I feel like I'm rambling at this point, and not doing any good at explaining what I'm trying to accomplish. If you do, by all means, respond as thoroughly as possible if you'd be so kind to do so. 

You're talking about a wide range of abstract problems, to which there are only abstract solutions.

Next time you get into difficulty, start a thread here on the forum, show some of the specific code that you're not happy with, and tell us what your concerns are and what you hope to achieve. People will give you advice and will explain their reasoning, and you can learn from that and improve your programming.

You get the hang of it eventually. I was like that at one point, had a good understanding but didn't even know where to start.

Now I can be like, "Okay, I want to make a building system", open the script up and I just plow through it like it's nothing. Just practice and eventually you'll feel able to do it on your own. 

The question you really need to ask yourself is do you really understand the fundamentals?...and by fundamentals I mean the very basics, variable type, function, function params vs arguments, loops among other things. If you really do, then simple text base programs that accept input and print something out to the console etc should be no worries. Then work your way up to more complex problems. If you can't make it past the first step of the simple programs, then you are working up for disappoint if you proceed to more complex problems. This should be an indication that you really have not grasp the basics.  As other have mentioned before, you just don't get good at something by 1. giving up or 2. dreaming. you have to do it over and over until you've mastered it or at least at a level of comfort where you know it like the back of your hand.

22 hours ago, LuridRequiem said:

This is how I was trying to build my game loop, but I didn't understand how to take everything I was going to write, and put it in the appropriate functions. 

I also get caught up on how to get classes to work inside other objects. For example, If I have a player class and a weapon class, I wouldn't know how to set up the weapon instance inside player.  I don't know if this makes sense at all, because it's difficult to explain what I mean. I think another issue I have is separating abstraction and implementation from one another. Just because an item or weapon has all the variable attributes of those things doesn't make that thing what it's emulating in the real world. It's still code representing a real world object, and I get hung up on how to replicate that object in code. 

I feel like I'm rambling at this point, and not doing any good at explaining what I'm trying to accomplish. If you do, by all means, respond as thoroughly as possible if you'd be so kind to do so. 

On 9/4/2017 at 1:10 AM, LuridRequiem said:

I've typed this up several times, and I think this is as good as it's going to get.

For a long time, I've understood programming concepts, but I am unable to write programs that I want. My favorite language is C++, and think I have a pretty good grasp on it. Variables, data types, classes, etc... I know them well, and could explain what they do and how they work. My problem is, when it comes time to actually write functioning code, I just can't fgure out what to do. I don't know if this is a lack of code architecture knowledge, or just sucking at logic skills.

To make things worse, I look at examples of other people's work and become even more confused as to why they did it this way, used that data type or even become genuinely frustrated that I can't read their code(I know it's not always immediately obvious what some code is supposed to be doing, but it gets to me anyways). I stare at other's accomplished works and wonder what it is I'm missing to the point that I throw my hands up and walk away.

A couple of things to note - It sounds like you have a high level understanding of how various concepts work (i.e. a integer variable is used to store numbers you need to use) but not a low level understand of how or why they work. I've been there, when I started programming 26 years ago, I really remember the frustration that came form this incomplete grasp of how computers actually worked. I remember being your shoes, telling my dad "I wish there was some sort of perfect *variable* that could communicate everything I need to other parts of my program at once."

What you are missing is an understanding of how memory works. I notice you didn't really mention any understanding of pointers. Understanding how computer memory works will open all sorts of doors for you. Part of the reason C and C++ are very powerful is because they completely expose all memory management to the individual. That's both a perk and a huge responsibility.

I would say begin with a tutorial on pointers in C. This is a pretty good one, it's only about 3 hours long tops but it'll drastically increase your understanding of memory:

To your other questions about how to structure your program, that falls more into design patterns than understanding of the mechanics of computers. Where you seem to be concentrating is on the rote basics of computer programming (syntax, etc). Nobody on this or any other forum can tell you definitively how you should structure your program, because there is no single right or wrong way to do this. However, over decades, a bunch of design patterns have popped up that'll really make things simpler. These patterns tend to rely on a pretty good understanding of the memory management stuff I posted above. This is a terrific guide for learning the types of patterns you are interested in, written from a former EA programmer:
http://gameprogrammingpatterns.com/

Again, I strongly urge you gain a good grasp of memory before diving into any books or tutorials on design patterns, because they are conceptually very deeply intertwined. It's basically impossible to describe a union, for example, if you have no grasp of memory.

My final bit of advice (from experience) is to pick a retro computer or game console and learn it inside and out. I started with the Sega Genesis. Learning m68k microprocessor assembly is actually how I taught myself memory management (there was no youtube back in those days lol). Retro computers are simple enough that a single person can grasp every bit of their architecture, and the things they teach are very much applicable today.

EDIT: Forgot to post some links for retro computer programming help. Today, there are lots and lots of really wonderful guides out there that'll walk you through some low level assembly. My personal area of expertise is the motorola 68000 microprocessor, a wonderful chip to learn. It's got a very wide pedigree, being the chip that powered the Amiga and Sega Genesis, along with countless arcade machines. Scoopex is one of the best known Amiga Demoscene groups, and there is a long series of tutorials online by Photon, one of their main coders. This is probably pretty advanced, but I still want to give it a shout:

A slower reference for beginners is MarkeyJester's Sega Genesis guide: http://mrjester.hapisan.com/04_MC68/

MarkeyJester is actually a regular poster over at Sonic Retro, which itself has become a pretty wonderful repository for 68000 programming. Diving into their hacking guide will reveal all sorts of goodies:

http://info.sonicretro.org/SCHG:Sonic_Community_Hacking_Guide
And finally, a more modern tutorial is this one by the dev behind the new Megadrive game, Tanglewood:

https://bigevilcorporation.co.uk/2012/02/28/sega-megadrive-1-getting-started/

These 68k ASM guides are probably all beyond you at the moment, but this is the type of stuff I started with, so who knows! I'd definitely recommend starting with the C pointers tutorials I posted above, but didn't want to leave you stranded if you wanted to dive much deeper. Once you start grasping this stuff, you'll come to understand why C was colloquially called ASM++ once upon a time.

Best of luck, and most importantly don't give up! Everybody goes through these growing pains.

On 9/4/2017 at 1:10 AM, LuridRequiem said:

For a long time, I've understood programming concepts, but I am unable to write programs that I want. My favorite language is C++, and think I have a pretty good grasp on it. Variables, data types, classes, etc... I know them well, and could explain what they do and how they work. My problem is, when it comes time to actually write functioning code, I just can't fgure out what to do. I don't know if this is a lack of code architecture knowledge, or just sucking at logic skills.

I fully get that. Function-level code design, class-level code-design, system-level code-design, and whole-project code-design, are different fields of knowledge. The higher up you go in scope (function -> class -> system -> project), the fewer *quality* resources I've found explaining good practices clearly.

Essentially, for lack of good resources, you have to just learn by doing. I've read a couple books and multiple internet tutorials on "building a complete game engine", that just break down the individual pieces and then never tell you how they are all connected together. The books just skipped it, and the tutorials never get finished. =P

The only solution I've found is, well, writing more code, completing projects, learning from my mistakes, and asking questions. But it's even hard to ask questions, because it's hard to frame the questions clearly when you get to larger scopes, and it's not like people have the time to go through hundreds of thousands of lines of code understanding my project's architecture to tell me how I should improve the architecture. 

I think the difficulty is in communicating/articulating abstract concepts at that level, perhaps from a lack of terminology. For example, at the class level we can talk using Design Patterns, and system levels are small enough that we can use our classes as building blocks for discussion, and a few Design Patterns describe things at that level as well (ECS, MVC, and a few other patterns), but the project-level code doesn't seem to be as standardized in terminology and design.

But anyway, just wanted to let you know it's certainly not your logic skills, but a lack of code architecture experience and a lack of community-pooled knowledge targeting this area.