Hola a todos!

Queria comentar algunos de mis avances en la programación de juegos y del motor que he estado haciendo en los últimos años (Hacia tiempo que no entraba y he visto que mis antiguos posts han desaparecido!!):

 - Hace algunos años pude completar una primera "demo" del juego que tenía en mente, un "remake" en 3D del juego Uridium, que lo presenté como proyecto del Master de videojuegos de la UPF.
    - Durante un año trabajé en hacer la demo y el "motor" de juego con las siguientes especificaciones
      - Windows/Directx9,
      - Importación/Exportador de mallas/"diseño de niveles" desde 3dsStudio.
      - Sistema de colisiones basado en Opcode, con un sistema personalizado para poder "caminar" sobre mallas en 3D (para hacer una idea, como el Mario Galaxy o el F-Zero de la N64,)...
      - Algo de integración con Scripting usando Lua, para la generación dinámica de música basada en eventos (aunque no estoy seguro de si todavía tengo ese código o lo perdí :()

   - Por desgracia, nunca he podido llegar a formar un pequeño equipo para llevar adelante el proyecto... No me gusta considerarme un "programador solitario", pero posiblemente puedo llegar a ser bastante terco y creo que como todo el mundo, me siento estimulado persiguiendo mis propios objetivos, supongo que con mi experiencia actual si que he llegado a entender que para llegar a "mi juego", hay que analizarlo con suficiente cabeza para copiar lo que necesitas de los "otros" juegos y finalmente poner tu parte...
   Finalmente, decidí volver a comenzar el proyecto,... Aunque estaba satisfecho con los resultados, supongo que estaba bastante confuso, me faltaba completar las colisiones, la IA, ... Pero cayó en mis manos una copia de libro "Game Coding Complete", con el código fuente completo del motor para Windows y un "didáctico" juego de ejemplo que pensé que podría integrar bien con mi trabajo anterior (iluso de mí), las especificaciones:
      - Windows/Directx9/10
      - Arquitectura basada en MVC y otros patrones de diseño aplicados a juegos,
      - Grafo de Escena
      - Física bullet
      - Integración con a extensión LuaPlus (se puede debuggar de manera remota)
      - Código de IA
      - ... y MUCHISIMO MAS
      * Además yo he añadido:
      - Importación/Exportador de mallas/"diseño de niveles" (incluyendo la exportación del nivel como un octree)  desde Blender en formato propio binario.
      - Adaptación del algoritmo de "caminar sobre malla" al sistema de física...
      - Lógica de juego basada en el patrón máquina de Estados
      - Capacidad para scriptar aspectos del motor de juegos y el comportamiento de los actores de juego desde Lua.
      - ... y mas aspectos que seguramente me dejaré en el tintero
   
   Por el momento, estoy limitando todo el motor al primer minijuego que quiero usar como presentación: Atrapar una bola que se lanza hacia el jugador...
   
   Creo que me faltaría poco para poder liberar una "release", y todavía estoy muy enfrascado en la programación, pero estaré encantando de escuchar opiniones, sugerencias y demás...




   Saludos

@B^)>
   
P.S: No puedo subir imágenes, actualizaré el post cuando lo haga

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^)>

Salam alekum! mira que saludo mas original...

Me llamo Sergio y soy de Barcelona, llevo algún tiempo registrado aunque creo que es la primera vez que escribo, así que saludos a todos y felicidades por esta maravillos comunidad de Strateros...

Supongo que me podría incluir dentro del grupo de principiantes aunque tengo cierta edad  y experiencia: Soy ingeniero en informática y también he estudiado un Master de Videojuegos,... Mi objetivo es trabajar como programador de videojuegos y por supuesto pretendo desarrollar un proyecto como carta de presentación, aunque estoy llegando a un punto límite... Me considero un "programador aventurero" con una idea en la cabeza y los recursos mas económicos posibles para ponerlo en marcha, trabajando en casa en mi tiempo libre, mucho, ahora que estoy en paro.

En cuento al proyecto, que tengo bautizado como "U3D" pretende ser un mata-marcianos inspirado en juegos de la antigua escuela ("Uridium 3-D" sería el nombre para los jugadores veteranos de los 16-bits ;) ) .Un buen punto de referencia es el remake del "Tempest" que hace Kenta Cho en "Torus trooper" aunque con menos rafagas de disparos, en definitiva, adaptando las reglas de los matamarciandos como simplicidad de movimientos, enemigos sin inteligencia, rapidez de reflejos y todo movido en un universo 3D por alguna targeta gráfica con billones de triangulos por segundo, ... Por soñar no me quiero quedar corto :P...

Antes de continuar, desde aquí podeis descargar el primer "prototipo" inacabado hasta la fecha, por cierto, el comentario que me han hecho en la página me parece muy acertado, creo que lo pondré como cabecera del título:

http://sourceforge.net/projects/uthreed/

(para windows y corazones fuertes, usar los cursores para moverse y el ratón para disparar aunque no hay colisiones, 'c' cambia el modo de la camara. Tengo un fallo engorroso de programación con las mallas que hace que la camara se vaya al infinito, 'ESC' para apagar, por cierto el programa a veces no cierra bien y hay que matarlo desde el administrador de tareas...  :grrr:)

