Learning C++ and Getting Into Game Development(jamesbrewer.me)
jamesbrewer.me
Learning C++ and Getting Into Game Development
http://jamesbrewer.me/learning-c-and-getting-into-game-development
9 comments
Learning C++ and getting into game development are not, unless you are particularly lucky or talented, tasks that should be accomplished concurrently. They're both hard enough on their own.
I guess I was particularly lucky or talented. Anyway, I feel obligated to point out that it's not impossible, since I did it, and I'm not that smart.
By your own admission, after three years your code still was pretty bad. That is the reason I said what I said, not because it can't be done--the results are entirely too often marginal. C++ is not pedagogically sound, and building something somebody actually wants to use with it is a nontrivial task.
I find it a little self-defeating to try to tackle two of the more complex tasks in software development at once. Learn to program (obligatory Learn Python The Hard Way reference), learn to write games, learn C++. Or learn to program, learn C++, learn to write games. It separates the hard bits in such a way that you can approach them, understand them, master them, and then move on.
I find it a little self-defeating to try to tackle two of the more complex tasks in software development at once. Learn to program (obligatory Learn Python The Hard Way reference), learn to write games, learn C++. Or learn to program, learn C++, learn to write games. It separates the hard bits in such a way that you can approach them, understand them, master them, and then move on.
Completely agree.
(It's important for your comment to be worded like that, and not just "you shouldn't learn C++ and game programming at the same time". Otherwise a lot of the context is lost.)
That said, if I had to do it over, I wouldn't change a thing. I know myself, and therefore I know I'd be too timid to try to ever do more than move Python code into C via writing my own extensions. That would have significantly crippled my career, and denied me the opportunity to work on game engines written entirely in C++ (which almost all triple-A game engines are, for better or for worse).
That's a personal failing, I admit. I'm just spewing thoughts that were important relative to my career, because it's the only actual example I know enough to talk about.
(It's important for your comment to be worded like that, and not just "you shouldn't learn C++ and game programming at the same time". Otherwise a lot of the context is lost.)
That said, if I had to do it over, I wouldn't change a thing. I know myself, and therefore I know I'd be too timid to try to ever do more than move Python code into C via writing my own extensions. That would have significantly crippled my career, and denied me the opportunity to work on game engines written entirely in C++ (which almost all triple-A game engines are, for better or for worse).
That's a personal failing, I admit. I'm just spewing thoughts that were important relative to my career, because it's the only actual example I know enough to talk about.
He really should learn game development in something slightly easier, like pygame, before he goes off into the wild world of C++.
I suggest reading these before getting too excited about the game industry:
http://ps3.ign.com/articles/117/1178844p1.html
http://www.tomsguide.com/us/Gameloft-Glenn-Watson-dangerous-...
http://www.reddit.com/r/gamedev/comments/iso44/trouble_at_ga...
http://ps3.ign.com/articles/117/1178844p1.html
http://www.tomsguide.com/us/Gameloft-Glenn-Watson-dangerous-...
http://www.reddit.com/r/gamedev/comments/iso44/trouble_at_ga...
tl;dr: the guy wants to get into game programming, plans to learn C++, get internship.
That's great for him, but why is this interesting?
That's great for him, but why is this interesting?
Not to mention how incredibly clueless he is.
He is. I think he should try to build a raytracer first and try to let it output the render in 1 second. Might give him some understanding of how hard programming and optimizing is.
This is terrible advice. Someone wants to get into gamedev, and the first project you want him to do is "build a raytracer"? Obviously you're just a terrible person trying to discourage the guy, so foo on you.
Well why is this terrible advice? Maybe you could explain this instead of calling me terrible.
I was serious. When you want to start programming in 3D you should first start with the basics: rendering. Raytracing is a very good place to start. There are tons of tutorials online and maybe the most important: it gives a nice visual result.
The visual results are very important. It will encourage to keep on programing and working on getting better results.
So I was serious. Building a raytracer gives you a lot of knowledge about 3D, programming and optimizations.
I was serious. When you want to start programming in 3D you should first start with the basics: rendering. Raytracing is a very good place to start. There are tons of tutorials online and maybe the most important: it gives a nice visual result.
The visual results are very important. It will encourage to keep on programing and working on getting better results.
So I was serious. Building a raytracer gives you a lot of knowledge about 3D, programming and optimizations.
I apologize for calling you terrible, but pagekalisedown called him clueless and you chimed in with agreement. The guy's completely new to gamedev and eager... it seems pretty terrible to go out of our way to specifically try to destroy his enthusiasm by calling him clueless.
That said, you're spot-on about how a raytracer is an excellent (and fun!) project that every graphics programmer should do at least once.
But... if you're saying "in order to get started doing any kind of 3D programming, such as moving a cube around, then you should first write your own raytracer"... then we'll have to agree to disagree. =)
That said, you're spot-on about how a raytracer is an excellent (and fun!) project that every graphics programmer should do at least once.
But... if you're saying "in order to get started doing any kind of 3D programming, such as moving a cube around, then you should first write your own raytracer"... then we'll have to agree to disagree. =)
So... when people say "Deep Understanding of Linear Algebra", is it really anything more than being comfortable with the idea that rotations, and perspective transformations, can be represented as matrices? Any 3D graphics programmers (not necessarily for games) who can highlight the main aspects of Linear Algebra that they use?
Dot product.
Here's a random list of thoughts, speaking as a graphics and game programmer:
First, you hardly ever have to even think about "perspective transformation". Put it out of your mind until you're ready to attempt acquiring advanced knowledge, because it will just confuse and therefore hinder you.
Second, a transformation is typically a 4x4 matrix. It looks like this:
X, Y, and Z are "right", "up", and "forward" directions, respectively.
That is, imagine yourself sitting in your chair. Your comupter table defines absolute right (1,0,0) up (0,1,0) and forward (0,0,1).
Now imagine a blue arrow coming out of your chest towards your monitor. That's your Z axis. Imagine a green arrow coming out of your head, pointed at the ceiling. That's your Y axis. And now stick your right arm straight out and color it red. That's your X axis.
Now rotate to the left 45 degrees. Then scoot two meters backwards ("backwards" as in "opposite the direction you're currently facing", NOT "away from your computer desk"). Imagine the arrows rotating as you do this. Now figure out the exact numbers for those arrows (vectors). Plug those into X, Y, and Z columns of the matrix. Plug (0,0,-2) into the P column of the matrix. Congrats, you've built a transform that "rotates an object to the left 45 degrees, then scoots it back two meters".
Note that the above assumes a left handed coordinate system, with Y axis being 'up'. Which is the most natural IMO.
Lastly, dot product is the most important tool you could possibly want to understand. It's so versatile. You want to figure out the closest point on a line to point P?
It's a projection. It "projects" a point onto a basis. (I know a lot of mathematicians are probably screaming at their monitors at me right now, but foo on that. This is one of the most useful ways to think about dot products with respect to game/graphics programming, which is what we're talking about.)
Also, if you want to impress any interviewer who asks you about dot product, remember this phrase: "The dot product of two normalized vectors is the cosine of the angle between them." ... But you should really also understand that phrase. =)
Here's a random list of thoughts, speaking as a graphics and game programmer:
First, you hardly ever have to even think about "perspective transformation". Put it out of your mind until you're ready to attempt acquiring advanced knowledge, because it will just confuse and therefore hinder you.
Second, a transformation is typically a 4x4 matrix. It looks like this:
Xx Yx Zx Px
Xy Yy Zy Py
Xz Yz Zz Pz
0 0 0 1
X, Y, and Z are "right", "up", and "forward" directions, respectively.
That is, imagine yourself sitting in your chair. Your comupter table defines absolute right (1,0,0) up (0,1,0) and forward (0,0,1).
Now imagine a blue arrow coming out of your chest towards your monitor. That's your Z axis. Imagine a green arrow coming out of your head, pointed at the ceiling. That's your Y axis. And now stick your right arm straight out and color it red. That's your X axis.
Now rotate to the left 45 degrees. Then scoot two meters backwards ("backwards" as in "opposite the direction you're currently facing", NOT "away from your computer desk"). Imagine the arrows rotating as you do this. Now figure out the exact numbers for those arrows (vectors). Plug those into X, Y, and Z columns of the matrix. Plug (0,0,-2) into the P column of the matrix. Congrats, you've built a transform that "rotates an object to the left 45 degrees, then scoots it back two meters".
Note that the above assumes a left handed coordinate system, with Y axis being 'up'. Which is the most natural IMO.
Lastly, dot product is the most important tool you could possibly want to understand. It's so versatile. You want to figure out the closest point on a line to point P?
dot( (P - line.start), normalize(line.end - line.start) )
It's a projection. It "projects" a point onto a basis. (I know a lot of mathematicians are probably screaming at their monitors at me right now, but foo on that. This is one of the most useful ways to think about dot products with respect to game/graphics programming, which is what we're talking about.)
Also, if you want to impress any interviewer who asks you about dot product, remember this phrase: "The dot product of two normalized vectors is the cosine of the angle between them." ... But you should really also understand that phrase. =)
Doing something is usually much more rewarding than talking about it.
[deleted]
Generally I wouldn't waste my time on naysayers, but I feel like this time I should.
I am fully aware of everything that has been said here. I know it's hard work. I've heard about the hours. I know that it would be easier to start with Python.
But you know what? I just don't care. None of that concerns me. This is something that I want to do, and I'm willing to put up with all of this stuff.
I am fully aware of everything that has been said here. I know it's hard work. I've heard about the hours. I know that it would be easier to start with Python.
But you know what? I just don't care. None of that concerns me. This is something that I want to do, and I'm willing to put up with all of this stuff.
This is simply not true. As an intern, I didn't need to understand hardly any math. From there, I learned what I needed as I went. I have a fairly deep understanding now (four years later), but you definitely don't "need math" in order to get started programming games, or even to get a job working on games.
"This, to me, sounds like a big undertaking, but I think that it is a good goal and hopefully 5 months will be enough to achieve it."
I wouldn't trust anyone who had only spent 5 months learning and applying C++ to work on any game I was a part of. My reputation would be on the line due to their mistakes. 5 months just isn't nearly enough time, even if you spent every day learning and working.
I spent almost every day of every year of my highschool time (Freshman, Sophomore, and Junior year) sleeping through class, then going home and learning how to make games in C++. Only then was I finally able to land an internship and get the heck out of school. And I was still a really bad programmer, even after "three years". It takes time to get good, and there are no shortcuts for experience.
Your demos are critical. Make as many of them as you can, as quickly as you can, and be sure they work with few flaws.
Don't really worry about code quality quite yet. It's exceedingly rare for anyone to actually look at the code you write before hiring/interning you. They will expect you to write code to their coding standards anyway --- they need to know whether you can accomplish things, not whether you can write pretty code.
Most importantly, keep it fun. Don't worry about "choosing to make this your path in life, no matter what". If you approach this like your life is over if you don't get an internship, then you'll fail. Conversely, you're much more likely to succeed if you try to learn the things you find fun. It was fun for me to put together physics demos, and so I learned PhysX. It was fun to get a character walking around, so I learned D3D9 Skinning. Etc. Have fun as much as possible. Lastly, it was important that I didn't delude myself into thinking I was more skilled than I actually was.