Someone told me the order I should work on things is as follows:
1. c++ basics (types, functions, classes, pointers, includes
2. sdl with the posted tutorial and/or sfml
3. opengl
thing is, i have no idea how to use those libraries. Letalone what programs to make using them.
I can honestly say I've never had that problem.
I got into this to make games like the games I love to play. I never worried about doing things or learning things in the right order, following some kind of schedule, or asking to be told what to do. Back when I was learning how to make games, everyone else was, too. There wasn't an internet to go to if I ran into a little bit of trouble. There were a few books I could buy, some of which helped me a good deal, but the vast majority of my learning came from trying to make games. If you worry too much about doing things in the proper order, let yourself dwell too much on how big the job is, etc... you stand the very real risk of total paralysis. Just figure out what game you want to make, then figure out what you need to do and learn in order to make it. If it turns out to be too big for you, try again or try a simpler one. But you'll learn far more from even failing at a project than you ever will lurking around on forums fretting about what to make or what order to learn things.
Programs are made to fulfill some need, not the other way around. If you have no idea what programs to make it means you have no need to fulfill. In this case, your need is education. You want to learn, therefore, you need programs which address this, and that means simple code that is easy to conceptualize but is still challenging to write.
OK, that sounds very unhelpful, but for the sake of education, you could always try writing a Pong clone or something, which will use most of what you cited above while giving you a clear goal in mind (I assume you know what Pong is, if not, google it). Libraries are "learnt" by reading through samples, tutorials and documentation, it doesn't just come magically. You need to work on it.
Once you succeed at making something that sort of works, self-satisfaction should power you through your next project. And so on..
I can honestly say I've never had that problem.
I got into this to make games like the games I love to play. I never worried about doing things or learning things in the right order, following some kind of schedule, or asking to be told what to do. Back when I was learning how to make games, everyone else was, too. There wasn't an internet to go to if I ran into a little bit of trouble. There were a few books I could buy, some of which helped me a good deal, but the vast majority of my learning came from trying to make games. If you worry too much about doing things in the proper order, let yourself dwell too much on how big the job is, etc... you stand the very real risk of total paralysis. Just figure out what game you want to make, then figure out what you need to do and learn in order to make it. If it turns out to be too big for you, try again or try a simpler one. But you'll learn far more from even failing at a project than you ever will lurking around on forums fretting about what to make or what order to learn things.
I want to make games too but you have to crawl before you walk, walk before you run, etc.
I have a LOT of books, a very good one in C++ Primer, but I get sick of reading so quick that I am not really going anywhere.
And it doesn't help the only games I can think of making are 3D.
AKA big projects that I shouldn't be focusing on as someone who hasn't really programmed squat in the 4-5 years I have been on/off programming.
There are plenty of 2D games you could 'clone' for experience purposes, like Pong (as Bacterius said), Tetris, Dig Dug, Galaxian, Asteroids, or just a simple platformer.
They may not be the awesome, huge 3D projects you want to make, but they're much more realistic.
Hell, if you really can't make a 2D game whatsoever, just start programming for your 3D game ideas, and get as far as you can get with them. You'll learn a lot, even if you fail to finish the project, and you'll probably feel more motivated because they're your little babies you're working on, not just clones of other games.
There are plenty of 2D games you could 'clone' for experience purposes, like Pong (as Bacterius said), Tetris, Dig Dug, Galaxian, Asteroids, or just a simple platformer.
They may not be the awesome, huge 3D projects you want to make, but they're much more realistic.
Hell, if you really can't make a 2D game whatsoever, just start programming for your 3D game ideas, and get as far as you can get with them. You'll learn a lot, even if you fail to finish the project, and you'll probably feel more motivated because they're your little babies you're working on, not just clones of other games.
That last paragraph is the most important thing in this thread.
Just start trying to make what you want to make. You'll learn so much from doing that. I piddled around learning stuff in the way I was "supposed" to, and then just started trying to make a game I really wanted to make, even though I wasn't "ready" for it. I learned more than I ever learned previously by doing that.
So? Go for it. You learn by doing. 3D games are only harder for people who only think in terms of code, which is an epidemic on forums like this.And it doesn't help the only games I can think of making are 3D.
I think any game designer runs into this problem on a regular basis!
First, there is good advice given by the previous posters about "just go for it". Expecting too much of yourself is usually counter-productive so you do have to just see what you can currently do and go from there...
Second, if you want to learn 3D then I recommend starting with a ray-caster engine. If you're using C++ then I'll assume you are a windows user and suggest you forget about all these game libraries and just use the WindowsAPI. So long as you can draw a single dot on the screen, get keyboard & mouse input, then you can do 3D programming. Its then a question of how good your maths and software development skills are! 
Third, whatever you do - good luck - but just start off small. Make a simple game in 3D and see it through to the end. As already said - it doesn't need to be perfect, just a start and something to show to others. You will get some who say its shit, but hey, we can't all be Elves from Rivendale, can we?
"Brother, I would spare you that pain..." Ramirez, Highlander
When I first started out, I spent about six months learning C and skimming over C++. After a quick command-line RPG game, I went straight into the bells and whistles of DirectX. There was something called WinAPI and GDI along the way, which I spent a few pages on, and went charging into API-madness like a bull in a china shop. To be honest, I really didn't have a clue what I was doing and it was painful, and whilst I managed to make a 2D blaster or two, I came away with the conclusion that I needed to go back and learn C++ PROPERLY, and even then, a few games later, I realised that skimming WinAPI and GDI was a mistake. So, don't be in a rush. Spend time learning your language first, then whatever you need next. You don't need to do everything all in one go...
WinAPI and drawing dots with GDI? Sorry but I think that might be some of the worst ways to start with (3D) programming. If you start with a really high level toolkit like unity, then you can do things in minutes for which you might need years (if you have the endurance) going the way you have mentioned. Yes you won't understand what is going on in the background but you can learn that later or don't bother at all and continue making games.
Learn what you need, as you need it, as you go along.
forget about object oriented C++ clasess. unnecessary overhead. unnecessary typing. and virtual methods are slower than non-virtual or regular code. use straight c code in a c++ compiler for the stronger compile time type checking. Use the standard C++ libraries and DirectX, unless you're targeting an Open GL only platform. for most PC's, DirectX is whats on the user's machine. If you ever plan on making games to sell, not requiring installation of OpenGL is a positive selling point. Also, vidcard driver support for directx is probably greater overall than that for OpenGL. And odds are there are more games made with DirectX than openGL, so any future project you become involved with will be more likely to use directx than openGL. While both are similar, already being versed in the one you're going to use helps. So even at the very start of a gamedev career, market forces influence what you do. In this case what poly engine library to learn.
Stay away from other libs like GDI, STL, templates, frameworks, and all that kind of junk. none of that stuff is for games, and just mucks things up.
I've been building games for 25 years. over time, programmers collect algo's into their "bag of tricks". code that they rely on again and again to get the job done. for making games, i've consolidated that bag of tricks into just 3000 lines of code that is a thin wrapper over directx. directx is rather verbose with lots of long variable and function names, and requires a lot of typing. The thin wrapper makes it less work: aniso(onoff) vs D3DSetTextureFilterSomethngOrAnother(Blah,Blah,Blah.........).
the "library" provides wrappers for directx, file io, mouse, windows message processing, keyboard input, string conversion, and random number generation. all wrappers compile inline.
the "library" also adds the following capabilities to directX: timer system; popup menu system; mesh, texture, model and animation databases; a limb based animation system; and matrix and string manipulators.
but the most important technology in the library is the drawlist. the drawlist queues all drawing calls, then sorts them based on the optimal order directx desires, then sends them off to directx for drawing.
these are representative of the types of capabilities needed in a generic gamedev library. As you can see, WINAPI, STL, MFC, GDI, and all the rest of that !^#@#%^$#*&^#@*%@!!!! stuff have none of this.
A minimal amount of windows API will be required to create a window class, register it, create a window, then go 3d and kiss windows goodbye! (yeah!).
a minimal windows message handler and window procedure will be required for mouse input.
as for what game to make....
well, the answer is obvious:
you make what you want to play and isn't already out there!
if you don't want to play it, odds are others won't want to either.
if you don't want to play it, you won't be motivated. might as well be programming databases for all the thrill you'll get at the end when you can use what you've built. if you're not motivated, you won't CARE about the project with the same passion, and the quality of your work will show it.
if its already out there, you don't need to built it, you can just go buy a copy and play it. in this case, building it would simply be an educational exercise. Nothing wrong with that, but another team has a head start, and it would be more work to eventually compete against them commercially.
Since you're just starting out and this will be for learning, not profit (at least at first), don't worry about whether there is already a game out there like it. this can actually be an advantage, as it gives you a working game to study and use as a reference for what you want to do. So simply decide what _FOR_YOU_ would be the coolest type of game to build, and go for it. I emphasize the "for you" because this will be key in keeping you motivated though the learning curve.
If the types of games you want to make are 3D games, don't waste time on learning how to make other types of games. there is very little in the way of game building knowledge from Tetris that transfers to Skyrim.
Also, if you want to BUILD games, don't waste time learning how to mod a game someone else has ALREADY built. While modding can be a somewhat roundabout way to learn how 3d games are built, its not the same thing as building one yourself (think "pimp my ride" vs a hand-built high-end Ferrari). And you get locked into the mindset of the designer of the engine you mod, thinking all games should be made this way. many is the time i've lamented the fact that Wolf3D/DOOM/Quake (and every shooter like on tthem) uses "levels" (level maps). now everyone thinks of game environments in terms of level maps, and that level maps are the only way to make a game. For anything you want to do in a game, there's usually a number of possible algo's, each with its own advantages and disadvantages, and its own capabilities and limitations. Learning game design by modding only exposes you to the solutions chosen by the engine designer for their particular application. If you build it yourself, the first step is to learn what algo's are out there, then pick one or roll your own if none is suitable. By doing so you learn about all the ways something can be done, not just one that may or may not be appropriate for the project at hand.
keep your favorite C++ book at your side, your favorite DirectX book at your side, the directx docs on a shortcut on your desktop, and GO FOR IT!
you may be looking up every single word in a line of code at first, and it may take a whole day to get 5 lines to work right, but keep at it, and you'll get there. eventually, it all becomes easy, especially if you spend 12-18 hours a day thinking 3d.
(1) watch the demoscene documentary and get inspired to create cool effects
(2) make some demos!
(3) profit! 
can start by doing a 4k intro doing pretty much just a GLSL or HLSL shader on fullscreen quad and go to demoparty (if you're in USA @party is in June http://atparty-demoscene.net/) and show it on the bigscreen and win fabulous prizes!
Learn what you need, as you need it, as you go along.
forget about object oriented C++ clasess. unnecessary overhead. unnecessary typing. and virtual methods are slower than non-virtual or regular code. use straight c code in a c++ compiler for the stronger compile time type checking. Use the standard C++ libraries and DirectX, unless you're targeting an Open GL only platform. for most PC's, DirectX is whats on the user's machine. If you ever plan on making games to sell, not requiring installation of OpenGL is a positive selling point. Also, vidcard driver support for directx is probably greater overall than that for OpenGL. And odds are there are more games made with DirectX than openGL, so any future project you become involved with will be more likely to use directx than openGL. While both are similar, already being versed in the one you're going to use helps. So even at the very start of a gamedev career, market forces influence what you do. In this case what poly engine library to learn.
Stay away from other libs like GDI, STL, templates, frameworks, and all that kind of junk. none of that stuff is for games, and just mucks things up.
I've been building games for 25 years. over time, programmers collect algo's into their "bag of tricks". code that they rely on again and again to get the job done. for making games, i've consolidated that bag of tricks into just 3000 lines of code that is a thin wrapper over directx. directx is rather verbose with lots of long variable and function names, and requires a lot of typing. The thin wrapper makes it less work: aniso(onoff) vs D3DSetTextureFilterSomethngOrAnother(Blah,Blah,Blah.........).
the "library" provides wrappers for directx, file io, mouse, windows message processing, keyboard input, string conversion, and random number generation. all wrappers compile inline.
the "library" also adds the following capabilities to directX: timer system; popup menu system; mesh, texture, model and animation databases; a limb based animation system; and matrix and string manipulators.
but the most important technology in the library is the drawlist. the drawlist queues all drawing calls, then sorts them based on the optimal order directx desires, then sends them off to directx for drawing.
these are representative of the types of capabilities needed in a generic gamedev library. As you can see, WINAPI, STL, MFC, GDI, and all the rest of that !^#@#%^$#*&^#@*%@!!!! stuff have none of this.
A minimal amount of windows API will be required to create a window class, register it, create a window, then go 3d and kiss windows goodbye! (yeah!).
a minimal windows message handler and window procedure will be required for mouse input.
as for what game to make....
well, the answer is obvious:
you make what you want to play and isn't already out there!
if you don't want to play it, odds are others won't want to either.
if you don't want to play it, you won't be motivated. might as well be programming databases for all the thrill you'll get at the end when you can use what you've built. if you're not motivated, you won't CARE about the project with the same passion, and the quality of your work will show it.
if its already out there, you don't need to built it, you can just go buy a copy and play it. in this case, building it would simply be an educational exercise. Nothing wrong with that, but another team has a head start, and it would be more work to eventually compete against them commercially.
Since you're just starting out and this will be for learning, not profit (at least at first), don't worry about whether there is already a game out there like it. this can actually be an advantage, as it gives you a working game to study and use as a reference for what you want to do. So simply decide what _FOR_YOU_ would be the coolest type of game to build, and go for it. I emphasize the "for you" because this will be key in keeping you motivated though the learning curve.
If the types of games you want to make are 3D games, don't waste time on learning how to make other types of games. there is very little in the way of game building knowledge from Tetris that transfers to Skyrim.
Also, if you want to BUILD games, don't waste time learning how to mod a game someone else has ALREADY built. While modding can be a somewhat roundabout way to learn how 3d games are built, its not the same thing as building one yourself (think "pimp my ride" vs a hand-built high-end Ferrari). And you get locked into the mindset of the designer of the engine you mod, thinking all games should be made this way. many is the time i've lamented the fact that Wolf3D/DOOM/Quake (and every shooter like on tthem) uses "levels" (level maps). now everyone thinks of game environments in terms of level maps, and that level maps are the only way to make a game. For anything you want to do in a game, there's usually a number of possible algo's, each with its own advantages and disadvantages, and its own capabilities and limitations. Learning game design by modding only exposes you to the solutions chosen by the engine designer for their particular application. If you build it yourself, the first step is to learn what algo's are out there, then pick one or roll your own if none is suitable. By doing so you learn about all the ways something can be done, not just one that may or may not be appropriate for the project at hand.
keep your favorite C++ book at your side, your favorite DirectX book at your side, the directx docs on a shortcut on your desktop, and GO FOR IT!
you may be looking up every single word in a line of code at first, and it may take a whole day to get 5 lines to work right, but keep at it, and you'll get there. eventually, it all becomes easy, especially if you spend 12-18 hours a day thinking 3d.
So I should forget OpenGL altogether?
I've been trying to figure out all of the crap I need to download aside from SDL for OpenGL.
I see a million things like FreeGLUT, GLFW, GLSL.
I figured DirectX was a microsoft only thing.
DirectX is MS only, though Wine can offer emulation for other platforms.So I should forget OpenGL altogether?
I've been trying to figure out all of the crap I need to download aside from SDL for OpenGL.
I see a million things like FreeGLUT, GLFW, GLSL.
I figured DirectX was a microsoft only thing.
blackpawn: while making demos sounds like fun, they do not help in teaching how to handle the interactive components that are present in games. Plus, a lot of demos involve generating procedural content on the fly, which can get pretty low level and therefor not as friendly for beginners (unless you're okay with your demo totalling several MB in pre-made assets).
My first experience with graphics programming was in SDL. I was able to get started sooner because I still haven't fully understood OOP at that time, but it wasn't necessary to make games with SDL.
I was still learning a lot about the C++ language with SDL, but I was able to make some basic scrolling shoot-em-ups (one with a ninja theme that I was proud of) and a Tetris Attack (Panel De Pon) clone with it. That puzzle game was coded sloppily and there were no menus, but it had a scoring system and game over condition that worked. To put it in perspective, the game was only one main.cpp file around 600 lines long. I could re-do it from scratch with a whole different approach, but the point is you don't have to be a big expert in any one area to make a playable game.
sure, kinda depends where your interests are. if you're interested in graphics and looking for something to make a game could turn into a massive undertaking involving not much of the fun graphics you were hoping to spend your time on. with small demos and intros near 100% of your time is on the visuals and cool stuff. code up a tunnel, add some glow, put some music to it with lots of bass, show it off to your friends and you may find that much more rewarding than mucking about on a more complicated project you may never finish and get that self motivating pay off from. all depends on personal interest i suppose but that's my recommendation for Bill. :)
blackpawn: while making demos sounds like fun, they do not help in teaching how to handle the interactive components that are present in games. Plus, a lot of demos involve generating procedural content on the fly, which can get pretty low level and therefor not as friendly for beginners (unless you're okay with your demo totalling several MB in pre-made assets).
DirectX is MS only, though Wine can offer emulation for other platforms.So I should forget OpenGL altogether?
I've been trying to figure out all of the crap I need to download aside from SDL for OpenGL.
I see a million things like FreeGLUT, GLFW, GLSL.
I figured DirectX was a microsoft only thing.
This is a pretty complicated field you are looking to get into. It's not overtly difficult, per se; there are areas of computing that are more challenging than game development. Nevertheless, you are going to have to learn to deal with some complexity. Google is your friend. For instance, if you used Google properly you would know that GLFW, FreeGLUT and SDL all fall into the category of abstraction frameworks that make it easier to create a window and initialize OpenGL, so you only need one of those; while GLSL stands for the GL Shading Language and is the language you would use to write shaders. Forgetting OpenGL altogether won't remove from you the need to understand a technical framework (trade the GL API for the Direct3D one, trade GLSL for HLSL).
The other posters in this thread have offered some good advice: figure out what you want to do, then figure out the very simplest set of tools you need in order to accomplish it. Don't get overwhelmed worrying about all the latest 3- and 4- letter acronyms, the latest technologies, etc... Frameworks such as SDL and SFML offer abstractions so you don't have to worry (yet) about the deeper technical aspects of OpenGL or Direct3D. Move up to more advanced stuff once you have a good grasp of the basics.
And understand that nobody on this forum or any other is going to solve your problem for you. No amount of forum posting or question asking is going to replace the simple acts of closing your web browser and opening your IDE and applying your brain to the active process of learning by doing.
that was...unnecessarily rude.
WinAPI and drawing dots with GDI? Sorry but I think that might be some of the worst ways to start with (3D) programming. If you start with a really high level toolkit like unity, then you can do things in minutes for which you might need years (if you have the endurance) going the way you have mentioned. Yes you won't understand what is going on in the background but you can learn that later or don't bother at all and continue making games.
If Bill was to attempt something like COD in WinAPI and drawing Dots in GDI - then yes, you are correct. It would be bloody painful. However, I was suggesting he start with a Wolfenstein-style ray-caster game, first. That's is a gentle introduction to 3D before the likes of DirectX and OpenGL. Windows API is readily available with minimum fuss, it only requires basic maths for raycasting and a knowledge of WinAPI allows one to make their own tool applications, which is of course useful for banging together level editors etc. With that experience stuff like DX and OpenGL will be much easier to settle into and be more appreciative of them.
that was...unnecessarily rude.
No, it was just about the right level.
You have already been given every single detail and then some about what you need to do next, yet you stand in paralysis, afraid to take even one step of your own into the wild.
The very first answer you got from JTippetts was already spot-on, and more people gave more advice on top of it, yet you keep coming back with “what should I do?”.
And as much as we want to help, what are we supposed to do? Keep repeating what has already been said?
My story is the same as JTippetts’, but maybe I can present it a bit differently. In steps.
Step 1: Acknowledge that I am a beginner and that my goal right now is more of a learning process than anything else. But games motivate me so that is what I want to make.
Step 2: Think of a simple game that I could make with my abilities.
-> #1: A text-based guess-the-number game first.
-> #2: Then a crappy DOS space shooter with lines for graphics.
-> #3: Then a C# Tetris clone third.
-> #4: Etc.
Step 3: It doesn’t matter what graphics API I use. My goal is to learn.
I guess what you need to learn is to stop thinking 12 years into your future. Stop over-complicating things.
Do you think I was worried about the differences between OpenGL and DirectX when I was making a crappy DOS shooter?
Do you think I made the Tetris clone in C# because I thought C# or XNA would be relevant to my future?
No. There are other things to be gained from making games than just graphics API’s.
C# has been completely irrelevant to my programming career, and that didn’t matter back then! I chose it because it was the easiest way to get graphics onto my screen.
Nothing else.
Stop over-complicating this.
Stop lurking the forums, get out there, and start coding. The point is to learn basic principles, and if you would stop overthinking things you would easily realize that whatever graphics API you are using you are gaining valuable experience in programming in general, game architecture, game-flow logic, etc.
L. Spiro
I have a LOT of books, a very good one in C++ Primer, but I get sick of reading so quick that I am not really going anywhere.
Start doing its exercises and read what you need to complete them.. the exercises are normally complete programs that you can make so that answer you're initial question..
I didn't use to like reading books too much either.. When I read technical books I sometimes can't read more than one page.. other days I can read ten or even more, but I force my self to at least open them once every day so the last years I've read many.
As everyone else says, just get started..
This topic has been locked by a moderator. New replies are not allowed.
With your permission, GameDev.net uses analytics cookies to understand how people use the platform. You can accept analytics or continue with necessary cookies only. Learn more
