Esto es documento de diseño para un juego de naves?

[kidchaos2k9]

Buenas,

Pues me lanzo al ruedo de los diseñadores para oir sugerencias sobre esta propuesta de diseño de niveles... He visto pocas ideas desarroladas por aquí, así que "patente en trámite" como díria Homer ;), aunque voy a ir muy rápido, intentaré explicar lo mas claramente posible todos los conceptos:

Antes de empezar, breve introducción, aunque también he dejado un post en la sección de Principiantes...

U3d: Un matamarcianos en 3D insipirado en el genero clásico totalmente olvidado hoy día, pero con un novedoso 3D... Se puede descargar un demo "injugable" para pillar la idea
   http://uthreed.sourceforge.net/
   
Ideas que servirian para aclarar el concepto:
  - "Wipeout matamarcianos"
  - "U.N. Squadron en 3D" ó "Uridium 3D"
  - "Un Starfox aun mas 3D!"
  - "i don't understand jack shit about this game... it's unplayable "
 
El guion, me lo saco de la manga ahora mismo: "Atención Red Wings! Atacad y destruid la nave nodriza"... Con este guión, Tiembla Molyneux!!

En cuanto al aspecto técnico del juego que tengo en desarrollo ahora mismo, y para no programadores, el funcionamiento del motor es el siguiente:

  - Una vez el programa se inicia, se lee un fichero de scripting Lua con la definición de elementos del nivel/Actores de juego, cada actor genera una señal/evento en el motor que produce la creación de este actor en los sistemas de lógica y opcionalmente en la física, gráfica y eventos del juego, aquí es donde me entra la primera duda: Hago que cada actor puede generar y responder a eventos del motor/juego(p.ej "ataco si el enemigo está cerca", o "no me pinto si la camara no me ve") o bien, lo programo dentro de la misma lógica de juego? ...
 
  - La programación en scripting con Lua en esta caso, es muy potente para el diseñador y un autentico dolor de muelas para el programador, pero básicamte lo que tengo escrito arriba es cierto y aunque todavía está incompleto... Quiero decir que el diseñador podría llamar a funciones internas del juego tranquilamente para modificar el color de un personaje o pasar el juego de ventana a pantalla completa, pero como programdor tendría que tener en cuenta que esa llamada no petará todo el motor gráfico (pasará seguramente)...
 
   Antés de seguir, simplificaré algunos conceptos de programación, relacionando el sistema de lógica con la librería LUA, el sistema físico con la libreria BulletPhysics y el sistema gráfico con DirectX+Grafo de escena...
 
  Pues ahora pasemos al tema del diseño del nivel: Supongo que lo voy a escribir a continuación estaría a medio cámino entre el guión de SpaceBalls y una clase de tecnología de 3o de ESO (o P-3 soy demasiado viejo para enterarme), ajustense los cinturones...
 
  Los actores de juego que se me ocurren serían los siguientes:
   * Nivel, Cuadrante de colisiones de nivel, Cuadrante visual de nivel, Cámara, Nave, Proyectiles, enemigo/s, particulas.
   * Además también tengo pensado dos conceptos importantes: Los Grupos lógicos de elementos(Por ejemplo el nivel agrupa sectores) y la Jerarquización (pej "la nave tiene una relación padre-hijo con la camara")
   
   El método de trabajo que yo utilizo además de lapiz y papel, es usar Blender como si se tratara de un editor de juegos 3D, me dedico a ir poniendo "cubos" en la escena y empiezo a ponerle nombres absurdos a cada uno y a añadir la información que se me ocurra en las properties, una vez hecho esto a partir de un script de Python exporto toda esa información al fichero de exportación en Lua y ya puedo probarlo en el juego. La principal ventaja que persigo es no modificar el código fuente para ir haciendo pruebas de nivel, chulo? Ójala fuera tan fácil... Con el Blender tambien puedo poner una cámara en cualquier parte y hacer un render rápido para ver si las dimensiones de los objetos se aproximan a lo que quiero ver,...
     
  Describiendo mas detalladamente los elementos, pienso que siempre debe haber información común y específica de cada Actor:
   - Común:
   * Tipo de actor
   * Nombre
   * Matriz/Posición del actor
   * Color (no lo he hecho pero si que recuerdo ver en algún juego el blending de colores para diferenciar a los jugadores/IA's/etc...)
   * Tamaño de la caja contenedora (Bounding Box)
   * Relativo a Padre?
   * Grupo lógico al que pertenece
   * Sistema gráfico: Indicar un tipo de forma básica (cubo, esfera) o una referencia a un módelo 3D
   * Sistema Físico: En este caso Bullet obliga como mínimo a definir dos bytes(8 bits):
   ** Flag de colision(un número del 1 al 256 en multiplos de 2, 1,2,4,8....256) y
   ** Mascara de colision para explicar como colisiona cada actor con el resto de actores físico (cualquier valor entre 1 y 256), 0 indicará que no hay colisión posible. Este es el sistema mas sencillo/primitvo que ofrece Bullet aunque otras posibilidades incluye código mas complejo (mejor no pensar en ello todavía)
   En Bullet se pueden definir objetos rígidos con y sin dinámica (respuesta a una colisión) y "fantasmas" (detectan una colisión sin afectar al objeto colisionante, que seguramente debo utilizar para activar señales al sistema de lógica)   
   ** Grupo físico: Sin llegar a tener un sistema de animación de personajes, Bullet permite que dos a más objetos físicos estén relacionados a través de una "interfaz de acciones", el ejemplo mas claro sería decir que si pusiera un vehiculo-coche, Bullet podría entenderlo como un cubo/chasis y cuatro donuts/ruedas unidos por ciertas reglas físicas y manejados a través de conceptos como volante,dirección, freno, etc... Los elementos físicos responden independientemte pero ¿milagrosamente? funcionan de manera conjunta...  :o
   Es decir, posiblemente para cada elemento del grupo, definiría la forma física y los flags de colisión, aunque pensandolo bien, estos elementos también debería indicarlos en el sistema gráfico... Me estoy mordiendo la cola... :(

Me iré a comer y después seguiré comiendo la olla... :)_

@B^)>

