What about game programming? Nobody mentioned it. It's the ultimate test. Try to hack together a simple pool game. You'll be amazed of how much maths and physics go into a simple game that millions use and enjoy.
'At this point in the book, I was originally going to present a BSP-based renderer, to complement the BSP compiler I presented in the previous chapter. What changed my plans was the considerable amount of mail about 3-D math that I’ve gotten in recent months. In every case, the writer has bemoaned his/her lack of expertise with 3-D math, and has asked what books about 3-D math I’d recommend, and how else he/she could learn more.
That’s a commendable attitude, but the truth is, there’s not all that much to 3-D math, at least not when it comes to the sort of polygon-based, realtime 3-D that’s done on PCs. You really need only two basic math tools beyond simple arithmetic: dot products and cross products, and really mostly just the former. My friend Chris Hecker points out that this is an oversimplification; he notes that lots more math-related stuff, like BSP trees, graphs, discrete math for edge stepping, and affine and perspective texture mappings, goes into a production-quality game. While that’s surely true, dot and cross products, together with matrix math and perspective projection, constitute the bulk of what most people are asking about when they inquire about “3-D math,” and, as we’ll see, are key tools for a lot of useful 3-D operations.'
(Michael Abrash, "Graphics Programming Black Book Special Edition")
Not much math. Some simple physics like velocity and momentum transfer that you can learn in a tutorial (in a day). I think it is important to make the distinction between game development (lots of simple math and complex "pluggable" formulas) and game engine development (yes, you need to understand linear algebra,trig, and perhaps calculus).
I believe, when the parent said "hack together a basic pool game," they meant "hack together just enough of a game engine to write a pool game on top of it, and then write said pool game atop it."
No, game development includes 'game engine development' - the majority of companies write their own engine or have heavily modified a licensed engine. And you often need to understand quite a bit of math to use even off the shelf engines - to debug issues and to tweak stuff.
Perhaps you're referring to what industry folk call gameplay programming? There's a lot less hardcore math there - but you still typically need to understand basic physics, trig, interpolation, etc.
Most of the time working with a game engine does not involve inventing any new mathematics, so there is an upper bound on just how hardcore it can really get :)
'At this point in the book, I was originally going to present a BSP-based renderer, to complement the BSP compiler I presented in the previous chapter. What changed my plans was the considerable amount of mail about 3-D math that I’ve gotten in recent months. In every case, the writer has bemoaned his/her lack of expertise with 3-D math, and has asked what books about 3-D math I’d recommend, and how else he/she could learn more.
That’s a commendable attitude, but the truth is, there’s not all that much to 3-D math, at least not when it comes to the sort of polygon-based, realtime 3-D that’s done on PCs. You really need only two basic math tools beyond simple arithmetic: dot products and cross products, and really mostly just the former. My friend Chris Hecker points out that this is an oversimplification; he notes that lots more math-related stuff, like BSP trees, graphs, discrete math for edge stepping, and affine and perspective texture mappings, goes into a production-quality game. While that’s surely true, dot and cross products, together with matrix math and perspective projection, constitute the bulk of what most people are asking about when they inquire about “3-D math,” and, as we’ll see, are key tools for a lot of useful 3-D operations.'
(Michael Abrash, "Graphics Programming Black Book Special Edition")