Bueno, no lo has dicho, pero supongo que querrás encaminarte a la especialidad de programación.

Depende de lo que más te guste programar te recomendaría una cosa u otra. Si hay algun aspecto de la programación de videojuegos que te llama más o al que te gustaría orientar tu formación, mi consejo es que te centres en él. Es decir, si no te interesa por ahora la programación de gráficos, física... pues usa librerías para ello que te faciliten la vida. De esta manera podrás ir abarcando mejor lo que te propongas, y tal vez no lo pases demasiado mal.

Este es mi consejo, basado en mis experiencias personales. Pero claro, es que das muy poquitos detalles tío. Si nos cuentas más sobre lo que te interesa podríamos darte enlaces, consejos más aprovechables...

Pues yo sí que estaré. Pa una vez que puedo ir a algo, no voy a fallar ;-)

Será la presentación en sociedad de mi proyecto, cocinado a fuego lento desde hace meses.

Nos vemos allí

Has leído el primer post de este subforo?

A mí se me ocurre otra cosa que podrías hacer. Definir una clase para cada uno de los tres tipos que comentas, p. ej: Grado, Radian, Gradian (sí, se llama así). Entonces, para cada una de las clases, defines operadores de conversion implicita (operator=). Claro que tambien tendrías que definir los operadores +, -, * ....

Ogre, la librería de gráficos, hace esto mismo. Existe la clase Radian y la clase Degree, y ambas son intercambiables de manera automática gracias a esos operadores. Puedes ver el código en este fichero. Prácticamente te diría que copiaras ese código y lo usaras. Donde pone Real, cámbialo por float. Sí, de esta manera lo tendrías ya hecho. Ah, y no te preocupes, es Open Source :-)

De todos modos, mi consejo es que te líes a hacer esto sólo si ves una utilidad grande, o si te vas a divertir haciéndolo/aprendiéndolo. Porque como ya te han dicho Ruben y Hechelion, realmente no es una funcionalidad muy importante, nada que no puedas controlar de manera sencilla.

Conste de antemano que estoy de acuerdo con lo que te han comentado, JMAA. Lo que intentas conseguir es imposible, no ya para ti, sino para cualquiera. Y mucho menos sin tener medios ni experiencia. En serio, olvídalo.

Lo que no entiendo es que se hayan cebado contigo de esa manera. Vale que ya tienes mala reputación, vale que se te conoce de hace tiempo... Pero eso no es excusa para decirle cosas así a alguien, y menos cuando no ha insultado a nadie, al menos no voluntariamente.

Siempre me ha parecido horrible y detestable insultar a alguien por internet. Es totalmente de cobardes. Preguntaos si os comportaríais así si estuvierais hablando en persona con JMAA.

Huelga decir que mi respeto hacia la integridad de quienes deben aupar este foro acaba de pasar por un bache. Puede que JMAA tenga mala reputacion, pero con respuestas como las anteriores es el foro en sí quien la va perdiendo.

Hay otra técnica que también se usa, conocida como selección en buffer. No sé si es lo que quieres, pero es muy útil para conseguir precisión 'pixel-perfect', usando la imagen tal y como sale por pantalla.

Básicamente, consiste en lo siguiente: cuando el usuario hace click renderizas tu escena en memoria, en un buffer. En el buffer, pintas los objetos con colores planos, un color único para cada objeto. En un mapa, almacenas cada objeto identificándolo con su color. Usando las coordenadas del ratón puedes pillar el pixel concreto sobre el que se ha pulsado, comprobar su color, y buscar en el mapa qué objeto se pulsó.

Para mejorar la eficiencia, puedes usar un buffer pequeño (por ejemplo, 320x240 para una resolución de 1024x768). También puedes limitar lo que se dibuja en el buffer a una sección de la pantalla.

Aquí tienes un enlace a un post de los foros de Ogre3d donde Sinbad explica cómo implementarlo. Es pseudocódigo, nada de C++ ni Ogre.

No, no tengo nada en contra de Paco el Pocero.

Enhorabuena por el éxito. A ver si pruebo el jueguillo un día de estos (pirata, of course) jajajjaajajaja

Sorry :-)

Tienes también PythonOgre, la versión en python de Ogre. Aunque puede que esté algo desactualizada, pero bueno, ahí está.

Ostrass, me ha sorprendido un montón

Akira Toriyama + megaman + braid = OMFG YEAH!

jeejejjeje

Tiene una pintaza, a ver qué tal os va. Suerte!

Con Ogre se han hecho muchas aventuras gráficas. Ogre es multiplataforma.

Con Mogre tendrías las ventajas de programar Ogre en C#, y si empleas Mono también puedes conseguir que el resultado sea multiplataforma.

Feliz navidad!

Comed todo lo que podáis esta noche que nunca se sabe lo que puede pasar mañana... o_Ô

A todo esto sólo puedo decir: ains.

kraj0t no comparto tu opinión, porque no verá ningún tipo de resultado hasta después de años y no creo que eso le vaya a motivar para seguir en el tema. Intentar abarcar demasiado puede ser un problema, vale más empezar haciendo cosas pequeñas e ir poco a poco abarcando más y más. Una visión global le puede venir bien, pero desde un principio debería de ir viendo resultados y como se hacen las cosas porque sino sabrá lo mismo que cualquier chaval que se dedique a jugar con juegos y no tenga ni idea de programación, ni de nada más. Además un programador no tiene porqué hacer ningún gráfico ni ningún modelo 3D. Una cosa es un grafista y otra cosa es un programador y otra cosa es un guionista y otra cosa un director y otra cosa un músico

