Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Juego de estrategia 3D

Iniciado por Ocho, 01 de Enero de 2009, 02:17:16 PM

« anterior - próximo »

Ocho

La verdad es que me da un poco corte escribir a qui. Por que he visto que hay gente que sabe muchísimo, yo no se casi nada aunque tengo mucha imaginación programando soy un poco chapucero. Estoy haciendo un pequeño juego 3D de estrategia muy sencillo y con gráficos muy simples. Me gustaría con el tiempo poder proyecta sombras, pero no se que técnicas hay y que tipo de técnica se puede usar en un juego de estrategia donde puede haber una media de 1000 objetos visibles en pantalla. Además mi ordenador no es muy potente un AMD de 1.80 GHz. No se que técnicas se pueden aplicar y si hay ejemplos sencillos. He visto muchos ejemplos pero no se como se pueden aplicar a mi programa. Son demasiado enrevesados. Necesito algo más básico y sencillo para poder entenderlo.
El juego y el motor que estoy usando lo estoy programando en Visual C++ Express y DirectX 9.0. Los gráficos, texturas y animaciones son básicos pero por ahora mi objetivo es terminar el juego. Esta es alguna imagen del juego.





RobiHm

la verdad es que es el primer juego de estrategia que veo por el foro xD

de momento para ser un primer paso no tiene muy mala pinta, por lo que veo solamente se centra en la acción y no gestión, ¿no?
Web : Indómita
Blog : MiBlog
Evobas : Evobas
Kobox : Kobox

tamat

tiene buena pinta, felicidades.

mi consejo para sombras es que empieces por poner un circulo negro con alpha debajo de cada uno.

la siguiente opcion sería crear un shadowmap desde el foco de luz pero es un poco lioso, es renderizar en dos pasadas y aplicar un shader (aunque creo que openg tiene opciones para hacerlo sin shader).

aun así no creo que ponerle sombras sea prioritario, te sorprendería la de juegos que no tienen sombras y lo disimulan quemandolas en todos los objetos (y personajes), el truco es evitar que todo se vea muy brillante.
Por un stratos menos tenso

Loover

Muy buen trabajo. ¡Enhorabuena!

Si todavía no te estás centrando en la parte gráfica y es más un prototipo, deja las sombras y ese tipo de efectos para más tarde. Cuando tengas más o menos terminada toda la lógica del juego y quieras ponerte con lo visual, no estaría de más empezar a buscar a algún grafista que te hiciera una composición de como sería su visión del juego final. En base a esa composición, verás si es necesario o no ponerle sombras proyectadas reales, o simples círculos con alpha debajo de cada unidad, etc.
IndieLib Libreria 2.5d utilizando aceleración por hardware para la programación de juegos 2d.
Indie Rover The monkeys are reading!

josepzin

Si te atreves, puedes mirar el código del Glest.

Ocho



Gracias por las respuestas.

Lo de poner simples círculos ya lo había pensado.  El shadowmap por ahora me parece demasiado complicado aunque creo que por ahora seria la técnica mas adecuada en este caso.

En el juego por ahora es esto lo que se puede hacer.
Construir edificios.
Destruir edificios
Recoger recursos
Producir unidades
Abrir baúles y  puertas
Capturar unidades neutrales.
Luchar contra unidades enemigas.
Realizar misiones.
Hablar con personajes.

El  juego tiene un editor de mapas.

Para terminar esta primera etapa. Me falta el ataque de las unidades enemigas, es decir que puedan hacer ataques desde sus campamentos. También me falta de desarrollo de tecnologías.

Para hacer los modelos, escenarios y animaciones utilizo un editor que me hice en Visual Basic.   No paso mucho tiempo con los gráficos animaciones y personajes por que con 24 horas al día  no me llega  para programar y hacer el diseño grafico, teniendo en cuenta el juego puede tener cientos de objetos y cientos de personajes diferentes.
   
Lamento que no salgan todas las imágenes. Haber si puedo poner más en otro sitio.

Nato_msc

#6
Impresionante el trabajo que llevas hecho, parece que vas bastante encaminado, aunque creo que deberias reducir poligonos, porque si vas a mostrar tantos objetos en pantallas, mas las particulas que vayas a meter para el humo, hechizos, los efectos para el agua, arboles... no se me ocurre que mas, pero tendras que meterle bastantes cosas.

