On the Heroes of Newerth forums, a player asked: "Could you show me a few games that you have developed? A link or two maybe? I'm not asking you this with any reference to this thread, I want to learn game development and so I want a starting point."
Since I am one of the Heroes of Newerth programmers, others might be interested in how I got to this point. Here are the steps I followed.
Anyone who knows me will tell you the same thing: I'm not exactly Einstein, if you know what I mean. :) If I can follow these steps, then so can you. Yes, you. The only reason you personally can't become a game developer right now, just like you dream about, is because you choose not to.
Step 1: learn how to make computers do what you want. That's done by learning a programming language. Python is a great starting language, and a great starting point for making games, too: http://www.pygame.org/news.html
Personally, I started out by learning C++, which was painful. But I feel obligated to point out that the game industry currently makes most games with C++, so you'll probably want to bite this bullet eventually. The absolute first step for C++ would be to download Visual Studio Express (free): http://www.microsoft.com/express/Windows/
(But seriously, start with Python.)
Step 2: the hard part is persistence. Stick with it. Any time you have some free time, try to solve your current task by Googling it and reading. For example, your current task is "make a program that says 'Hello'". But whatever you do, don't give up. This is the most important part, and also the hardest.
Step 3: read everything you can. Most people hear "read" and think "book". Well.... I'm not really proud of this, but the fact is that I didn't read any books about programming whatsoever until after I got my first job.
Books are great once you understand the basics, but you're just starting out. You need answers to practical questions, like "how do I use visual studio to make a program?" "how do I make my program to ask for someone's name, then call them a noob?" etc.
So don't go to the library. Don't go to the bookstore. Don't spend time searching for "the perfect book that teaches everything". I tried it; maybe things have changed, but for me it was a lot more effective to Google specific questions.
Step 4: make a game. (sort of.)
Start by making 'guess the number'. That might sound easy, but when you're literally just starting out, it might become scary once you actually try to do that.
The trick here is to break it up into steps. I like to start by writing the "comments" first:
// choose a random number from 1 to 10.
// ask the user to type a number.
// compare that number with the first one. If they are the same, print "gratz bro!"
// otherwise, print "n00b"
There, that seems much simpler. Figure out how to do each of those, and you're golden. But how? Google, google, google! "Choose a random number from 1 to 10." You'll be AMAZED how much you can learn just by googling what you're trying to do.
Step 5: Make tic tac toe. Don't try to use graphics. Just use text, like you've already been doing. At this point, you already know how to "say something to the player" and you know how to "ask the player for input". Those two are enough to make Tic Tac Toe without any graphics.
Step 6: Have you made tic tac toe yet?
Step 7: Have you really made tic tac toe yet?
Even if you can put an "X" or an "O" someplace on the board, does it...
* detect when you've won (three in a row)?
* stop you from choosing a spot that's already taken, or does it accidentally let you use that spot anyway? (woohoo! you just fixed your first-ever bug! :))
* detect when all spots on the board are taken, but nobody won? (stalemate)
At this point, and only at this point should you attempt anything more complicated.
If you get through the "tic tac toe" phase without breaking your keyboard in half out of frustration, you win at programming.
Step 8: congratulate yourself. Seriously. Buy yourself something cool, because you friggin' deserve it. Making Tic Tac Toe is a step that few people ever get to, and it says something about you: it means getting your dream game programming job is just a matter of time.
But not yet! Right now, do this in order:
- Make text-based checkers.
- Make text-based chess.
- Make text-based hangman.
Make sure you actually do each of those. Make sure they work. Maybe even make sure they work well. But the point is, always be learning!!!!111`
What I mean is, don't sweat the small stuff. When you get your Chess program to the point where it can show the chess board, do not spend the next two hours tweaking how the chess board looks. That's worthless. Goal: always be doing things that will eventually get the program functioning.
You've jumped a lot of hurdles getting to this point. Getting "hello world" working, getting Chess working, etc. Well... if those were 'hurdles', you're about to matrix-jump a fucking skyscraper:
Step 9: Learn graphics programming.
This was the direction I chose to go. But you have alternatives. For example you could stick with text and learn Networking instead, then write a text-based MMO. Or you could try to learn how to use someone else's game engine to make your games (not recommended; you won't get more than a small glimpse at the actual amount of work involved in creating a game, and you will forever be limited by others rather than by your own ability).
But whatever you do, there's only so much you can do with just text, so "graphics" is probably the next step. The upshot is, there is something incredibly satisfying about typing a mystical incantation into a computer and watching it cause your program to magically draw pretty things.
Onward!
You'll discover very quickly that graphics programs are written in one of two ways: either "with Direct3D", or "with OpenGL". Keep in mind that there's no reason you can't learn both. If one of them starts to frustrate you, just switch to the other one.
These were my two most crucial resources:
http://nehe.gamedev.net/ On the left, go to "Lessons 01 - 05". Download their 'white triangle' lesson, open the source code in Visual Studio, and run it. Now for the fun part: mess with the source code! Move one of the corners of the triangle. Make the whole thing smaller. Draw two triangles. Etc.
http://www.drunkenhyena.com/pages/projects/d3d_tutorial.php Another great resource, but you use D3D rather than OpenGL.
Step 10: Here are specific steps to follow to progress from "beginner" to "intermediate":
* Learn how to get keyboard input. Now make your program move the triangle upwards whenever you hold down the space bar.
* Learn what a 'texture' is (spoiler: it's a picture). Draw a square with a smiley face texture. Now make it spin around.
Warning: don't try to learn about a 'vertex buffer' or 'index buffer' right now. They don't matter. All you need to know is, they just make your graphics go faster. They let you "put more things on the screen". But you don't care about that. No really, you don't. If your computer can run Heroes of Newerth, then you do not care about vertex buffers or index buffers right now. Your $300 video card is more than capable of running your test app.
WARNING: Do NOT, under any circumstance, try to learn what 'a matrix' is right now! Matrix math is a ridiculously advanced topic for what you are you doing right now. It is highly technical, incredibly confusing, sometimes contradicting, and just plain mysterious. (In a 'wtf' way, not in a fun way). As time passes, and as long as you keep programming, you will learn enough about what 'a matrix' is to use them to move things around and to move the camera around, which is all you should care about.
I cannot stress this enough. When you are just starting out, if you try to learn any mathematical / technical details about 'a matrix', even if you're a 'math guy' and know you can handle it, the end result is the same: you're dumb for risking your whole future. Attempting to learn any details about 'a matrix' will likely destroy any enthusiasm you currently have. It will likely make you say "I'm not a math person, F this shi'" and you'll give up. Math is nice; but not right now. Avoid googling 'matrix math' unless you truly love the idea of being a "graphics programmer" more than being "someone who actually makes games"!
And it's not just the math. Even if you love math so much that you have framed formulas hanging on your wall, you masturbate over "eigenvectors", etc etc, there is simply no way you will be able to tell me with a straight face that learning about matrix math in relation to graphics programming did not completely piss you off. There are arbitrary, confusing standards which are literally just that: arbitrary. Some human, somewhere, decided to do it that way, and now you have to learn it. But wait; no, you don't!
If you find yourself asking questions like these, then immediately run away, as fast as you can:
- "Why is a matrix 4x4?"
- "What is 'row major', what is 'column major'?"
- "What are the differences between how OpenGL uses matrices and how D3D uses matrices?"
They all have the exact same answer: "Pain! Anguish! Arggh!" Do the smart thing and stay away!
Alright, so what do you need to know about this mysterious 'matrix'? For now, only this:
1) To move an object around on the screen, you apply a matrix. Roughly, a matrix represents "a rotation, followed by a movement".
Here's a simple example. You could make a matrix that represents "spin your body to the right; now walk forwards two steps".
2) You can apply a matrix, then you can apply another matrix. For example, you could "spin right; walk forward two steps", then "spin right; walk forward two steps" again. Congrats; you have just "multiplied" a matrix by another matrix, aka you just performed "matrix multiplication"! It really is that simple, for now.
3) You use a matrix to "move the camera around" (called a "view matrix"). With this, you can say "the player is in the sky looking down at the scene" (overhead view, like in Starcraft).
4) You use a matrix to adjust "the 'lens' of the camera" (called a "projection matrix"). You can zoom the camera in and out, for example.
And that's all.
(On the other hand, if your goal is to be a great graphics programmer, then you will never even be a decent one unless you have a mathematical understanding of why a matrix works. And learning that will forever make you a better programmer. It will also make you just a little smug, too, but that's okay. You deserve to be.)
Anyway -- back to games!
* Now that you know a 'texture' is just a fancy-pants word for 'an image', and you know how to draw a square with an image on it, remake Tic Tac Toe. This time use textures instead of letters. (Don't worry about learning how to draw actual text to the screen, yet. Just open up Paint, type an X, save it as an image, then load it. Do the same with "O".) To choose where to move, the player would press a key 1 thru 9.
* Now make Pong. This is your "Hello world" of graphics programming. It will teach you the fundamentals of collision detection (detecting when the ball hits the paddle). Almost nobody ever reaches this point, and when they do, almost none of them make it past. What you need to understand is, there is no reason they give up... people simply choose to give up. Keep trying. Try, try, try. If you get stuck, try something else. Or simply ignore that problem and work on some other part of Pong.
Seeing that damn Pong game finally work was one of the proudest moments of my life, and you'll enjoy a deep sense of accomplishment. You'll gain confidence in your abilities, too. You'll realize the most important thing, which is that everything in life is just a matter of time, not ability. If you ask yourself "How would I make a 'Quake' clone?" you will be able to start coming up with actual steps which you can then actually follow to eventually make Quake, rather than answer "lol magic".
=======
Now you have a choice to make. You have the knowledge necessary to go one of two ways: game programming, or graphics programming. And that depends entirely on what you want out of life.
Graphics programming is an incredibly fun field, with literally endless puzzles to solve. As a job, it's uniquely satisfying in a visual way (of course) because after working for 8 hours a day, you'll literally have "something to show". As a field, graphics programming is ever-changing: the pros are always working on some new, major, and fundamental problem. Right now. And not just by Carmack, either; there are a lot of cool graphics problems being solved right now, and you personally can participate in solving them, and experience the joy of "figuring out how to solve a problem in a way that nobody has done before, ever". That is a rare thing, and one of the primary reasons for falling in love with graphics programming in general.
If you enjoy learning, then graphics programming has just about everything you could possibly want out of a profession. There is nothing to limit you except your own ability. Always remember that Doom and Quake were mostly built by just ONE programmer. And if you think those days are dead, buried, and forgotten, then consider this: From a programming perspective, Heroes of Newerth was "mostly" built by one incredibly talented programmer. Don't get me wrong, it was a team effort. HoN could not have happened without the massive effort put in by many different programmers. But... imagine being able to claim that it literally could not have happened at all without you personally, and being right. If you like how that sounds, then graphics programming is the field for you.
On the flipside, game programming is equally satisfying, in different ways. You are rewarded for your effort way more quickly. Prototype your game ideas, right now, by hacking together a little app and sending it to your friend. You now have all the skills necessary to do that. And there's no feeling quite like sending an actual program to actual people and seeing if they have fun. Then, you would fix some small problem, or add something else cool, and send it to them again. Repeat this over and over. It's really fun to have such a short feedback cycle.
As a game programmer, you can test most of your ideas incredibly quickly. I wouldn't say it's "effortless" to try a new idea, but it is not nearly as hard as, say, building a whole game engine from scratch. Small tweaks can have a huge impact on the overall experience of your game. Oh, also: you get to call it your game.
Lastly, I should probably mention that as a game programmer, if you repeat the "fix a problem; add something cool" cycle long enough, you might get lucky and wind up rich. Minecraft is a perfect example. It was made by one person repeating that exact cycle, over and over. At one point Minecraft was "pretty cool"; then, shortly thereafter it was "holy crap people friggin love this". And all you have to do is keep programming.
=======
So, there you go. I've described, step by step, in detail, the exact steps necessary to go from "zero knowledge" all the way to "lol wtf I made Quake!"
What are you waiting for? Go! Start programming! Do not stop! And above all else, no matter what you do, have fun with it.