[kidchaos2k9]

   Pensandolo mejor, que tal si el grupo físico solo define las referencias a objetos y en el motor me encargo de montarlo? Estudiandolo por casos:
   -Nivel: Las referencias a los sectores deberían estar antes de empezar a montar el nivel o después? O procesarlo antes y después para hacer comprobaciones antés de cargar los sectores y acabar de montar la estructura después de tener los sectores?
   - Sector de colisión: Debería comprobar que los sectores no se pueden solapar entre ellos. Las dimensiones no deberían sobrepasar las establecidas por el nivel, también hay que añadirlas a la lista de visibilidad? Deben contener el índice de sector del
   nivel?
   - Sector de nivel:Las mismas que para colisión?
   - Puntos de spawn: Ahora caigo! Desde donde arranca el jugador y los enemigos? Defino uno para cada sector? comprobar a que sector existente está asociado...
   - Nave: Los parametros de velocidad los cogería del nivel,...
   - Proyectiles: No creo que influya en el orden
   - Enemigos: No creo que influya en el orden
   - Partículas: Tampoco!!
   
   Segun todo esto, mantendría este orden para cargar los elementos, y tendré en cuenta que el nivel es lo primero y lo último que inicio   
   
   Ahora, dedicándome a los parametros espécificos:
   
   + Nivel:Todo lo que se me ocurre poner sobre variables de nivel que creo que pueda necesitar y no he puesto en otros actores:
      * Tamaño máximo del nivel, o bien reaprovecho los valores de la caja contenedora?
      * Número de Cuadrantes de colisión (hay límites?)
      * Número de Cuadrantes visuales (hay límites?)
      * Escala/Unidad mínima de movimiento (tamaño mínimo de un triangulo?)
      * Sistema de referencia del nivel (RH,LH? XYZ, XZY?)
      * Velocidad máxima de actores en el nivel
      * Velocidad lateral máxima de actores en el nivel
      * Skybox? referencia a los gráficos para pintar los fondos?
   + Camara: Parámetros típicos de camara:      
      * fov
      * aspect
      * near
      * far
      * Tipos de camaras? De juego, que enfoquen a un enemigo, que enfoquen puntos interesantes, pensar en un posible blend de camáras?
      * La posición ya ha sido definida, sin embargo estos datos podrían ser relativos al tipo de cámara que utilizamos
      * Relativo a padre otra vez: Definir la cámara de manera que siempre esté enfocando al jugador?      
   + Sector físico
      * índice de nivel, bitmap de sectores adyacentes?
   + Sector Visual
      * idem que arriba
   * Puntos spawn
      * Velocidad de salida del spawn?
   + Nave:
      * Ratios de disparo? Parametros físicos de masa/material?
   + Proyectiles:
      * Textura para el billboard, entraría dentro de la información de recurso... Parametros físicos de masa/material?
   + Enemigos
      Parametros físicos de masa/material?   
   + Particulas:
      Solo visuales o añado también propiedades físicas?

