[Help] Getting into game programing
1) roughly -2/10 , they'll do more harm than good. (For C++ you really want to use books, most online tutorials teach extremely bad practices or leave out essential information)
2) Don't worry about the whole engine abstraction yet and don't look for tutorials, most are crap, if you want to learn how to program at a lower level get solid grasp of the language and check the documentation for your OS API (or use something slightly higher level like SFML)
3) Just start simple, games like pong, snake, etc are fairly straightforward and can be done once you're able to draw basic shapes.
I was just at gamasutra checking out jobs ads, and I found this article:
http://www.gamasutra.com/blogs/TommyRefenes/20130107/184432/How_do_I_get_started_programming_games.php
Tommy Refenes was the programmer behind Team Meat's Super Meat Boy that got critical acclaim on the XBox LIVE Arcade. He's also featured in Indie Game - The Movie, which I highly recommend you watch that as well for extra motivation.
EDIT: I just read Simon Forsman's reply above, and his answer for your second question is spot-on. I wouldn't even consider building an engine at the beginning. You're just starting out, and you'll want to start small. An engine implies you have ambitious projects, and you don't want that in the beginning --you goal is just to complete simple projects, and learn your trade. You trade in this case, sounds like programming instead of art, audio, writing, etc. Plus, engine code is meant to be both functional to a degree, flexible for many projects, and easily extensible so you an sub-class which is where you'll want some experience writing complete games before trying. That way, you'll know how to code effectively.
As Simon pointed out, you'll want to write your own code from scratch so you get familiar with the lower-level libraries you'll come into contact with like DirectX, OpenGL/AL, SDL, etc. As you develop code, and complete your projects, you'll start to notice that you're coding the same things over and over again. When you're at that point where you're redundantly doing coding certain routines, you should start learning more about object-oriented programming concepts. Once you've made a few games, you'll notice that you've developed a coding style for your games, and at this point, you're probably copying and pasting entire source files from other projects to serve as a starting point to save you time from re-writing the same stuff from scratch. When you start using really similar code across multiple projects, I'd say that's when it's time to make abstract classes to cut down on coding time, and increase initial functionality of your subclasses. These classes used across projects will be considered the beginning of your game engine
For example, when I first put my menu system together for a specific title, I found that I was re-writing code to do the same things for each type of widget my game-specific menu system did. I created a generic Menu, Screen, and Widget class which literally trimmed of over a thousand lines of code, and made it easier to create different types of widgets (controls like Buttons, Labels, Textboxes, etc) and add it into my game.
This Menu system was used across multiple projects, and so I created an abstract version that had all of the features I'd always need for each project. Then, I'd create a game-specific subclass for each game. Eventually, I created a more abstract interface from the Widget class called CollectionItem. This was my OOP linked-list system, and nearly everything in my engine inherits from it. This engine, btw, is the result of many projects I've worked on in the past (although I've only publicly released one projects so far).
I'm talking in terms of object-oriented programming. If you're not familiar with these concepts yet, learning any object-oriented programming language would get you up and running. I highly recommend C++, and a good book to learn this language would C++ From the Ground Up by Herbert Schmidt. I think helped write part of the C++ standard we use today, and the book seems to cover the concepts well enough, and get to the point.
EDIT2: I would also recommend playing around with a drag and drop editor first like Game Maker: http://www.yoyogames.com/gamemaker/studio. This is where I got my start back in middle school, and it taught me a lot about Game Development just playing around with it. I think it helped me pick up programming because I learned a bit of the logic behind it just playing around with this editor. Honestly, if you're an artist with a technical side, you'd be well-rounded enough to make games on your own with this tool.
Honestly, I would say borrow books from the library and start from there. You can never go wrong with books. Program everyday-embrace, live and breathe it. You will not improve unless you write code. There are engines out there that you can use so you do not need to write it yourself.
Good luck!
Another question is how to import them and use?
If you're looking to stick with C++ (Which isn't a bad choice, though perhaps not the easiest) you should probably have a look at some of the frameworks built to help with such projects.
OpenGL and DirectX are both pretty great but getting them to do 2D stuff can be complicated, and with raw OGL, you'll also have trouble with window management, input, sound and some other things. There's quite a few great libraries that abstract the things that should be trivial and make life a lot easier for the budding 2D game developer.
Simple Directmedia Layer (SDL) is probably the lowest level of the lot, but it helps significantly with things like creating windows, capturing input, loading files and the like. It's also nice as it doesn't really get in the way of using raw OpenGL for the rendering, i.e. use it for what you need and OpenGL for the rest.
SFML is a similar framework. It's newer and its claim to fame, as I understand it, is for being written in C++ and following OO principals (SDL is in C I believe).
A couple other libraries I know of are Allegro which from my limited experience seems to be pretty easy to use and is well liked among its community and Cocos2d-x which is a fairly new multi platform (PC, iOS, Android) port of iOS's Cocos2d framework.
All of these libraries/APIs have pretty good documentation on how to get started with using them (how to build, what to include, project setup etc...) that should get you well on your way to getting your first game or prototype made.
The best advice I can give you is to keep at it and don't let failure slow you down. Best way to learn is by doing it wrong and figuring out how to fix it.
Cheers, and good luck!
(Microsoft XNA Game Studio 4.0)
XNA is a nice framework to work with. It acts somewhat like a lower-level library like OpenGL, but at the same time, it provides higher-level routines like models. However, like DirectX, it provides higher-level interfaces like content processing for sounds, images, textures, fonts, etc. It also provides some nice functionality for utilizing those.
If you were to work with OpenGL directly, you'd be writing all your content loaders yourself, or be spending the time trying to link external libraries to your project to do it for you.
@Hordeon: I was the one who suggested XNA, and I stand by that recommendation. If others have recommended it to you as well then that should really vouch for it being a good option.
I find that using XNA (with C#) gives a good balance of ease-of-use and power/flexibility (more so than, say, Unity). You still need to write a lot of your own code, but as Vincent_M points out you don't need to spend half your time messing around with content loading, external libs, etc. It really lets you get to the point and start creating something.
@Hordeon: I was the one who suggested XNA, and I stand by that recommendation. If others have recommended it to you as well then that should really vouch for it being a good option.
I find that using XNA (with C#) gives a good balance of ease-of-use and power/flexibility (more so than, say, Unity). You still need to write a lot of your own code, but as Vincent_M points out you don't need to spend half your time messing around with content loading, external libs, etc. It really lets you get to the point and start creating something.
Well, I dislike unity v. much. 5% coding, 95% else. Unity is more for designers rather than real programmers. Also other engines are more flexible than unity. Maybe u know something similar to XNA, but for C++? Yep, you recommended it, but also another friend from skype.
[quote name='Hordeon' timestamp='1357842102' post='5019936']
Maybe u know something similar to XNA, but for C++?
[/quote]
Yeah check out SFML: http://www.sfml-dev.org/features.php