Resumiendo un poco, estoy desarrollando el motor/juego de manera gratuita como tarjeta de presentación, las especificaciones de juego serían para PC con windows, versiones recientes de DirectX y targeta gráfica 3D.  La programación del juego es en C++ utilizando Visual Express 2008 , aunque nunca he conseguido superar una prueba de programación en las entrevistas de trabajo :) ...  en algún momento diseño o analizo los diagramas de clase con algo de UML utilizando BOUML...

Utilizo el motor de programación didáctico del libro "Game Coding Complete" de Mike McShaffry, para el que no lo conozca se puede resumir como un motor de juegos basado en el patrón de diseño MVC (incluyendo gestión de eventos), con soporte para DirectX y Shaders, Grafo de Escena, caché de recursos, Scripting con LuaPlus, integración de la libreria física Bullet, sonido con DirectAudio/soporte OGG y hasta un juego completo de ejemplo que funciona perfectamente, llevo mas de un año trabajando con él y iluso de mi, pensé que con todo eso acabaría en dos días... Antes de que alguien diga algo, me interesa aprender a programar, no hacer juegos con motores cerrados.

En cuanto al diseño, utilizo Blender como herramienta de modelado/editor de niveles, mis modelos son un poco "cúbicos" ya que no se trabajar en 3D, pero me defiendo lo suficiente para poder importar modelos que encuentro por internet y programar los exportadores de modelos y niveles a un formato propio utilizando el Python de blender.

Lo único que puedo decir es que despues de todo este tiempo sigo un esquema de trabajo caotico, sin ninguna documentación, con un modelo que supera las ¿cien y subiendo? clases, tampoco tengo claro cuanto tiempo podré seguir trabajando sobre el proyecto, y tampoco tengo experiencia ni ninguna dirección para poder confirmar en que dirección tirar... Aun así, ya he llegado a un punto de saturación en el que creo que tengo suficiente base para empezar a programar la lógica de juego, aunque el agotamiento mental ya es alto   :-X...

Supongo que esta no es la mejor manera de pedir algún tipo de colaboración, aunque me imagino que este tiene que ser el día a día de hacer un juego:
-  Tengo claro que aunque la propuesta en apariencia sencilla y divertida, pero no acaba de calar, pero una cosa que no puedo evitar decirme es que si no tengo la posibilidad de hacerlo ahora, dentro de la industria las posibilidades serán todavía mas escasas... Me llevé un  "mal sabor de boca"  al acabar este proyecto en el Master después de trabajar como un loco durante ese año. Sin pretender desanimar a nadie, estoy de acuerdo con un comentario sobre un Modder amateur del L4D que leí hace poco: "Hacer un videojuego es la tarea peor recompensada que conozco"...
- No estoy muy interesado en los temas de diseños conceptuales ni los gráficos de juegos, me gustaría que fuera visualmente vistoso, pero en mi caso como programador prefiero ver cuatro cubos persiguiendose que una explosión que me ralenticé mi pobre Radeon...
- Me costaría bastante explicar todo el trabajo realizado para poder ver como repartirlo, el código está bastante saturado y mal comentado, no me considero ningún crack en matematicas 3D, DirectX, ni estructurando el código,... y supongo que estoy afectado de esa extraña enfermedad del programador de no quere enseñar el código para que no te lo copien o aun peor me lo tiren abajo...

En definitva, que con este post no pretendo ir mas allá de explicar la situación actual de mi proyecto y tampoco tengo ninguna expectativa de despertar algún interés. Me digo a mi mismo que tendría que estar diseñando un nivel en vez de perder medio día explicando cosas sin sentido...

@B^)>

Hola,

Este es mi primer post por aquí, saludos a todos!  :)

El caso es que estoy haciendo unas pruebas en OpenGL para importar directamente arrays de vertices indexados desde Blender hacia mi motor (usando glDrawElements sin extensiones)... Mas que nada por aprendizaje tengo claro que prefiero hacerlo así en vez de usar algún formato de exportación... Aunque finalmente puedo ver el modelo con la textura en mi motor, no se acaba de ver bien (ver imagen si la puedo subir), y no tengo claro si es un problema de la parte de OpenGL o de la exportación y hasta donde llego creo que he limpiado el DepthBuffer y he probado a activar/desactivar el cull y con todas las funciones del depth buffer que se me han ocurrido

Podeis sugerir alguna ayuda? Gracias por adelantado

@B^)>

Mas o menos el código para el render de cada frame es este...

Código [Seleccionar] Expand



glFrontFace(GL_CCW);
glEnable(GL_DEPTH_TEST);

glDisable(GL_ALPHA_TEST);
glDisable(GL_STENCIL_TEST);
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
glDepthFunc(GL_GREATER);

glDepthMask(GL_TRUE);
glShadeModel(GL_SMOOTH);
glDisable(GL_CULL_FACE);

glViewport(0, 0, 640, 480);

glClearDepth(0.0f);
glClear(GL_COLOR_BUFFER_BIT+GL_DEPTH_BUFFER_BIT+GL_STENCIL_BUFFER_BIT);


glLoadIdentity();