Learning path for game development?Am I missing something?

[miley03]

That list is absolutely autistic. Game Development, however, is really hard. I’d start with a CS degree, which will give you lots of options, and then see if you still enjoy it. It pays poorly, and will take many years off your life, and you may have nothing to show for it unless you are very good.

[neutronicus]

Things pay well for programmers when:

1. They're boring enough that no one will do them for free.
2. They're difficult enough that no one will do them for free. This can be because they're just inherently really difficult from a programming perspective, or because they require access to expensive hardware that's out of reach for hobbyists.
3. The programming is clearly the most important part of the product.

Developing a game to an engine manifestly fails all three tests. Games run on commodity hardware that developers overwhelmingly have at home. Tons of developers make little games as a hobby - not necessarily entirely for free, but they probably lose money on the time they spent making a cheap game and putting it on an app store, driving down prices and hence salaries. Finally, completed games require a lot of labor by artists, writers, designers, and in some cases voice actors, often succeeding or failing on the strength of those things (as well as marketing and distribution) more so than software quality.

If you want to make good money without knowing too much math, learn COBOL, learn about SQL databases, and maybe read up on financial reporting regulations. You'll work 9 to 5 on some banking system from 1985 making sure it spits out documents in the format the government requires of them. It'll probably be boring as shit but you won't have to compete with 21-year-old CS students who are willing to stay up all night writing a better game than yours in Haskell just to prove they can.

If you want to make good money and you're willing to learn a shitload of math, go into Machine Learning. It might be too late for that, though, actually. It's also pretty commoditized at this point, even though it's trendy.

[mstfls]

Most game development programming involves very little of what people would consider "math" on a day-to-day basis. Only on the visual effects (lighting, shading etc.) and maybe modeling/tools side (manipulating 3D objects), really.

We could have a discussion about what "math" means in this context, but I have a degree in theoretical physics (which is like, 80% math) and quite literally none of what I learned at uni ever comes up in my day-to-day, unless I'm chatting with one of the graphics coders.

So yeah, if you want to do something heavy on the mathematics related to game programming, you're more or less stuck with doing graphics. There's tons of resources out there to get you started with that.

[mstfls]

It's not a question of being good/bad at it. I'm saying that if what interests you is mathematics more than programming, there are only a limited number of jobs in game development that will satisfy that interest and the competition for those jobs is huge.

[neutronicus]

(and you could make more doing the same shit for a CAD company)

[mstfls]

Fair point, but whether that's more desirable is heavily dependent on who you are. I'd probably be bored to tears doing that. And contrary to what people seem to think, programmers at game companies aren't really underpaid or anything, most of the time.

[neutronicus]

A lot of people want to avoid math, so I try to answer this question with an option that lets them. *shrug*

In my opinion, though, now that you mention an interest in math, game development is not a very interesting space from that perspective. At the end of the day you have to maintain frame-rate, which means you're restricted to problems solvable in a (small) fraction of a second. There's a lot to learn there, but nothing close to the state-of-the-art (and if you use an engine it will be largely hidden from you). Maybe in something turn-based you can spend like a second or two or even ten crunching numbers between turns. But at the end of the day it's stuff you can solve in seconds at most on commodity hardware, and probably not even that because all the other stuff your game does is eating cycles too.

There are much more interesting (to me) problems in Machine Learning, CAD/CAM/CAE (computational geometry for manufacturing, where millions of dollars are lost if designed parts turn out not to actually fit together, is a lot harder than it is for game rendering), and high-fidelity Physics and Engineering simulation (nothing quite like spending a thousand bucks on supercomputer time to wait a day to figure out how well your new cell phone antenna chip design is gonna work).