Completely overwhelmed - should I just give up?

It sounds like you need to set some short term goals to help you feel successful as you move towards your end goals. Give yourself some smaller steps to accomplish, break it into chunks.

I read C++ Primer. That's a huge but excellent book, as I really understood C++ deeply with it, but it also took me a long time to read (I read it thoroughly, taking notes, making sheets for memorizing and personal reference, etc).

Reading, taking notes and making yourself learning aids is a great start, but were you also writing code while you read through the book? A theoretical understanding of programming won't get you all that far unless you're actually applying it to properly test your understanding and to learn all the practical details of the process that aren't necessarily covered by your book.

Along with your reading and note-taking you should also be doing any exercises presented in the book as well as actively seeking out additional practical problems to test your knowledge. If you need some additional problems to solve you could try some problems from Project Euler, Code Kata, or some of the quiz questions and problems presented throughout LearnCpp.com. You should also create additional learning opportunities from your practice problems; intentionally create bugs to see what errors arise, try to add your own additional features or change how things work, etc.

Is it realistic to expect some people to join me and pick up the GDD and get things started?

Probably not unless you can a) pay them, or b) get the project started and make some good progress by yourself so that they can see you really have something to offer a team and that your idea is really interesting. The overwhelming majority of would-be game programmers have their own ideas they would like to see brought to fruition, so it takes something a bit special to motivate them to work on your idea instead. See the discussion "what programmers want from a designer" in our Game Design forum for some more good information.

B) change my approach to learning game programming (if so, how? Give me some advice, pls)

It sounds like you might be getting bogged down in details; you wanted to develop 3d games, so you first started learning OpenGL and then proceeded to try to learn about the underlying theory. While all of that stuff is very valuable and worthy of your time and effort, if you really want to get a game made you might be better off picking up an engine like Unity, UDK, or others which handles all of those details for you so that you can concentrate on actually making a game rather than learning about 3d math.

You can always go back and learn more of the underlying theory later on -- it all depends what you really want to achieve -- is this project about learning how everything works, or is it about making the best quality game you're able to in a reasonably efficient manner? Clarify your goals and the path to proceed should be clearer.

I would also agree with Dragonsoulj: it sounds like you're piling up more and more work for yourself on the path towards your ultimate end-goal but aren't making smaller achievements along the way to keep up your morale. By breaking down your goal into smaller mile-stone projects that are achievable in a reasonable period of time rather than some unspecified future date you can have a sense of accomplishment and may be more motivated to continue.

Hope that helps!

Ditch the C++, use something else.

I realized that, even though I was able to write custom classes and all that jazz according to the principles taught in the SDL book, learning SDL seemed too much of a detour for something that only handles 2D. "Maybe I could just get on with it and jump straight into OpenGL, which does SDL stuff and much more", I thought to myself. Besides, the fact that I was staying clueless as to how to implement 3D and even 2D on some subjects started to bug me.

Before moving to OpenGL, did you even make a game with SDL? OpenGL only does graphics, so you still need to use an API such as SDL for handling player input, music, sound, and other things required for a game. At its core, programming a game is very much the same whether it's 2D or 3D. Most of what you learn in 2D game development can be carried over to 3D game development. As you've already learned, 3D graphics programming requires you to learn a lot of 3D math as well as learning a complex API, which is why it's a good idea to start with 2D development when learning how to make games.

Since you have a grasp on C++ and learned a bit of SDL, your short term goals now should be creating and completing a few simple 2D games with that API. OpenGL can wait for later, as well as your dream games.

Of course, that's only if one of your goals is to learn how to program games. If your real goal is simply to turn your ideas for games into a reality, then you're better off using a game engine as was previously mentioned.

First, I'll try to give you a dose of reality instead of encouragement. If you're willing to accept the advice that you should give up, you absolutely should give up. Learning the basics is a lot easier than getting to the finish line, so it's going to get a lot harder before it gets easier.

If you can offer more than just game design documents, you might be able to find others to help you. If you can pay them even below market rates, that would work. If you have art assets that can convince people to take you seriously, that might work. If you have experience delivering products to market, that would help. If you wanted me as a programmer, you'd basically have to convince me you solve the non-programming problems for me and I can just focus on what I enjoy most.

