Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





mi proyecto U3D... Esto no es serio

Iniciado por kidchaos2k9, 20 de Julio de 2010, 06:03:10 PM

« anterior - próximo »

kidchaos2k9


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



blau

Aqui un valiente.

He probado el juego, siento decírtelo,  ^_^' pero ha sido traumático, esa gestión de cámara hace que sea injugable.

otra cosila menor es que el blending de los disparos no esta activado y hace un efecto muy feo.

y es que no he podido probar más.

Al menos, la idea de atacar una nave nodriza es muy buena, me gusta :) , pero ya te digo, le falta mucho pulimento.

Animo ;)

josepzin


[EX3]

Bienvenido, hacia tiempo que no se presentaba alguien con tantas energias por estos foros :D

Cita de: josepzin en 21 de Julio de 2010, 08:27:34 AM
Bienvenido y ¡haz un video del juego!
Con capturas de pantalla igualmente cumple :)

Salu2...
José Miguel Sánchez Fernández
.NET Developer | Game Programmer | Unity Developer

Blog | Game Portfolio | LinkedIn | Twitter | Itch.io | Gamejolt

kidchaos2k9


Gracias por los comentarios,

Igual no lo he explicado bien, tengo muy claro que lo que enseño es el prototipo inacabado que hice hace cuatro años y decidí tirar todo el código y volver a empezar, cuesta mucho de apreciar el valor de la programación, teniendo en cuenta varios aspectos:

- El motor del juego estaba hecho desde cero, me basé en un tutorial de flipcode llamado "Enginuity" al que dediqué tres o cuatro meses, tiempo que debería haber aprovechado en aprender mas técnicas de 3D para la parte gráfica... Como mínimo a hacer transparencias entre otras cosas...
- La idea de "atacar una nave nodriza" a mi tambien me encanta, si teneis la oportunidad de jugar al Uridium 2 de Amiga se ve mas claramente la idea en 2D, claro... Pero en 3D es muchisimo mas complicado, supongo que los únicos juegos de donde sale la influencia sería el Wipeout o el F-Zero de GameCube donde las pistas de carreras son autenticas montañas rusas, pero sobre todo y eso es lo que mas me importa es que la cámara no determina la posición del jugador y por tanto el punto de referencia para entender donde está la derecha o izquierda... Hace poco me comentaron que el sistema de cámara funciona igual que el del Mario Galaxy, y me hacía gracia pensar que lo había desarrollado tres años antes!
Vsualmente, es imposible de explicar todo el trabajo que hay detrás para que la nave se mueva, en un juego típico en 3D lo normal es calcular una altura fija sobre el terreno en el eje de las alturas y quedarse tan pancho,... Sin embargo, cuando uno de los profesores del Master me creó un sistema de colisiones con terrenos basado en triangulos arbitrarios me metí en un lio de proporciones inimaginables... Si se piensa en ello, no es tan sencillo como pueda parecer ya que para poder moverte sobre un plano de cualquier orientación, no sirve de nada detectar donde está el arriba y el abajo, tienes que tener en cuenta todos los triangulos del terreno y sus orientaciones y todavía es peor para conseguir cambiar de un triangulo a otro, hay que detectar exactamente las aristas de salida y entrada entre triangulos y aun peor es que tienes que conocer la libreria de colisiones al dedillo para poder integrar esta idea, me he pasado otro medio año consiguiendo reprogramar este sistema dentro de las físicas de Bullet.
El segundo problema que hay detrás de esto es que una vez funcionando, la camara no se puede colocar hasta que la nave esté fijada correctamente a un triangulo, si esto falla, no hay nave ni camara! Además hay que "parchear" la camara en la medida de lo posible para que relativamente la nave siempre quede en la posición inferior de la pantalla pero al mismo tiempo te permita ver un rango del nivel hacia el que avanzas y por el que deben venir los enemigos...
Y aun mucho después de esto, hay que tener en cuenta que el modelado de las pistas ha de ser consistente, con que un solo triangulo no esté bien orientado o se borre sin querer o el paso de un grupo de triangulos a otro falle, todo el sistema se descompone... En definitiva, una autentica locura...

Creo que he superado el límite de carácteres...

kidchaos2k9



Ahora que ya he empezado no voy a parar...

En cuanto al motor gráfico, el aspecto mas "potente" es la serialización de mallas: Utilizo mi propio sistema de exportación de mallas indexadas (sin stripificar) para las naves y los niveles. Sin llegar al nivel del MD3 o formatos parecidos, basicamente exporto estructuras de datos de tipo vertex Buffer, sobre un fichero binario que entran directamente a los buffer de la memoria gráfica, tengo definidos dos formatos, k3d para modelos sueltos y k3s para un nivel completo basandome en un sistema de Portal-Rendering, ahora mismo el exportador está programado en Python para exportar desde Blender, aunque en el Master lo programé sobre el MaxScript del 3DSMax...

Explicaría otras cosas como la cache de recursos, la definición del nivel por scripts de lua o el módelo MVC que he aprendido del GameCoding, pero abriré un nuevo en la sección de diseño para comentar otra dudas...

Saludos,

josepzin

No he leído todo lo que has escrito, ya luego me tomaré un "ladrillo-moment" ;)

Pero sólo quería decir que el Uridium (de C64) fue uno de mis juegos favoritos!






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.