Essential Math for Games Programmers
essentialmath.com
essentialmath.com
I'd sum up the most important skill like this: "learn how to finish projects". You can know all the math (or design) in the world, but if you can't finish anything, no one will be impressed unless you want to be code monkey #3249 at EA (and who wants to be that?). This seems easy when read on paper, but in reality it's fucking hard a shit. I've probably abandoned about 95+% of game projects I started. Anyone that says they finish more than 50% of the projects they start is full of shit. This is a skill -- and it's by far the hardest one to hone.
Note that it's not that I don't approve of OP's hard work compiling the list, I just think it perpetuates the idea that good games == good technology. Carmack is a CS genius, sure. But more importantly, he's a damn good game designer.
This is very true. I can testify that I work very hard at making my own 3D/2D game engines/gui frameworks. Yet, how many games I have finished: 0
> I've probably abandoned about 95+% of game projects I started
We should start a club ( http://jeffrey.io/wall-of-shame )
> perpetuates the idea that good games == good technology
I think, we are very fortunate, to be in this realm of easy and cheap CPU. good technology, back in the old days, were critical to putting out amazing games. This was simply due to the fact that without the crazy tech, you wouldn't have anything worth playing.
Now, woah, I can have my browser in an emulated android instance running on my emulated linux machine run games just as good as SNES.
For some new side projects, when I just "let go" of all the tricks and crazy algorithms I know and just "code to get things done"; it's like flying. Maybe in the next couple of years, I'll actually finish a game... Maybe
i am regularly shocked that 'world class developer a' has no idea about, e.g. bsp trees and partitioning - which are fundamental (or at least good VSD in general) to why e.g. Quake shipped when it did and not 3 years later. and when people moan about memory speeds etc... also the shocking amounts of memory used for simple things.
a couple of years back i replaced an utterly broken vsd solution in a 'AAA' game for the current/last gen consoles - the memory footprint was around 1mb, with about 640k of that being totally uncompressed PVS data as bit vectors, but it lived alongside horrendously wasteful systems that managed to use whole megabytes to do tiny things in the world - much less than, you know, drawing all of it. :P
also, do note, you can finish a shippable game in a week if you just force yourself. with a month or two constructing a usable fps with physics basic ai and loading some 3rd party environment, meshes and animations is completely feasible even with little prior knowledge. finishing things is the ultimate skill it turns out...
> Making an amazing indie game is probably the best way to get in the game industry. Studying math is not.
There are many specialized graphics programmers in the industry. They do not design games. They do not write dialogue. They do not make any art. They don't make sound effects. They don't design plots. But they absolutely do need to know linear algebra and a lot of the stuff listed here. I think the only problem with this post is that its title suggests it's aimed at the general game programmer, but it's actually aimed at the graphics or physics programmer, the sort of guy who would work on the Unreal Engine itself, not a game made with the Unreal Engine.
EA is probably a really crappy place to work (don't know for sure, but that'd be my guess). However, I've heard amazing things about, e.g., Valve, and I think they'd be more than happy to hire a brilliant graphics programmer who's never shipped an indie title that he built from scratch.
I know 3 people that work at EA. One of them likes it and two of them hate it. I guess it's like working in any big company. My dad worked for IBM and hated every moment. I, like him, don't think that could never really work at a big company where my creativity/intelligence/drive is inconsequential.
Edit: let me just say that maybe there are extenuating circumstances -- for example, if you presented some novel shading algorithm at SIGGRAPH or something. But for the most part, I think my claim holds.
It's been a long while since Valve has worked on one of their own ideas.
Dota 2 this year
I have some graphics programming experience outside of a professional context, and I can say you're not going to get stuff to work by blindly copying other people's code in any complex, new, and non-trivial situation. You've got to understand what's going on to at least some degree. You'll never get the top graphics jobs by copying code; you'll very quickly be identified as someone who doesn't really know what he's doing.
With that said, anybody who's truly got the math and programming know-how for this stuff will be able to easily put together demos. A demo is not a self-published indie title. These are two totally different things. If you've got a new terrain LOD algorithm, for instance, you definitely do not need to build an entire published and profitable game to show that off to the world.
You present a reasonable idea. But it's totally orthogonal to the content of the post, so I wish you hadn't made it here.
These days this should be called "essential math for game engine programmers". You're not going to write a good 3d game engine without knowing how to interpolate quaternions, for example (needed e.g. in skeletal animation).
If you just want to write a game, you should pick up an existing engine and go with that. No extensive math or 3d skills required.
If, however, you want to learn how computer games work underneath the surface, you will have to learn the math.
And there's also increasingly a place for "outsider" works now, because the off-the-shelf tools are very capable. Tech skills still help smooth the way with those, but I've encountered a lot of people who aren't deep into CS and get by with a lot of handholding from friends. I find this more interesting than traditional gamedev now, since there are so many perspectives outside of the tech sphere.
You may also end up working where there is a clear 'game designer' and 'game programmer' separation even if it is a small studio (20-30 people). In both these cases, you need to know your basic 3d maths to be useful in your role.
I concede that it's much easier nowadays since you end up using an engine that abstracts most things for you. Nevertheless, you do end up hitting the limits of the engine and may want to implement that killer feature yourself.
I have encountered all of these situations. I'll say that the minimum you should know if you want to be a game programmer is:
- high school level algebra
- high school level trigonometry
- basic 3d vector mathematics
- an understanding of graphics transformation (and the corresponding matrices)
- basic splines
If you are looking for a very specialised role, then you can probably forget these and focus on say AI or Networking but I see that as too risky in an industry that is already infamous for its treatment of employees.[Edit: Formatting]
Right now, I am writing a text adventure bushcraft game and the coding is almost tedious and boring.
Or you can use a framework which makes everything easy, like Unity.
Component oriented programming makes it rather easy to pick a technology, make a component out of it and adding it into your system.
Especially if you use a prebuilt/popular component system like Unity3d you can almost just click and drag technologies together.
It's true that if you need any of your components to perform extraordinarily then you'll have to dive deep and become an expert, or make sure you find an expert to help you.
Ofcourse, if you want to do everything yourself, then you might have to learn everything yourself , and you'll have to master a lot of things. It is true that games programming covers (almost?) every field in computer science. I guess this is the result of games basically being simulations of (part of) the universe.
I know dozens of independent developers who work on their own games (myself included) - people who work in fields completely unrelated to CS/video games, but still work on games simply because they are such complicated projects to develop.
If you're the kind of person who thrives on difficult algorithmic and code architecture problems, I highly suggest giving game development a shot.
Knowing how to interpolate a catmull rom spline is not required of a network programmer.
If you're considering a career in the games industry the best advice I can give you is to create a demo of your work. Do not build something ontop of a mod, build something of your own, be original and creative (something that the list does not emphasis). Don't worry if you can't draw, it matters not.
So if I were going to start again from scratch, I would probably do the following:
- Choose one platform to target (HTML5/Canvas, WebGL, OpenGL, DirectX, etc)
- Pick up a book and learn the basics of that platform, and do the exercises
- Learn what you can about the APIs and start playing around.
- Fractals and cellular automata are always fun - you can find Mandlebrot and game of life examples in pretty much any language.
- Think of something in your head and try to make it happen!
- Add interaction
- Rinse and repeatIt's really surprising there's this much math in videogame programming.
There is all kinds of awesome geometry algorithms out there but I didn't know if they were used in the real-world. http://www.cs.jhu.edu/~misha/Fall09/
My background is in math without too much knowledge about specific video games but I really love shapes. I wonder if I could fit in there.