If you want to learn game programming yourself, I strongly recommend you drop the books. It sounds like you're reading big, bulky books that are teaching you way more than you'll ever use, and doing it without even giving you the sense of satisfaction gained by actually coding. Just work on your game, and when you hit a problem look up how others solve the problem, then find online tutorials that will quickly teach you whatever is needed to solve the problem at hand. Does it really matter if you don't know how to add sound to a video game before you even have the core gameplay implemented? Does it really matter if you even know a geometry shader exists on your video card before you have core gameplay? Seriously, implement the basics of your game in HTML and Javascript if you have to so you can see if the idea really holds up anyways.

I'd also recommend upgrading your video card if it only supports OpenGL 2.0. A card that old (5+ years, right?) and weak will really limit you when you're running debug builds. It will force you to fix performance issues before playing with the visual result, meaning you might fix a performance issue only to find the code didn't accomplish the effect you wanted anyways. Avoid the countless hours of trying to get more than 0.004 fps every 2nd or 3rd compile. Your time is worth more than a semi-decent video card costs. A better card will also allow easier use of more advanced tools other people have already written when you're just testing out new ideas and such.

IMO Learning game programing is a 5 year course at least (then you will be knowing something, and to be better it is 10 years 15 years) and even then it does not mean you will be able to make something good just you will be educated in the field

IMO Learning game programing is a 5 year course at least

You just reminded me of an excellent journal entry from ApochPiQ, "Become a Good Programmer in 6 Really Hard Steps". That being said, you don't need to do all of this stuff before you can make a great game, and there's a lot to be said for hands-on experience gained during the course of attempting real projects.

Now I'm reading an 800 pages book that teaches math 3D thoroughly until I'm grabbing my hair and tearing it out lolol...

Books tend to teach extremely generalized theory, proofs, then provide less-than-minimal examples and don't explain how/why/when it is used. My belief is they're useless.

Have you tried playing with code or reading documentation? It's easy to figure what Translation/Rotation/Scaling matrices do; how they do it doesn't matter at all. View/Projection matrices are a bit harder to figure, but you have documentation, forums, Google. As long as you won't care how it works, but rather what it does you'll soon learn to use it.

Now I'm reading an 800 pages book that teaches math 3D thoroughly until I'm grabbing my hair and tearing it out lolol...

Books tend to teach extremely generalized theory, proofs, then provide less-than-minimal examples and don't explain how/why/when it is used. My belief is they're useless.

Have you tried playing with code or reading documentation? It's easy to figure what Translation/Rotation/Scaling matrices do; how they do it doesn't matter at all. View/Projection matrices are a bit harder to figure, but you have documentation, forums, Google. As long as you won't care how it works, but rather what it does you'll soon learn to use it.

This. Books should mainly be used as a reference for something your actually doing. In college, I was forced to buy all of these programming books, that I rarely, if ever actually used. Learning was mainly in the form of homework that involved actually creating stuff. If I ever got really stuck, that was the time to start delving into the books. So my advice to you is to drop all books, and start up a project, one that is not an MMORPG :)

I recommend that you at least work in something.
Your experianse sounds a lot like mine and it encourages me that I have already passed a point that others are still stuck behind. I would also suggest learning a easier language like python or c# first while trying to get the basics under control. Also, I suggest the Head First book series, because they are simple and have books for basically every language.

Thanks for all the input! It's helped a lot. Yeah, I think I should drop books and start making some simple games with C++ and SDL. As for dropping C++ and using a simple language, I think I'd rather take advantage of the huge effort I made when I learnt C++ thoroughy, so that doesn't go to waste.

I just graduated (my professional field has nothing to do with computers whatsoever btw), so in a couple of months I'll start working and I'll buy a laptop with a better GPU. So the OpenGL 2.0 restriction shall fade away soon, I hope. In the meantime I may just take baby steps with SDL + pong / pacman / tetris clones, etc.

