lo malo es que por mas que busco no dicen que tipos de certificaciones tienen como para poner una academia, que segun las fotos que veo en facebook tambien esta medio improvisada? que garantia dan de que de verdad vas a aprender?
No sé si esa información sale en la página (no recuerdo). Uno de ellos estudió diseño de juegos en Holanda, el otro si es alguien empírico, no ha estudiado nada de juegos afuera ni nada de eso, sino que estudió puramente programación en general.
Antes que nada, viendo el portafolio de trabajo de los dueños, parece que son excelentes artistas gráficos digitales y 3D, y excelentes usuarios de Maya (asumiendo que han creado todos los gráficos renderizados -carros, salones, el edificio chino- sin ninguna ayuda de plantillas, sino que desde cero, en cuyo caso es admirable).
A gente como yo que ha logrado aprender un poco de gráficos (procesamiento de GIFs realizado absolutamente por mí incluyendo GIFs animados), se nos hace necesario saber qué lenguaje de programación van a usar, y la lista completa de herramientas, aparte de Maya.
En lo personal me parece bastante caro, y aún más caro tomando en cuenta que el curso es más específico a Maya que a otras herramientas igualmente potentes, como Blender. Probablemente el precio de estos cursos está ajustado para gente que puede costearse las Macs y PCs multimedia más recientes y poderosas junto con paquetes comerciales como maya. En otras palabras, obviamente no mucha gente va a poder pagar estos cursos.
Yo no podría pagar ninguno de esos cursos. Pero lo más importante es que si hablamos de una audiencia mínimamente educada, tienen una enorme competencia, desde cursos de Blender pirateados (que se orientan más al diseñador digital y programador multimedia), hasta libros de programación de juegos 2D, que están pirateados, y sino, están desde unos $40 a $60, los cuales son excelentes.
Además hay muchísimo material en libros y gratuito sobre algoritmos de renderización 3D, que es algo más complejo y que sé que está fuera del programa de esos cursos, pero aunque sea más complejo, es mucho más barato que esos cursos, y es extremadamente importante para programadores puramente gráficos con habilidades artísticas.
Incluso el material anterior, los documentos más difíciles de encontrar, son mucho más baratos que esos cursos, y no menos complejos (incluyendo libros específicamente con los fundamentos de crear juegos, ya sean 2D -lo más común- o 3D).
Hasta yo tengo por lo menos un libro en papel, y varios otros, sobre cómo crear juegos 3D (además del sitio web de Graphics Gems). Todo este material sé que solo puede llegar a dominarlo alguien que se dedique 100% a gráficos, juegos y multimedia, pero ese material yo lo tengo, son libros de nivel legacy que hablan de muchos más conceptos que los libros más recientes, pero muchísimo más baratos y que podría enumerar todos los puntos en los que sobresalen (no me costaron ni siquiera $70).
Lo mejor sería saber si quien vino a anunciar esto recibió clases con ellos, y también cómo logró o lograron aprender exactamente a crear el juego que he visto que han estado anunciando por bastante tiempo (Enola).
Un resumen de qué han tenido que hacer para aprender y para haber logrado crear ese juego (cosas sobre cómo consiguieron el equipo de captura de movimiento, etc.) sería bueno para que tengamos un "walkthrough" de cómo proceder de la mejor manera en este ámbito informático específico.
En todo lo que mencionás de los libros tenés razón, y también tenés razón que solo quien se dedique al 100% a eso va a poder hacer las cosas, aunque difiero en que hay que aprender todo lo de algoritmos y procesamiento de gráficos, y demás cosas, porque en general estoy en contra de cualquiera que quiera hacer su propio motor en lugar de usar uno existente por sencillo que sea (en parte porque no soy un master programmer pero en parte porque el objetivo es hacer un juego, no hacer una super engine). Con las preguntas que hacías:
Los lenguajes a usar son Java (con unas librerías para desarrollo de juegos que ya te dan una "engine" bien básica para no tener que hacer todo desde cero) y Unreal Engine. Todo eso se va a ir expandiendo a medida la academia tome más forma porque no se quieren quedar solo con esas 2 cosas.
No he recibido clases con ellos. El chero que estudió juegos afuera lo conozco porque trabajamos juntos en un juego una vez, y el otro lo conozco porque fuimos compañeros de universidad. Enola es un proyecto que comencé a principios del año pasado y antes de ese había estado trabajando con unreal engine por un año (cuando trabajé con el chero este) y bastante de lo que sé del UE lo aprendí de él. El proceso para hacer el juego ha sido bastante complicado como para explicarlo aquí porque no solo es el manejo del engine sino el diseño del juego, la conceptualización, diseño de jugabilidad, de interacción, unión de la historia con gameplay (que es importante en juegos como este, aunque no tan importante en juegos como Diablo, por ejemplo) y cosas del "management" de distintas cosas del proyecto (en el juego están metidos tanto personas nacionales como extranjeras y trabajar con eso es un rollo que no lo sacás de un libro sino de la experiencia). A nivel de diseño del juego ha sido un proceso de muchas pruebas, muchos playtests, muchas iteraciones, y muchas ideas desechadas hasta llegar a un diseño que sí funciona porque los diferentes elementos trabajan bien juntos.
Pero fuera de eso, tengo 12 años de experiencia con Maya y 15 años de experiencia con 3d en general (también empírico), y me puedo el Maya *casi* de pe-a-pa como dicen. Como también aprendo otros programas, sé qué usar para qué y qué para qué otra cosa. Por eso es que los modelos los hago en Maya, pero por ejemplo las animaciones faciales las hago en otro. Luego este año conseguí otro programa que se basa en reconocimiento óptico que es el que estoy usando para motion capture con las cámaras de playstation (y ahora que he conseguido un kinect, voy a probar eso también), y aunque el resultado es más bonito solo complica más las cosas porque tengo un programa para mocap, otro programa para animación facial, y luego Maya donde hago la unión de las 2 animaciones y el "cleanup" para arreglar errores del mocap. Todos esos procesos han sido basados en pruebas, combinando las técnicas que ya tenía desde hace años con otros truquitos nuevos que he ido adquiriendo, pero que siempre van fundamentados en técnicas viejas (tipo, cómo voy a ponerme a cleanup y arreglar una animación en mocap si no supiera cómo animar un personaje o configurarle el esqueleto). Y ahuevo la unión de todo eso con el unreal.
Al final de tooooooooooodo eso está saliendo un juego que ya tiene mecánicas de juego sólidas (aunque sencillas) y que ya tiene su core following. No es algo que le va a dar duro a Crysis 3 a nivel de gráficos y tecnología en general, pero no se puede comparar un juego hecho entre 5 bichos contra un juego hecho por un ejército de alemanes (o un ejército de desarrolladores en general). En general la parte más complicada ha sido la conceptualización, porque con las partes técnicas se tienen básicamente 2 opciones: o se sale con lo que se quiere hacer, o se quita la característica y se compensa de otra forma. El diseño de Enola está basado tanto en decisiones conceptuales (como lo del género y jugabilidad) como en limitantes técnicas (como el por qué no tiene combate), y así se va viendo qué elementos se combinan para hacer el juego.
A graaaaaaaaaaaaaaaaaaaaaaaaaaaandes rasgos y de forma extremadamente reducida, eso ha sido el juego. Dar un "walkthrough" es la de nunca acabar porque han entrado demasiadas cosas en juego de las cuales solo el 25% son cosas más "técnicas."
