Ostras Neo_one y eso? Qué te ha hecho tomar esta decisión? En cualquier caso mucha suerte en tus futuros proyectos!

Este hilo es antiguo pero hace tiempo que no me pasaba, para los que queráis ampliar temas de C++ un buen libro es Effective C++ Third Edition:

https://www.amazon.es/Effective-Specific-Programs-Professional-Computing/dp/0321334876/ref=sr_1_1?ie=UTF8&qid=1539433856&sr=8-1&keywords=effective+c%2B%2B

Cuando los topics de ese libro estén dominados sería bueno ponerse al día con los cambios en C++11

La universidad de la vida.

Lo primero, cual es tu especialidad? Estoy viendo el video del tecnocampus y hacen incapie en lo de multidisciplinar, a ver, esto es fácil, si te gusta el cine y quieres convertirlo en tu profesión, generalmente serás, o bién actor, o bién director, o camara, o el músico que hace la banda sonora, o guionista, o productor, etc.. puede que incluso seas actor y guionista, o actor y director y sepas manejar una cámara, pero desde luego no serás todas las cosas a la vez, tal vez al hacer tu propia película indie, pero no en una película donde empresas e inversores ponen pasta.

Lo que vengo a decir es que la formación de videojuegos está algo verde y es excesivamente multidisciplinar, a ver, es bueno conocer todos los campos, pero a la hora de formarse por que va un concept artist o un modelador / animador 3d a querer aprender a programar? o por que iba  un programador de videojuegos a estar en una clase de programación donde le nivel ha de ser lo suficientemente bajo para que los que están ahí por el diseño y la animación también lo entiendan? Al final se queda en algo mediocre en todas las areas.

Por eso te pregunto, que es lo que quieres hacer? Quieres ser programador? aprende programación, ya sea donde estas ahora, o en una ingeniería de verdad, o en FP, y por tu cuenta claro, pq ni los masters ni la ingenieria te van a enseñar el 100% de lo que necesitas saber para ser programador en una empresa de videojuegos, por eso es bueno hacer proyectos personales., Quieres ser concept artist? pues bellas artes y/o una escuela de arte, ej: JOSO, Quieres ser animador? escuela de animación, ej: Pepe School, Quieres ser diseñador? ahí si que no se que decirte, quizá en ese caso el grado sea buena opción, pq vayas donde vayas te van a engañar igual, no deja de ser un negocio, ni siquiera todos los profesores son profesionales de la industria cualificados para enseñarte, una buena parte si lo son, otros son solo caras conocidas sin nada que aportar, otros casi ni o nunca han pisado una empresa (ni de videojuegos ni de ninguna otra cosa) en su vida.

Así que ya sabes, no te comas el marketing de los masters y grados con patatas, ninguno te puede asegurar trabajar de esto ni estar cualificado para hacerlo, si no ya verás cuando compares el discurso del primer día con el del último, solo depende de ti y del esfuerzo que le pongas en llegar ser desarrollador de videojuegos, que si has entendido el mensaje, lo "de videojuegos" es solo la coletilla, has de ser muy bueno y apasionado en tu especialidad, mas allá de que luego lo emplees para videojuegos.

Cuando tu ejecutas un programa, el código binario de ese programa pasa por la ram y se manda a la CPU los cachos que se van ejecutando o los datos que se van creando. Cada vez que instancias un array, una estructura, o llamas a una función que va al stack, estas usando la memoria, cuando cargas una textura, primero la lees en la memoria ram, haces las operaciones pertinentes para descomprimirla si hace falta, se copia a la vram, y luego se borra de la ram, lo mismo con los modelos 3D. Propiedades como la vida de un personaje, su daño, su inventario, su posición en el mundo etc, están en ram.

Para ser mas correctos, están en la caché del procesador en el momento de ser utilizadas, pero debido a lo limitada que es la caché se va copiando páginas de la posición de memoria que estas intentando leer, y se copia de la RAM claro.

Por favor, especifique el lenguaje https://en.wikipedia.org/wiki/List_of_programming_languages

Muy interesante. Pero, a menos de que me equivoque, si yo por ejemplo rendereo un objeto u objetos 3d usando una proyección ortonormal usando por ejemplo glortho, queda bien. El problema viene cuando el fondo ya no se ve en perspectiva. Y si primero rendereo los objetos de frente con glortho y después el fondo con gluperspective, se "desfasan" los objetos 3d del fondo. Pues mientras los primeros están en un "espacio" que tiene por lo general el tamaño de la pantalla X: 0 a anchoPantalla, el fondo se renderea en un sistema de coordenadas que va de X: -1 a 1. 

