Sin duda me atrevo a resaltar la respuesta de mxgxw.
Geometria, algebra lineal, sin duda sera el pan de cada dia de aquel que tome en serio la programacion de juegos. La necesidad de lenguajes como C, C++, Lua, squirrel y otros se haran presentes eventualmente. OpenGl vs DirectX sera en mas de alguna ocacion el tema de busqueda en google. Mas de alguna vez se indagara en diferentes paradigmas de programacion y habran muchas indecisiones de arquitecturas de desarrollo.
Motores como Unity, GameMaker o similares, sin duda son excelentes herramientas para el desarrollo de un videojuego, en terminos de rentabilidad y tiempos de desarrollo. Mas sin embargo en terminos de aprendizaje me atrevo a decir que su colaboracion es inversamente proporcional a la abstraccion que estos brindan. No me atreveria a decirlo sin antes haberlos usado, pues fue emocionante usar gamemaker hace mas de 8 anios y poder replicar un ninja gaiden en menos de dos meses cuando mi repertorio solo contaba con saber un poco de VB6.
Unity, fue un escape temporal al descubrir la complejidad de un engine. Pues muy diferente es tener todos los subsistemas a la orden de un click. Pues por jebus que es mucho mas sencillo agregar un componente de cuerpo rigido a sumergirse en las alucinaciones de euler o verlet. Arrastar un componente de sonido, uno de sprite, agregar colliders visualmente. Conoces los conceptos, pero dificilmente su complejidad, no mientras las cosas funciones. Si sirve para que repararlo? o algo asi iba una frase.
Talvez en algun momento se puede tomar como que estoy en contra de los motores, pero no es asi. Nuevamente, son buenas herramientas que dan enormes prestaciones, como se dice Out-of-box. Portabilidad y extensiones las acompanian. Es mucho mas gratificante poder ver algo funcional en el primer dia, que pasar semanas o meses en ello, que para aquel que cuyo deseo por el arte no es lo suficientemente grande, abandonara la tarea si se va por el segundo escenario.
Pero la generalizacion y abstraccion siempre conllevan costos, y estoy en contra de que les den soluciones sin explicar cual es el problema o aun, sin decirle si existe alguno. Esos motores esconden demasiado, y al final lo que haces es diseniar un juego no programarlo. Aunque le puedo dar vuelta al mensaje y decir que estos motores permiten concentrarse en materializar tu idea del juego y no desviarse en complejidades, no todos ven la rentabilidad que esconde conocer la complejidad.
En mi humilde opinion de una persona que pueda o no estar sumergido en el area de juegos, me gustaria decirles que hubiera cogido una licenciatura en matematica o fisica, disculpen si no conozco el nombre en si de las carreras, porque esas me hubieran sido de mucha mas utilidad para el desarrollo de juegos no limitandolos a estos, pues la institucion donde lleve ingenieria en sistema, no cumplio ninguna de las expectativas, y menciono la institucion porque puede que en otra la realidad sea diferente. El hecho de que tengan un titulo diferente no impide que se desempenien de diferente forma hasta cierto punto.
Sin duda que me aleje un poco de la pregunta en si, la oriente mas a la respuesta dada de lo que la UFG brinda. No para desvirtuarla, pero si para aquel que venga en busca de informacion tenga un mejor panorama y no se ciegue en terminos de las tecnologias nombradas, y asi al leer un pensum pueda determinar que le sera util y que no.
Y a la vez dejare el nombre de un libro que a mi me sirvio bastante y con suerte a otro tambien: Game Engine Architecture - Jason Gregory
No lo tomaria tan literal y evitaria la parte de las implementaciones, pero en sus primeros capitulos te da una idea bastante general de lo necesario para un juego, no necesariamente para todos los juegos. Y menciono que esto ha sido muy mi opinion fruto de experiencia, en la realidad dos personas pueden hacer lo mismo y obtener resultados diferentes.