Por ejemplo, las casas esas, es indispensable que sean circulares? y la torre?  esos bidones de decoracion, las rocas, los personajes tienen tambien demasiados poligonos para lo que intentas, no hace falta que los objetos tengan muchos poligonos para que se vean bien, es mas, sin querer ofender, la pinta de los objetos que muestras es bastante fea, aunque como ya has dicho no te estas preocupando demasiado en eso, con unas buenas texturas y menos poligonos, tendrias una relacion calidad/rendimiento bastante buena, por ejemplo la torre, con hacer algo asi, que ademas es bastante sencillo quedaria de lujo.



Serian unos 20 poligonos nada mas y no se veria nada mal, porque al ser un RTS podrias alejar un poco la camara para que no se vea tanto el detalle (ni los fallos...).

Animo con el proyecto y mucha suerte.

Ocho

#7
Bueno aquí hay un par de imágenes que he colocado en otro sitio haber se salen.
Por cierto josepzin , ¿que es código de Glest.? ¿Dónde esta?.

Los polígonos no son muchos en realidad la mayoría de los juegos actuales tienen infinitamente mas polígonos. Para la mayoría de los objetos que se  ven apenas he dedicado unos minutos para hacerlos. Los personajes incluido animaciones, acciones y texturas algunos he tardado una mañana en hacerlos y otros una hora como mucho. Muchos objetos son feos y eso mismo me lo digo yo.  La perspectiva del juego la he puesto solo para sacar las imágenes pero se juega con la cámara enfocada hacia abajo.  En esa posición se dibujan pocos objetos. Pero se puede cambiar la perspectiva con la ruleta del ratón. Las cabañas son circulares por que mi programa las permite crear muy rápidamente rotando un perfil. Para mi es cuestión de tiempo. Ya que como he dicho solo dedico unos minutos para la mayoría de los objetos. Si ves por ejemplo SpellForce te darás cuenta que la cantidad de polígonos que yo utilizo es ridícula. Los personajes que yo he hecho tienen poquísimos polígonos. Los efectos de partículas usan un solo objeto por cada efecto y en muchos casos son objetos clonados.



josepzin

Cita de: Ocho en 03 de Enero de 2009, 02:13:38 PM
Por cierto josepzin , ¿que es código de Glest.? ¿Dónde esta?.

Ha! Hereje de la vida... no conocer el Glest :P

Mira mi firma > Glest.org

yens

Qué pasada Ocho, felicidades por el curro que llevas hecho! Dá gusto ver entrar a gente en el foro con imágenes y cosas hechas, molaría un montón ver un pequeño vídeo en movimiento también...

Por si te sirve de ayuda, me acabo de acordar que tucho, uno de los modeladores de Glest había sacado para descargar algunos de los modelos del juego, te dejo un link a uno de los posts de su blog, igual te sirven de ayuda: http://artbytucho.blogspot.com/2007/06/more-downloable-models.html

Ocho

Gracias

Después de descargar el Glest resulta que si lo conocía. Lo vi, hace mucho tiempo, pero no le hice caso porque no me gusto (Como juego claro). Los árboles me gustan, pero el entorno me parece algo pobre, no se le falta algo.  Las animaciones están relativamente bien. Pero el movimiento muy mal, los pasos de los personajes no se corresponden al movimiento. Un error bastante típico en muchos juegos, que hace parecer que los personajes están patinando por el suelo no andando. En algunos juegos actuales se ve que este error esta corregido. El juego esta bastante bien, pero es muy típico me gustan mas al estilo de Spellforce. Los gráficos en general están bien bastante elaboraros, sobre todo el tema de las texturas. Lo que me he dado cuenta es que esta en ingles, algo que no me gusta nada de nada. Supongo que abra una versión en castellano. Poder entender el código de Glest, me parece improbable, ya que parece estar basado en OpenGL, sistema que no conozco en absoluto. Por otra parte como una persona con educación básica va ha entender un programa hecho por un ingeniero.  De todas maneras muchas gracias por la ayuda y atención prestada.
Los personajes que yo uso tienen una media de 1000 polígonos. Contando que tienen manos con dedos claro. Pero las texturas que yo utilizo no son tan elaborarás.
Gracias yens por indicarme los de los modelos. Desgraciadamente yo no tengo, ni se usar "3D Studio max" así que  no he podido ver los modelos (En estos casos uso programas gratuitos, "3D Studio max" me parece un poco carillo para mi bolsillo, se lo dejare a los profesionales). Solo he visto las texturas que están muy bien, pero que tampoco me sirven, porque mi juego esta basado en una novela de ciencia ficción de 1000 paginas. Es decir, los personajes y juego en general tienen que seguir un guión, por lo que no puedo usar modelos al tuntún, sino que tienen que corresponder a la historia. En realidad el juego es una novela interactiva. No se trata de estar todo el día construyendo y destruyendo al prójimo. También tienen que haber algo de paz. Lo de hacer un video me parece una buena idea. Aunque no tengo mucha idea de cómo hacerlo. Por que con una pantalla de 800x600 supongo que ocupará mucho y tendré que ponerlo en algún sitio. Bueno de todas formas aquí pongo un video en flash de unos de los personajes del juego en movimiento, a ver si hay suerte y se ve.


