C++ is simultaneously the best and worst language to learn, IMO.. It's the best because it forces you to learn not just how to program, but how to manage the memory that your application is using.  It is literally as flexible as you want it to be; you can define your own data types, define your own classes, and get into seriously advanced computer science concepts:  polymorphism if you want, lambdas if you want, all manners of pointers/references, etc... Or you can use none of those features, and still probably write some sophisticated software.  In C++, the world is your oyster..

And that's also what makes it terrible to learn, especially as a beginner.  Learning C++ (especially if it is your first programming language) is very much a sink-or-swim endeavor.  More often than not, it's sink first, inhale some water, and nearly drown... and then swim.  So I echo what others have said before me:  don't get discouraged.

You also have to contend with years of C++ standards changing underneath your feet.  The code style in 2017 is very differnet than it was in 2007 (or even 2013), which in turn was very different than it was in 1997, and so on.. Yet, the language has to remain backwards-compatible; so you might read some blogs that have old-style code that doesn't look like other blogs or articles you read, and yet it works.  And that sucks, but you just have to keep trucking along.  Study code and learn what's what, and practice writing code (practice writing lots of code).

Also, remember that game development is VERY, VERY DIFFERENT than other types of software development.  Of course, it incorporates known computer science/programming principles.  But it also follows some design principles that other types of applications do not, and you'll want to be aware of that.  Check out this book as a reference: http://gameprogrammingpatterns.com/contents.html

And lastly, as others have said:  Just write a thing and finish it.  Don't worry about how "perfect" it is.  Don't do any Big O analysis or optimization.  Just focus on finishing the program.  And then, see if you can get more experienced developers to review your code.  You'll discover that the code you write the first time around sucks hard.  You'll also discover new "unknown unknowns" -- things you were unaware that you didn't know.  But all of it will be good; you'll learn better ways to design code as you iterate.

"Game Coding Complete" by Mike McShaffry and David "Rez" Graham helped me understand how to program for games, and how some individual parts of a game fit together. The structure of the code is written well enough to be expanded on too, somewhat easily after you understand each part's role. I think you might need a simple example of how things fit together, or maybe even when you're suppose to call certain things.

Maybe this tutorial will help, it has one of the better code structures I've seen in a tutorial. https://learnopengl.com/#!Introduction

Check this for the msg loop problem https://msdn.microsoft.com/en-us/library/windows/desktop/ff381405(v=vs.85).aspx

After the DispatchMessage() function, then you update everything that needs it, then render. Everything thing that needs to be loaded/initialized when the game starts should be done before msg loop, typically in the Game class Init() or one of its subsystems. Actors, physics, processes,  etc. would be handled by the game logic class.

You should have an EventManager that fires events to add weapons to actors. When it gets updated it fires the next event in its event queue. The weapon should be created when the event is fired, and the delegate function of the object listening for the event is called. "Game Coding Complete" has a good event system in it. However, I couldn't understand what it was doing to start with until I compared it with this https://stackoverflow.com/questions/7464025/designing-an-event-mechanism-in-c

Its basically the same idea, just written a lot differently, and simpler.

I dont understand why most people here, de-recommend the handmade hero series.

Its the only series/man i know of teaching the core fundamentals from the very beginning without forcing himself to any programming paradigmas at all:

- He simple doesn´t care about any programming rules, patterns, whatsoever.

- He just writes it down in the simplest straightforward way and extend it or compress it as he goes.

- He produces working code doing real work, while explaining everything he is doing.

So just write it down in the most stupid simplest way you can imagine - without forcing yourself to restrictions, managers, classes, any patterns, whatsoever. Extend it when you need it, abstract it when there is actually a need for.

Thinking about how should i design my classes, how should i interact with them, how i can extend them in the future, how to abstract X to solve problem Y is just a trap most programmers will fall in - always. Unfortunatly even the most talented ones falls into this trap as well.

15 minutes ago, Finalspace said:

I dont understand why most people here, de-recommend the handmade hero series.

[...]

- He simple doesn´t care about any programming rules, patterns, whatsoever.

Your answer is right there. It's someone trying to teach games development while deliberately ignoring all the accumulated knowledge and experience that the programming community has acquired. His experience is mostly in low level middleware implementation where the concerns are quite different.

As a side, I would like to ask why no game developer is following the same model he is.

I personally think he invented (or who before of him, in case someone else did it and I am not aware of) a Game Developer "buiseness model" that will trend in future.

I mean he gets paid/supported for it so is like a kickstarter/patreon model but with a streamer element added into it, for Game Developers.

I urge everyone who can to do the same because knowledge is meant to be shared 

On 04/09/2017 at 7:10 AM, LuridRequiem said:

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.

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 very good advice had been given already, I have not read all previous posts though so maybe some of these steps has been mentioned - i don't know. In case its not, here is my 2 cents

Seems to me you have no trouble writing isolated algorithms but have trouble  putting it all together for a project. So my advice or methodology to get through this    

1. At the initial stage think globally about your project::   a.) what you want to achieve in the project,  b.) Inputs  c.)  outputs or outcomes

2a.  Then think about the modules (functionalities) of your project.  What different parts does it have?  (write these down)

2b.  Drawing a very simple interaction diagram between functions/classes might help.  (though I rarely do this myself)

3. Identify the core part of the project

4.  Start coding the core in the simplest way possible.   Build it up gradually and gradually add functionalities  (again one at time and in the simplest possible way)

5.  Avoid thinking too much details on the parts you are not currently coding

6. When you add a functionality (or class), think about what the core is,  and start coding this in the simplest possible way and build up gradually

7.  Interaction between modules is going to be the toughest part,  but if you start simple (and write things down and draw interaction an diagram to keep track then you will pull though. These days I don't have to write things down (or draw) any more, but years ago I had to write down to keep track (this come with experience))

On 15.9.2017 at 3:43 PM, Kylotan said:

Your answer is right there. It's someone trying to teach games development while deliberately ignoring all the accumulated knowledge and experience that the programming community has acquired. His experience is mostly in low level middleware implementation where the concerns are quite different.

Thats not true for several reasons:

- He does use knowledge from other people but he use this very carefully (papers, libraries, articles)
- He teaches everything from low to high level concepts, everything you need to know about game development: Keeping nothing left behind

- He teaches how to solve unknown problems, including all the mathmatical concepts (In school / university you learn a ton how to solve existing problems very well, built on existing knowledge - but not much about solving totally unknown problems).

- He teaches how to build up your own knowledge, so you dont have to rely on others for everything

- He teaches you can rely others, including using existing engine/libraries but you need to understand the downsides/costs of that.

- He teaches programming languages are just tools, tools should not limit you - it should help you get the job done.

- He teaches the most important thing is: There is actual hardware running your game!

Really there are just a handful people like casey out there which does these sort of things: Sharing its entire knowledge, showing people its not the programming language that matters, but rather what you do with it and really... you can do everything if you want.

And lastly most important he teaches that:

Its one way how to make games, but it may not be the best way for you - because its a teaching series after all.

I personally like the series very much and can recommend it to everybody, even though i still disagree about some statements.

Nothing more to say about that.