Indeed, my goal is actually to turn my game ideas into reality. Therefore I might consider using a game engine, or at least a higher-level graphics engine...

Btw, one of my game ideas was deliberately simple: it's a 2D multiplayer soccer game played online with the mouse + keyboard, like netsoccer (

) and soccer kiekko (

). I believe I'd only need to learn SDL and netcode. Am I right?

Again, thanks for all the advice

Just think about it this way.

If learning C++ and OpenGL are your goals:

- Set short term goals

- Make these goals easily attainable

- Understand it may take years to master or sometimes produce something worth selling

If making these games a reality is your goal:

- Grab Unity3D

- Go through tutorials

- Learn game pipelines and the basic C# unity requires

Learnings C++ and OpenGL is EXTREMELY valuable but also can take years before you are a competent C++/OpenGL programmer. Learning Unity3D can take months and can deploy on any platform. Learning Unity3D is also valuable, just not as transferable as raw C++/OpenGL.

I'm in a similar boat, Zanman. Matrices, Quaternions, etc. scared me to death. Then it just clicked after a final look over. It took quite a bit, but it'll arrive when it's time.

See though, me personally, I prefer to do it myself instead of use a prebuilt library. I'm learning about the Linux system as I write my test-hobby game.

Being open to use what I need to restricted to certain things, learning WTF X11 is talking about, switching from DX9 to OpenGL3, learning how to deploy on different platforms efficiently as I code, etc., yeah, not exactly fun at the moment.

However, notice my mistake. I'm thinking because I have past history in Win32 & DirectX, I can just carry what I know in programming to a completely different OS and it'll work dandy. Well that's a big no.

I thought I could just jump into 3D games right away. Talk about falling on your face. Spending time in the 2D field, studying up on math, the API and what happens behind it as I continue to make simple games was, and I'll stand by it, the best option I and anyone else could've done.

Take steps, learn what you need to do first. Tackle it. Grab the next subject, take it down. Honestly though, time, patience, Google and creating test applications ARE your very best friend. I'd stick with C++ and OpenGL, they'll be more valuable to you, IMHO.

As for your netsoccer idea, that's all you need. Well, graphics too. Trust me though the networking can and will get tricky.

IMO the only way to learn to make games is to make games.

You're learning a lot of details that have something to do with making games (like programming and various libraries), but you're not making games.

Research and find something that lets you make games fast. Try out a full game's built in map editor (Age of Empires 2 and Operation Flashpoint are my favorite for their ease of use). Try out one of the game making software (such as Game Maker or RPG Maker). Or get a game engine to work with (such as Unity or UDK). Learn to come up with ideas even in a limited environment such as these.

Once you start making games, you'll be happy with yourself, you'll come up with even more ideas, and learning becomes easy.

I'm not much ahead of you. In fact, I have no idea how 3D games or OpenGL work. But I have made some small Half-Life maps and a simple 2D game, and I am not burned out.

Ditch the C++, use something else.

I downvoted your post, but since so many others have also done so, I figure I ought to explain why I disagree.

A) The solution to overcoming challenges isn't to run away from the challenge.

B) The OP hasn't been having difficulties with C++, at least as far as I can tell. So it's akin to telling someone with toothache to put a bandaid on their knee.

C) He's already made a good start with C++, according to his own opinion, so abandoning it wouldn't really help.

D) His problem, as near as I can tell, is that he keeps jumping from subject to subject and not sticking with one thing long enough to really understand it. Telling him his solution is to jump yet again to something else just continues the cycle.

@Zanman777: My opinion is thus:

1. Programming takes years. Learning C++ takes years - you can learn the surface-level knowledge in less than a year, but to learn it deeply takes real time. Skill mastery is a journey, not a "do it once" kind of thing, so you need to pace yourself for that journey. Don't work so overly hard that you burn yourself out. Don't take it so easy that your knowledge rusts.
   
2. When shovel-feeding yourself knowledge, unless you put that knowledge into practice, you'll lose the great majority of it. Skill is a mixture of both knowledge (facts gotten from books) and experience (actual use of that knowledge).
   