En el máster que conozco, el de la Pompeu, dedican 3 meses a todo lo que no es programación: 3ds, diseño, produccion, marketing, etc. Los programadores entran en el curso con ganas de empezar a mancharse las manos de código, y eso no es bueno. Un programador sin objetivo no sirve de nada. Pongo el ejemplo del master de la Pompeu porque es el que conozco, y porque los resultados están a la vista de todos.

Lo que quería decir es que antes de hacer un análisis técnico de tu juego necesitas saber qué será necesario para hacerlo, pero no ya a nivel de código, sino a nivel de diseñador y artista. No estoy diciendo que se lleve años sin ver resultados, cualquiera puede hacer un jueguito en Unity en unas semanas o días. Estoy diciendo que no reinventes la rueda; ya hay mucho camino andado en esto de los motores de videojuegos y herramientas y tal. No te vayas a liar ahora con OpenGL o a definir un importador de modelos de 3Ds cuando eso ya está hecho y rehecho. Si vas a programar algo, antes entérate de cómo está hecho en otros programas y copia lo que te interese.

aunque siempre puedes encontrarte con el hombre orquesta que toca todos los instrumentos, aunque hoy en día es algo rarito, rarito.

Cada vez salen más y mejores juegos indie donde unas pocas personas se las tienen que apañar para el desarrollo completo. Por no hablar de los juegos flash, que pueden hacerlos una o dos personas. Además, nadie empieza siendo programador 100%, eso sólo ocurre cuando una de las gordas (Ubisoft, Pyro...) te pilla para ser programador de una especialidad concreta en un desarrollo de decenas o cientos de personas. Aun así, todos necesitamos tener una visión de conjunto. El programador no trabaja solo, trabaja para los demás, de ahí que sea necesario tener esa visión de conjunto.

Pero vamos, que todo esto es personal, y todos los consejos son buenos  ::) Como dice EX3 no hay una fórmula concreta para aprender  :-[

Vendría bien que comentaras qué motor estás usando. Si estás usando Ogre, podría ayudarte de manera más precisa, porque conozco ese motor. Y si no es Ogre, seguro que alguien que lea esto puede ayudarte con el motor.

Dicho esto, a ver. Los quaternions... puff son algo jodidos. En Ogre, la clase Quaternion cuenta con métodos que te permiten trabajarlos de manera mucho más intuitiva, usando vectores y ángulos. Imagino (espero) que tu motor también contará con esos métodos que son básicos para cálculos con quaternions.

Prueba a poner este algoritmo en tu método Update de la cámara (en parentesis los nombres de variables):
1. pilla el quaternion (orientacionPrevia) de la cámara
2. pilla el eje de orientacionPrevia hacia donde está mirando tu camara (vectorDelante), en el caso de tu motor supongo que es el eje Y
3. calcula un nuevo vector (nuevoVectorNormal) pillando el vector de posicion actual de la camara y restandole el vector del centro del planeta.
4. normaliza nuevoVectorNormal. Con esto tienes en nuevoVectorNormal la dirección que apunta del centro del planeta a tu cámara.
5. haz el producto vectorial (cross product) entre el vectorDelante y el vectorNormal, y guardalo en un nuevo vector llamado nuevoVectorDerecha. Esto te está dando un vector ortogonal a los dos vectores, o para que se entienda mejor, un vector perpendicular al plano formado por esos dos vectores.
6. haz el producto vectorial entre nuevoVectorDerecha y nuevoVectorNormal y almacenalo en nuevoVectorDelante.
7. Ahora que tenemos los 3 vectores, uno para cada eje, podemos construir un quaternion (orientacionNueva) a partir de ellos. Algo que tal vez no sepas de los quaternion es que tienen que construirse a partir de 3 vectores ortogonales y normalizados. De ahí que hicieramos los productos vectoriales.
8. dale a la cámara la orientacionNueva, y listo.

Con esto te debería funcionar. Pero la verdad, con los detalles que has dado no sé si he escrito esta parrafada para nada o qué. ^_^'

PD: no sé si necesitarás que te dé tantos detalles, pero creo que es bueno explicarlo bien todo, por si alguien que sepa menos lee este post algún día.

Buenas afk y bienvenido, aquí estamos o hemos estado todos igual que tú :-)

Mi recomendación es simple: olvídate de programar. Aunque sepas programar de lujo, olvídate por un tiempo. Dedícate unos meses a estudiar cómo se hacen los juegos de manera global. Descárgate motores y herramientas, utilízalas, mira tutoriales. Haz algunos juegos o prototipos. Prueba a crear unos cuantos modelos 3d y animarlos. Busca algun tutorial para hacer texturas, photoshop... Siempre que veas algo de código, huye. En resumen, empápate de todo lo que no sea programar.

Prueba estas aplicaciones: GameMaker, Flash, Unity, 3D studio max, Blender, Unreal Development Kit, etc. Buscando por internet encontrarás muchas mas aplicaciones que te resultarán super curiosas.

Esto te va a permitir entender qué es lo que necesitas programar y cómo hacerlo. Si no, vas a estar dando palos al aire una buena temporadita, créeme. Una vez que sepas qué es lo que necesitan los diseñadores y artistas para crear un juego, estarás en la perspectiva correcta para empezar a diseñar el código de un juego. Sentirás que tienes más confianza.

No sé si te habrá servido de algo. Lo que sí sé es que a mí me habría servido de mucho haber hecho esto desde el primer día  ^_^'