¿Qué SceneGraph es óptimo para comenzar con la programación de juegos pequeños?

Soy un desarrollador de aplicaciones web Java (principalmente del lado del servidor) desde hace 7 años que recientemente se interesó en el desarrollo de juegos (no sé por qué, tal vez estoy aburrido). Hoy estaba buscando marcos. Leí sobre algunos gráficos de escenas y eché un vistazo a jMonkeyEngine . Fue recomendado aquí y aquí .

Mi primer objetivo era crear un plano simple y una esfera que se pudiera mover usando el teclado. Bueno, como mencioné, soy desarrollador web y nunca programé nada más, así que comencé con los tutoriales de jMonkey. Pero no pude hacer que funcionaran. Eché un vistazo a la wiki pero noté que la documentación parece ser muy pobre, al menos en comparación con lo que estoy acostumbrado. Luego eché un vistazo a algunos otros gráficos de escenas (también para C ++) pero también parecen tener una documentación pobre incompleta y obsoleta.

¿Alguien puede recomendarme un gráfico de escena que esté bien documentado con muestras de trabajo? ¿O hay algo así como la "guía definitiva" para entrar en este tema? ¿Primero necesito saber cómo desarrollar mi propio gráfico de escena para que funcione o es posible entender los principios abstractos y usarlo desde un punto de vista superior?

De alguna manera tengo la sensación de que necesito entender el interior profundo de un gráfico de escena para usarlo bien (como es el caso de las herramientas ORM en el desarrollo web, no puedes usarlas bien si no entiendes las bases de datos)

Lo siento si esta pregunta es demasiado 'novata', pero solo quiero ponerme de pie y dar mis primeros pasos.

Un gráfico de escena es una herramienta. Realmente no es una herramienta adecuada para cuando recién estás comenzando en el desarrollo del juego.

Creo que lo que buscas no es un gráfico de escena, sino solo un marco de algún tipo.

Normalmente recomendaría XNA porque es realmente bueno (potente, moderno, bien documentado, apto para principiantes). Pero es C # y puedo ver que eres un hombre de Java. Si prefiere seguir con Java, quizás un buen lugar para comenzar sería los puertos Java de los antiguos Tutoriales de NeHe OpenGL (esto no es un marco, pero es un conjunto de tutoriales sobre cómo hacerlo (en un nivel bajo) ) el tipo de cosas que un marco hace por usted: cargar y renderizar modelos, cargar texturas, etc.

En las primeras lecciones aprenderá acerca de las matrices de transformación, que es básicamente de lo que se tratan los gráficos de escena (en el caso común).

Para describir brevemente un gráfico de escena: Digamos que tiene un modelo de molino de viento, se define en su propio espacio. Lo traduces a donde quieres que aparezca en tu espacio mundial . Ese molino de viento tendría un objeto secundario para sus palas giratorias, por lo que aplicaría una transformación de rotación a las palas, y también heredaría la traducción de sus padres para colocar las palas correctamente en el mundo.

Cuando comienzas, haciendo pequeños juegos, no tienes que preocuparte tanto por tener esta gran estructura de datos complicada. Por lo general, solo tendrá un par de modelos a los que aplicará matrices de transformación directamente.

(Los gráficos de escena también se usan para cosas relacionadas con el rendimiento, como ordenar por material, seleccionar, etc., todo innecesario para el principiante y para la mayoría de los juegos pequeños).

El gráfico de escena ha perdido ligeramente su lugar como algo imprescindible. Principalmente porque un motor centrado en el gráfico de escenas está tan ligado a la idea de un scenegraph que se confunde a sí mismo. El hecho es que varias partes de un motor necesitan una visión diferente del mundo, mientras que un motor centrado en la escena tiende a imponer la misma vista en todas las partes del motor.
La escena como se ve tradicionalmente, una jerarquía de objetos principales y objetos secundarios es buena para las transformaciones, pero puede ser totalmente inapropiada para la representación, donde está más interesado en qué materiales se utilizan (bueno, la ubicación también cuenta, pero hay diferentes formas de lidiar con eso y padre-hijo no garantiza que estén juntos, solo tendemos a verlo de esa manera).
En muchos juegos encontrarás que tienes una raíz de escena con muchos niños, pero esos niños rara vez tienen hijos propios. Los pocos que tienen hijos también podrían actualizarse y omitir la escena, ya que agrega complejidad innecesaria y pérdida de rendimiento (cada transformación verifica si su padre está sucio, mientras que solo unos pocos tienen un padre que se ensuciará siempre (la raíz del mundo rara vez movimientos)

¿Por qué no usar un motor de juego como Unity3d ? Es muy conocido por ser fácil de usar y con excelente documentación. Lo probé brevemente y me impresionó lo bien documentado que estaba todo el API y una serie de buenos tutoriales. Tuve problemas con mi brazo y alguna etapa y tuve que pedir ayuda a mi esposa. No tiene idea de la programación, pero pensó que Unity3D era realmente genial. Puede lograr mucho simplemente arrastrando y soltando. Puede usar varios lenguajes de script con el motor. Admite JavaScript, entre otras cosas, lo que supongo que dado el fondo debería ser atractivo. Puedes obtener una versión gratuita con todas las características que necesitaría un desarrollador principiante de juegos.

Si no necesitas 3D, entonces GameMaker es una gran alternativa. Es realmente fácil entrar y hacer juegos. Lo usé en la universidad e hice un par de juegos con él. Gran diversión. Te permite realmente concentrarte en hacer el juego y no tienes que pensar mucho en la tecnología. Puedes armar un juego completamente con solo apuntar y hacer clic. Pero a medida que progresa y comprende cómo funciona todo, comienza a escribir sus propios scripts.

En mi opinión, funciona mucho mejor que decir GameSalad, que no tiene lenguaje de script. Tan pronto como comienzas a hacer cosas más complicadas, se vuelve realmente molesto con solo apuntar y hacer clic, creo.

Estoy completamente de acuerdo con Kaj. Para obtener más información sobre este tema, consulte gamearchitect (por cierto, si está interesado en el desarrollo del juego, simplemente lea todo el sitio, especialmente el antiguo)