3. It's difficult to really go deep in a subject if you jump between subjects. You need to stick with one thing for long enough that you truly get it.
   
4. There will always seem to be 'something else' that you need to learn 'right now'. But you don't actually need to learn it right now, and often if you stick with what you're currently learning, you'll find that the big thing you thought you needed to focus on no longer matters.
   
5. Some subjects you do have to learn. But learn them when you need to, not preemptively, because what you think you might need to learn and what you actually need to learn might not line up as clearly as you think. Knowledge isn't a car salesman where the deal will expire if you don't get it now. There are dozens of subjects you need to know, but you don't need to know them now, and you can't learn them all at the same time anyway.

My advice:

Take a week off of programming and reading, and use the creative side of your brain to design a simple 2D game. Then, take the next 4 months and make that game. Using SDL and C++. Apply your knowledge. Have fun while doing so. Mix creativity with intellect. Go at a sustainable pace.

After you finish the project, think about what went right, what went wrong, and how you can improve and tweak your programming habits and coding styles to refine your overall skill level.

Hello.

A) The solution to overcoming challenges isn't to run away from the challenge.

First of all, thank you for taking the time to discuss.
I disagree that changing the way you approach the challenge (the challenge being "making my games") is equivalent to running away from it. If you're trying to reach a place, there is usually more than one way to get to it. By all means, you will not be running away from something because you chose a smarter way to get to it.

B) The OP hasn't been having difficulties with C++, at least as far as I can tell. So it's akin to telling someone with toothache to put a bandaid on their knee.

I understand that a small sentence like the one I posted can lead to misinterpretation.
Using "something else." If he would use...
C# with MonoGame;
C# with Axiom;
Java with JMonkeyEngine;
LUA with Löve and Leadwerks;
C#\Javascript\Boo with Unity;
Python with Soya3D;
GLBasic;
AGK Basic with AppGameKit;
for example, this would fall into the "something else" category, would most likely let him get much farther ahead than he's ever been with completing his games and is certainly not as a misguided proposal as "putting the band-aid on the knee."

C) He's already made a good start with C++, according to his own opinion, so abandoning it wouldn't really help.

D) His problem, as near as I can tell, is that he keeps jumping from subject to subject and not sticking with one thing long enough to really understand it. Telling him his solution is to jump yet again to something else just continues the cycle.

I don't think we are in a position to extrapolate what would happen if he would jump to one of those "something elses," although I do think you should have a bit more faith in him as he has managed to grasp C++, one of the toughest languages - with a lot of ways of doing things wrong - that one can learn, as well as raw OpenGL and SDL.

If he would instead use "something else" that would already come with a ready-to-use game framework and a high-level environment for him to gladly ignore the elements that he's been complaining about, such as complex 3D maths and low-level programming, he would be able to focus on things past this "foundation architecture" and head straight to designing and programming gameplay, doing level-design, writing story, worrying about assets and his game-design document etc.

You see, there will always be a challenge there; This time the challenge will be "making my games" instead of "tearing my hair apart, becoming burn-out, demotivated and lost."

As for dropping C++ and using a simple language, I think I'd rather take advantage of the huge effort I made when I learnt C++ thoroughy, so that doesn't go to waste.

If by "simple" you mean "high-level," your previous experience with that language will most definitely not go to waste even if you do switch languages.

- http://stackoverflow.com/a/2974690
- http://stackoverflow.com/a/719316

There are also a couple of other reasons why you should not hesitate to change your current choice of language and your current approach to "something else."

A) Your goal does not require that you use C++. In fact, as Servant mentions, your learning curve will be extended by several years if you do use it.
If you're concerned about performance, one of the golden rules in software development is that it is far and away best for you to assume that your current tool is fast enough until you have evidence that it isn't. Programs are faster than you think. People write high-performance scientific data crunchers in Python, and that's interpreted.

B) Whoever plays your game won't mind the language or engine that you used to make it. They will mind emphatically, among a lot of things, if it's fun.
Your fellow artists, on the other hand, will mind if it has a tried-and-true asset pipeline so it's easier to prepare their work for it, and also the reason why you will be - most likely - better off by using something that is already-made (regardless if it's free or not) instead of rolling your own and adding yourself more headaches and hair-tearing.

