15 minutes ago, LuridRequiem said:

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 that too, so I would try to decompose te tasks as @Oberon_Command did, I'll give it my best shot, for instance for me the first logical step would be that my player holds an array of pointers to weapons, and I assign a new weapon to the index[0]. The weapon should also go in my player hand, so I would think I would need some kind of socket variable inside my player to represent where the hand is, and then I would try and snap the gizmo of the weapon to that socket, maybe give it some offset.

The point is that what I said above is probably incorrent, but making the mistake is part of learning, in fact the next thing would be fo me to show on the forum what I did and ask if it was good/right.

So my whole message is, first give it your best shoot, do it wrong but see how far you get, and then show online and ask for feedback    

That's where you learn

Build the complete game. Don't worry about doing it wrong. Don't worry if it's messy, or has performance problems, or is hard to maintain, or whatever.

Just get it done. It is this practical experience that you are lacking, and completing some small programs will be an invaluable learning experience.

I'd suggest making Pong like this, then Breakout, and then attempting a couple of 1-2 week game jams.

Once you have some real experience putting together complete programs, you'll be better able to tell what has been a problem for you, what seems to work well, etc. and will have a better framework for understanding other people's suggestions for structuring your programs. 

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.

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

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 initially said that code can be incomprehensible because it is just bad code. On the other hand, code can also look incomprehensible, the first, second and maybe the third time, you look at it because the code is really good. I remember that for some software design courses in the past, my team mates and I spent hours (and maybe even days) on drawing graphs and discussing designs before we even wrote a single line of code. The final code would have been difficult to grasp for an outsider at a first look without reading the design reports.

Furthermore, code is far from static and at best should be continuously refactored and optimized (since programmers are never happy about their code and if they would, there would still be lots of "buts"). So it can be challenging to start at iteration 100 of some multi-year/multi-version project.

So besides programming skills, design skills are important as well, but they are no guarantee for understanding plain code right away. In the extreme, look at some arbitrary assembly or bytecode, could you figure out what the program is about? 

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.

It doesn't look like anybody has touched on this yet but something that not everybody understands or at least everybody seems to not want to acknowledge is that not everybody has a mind for engineering.

At its core building software is engineering. You may be able to build small pieces of a program but putting it all together into a functioning larger machine can be really hard.

I saw two other posts that I think would address your particular issue (as you don't strike me as someone who doesn't have a mind for engineering). First -- practice. You should probably consider building smaller programs first before you try to build larger programs as a bunch of classes and then trying to force them to work together. That doesn't always work well.

Second -- analysis paralysis. You're overthinking the problem. It's an annoying habit I have in myself as well and it trips me up from time to time. Sometimes it's better to 'just do it' to get a better understanding of the problem than to sit there scratching your head wondering about it. As you flesh it out and get a better grasp of the problem, you can refactor/rewrite the parts that don't work as well as they should. When I was new to programming I found myself doing this a lot when I was learning various problem domains. Today much of it comes naturally but it took me many years of developing code, studying code and trying different solutions to problems before I developed that intuition. Don't be discouraged -- C++ is a very hard language to master and takes time to really understand how to use all of the features it offers.

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.

I would like to preface the end of this thread by saying that I've completed hundreds of programming challenges, ranging from beginner to advanced. Why I can complete them in a relatively quick time, but struggle for days to write code that'll keep a window open in some graphics library, I don't know. It's been a problem for a long time, and I'm tired of getting stuck in this cycle of Inspiration->Frustration->Quit.

Edit: To sum this up as a TL;DR: Why is it I can write several classes, flesh them out with their working code, but not put all of those things in working order to produce the main loop?

A lot of people have covered the issues you may have.

I think you may just want to follow a tutorial step by step until you understand how GUI apps work in general.

Here are a few sites that may help with that:

http://www.gamefromscratch.com/page/Game-Development-Tutorial-Series.aspx

http://lazyfoo.net/tutorials/SDL/

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.