¿Me equivoco?

Saludos y gracias por tu(s) respuesta(s)
:)

A ver, te aseguro que para conseguir lo que quieres lo puedes hacer con modelos 3D  manipulando la matriz de transformación, el hilo que puse de stack overflow menciona un par de ejemplos buenos, el de Guilty Gear Xrd donde crean una matriz hybrida en la que en el eje horizontal hay 70% de ortogonal 30% de perspectiva para que no se fugue en los extremos de la pantalla como comentaba, el otro ejemplo, el que pre-fuga los objetos según la posición de la cámara también es interesante, aunque no ponen un ejemplo de juego donde se utilice.

El problema es al ver este comentario que has hecho, que para empezar la funcionalidad built-in de matrices de OpenGL quizá no sea lo mas adecuado ya que tienes que crear la matriz a mano para hacerla hybrida, supongo que se puede hacer con la built-in pero yo por ejemplo ya solo utilizo shaders a los que le paso una matriz manipulada por mi y si lo necesito la vuelvo a manipular en el shader, es como se hace hoy en día.

Lo que tienes que tener en cuenta es que OpenGL es una API para dibujar en 2D, todo lo que haces por mucho que emplees coordenadas 3D son solo para cálculos matemáticos que acaban siendo rasterizados en un plano 2D, con lo cual ese "desfase" del que hablas es que simplemente estas dejando que las mates u OpenGL hagan algo que deberías manipular tu, no se si me explico pero a veces, sobretodo al empezar, hay esa falsa percepción de que te tienes que adaptar a lo que te deja hacer OpenGL pero cuando se trata de pintar, teniendo shaders en realidad puedes hacer lo que te de la gana, se trata solo de encontrar las matemáticas adecuadas.

En juegos indie y de mobil se utiliza mas Unity, en juegos AA o AAA de PC/Consola y sobretodo 3D se utiliza mas Unreal, aunque al final para aprender eso no importa demasiado, aunque como demanda de empleo diría que tiene mas Unity. Si no tienes un equipo muy potente utiliza Unity o tira por incluso otro motor como Cocos2D-X, yo siempre recomiendo aprender con algo que te de conocimientos algo mas transversales que Unity, por que al final si sabes programar juegos da igual con que herramienta te toque hacerlos, pero si solo aprendes Unity puede ser que estés muy limitado y no aprendas otras cosas muy importantes.

Al fin y al cabo el lenguaje estandar de facto en la industria es C++, y Unity precisamente utiliza C#, con lo que muchas cosas de C++ no las llegarás a ver si solo utilizas Unity.

El tema de centrar la cámara en la acción influye en tu percepción si, pero realmente el truco de estos juegos es no utilizar perspectiva 3D o elementos 3D al 100%, algunos elementos son planos o 3D pero modelados de una forma poco realista y exajerada, pero la técnica mas interesante y que creo que es lo que estas buscando es la de renderizar objetos 3D con una matriz ortonormal en lugar de perspectiva, o incluso mezclar una de perspectiva con una de shearing para eliminar esa "fuga" en los extremos de la pantalla, aquí tienes un hilo en stackoverflow sobre el tema:

http://gamedev.stackexchange.com/questions/86960/mixing-perspective-and-orthographic-projections

Buenas compañero, apuntado queda!

Se percibe realmente bien, muy buen ejemplo de como coger elementos simples y hacer un buen diseño en mi humilde opinion, parece muy entretenido.

Se ve bastante bién. En una gráfica de gama bastante baja (GTX 420) va a unos 15 fps y un poco laggy, pero va y se ve bién. Que herramienta o herramientas has utilizado para crear los modelos y sobretodo, las texturas PBR?

Me parece perfecto lo de empezar por C, creo que es un proyecto ideal para hacerlo con raylib, tiene todo lo que necesitas para crear este proyecto, el tema de pintar elementos 2D en una ventana, leer interacción por parte del usuario y un modulo para simulación de físicas, tienes varios ejemplos, hay uno llamado physics_basic_rigidbody.c que te puede ser especialmente útil. Si el módulo de físicas de raylib se quedara corto puedes utilizar box2d, pero es algo mas avanzado, no seria lo mas aconsejable.

raylib: http://www.raylib.com/index.htm

box2d: https://github.com/erincatto/Box2D

Como juego de referencia, podrías mirar "The incredible machine" de 1993, sin llegar a implementarlo todo por que tiene muchos elementos, pero está bastante claro, objetos de diferentes tamaños y densidades que pueden caer, deslizarse y rebotar hasta llegar a un botón, palanca, etc, puedes hacer que también consista en explotar globos, o solo hacer llegar un objeto concreto de un sitio inicial a una meta.