Best of luck.

I'm starting to become overwhelmed myself, however I have the same math book that you are using, and I can tell you one thing, 99% of all the stuff you learn from that book isn't needed. There are a lot of good online sources and tutorials that teach you how to use matrix and vector mathmatics for OpenGl. Just try to take things slow. Don't try to make your goal to "make a game", make your goal to "draw a triangle to the screen", or "write a working shader", cuz u gotta start small.

I, after learning and using C++, with the Irrlicht engine, and using some basic OpenGL code to make a few 3d things myself, have gotten to prefer GameMaker for 2d, and Unity for 3d. There's something to be said about using nice tools to get things done faster.

I should also comment that I agree that you don't need C++ or the massive amount of math you may be getting out of those books. Unity handles most of that for you, and when you need math, it is basic vector/quaternion math. And you only need to use it, not implement it. As in you need to rotate some vector by quaternions to handle AI or other game logic, but you don't have to actually calculate that yourself, rather simply do it as an operation(or function call). If you go 2d and use GameMaker, it is even less than that, and 2d seems to be your goal.

You sound passionate and extremely determined. After reading at least half of your opening statement, I couldn't help but feel over whelmed myself.

A lot of people here have given you some really good advise, except for perhaps the most important one you need. You're recreating the wheal and you're not realizing it. You need to take a step back and research what you're actually doing, and what you really want for the work your dishing out. Don't get me wrong, what your doing now is great. You're teaching yourself a great deal about the mechanics that goes on deep inside a game. However, if your desire is simply to get the result of a game and not a game engine, you're going about it the wrong way.

Just like frameworks are used to simplify your tasks and project needs, so are game engines and game engine SDKs. See below to get an idea of what paths their are, and which one you believe your taking:

There are three options below that I know of:

You can create a game engine

You can create a game using a legacy design paradigm (creating a proprietary game engine for the game you're designing)

You can create a game using a more current design paradigm (using frameworks, game engines and game engine SDKs).

From my perspective, you are either creating a game engine or creating a game using a legacy design paradigm. However, from what I read, it sounds like you simply wanted to create a game; preferably one in 3D.

The current design paradigm for most game developing industries, is to use a game engine, and program around it. The biggest bulk of math is already done, SDL/OpenGL (low to mid level frameworks) are already implemented. You simply need to understand the core language and the game engine's frameworks in order to get the results you are aiming for. Look at this game as this would be an example of a professional grade game in development: https://robertsspaceindustries.com/

Now, their are several game engines out there:

Unity Engine.

Cry Engine http://www.crytek.com/cryengine

Unreal Engine

... and so much more (wiki has them for Java, I'm sure it has them for C++ too!)

Now, if you do plan to go into making a game from the bottom up using the legacy design paradigm, there is no shame in this. However, let me stress this:

Full Sail University has a 22 month BS degree for game development. Approximately 10 months through the degree, students are assembled in a team of 3 to 5 people and are required to make a fully working 2D game in under one month. The work load is shared. A 3D game is not worked on until the 19th month where a team of 5 people focus on making a 3D game in 3 months. Again, the work load is shared. The average work load per day and per student is 12 hours (4 hours lecture, 4 hours lab, 4 hours homework) every day for the 22 months. Also account for the fact that the layout of education is already done for you, and you don't have to research what you need to learn next (e.g., You need SDL for user input, OpenGL for rendering [except on MS Windows!]).

Now, I'm not trying to discourage you, but if you plan to make a game from the bottom up and wish to incorporate 3D, you need to consider comparing your self to students who go to that school. So, I throw this question at you again. What are you really aiming for?

I hope this is helpful to you, as I honestly feel you deserve a break. For others reading, please feel free to add to this, or correct where I am wrong as this guy truly deserves some healthy direction.

NOTE: You do not have to change your programming language to achieve your goals. That only occurs if their are no frameworks you can use to achieve the result, and you can't afford making the framework yourself.

For the record, I program in Java, not C++.