http://www.terra.es/personal2/mmonje/Aprendiz.swf

[EX3]

#11
Cita de: Ocho en 04 de Enero de 2009, 11:10:13 AM
Lo que me he dado cuenta es que esta en ingles, algo que no me gusta nada de nada. Supongo que abra una versión en castellano.
Pues si quieres aprender de proyectos de otros o aprovechar la mejor documentacion disponible en la red tendras que aprender ingles me temo.

Cita de: Ocho en 04 de Enero de 2009, 11:10:13 AM
Poder entender el código de Glest, me parece improbable, ya que parece estar basado en OpenGL, sistema que no conozco en absoluto.
Un juego no es DirectX u OpenGL o SDL o XNA, no importa la api grafica que use si no como este programado el juego en si, la logica del programa, no el como se dibuja una textura.

Cita de: Ocho en 04 de Enero de 2009, 11:10:13 AM
Solo he visto las texturas que están muy bien, pero que tampoco me sirven, porque mi juego esta basado en una novela de ciencia ficción de 1000 paginas. Es decir, los personajes y juego en general tienen que seguir un guión, por lo que no puedo usar modelos al tuntún, sino que tienen que corresponder a la historia
Para hacer pruebas no necesitas hacerte las texturas ni modelos definitivos. El material definitivo del juego deberas hacerlo cuando el juego este programado, mientras tanto cualquier modelo podria servirte. Ten en cuenta que si hicieras modelo finales sin tener finalizado el proyecto podria ocurrir que tuvieras que hacer alguna modificacion importante del juego y por ello rehacer los modelos que ya tuvieras definitivos, en resumen, trabajo extra e innecesario. Para desarrollar tu juego hasta te bastaria un simple cubo para representar un edificio, por ejemplo, o un modelo del Quake para hacer pruebas de un NPC o el jugador mismo. Al fin y al cabo se trata de aprovechar tiempo en lo importante, que en este caso seria dedicarle a la programacion.

Salu2...

Edit: Por cierto que no lo he dicho, enhorabuena por el curre que lleva detras el proyecto, que para estar llevado por una sola persona tiene su merito ;)
José Miguel Sánchez Fernández
.NET Developer | Game Programmer | Unity Developer

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

gdl

El inglés es indispensable, me temo.

Ocho

Gracias por las felicitaciones.

Crea que se me ha interpretado  mal, lo que demuestra lo mal que me expreso y que escribo. Yo no se ingles porque tengo muchas dificultades con el lenguaje. Efectiva mente el ingles como otros idiomas son interesantes y facilitan el encontrar información en Internet. Aunque para programar parece que no es indispensable por lo menos en mi caso.
Por cierto yo todos los programas y juegos que tengo los tengo en castellano. Así que no debe de ser tan difícil hacer un juego en castellano. La mayoría de las empresas lo hacen, igual no me he dado cuenta y  el juego de ejemplo de Glest tiene alguna opción de instalación para que aparezca en castellano.
Tenéis razón. La lógica y como esta hecho el programa es lo importante y no el lenguaje o la librería utilizada. Desgraciadamente yo tengo mi propia lógica por que no he copiado técnicas de Internet por eso de no saber ingles, sino que me he inventado mis propias técnicas y formulas. Por lo que entender la lógica de los demás me cuesta más. Tened en cuenta que mi primer motor 3D estaba hecho en ensamblador, hay la lógica es lo único que vale. Lo único que he hecho es pasar la lógica de mi motor en ensamblador a DirectX lo cual me ha costado mucho. Quizás vosotros habéis tenido que leer mucha documentación en ingles para llegar a los conocimientos que tenéis; yo no.
Efectivamente para hacer pruebas se utilizan modelos básicos o incluso cubos. Yo por lo menos lo hago así. Quizás no lo he interpretado bien. ¿Lo que queréis vosotros es que pruebe vuestro motor?, vaya yo había interpretado que los modelos eran para probar en mi programa, que cosas.
Lo del curro del juego se extiende mucho mas halla. Por que como ya  creo que he comentado yo modelo los personajes, los escenarios y creo las animaciones con mis propios programas. Creo que vosotros no tenéis vuestros propios modeladores. Tenéis que usar herramientas externas si no me equivoco.