TIM: https://www.youtube.com/watch?v=kl7hT2GiO5E

Los pasos que te aconsejo seguir son los siguientes, te tendrás que basar en los ejemplos de raylib para saber como hacerlo y tener muuuuuuucha paciencia por que los inicios siempre son difíciles:
- Crear una ventana con raylib
- Pintar un objeto
- Arrastrar el objeto con el ratón
- Crear un botón que al hacer click cree un objeto que puedas arrastrar
- Crear un escenario (por código) en el que haya varios objetos con físicas.
- Crear un botón que active las físicas en lugar de hacerlo al empezar el juego
- (Ahora ya deberías poder crear objetos, colocarlos y posteriormente activar físicas)
- Otro botón que reestableza la posición original de los objetos. (has de tener guardada la información del escenario en una estructura que te permita saber donde va cada elemento y que propiedades tiene)
- Empezar a crear un puzzle con esos elementos.
- Crear otra estructura con otros objetos con diferente posición y propiedades y activarla cuando se acaba el primer puzzle
- (Ya habrás encadenado los dos niveles)
- Crear varios niveles.
- Extra: intentar que la información de los niveles salga de un archivo de texto en lugar de estar en el código.
- Agregar menú inicial, botón de pausa y salir.
- Entregar

Puedes preguntar aquí las dudas que tengas, el autor de la libreria raylib también está por este foro y quizá te pueda echar un cable.

Saludos.

Lo de los recursos es relativo, a las resoluciones de antaño no te digo que no, pero piensa que un juego isometrico 2D require una imágen de cada elemento, osea una textura, para objetos que puedes rotar necesitas una imágen de cada angulo, y para objetos que se pueden rotar y animar necesitas una imágen de cada ángulo de cada uno de los frames de la animación, para que se vea decente en una resolución a día de hoy es una locura de información de textura.

Por supuesto hay trucos en 2D, puedes utilizar animación esqueletal 2D, que no se lleva especialmente bién con el isometrico, y para escenario intentar re aprovechar pequeñas texturas para componer estructuras mas grandes. Aún así lo veo mucho trabajo. Normalmente para juegos en esta camara pero render 2D los personajes se hacían en 3D y se pre-renderizaban offline todos lo frames de las animaciones desde todos los ángulos a una o varias sprite sheets y es lo que se shipeaba con el juego. Un añadido a esta técnica es tener los frames pre-renderizados de diferentes objetos combinables por separado por ejemplo, personaje / arma / armadura para cada uno de los ángulos y frames de animación y componer un solo sprite sheet insitu en el momento en que por ejemplo, cambias un arma por otra, esta técnica era la empleada en Diablo 2.

Yo a día de hoy tiraría por el 3D, creo que al final serán menos recursos, piensa que, si es un dungeon o edificios por ejemplo, todas las paredes de ladrillos pueden utilizar una única textura de ladrillos de, digamos 1024? y luego una encima para crear variaciones / suciedad, un dirty map vaya, en cuanto a personajes y otros objetos animados solo tienes un modelo cargado con sus animaciones en lugar de todas las texturas que supondría cada una de las animaciones desde cada angulo, es un ahorro, ademas al ser un modelo 3D su aspecto como el color de la ropa o complementos no requerirían una nueva versión del modelo, solo cambiarle la textura de color o incluso simplemente cambiar un parámetro en el shader que lo esté pintando.

Otra opción es combinar escenario 3D con personajes 2D como se hacia en Ragnarok online, pero me sigue pareciendo un curro tremendo para los personajes.

Vigila con el bump mapping por que estas marcando mucho pezón. Usa Unity, por que si no tienes un PC pepino con Unreal 4 no vas a poder trabajar cómodamente.

Yo te aconsejo que resuelvas todo lo de los indices en CPU y subas simplemente una lista de vértices con los atributos de cada uno y lo pintes con glDrawArrays, se que con glDrawElements parece mas optimo por que la cantidad de vertices del buffer es mucho menor ya que no repites, pero a la práctica esto no funciona bien, para un mismo vértice probablemente necesites diferentes normales, incluso diferentes UVs, según la face que estas pintando, y eso significa que por cojones has de repetir el vértice (mas bien repetir la posición y cambiando la normal u otros atributos que varíen para esa misma posición en otra face) ya que no puedes tener una lista de indices para un atributo y otra lista de indices para otro.

En resumen, mi consejo, resuelve los indices de los atributos en CPU y sube una array con todos los atributos resueltos a la GPU, te será mas fácil y más cómodo para futuras operaciones.