I agree with Bregma.

The internet is an awesome resource for tutorials, but if you're just copying code, you're not necessarily learning; you can, though, learn a lot about the general architecture of a game (gameloops, for example) as those can be a little less intuitive (or maybe I'm just slow).

Further, I'd recommend against using an engine for basic games like those you mentioned, as they can strip away a lot of valuable learning opportunities to a new game-programmer (and nothing you'll be making for a long time will actually need or seriously benefit from an engine like UE4).

So, you are pushing someone who is not even comfortable with C++ and knows nothing about games programming to develop their own rendering system (it doesn't matter how simple it is) or input management? I totally disagree with you in that point.

I think it's far easier to learn very high level stuff first, then go deeper and deeper to the lowest level.

Hmm.. at this rate its so easy to start a holy war on which is the best way to learn... and this holy war is not my aim, but just to state my opinion with reasons for the sake of not confusing the OP or anyone else seeking similar advice

I think NoAdmiral and Bregma are right because

1. I read and re-read the OP's post and I cannot see any indication where he stated he is not comfortable with C++. Instead his post indicates that he is not well vast in the language but wants to learn and willing to make the efforts

I'd like to work on my game development skills. I want to create simple games using C++ language.

2. The quote above also indicates he wants to be able to create games, which is ambitious enough in my view

3. The post you quoted or Bregma's did not suggest that OP should write a complicated rendering system but that he should learn and write code actively as against passive learning, or copying code, which is ineffective.

4. Learning without an engine doesn't mean you have to write a complex rendering system. It means for instance OP can learn about vectors maths, simple collision detection, simple game architecture and progress gradually. And also he should try to code these as much as he can and see how it affects games so that when he begins to use engines later he will have a proper knowledge of how things work at the lower level and that would make him a better game developer

I agree with Bregma.

The internet is an awesome resource for tutorials, but if you're just copying code, you're not necessarily learning; you can, though, learn a lot about the general architecture of a game (gameloops, for example) as those can be a little less intuitive (or maybe I'm just slow).

Further, I'd recommend against using an engine for basic games like those you mentioned, as they can strip away a lot of valuable learning opportunities to a new game-programmer (and nothing you'll be making for a long time will actually need or seriously benefit from an engine like UE4).

So, you are pushing someone who is not even comfortable with C++ and knows nothing about games programming to develop their own rendering system (it doesn't matter how simple it is) or input management? I totally disagree with you in that point.

I think it's far easier to learn very high level stuff first, then go deeper and deeper to the lowest level.

Hmm.. at this rate its so easy to start a holy war on which is the best way to learn... and this holy war is not my aim, but just to state my opinion with reasons for the sake of not confusing the OP or anyone else seeking similar advice

I think NoAdmiral and Bregma are right because

1. I read and re-read the OP's post and I cannot see any indication where he stated he is not comfortable with C++. Instead his post indicates that he is not well vast in the language but wants to learn and willing to make the efforts

I'd like to work on my game development skills. I want to create simple games using C++ language.

2. The quote above also indicates he wants to be able to create games, which is ambitious enough in my view

3. The post you quoted or Bregma's did not suggest that OP should write a complicated rendering system but that he should learn and write code actively as against passive learning, or copying code, which is ineffective.

4. Learning without an engine doesn't mean you have to write a complex rendering system. It means for instance OP can learn about vectors maths, simple collision detection, simple game architecture and progress gradually. And also he should try to code these as much as he can and see how it affects games so that when he begins to use engines later he will have a proper knowledge of how things work at the lower level and that would make him a better game developer

Thank you for the interpretation. You were on target with everything, except my sex ;) . After reading and working in a book that illustrated the C++ language using UE4; I noticed that the engine did a lot of the heavy lifting- which wasn't what I wanted. After doing some research, I learned that learning game development through the use of an engine is still a good practice, but it's not the ideal practice. And since I want to apply the knowledge I've learned about the language and learn things that weren't taught in the classroom; I believe not using an engine (at first) would be best. Again, you were absolutely correct.

Thank you everyone, for sharing your advice. I deeply appreciate it.

After you become comfortable with C++, read Game Coding Complete, 4th Edition.

Take a look at the preview and you will be excited to read it afterwards. :)

I agree with Bregma.