[EX3]

#14
Cita de: Ocho en 05 de Enero de 2009, 01:35:47 PM
Desgraciadamente yo tengo mi propia lógica por que no he copiado técnicas de Internet por eso de no saber ingles, sino que me he inventado mis propias técnicas y formulas. Por lo que entender la lógica de los demás me cuesta más. Tened en cuenta que mi primer motor 3D estaba hecho en ensamblador, hay la lógica es lo único que vale. Lo único que he hecho es pasar la lógica de mi motor en ensamblador a DirectX lo cual me ha costado mucho
Pero ahi sigues mezclando churras con meninas. Una cosa son las rutinas graficas que hayas desarrollado en DirectX o la API grafica de turno para renderizar graficos y otra muy distinta y que deberias tener separada de la parte grafica es la logica del juego: ia de los personajes, gestion de entidades, administracion del escenario y sus elementos, mecanica del juego, etc... ahi tampoco entran las rutinas de audio ni las rutinas de input o fisica, todo ello son igual que la parte grafica, capas independientes de lo que vendria a ser tu motor. De ahi te decia que daba igual que librerias hubieras usado ya que la logica es la parte que desarrolla el comportamiento del juego.

Oviamente entender el codigo de los demas es dificil, nadie ha dicho que sea facil pero para eso existe la documentacion que sus autores hayan o deberian haber hecho del codigo, para entender que hace que y por que. Es interesante beber del saber de los demas por que muchas veces nuestra logica nos ofusca en problemas que tienen facil solucion, te lo digo por experiencia (bendito el dia que tuve internet y acceso a foros y tutoriales!) Sobre el ingles, puedes intentar usar traductores como los de google, aunque no hagan una traduccion correcta al 100% siempre te ayudara a enteder ese lenguaje maldito llamado ingles y con ello acceso a mucha cantidad de informacion util ;)

Cita de: Ocho en 05 de Enero de 2009, 01:35:47 PM
Por cierto yo todos los programas y juegos que tengo los tengo en castellano. Así que no debe de ser tan difícil hacer un juego en castellano. La mayoría de las empresas lo hacen, igual no me he dado cuenta y  el juego de ejemplo de Glest tiene alguna opción de instalación para que aparezca en castellano.
En verdad no es asi. Si la idea es desarrollar algo de forma que este accesible para cualquier persona del mundo, o en su defecto a una mayoria muy numerosa y extendida, tiendes a usar un lenguaje "universal", que en este caso suele ser el ingles. Que los juegos o programas que uses esten en castellano no quiere decir que se hicieran en castellano si no que al ser empresas quienes los desarrollan invierten un dinero en localizacion de textos y audio en el caso de juegos. Un grupo reducido de gente que desarrolla por amor al arte sin un duro y sin tiempo apenas como suele nuestro caso y el del grupo que desarrollo Glest, no va a dedicar tiempo en traducir a varios idiomas cuando usando uno "universal" puede llegar a mucha gente. Inclusive grandes empresas a veces tampoco dedican tiempo a ello, el mejor ejemplo es Microsoft con su SDK de DirectX, documentacion y ejemplos en ingles puro y duro (y traductores automaticos baratos para la documentacion online en muchos casos...).

Cita de: Ocho en 05 de Enero de 2009, 01:35:47 PM
Efectivamente para hacer pruebas se utilizan modelos básicos o incluso cubos. Yo por lo menos lo hago así. Quizás no lo he interpretado bien. ¿Lo que queréis vosotros es que pruebe vuestro motor?, vaya yo había interpretado que los modelos eran para probar en mi programa, que cosas.
O yo entendi mal o te han recomendado el paquete de modelos de Glest para que tengas material disponible con el que hacer pruebas y tengas que dedicar tiempo extra para hacerte tus propios modelos si no para que dediques el maximo tiempo posible a la programacion. A parte te han recomendado que le eches un ojo al codigo fuente de Glest simplemente por que es un proyecto del mismo genero y del que podrias sacar algunas cosas aprovechables para el tuyo.

Salu2...

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

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






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.