Buf! Después de tanto escribir, me han entrado muchas ganas de programar! Voy a ponerme a ello

@B^)>

[Makaimura]

Con el game engine de Blender se puede hacer prototipados buenos y rápidos? Van bien el modulo de físicas?

[kidchaos2k9]

Pues no se bien que decirte... ^_^'

La respuesta rápida sería que he hecho unas "pequeñas" adaptaciones del sistema de colisiones de Bullet para poder detectar exactamente el triangulo donde se encuentra el jugador y aunque se que Blender lleva el Bullet integrado no se hasta que punto puedo programarlo/scriptarlo para que haga lo mismo... Eso sin contar que del Game Engine de Blender ni "flowers", aunque podria aprender rápido...

Sin embargo, estoy de acuerdo contigo en que tendría que prototipar el juego rapidamente, pero no tengo ni idea de como hacerlo!  :grrr: Tardé un año en programar la "demo" que comenté al inicio del post y con todo eso no llegué ni a comenzar la programación de los enemigos  :shit: y ahora mismo ando igual de liado para intentar que todo lo que he escrito tenga alguna lógica,...

Sería mas rápido que le pudieras echar un vistazo a la "demo", pero voy a intentar hacer una idea de lo que necesito y a partir de aquí acepto cualquier sugerencia:

- Genero de juego: Shoot'em-up o "matamarcianos" en perspectiva tridimensional, los juegos de referencia podrian ser: "Tempest"(Jeff Minter por si suena) o "Torus trooper" del Kenta Cho, o bien, Wipeout/F-Zero disparando :) ...

  - Por lo poco que se de programar juegos, entiendo que necesito crear un "nivel", como si fuera una pista/carretera donde vas de un punto A a un punto B, y se me ocurre que debo separar la pista en secciones, de manera que en cada sección active los posibles enemigos que atacaran al jugador ... ¿Cual sería la mejor manera/mas rapida de dividir la pista? La manera mas sencilla que he usado, ha sido a partir de algún programa de modelado, secciono la pista como me parece y creo una lista de secciones, de manera que a medida que el jugador avance sobre la pista y entre/salga de cada sección se activan las IA's de cada sección... BSP/Portales ya serían palabras mayores, cierto?
  - ...
 
Estoy absolutamente en blanco  :(
 

[Mars Attacks]

Blender es una mina para todo lo que has comentado. Su Game Engine soporta muchísimas piezas básicas de lógica que te permiten resolver sin programar una sola línea de código un montón de problemas típicos de los juegos (físicas, colisiones, trazado de rayos, inputs, movimiento, fuerzas, orientación hacia un objeto...), y además se puede extender ejecutando scripts, así que te sugiero que te empapes al máximo de su Game Engine y seguro que ves automáticamente la forma de resolver muchos de tus problemas.

[kidchaos2k9]

Gracias por la sugerencia,

:.. Ahora mismo, llevo el motor bastante "avanzado", muy posiblemente si empezara el proyecto desde cero me habría puesto a ello a la hora de sacar un primer prototipo rapidamente, pero ahora mismo mi vena de programador ya no me permite tirar todo el código que tengo hecho  :'( así que solo estoy utilizando Blender para diseñar el nivel y exportar datos... en fin... Encontré un ejemplo de octrees que su autor decía que lo podía integrar bastante bien con el Game Engine de Blender y la verdad que prometía...

En definitiva, al final voy a combinar varias técnicas a ver que tal puede salir... Seguiré comentando ideas de juego que vayan saliendo

Saludos,

@B^)>