The internet is an awesome resource for tutorials, but if you're just copying code, you're not necessarily learning; you can, though, learn a lot about the general architecture of a game (gameloops, for example) as those can be a little less intuitive (or maybe I'm just slow).

Further, I'd recommend against using an engine for basic games like those you mentioned, as they can strip away a lot of valuable learning opportunities to a new game-programmer (and nothing you'll be making for a long time will actually need or seriously benefit from an engine like UE4).

So, you are pushing someone who is not even comfortable with C++ and knows nothing about games programming to develop their own rendering system (it doesn't matter how simple it is) or input management? I totally disagree with you in that point.

I think it's far easier to learn very high level stuff first, then go deeper and deeper to the lowest level.

Hmm.. at this rate its so easy to start a holy war on which is the best way to learn... and this holy war is not my aim, but just to state my opinion with reasons for the sake of not confusing the OP or anyone else seeking similar advice

I think NoAdmiral and Bregma are right because

1. I read and re-read the OP's post and I cannot see any indication where he stated he is not comfortable with C++. Instead his post indicates that he is not well vast in the language but wants to learn and willing to make the efforts

I'd like to work on my game development skills. I want to create simple games using C++ language.

2. The quote above also indicates he wants to be able to create games, which is ambitious enough in my view
3. The post you quoted or Bregma's did not suggest that OP should write a complicated rendering system but that he should learn and write code actively as against passive learning, or copying code, which is ineffective.
4. Learning without an engine doesn't mean you have to write a complex rendering system. It means for instance OP can learn about vectors maths, simple collision detection, simple game architecture and progress gradually. And also he should try to code these as much as he can and see how it affects games so that when he begins to use engines later he will have a proper knowledge of how things work at the lower level and that would make him a better game developer

It's not a war, it's just that I think you're pushing him into the wrong direction.

First of all, he wrote in the original post:

"I was about to purchase the SDL C++ programming book (I recently learned the language throughout this school year)."

From here, what I understand is that he has done some C++, but he hasn't even faced a non-educational problem, so he can't be comfortable with the language.

Secondly, if he doesn't use some kind of framework to abstract some things, he will have to learn and implement really low-level things which will probably be too overwhelming and he will probably lose his motivation.

That's why I recommend him starting without having to worry about graphics implementation, as an example. Just to learn what the main loop is, how to manage and implement collisions, Entity-Component Systems...

As a conclusion, it's far easier to learn how things work before trying to make them from scratch, that simple.

Anyway, follow the path you prefer.

Best regards.

Note: I never said I did not agree with that about active learning

I found this website a while ago, http://www.learncpp.com. I have not checked it myself but it looks like it good resource to learn with.

It should not take to long for you to be able to play around with SDL and get something graphical showing. The SDL Tutorials at this website might be a good start. http://gamedevgeek.com/tutorials.

Don't worry to much about using the latest C++ magic, my code looks like it is written in 1992 ;). Do what you enjoy so that you stay motivated to keep learning. Have fun :).

The SDL Tutorials at this website might be a good start. http://gamedevgeek.com/tutorials.

That explains SDL1, not really worth learning, as SDL2 is the current version, which does things a little different, in particular in the video area.

[More stuff seems old, Lua tutorial uses 5.0, while we're at 5.3 currently, approach this site with caution :) ]

If you feel comfortable with C++ I do recommend this book: do highly recommend SFML. Though I do recommend a good knowledge of C++ and even some C++11 (this book gets a +1 from me just because it does use some of the C++11 features)

The reason I really like that book is because I feel it gives you a good idea of how a Game is actually put together and how all the pieces work and function together. It doesn't just go and have you copy and paste code all of your code in main.cpp, and have it work but scare you away from ever programming a game again. In a few places it does "over engineer" some code for how simple of a game you end up making, but it really gave me a lot of knowledge and helped me out a lot in seeing all the pieces of a game can fit together and left me with enough resources to go out and experiment and learn even more complicated things on my own.

Though in the end, the most important resource to learn it all: is you sitting down at your computer and doing it yourself. Just start doing something and don't quit. Just give yourself some really small goals of "get a ball on the screen." Then maybe "I wonder if I can move this ball?" That leads to "lets to try to get this ball bounce around" and next thing you know you have made yourself a Pong Game by just setting some really small goals