2º Desafío PGD

[Ñuño Martínez]

Merced que me hacen ustedes con tanta felicitación. No es tan bueno, ¿eh?

Para empezar, hay que re-escribir de nuevo el motor gráfico, porque aunque funciona, hay algunas ideas que al final no eran tan buenas y he tenido que parchear malamente. El resultado es que el juego es difícil de pilotar, y la detención de colisiones a veces hace que tu nave explote "sin haber chocado con nada", por ejemplo. Y más cosas.

Empezado por Delphius

No jodas, Nuño yo si fuera tu y supiera tanto pongo precio a mi cabeza y busco en tierra, mal y cielo alguien que invierta en mi y a hacer realidad tu creación.

Pues en parte el plan del que hablo de vez en cuando es para eso, para hacer cosas de estas y mejores y ganarme un poco la vida. A veces pienso que es muy frívolo, teniendo en cuenta la situación política, económica, social y ecológica, pero luego pienso que si consigo que los juegos transmitan un mensaje (aunque sea lo estúpidas e inútiles que son las guerras) deja de ser tan frívolo, ¿verdad?

Empezado por newtron

Por cierto... llevas fundidos los pilotos traseros, te van a multar los municipales intergalácticos.

¡Cáspita!

[[Delphius]]

Empezado por Ñuño Martínez

Merced que me hacen ustedes con tanta felicitación. No es tan bueno, ¿eh?

Que no te menosprecies.
Ñuño, tu, yo y cualquiera que esté en el foro se da cuenta de que haber conseguido algo como eso no es de poca cosa.
Porque si hay algo que entendemos los que estamos en el tema es hay tres grandes retos en la programación: Compiladores, Sistemas Operativos, y Video Juegos.
Y no cualquiera tiene los conocimientos, y la sed de preparación, para enfrentarse a eso.

Empezado por Ñuño Martínez

Para empezar, hay que re-escribir de nuevo el motor gráfico, porque aunque funciona, hay algunas ideas que al final no eran tan buenas y he tenido que parchear malamente. El resultado es que el juego es difícil de pilotar, y la detención de colisiones a veces hace que tu nave explote "sin haber chocado con nada", por ejemplo. Y más cosas.

Siempre habrá cosas para pulir. Además, seguramente has estado trabajando en el proyecto a mil por hora para lograr adelantar y tener algo para mostrar y llegar a tiempo.
Sabemos que es un enorme sacrificio el tener un video juego. Ofrece retos que no se ven en el desarrollo de un sistema de gestión; es otro mundo.
Aún así, y por más básico y demo que sea lo que has mostrado en estos videos es digno de alabanza y admiración y estoy seguro que no muchos de los presentes se animará a ponerse en tus zapatos como diciendo "ba... eso lo hago en dos patadas".

Empezado por Ñuño Martínez

Pues en parte el plan del que hablo de vez en cuando es para eso, para hacer cosas de estas y mejores y ganarme un poco la vida. A veces pienso que es muy frívolo, teniendo en cuenta la situación política, económica, social y ecológica, pero luego pienso que si consigo que los juegos transmitan un mensaje (aunque sea lo estúpidas e inútiles que son las guerras) deja de ser tan frívolo, ¿verdad?

Se que las cosas en la querida Madre Patria están muy duras, y se hace difícil sostenerse pero no desfallezcas. Tu sigue intentando, porque si hay una industria que tiene mercado es el rubro del entretenimiento y los videos juegos y siempre se está buscando algo nuevo. Si tienes ideas frescas, y logras venderlas no tardarán en aparecer gente con el capital para invertir.

Saludos,

[Casimiro Notevi]

Empezado por Delphius

Se que las cosas en la querida Madre Patria están muy duras, y se hace difícil sostenerse pero no desfallezcas. Tu sigue intentando, porque si hay una industria que tiene mercado es el rubro del entretenimiento y los videos juegos y siempre se está buscando algo nuevo. Si tienes ideas frescas, y logras venderlas no tardarán en aparecer gente con el capital para invertir.

Si yo tuviera algunos ahorros, invertiría, los videojuegos son rentables, sobre todo si es algo innovador y diferente, que llame la atención.

[[Delphius]]

Desde hace un tiempo vengo escuchando mucho de Minecraft (y me ando resistiendo de jugarlo , más que nada porque es pago y no hay chauchas). Y tras ver algunos videos, como por ejemplos éste me hizo recordar de este hilo, el concepto de octree vs damero que nos comentaste Nuño.

¿Estás seguro de que Minecraft emplea damero? Según se cuenta el mundo de Minecraft no es constante... es aleatorio y se va formando (creando) en la medida en que uno va explorando. Por lo que he podido saber de la propia wiki de Minecraft y algunas cosas que se comentaron en sus foros es que si se le ha puesto un tamaño al mapa justamente debido al enorme tamaño y los recursos, creo que se lo definió en 30 millones de "cuadros". Y ese enorme valor me hace decreer que se tenga un damero para registrar semejante cosa.
Si el mapa se genera de forma dinámica, creo que más viable pensar en los octree ya que con ellos sería más fácil pensar en como registrar la enorme combinación cambiante de mapa + objetos.

Saludos,

[Ñuño Martínez]

No voy a decir que no, porque no estoy seguro y tampoco me he preocupado mucho en enterarme de cómo funciona por dentro, pero sigo insistiendo en el damero, aunque estoy casi seguro de que lo combinan con algún otro método como puede ser el octree o una cosa que he leído que llaman "mapa hash", aunque no sé cómo funciona. Por otro lado, es posible que el mapa esté, a su vez, dividido en secciones y que sólo tenga parte del mapa en memoria al mismo tiempo, sólo la parte que sea necesaria. No es necesario que cada cubo de escenario dentro de Minecraft sea una hoja del octree, quizá cada hoja del octree contenga 64x64x64 cubos, por ejemplo.

En cuanto a recursos, estoy casi seguro de que utiliza algún tipo de compresión de datos. El motor que usa Ace of Spades lo conozco relativamente bien y el mapa lo almacena en forma de damero de 256x1024 casillas. Cada casilla no almacena un sólo cubo, sino que es un "puntero" a una columna de 256 cubos (esto hace 256x1024x256 = 67,108.864 cubos). Lo hace así porque, de esta forma, si en esa columna hay varios cubos del mismo color (por ejemplo, varios cubos transparentes), entonces puede comprimirse fácilmente usando RLE (run-length encoding, o codificación por longitud), lo cual puede ahorrar mucha memoria ya que la mayor parte es espacio hueco (color transparente) y la parte que no se ve puede ser toda del mismo color (si te fijas en el vídeo de Ace of Spades, el soldado que está cavando la trinchera al principio, los cubos que salen a la vista son negros y luego cambian a verde). Sin embargo, no usa un octree sino que lo hace todo usando una versión simplificada del trazado de rayos (lo hace sólo en dos dimensiones, usando el damero, en vez de en tres dimensiones).

Quizá sea un poco difícil de ver, pero creo que se entiende que hay multitud de formas de solucionar problemas similares.

[[Delphius]]

Empezado por Ñuño Martínez

No voy a decir que no, porque no estoy seguro y tampoco me he preocupado mucho en enterarme de cómo funciona por dentro, pero sigo insistiendo en el damero, aunque estoy casi seguro de que lo combinan con algún otro método como puede ser el octree o una cosa que he leído que llaman "mapa hash", aunque no sé cómo funciona. Por otro lado, es posible que el mapa esté, a su vez, dividido en secciones y que sólo tenga parte del mapa en memoria al mismo tiempo, sólo la parte que sea necesaria. No es necesario que cada cubo de escenario dentro de Minecraft sea una hoja del octree, quizá cada hoja del octree contenga 64x64x64 cubos, por ejemplo.

He pensado en que tal vez tiene cargado en memoria secciones del mapa. De todas formas es una cosa enorme El juego tiene una opción para configurar la vista... lejos, medio, cerca. Cuando uno cambia a lejos puede llegar a apreciar sectores del mapa muy lejanos... de todas formas es un tamaño de mapa descomunal.

Empezado por Ñuño Martínez

En cuanto a recursos, estoy casi seguro de que utiliza algún tipo de compresión de datos. El motor que usa Ace of Spades lo conozco relativamente bien y el mapa lo almacena en forma de damero de 256x1024 casillas. Cada casilla no almacena un sólo cubo, sino que es un "puntero" a una columna de 256 cubos (esto hace 256x1024x256 = 67,108.864 cubos). Lo hace así porque, de esta forma, si en esa columna hay varios cubos del mismo color (por ejemplo, varios cubos transparentes), entonces puede comprimirse fácilmente usando RLE (run-length encoding, o codificación por longitud), lo cual puede ahorrar mucha memoria ya que la mayor parte es espacio hueco (color transparente) y la parte que no se ve puede ser toda del mismo color (si te fijas en el vídeo de Ace of Spades, el soldado que está cavando la trinchera al principio, los cubos que salen a la vista son negros y luego cambian a verde). Sin embargo, no usa un octree sino que lo hace todo usando una versión simplificada del trazado de rayos (lo hace sólo en dos dimensiones, usando el damero, en vez de en tres dimensiones).

Quizá sea un poco difícil de ver, pero creo que se entiende que hay multitud de formas de solucionar problemas similares.

Intenté razonar en una posible manera de concebir que la información estuviera comprimida pero como mis conocimientos son prácticamente nulos en el área no veía la forma. Al RLE lo conozco, pero no al nombre. Le leí hace ya un buen tiempo mientras leía sobre compresión de imágenes. El artículo no lo llamaba RLE, sino por el autor... creo que era Richtman o algo así.

Pues si... parece que hay mil y un formas de encarar las cosas. A mi ya me está picando el bicho de al menos formalizar mis vagas ideas del juego que intento dar forma en mi cabeza y pasarlas en papel.

Saludos,

[Ñuño Martínez]

Pues ya que te ha picado el bicho, voy a aprovechar a explicar un "truco del almendruco" muy usado en los videojuegos 3D.

Empezado por Delphius

(...) Cuando uno cambia a lejos puede llegar a apreciar sectores del mapa muy lejanos... de todas formas es un tamaño de mapa descomunal.

Sí, sí, pero hay truco.

No sé a cuántos juegos has jugado, pero en algunos, si te fijas bien, verás que los objetos lejanos (y partes lejanas de los mapas) están dibujados de forma tosca y, si te acercas a ellos, hay un punto en el que cambian de repente y se dibujan de forma más definida. Esto se ve, sobre todo, en los juegos de PC, pero también en algunos de videoconsola.

Esto se hace, principalmente, para ganar velocidad (al tener menos vértices y caras o planos, pues evidentemente tarda menos en calcular y dibujar), pero en ocasiones también para ahorrar memoria, si merece la pena para los sectores lejanos del mapa sólo mantiene información mínima y carga la información detallada cuando te acercas (depende de lo grande del mapa, velocidad del disco y demás puede o no merecer la pena).

[[nlsgarcia]]

Ñuño Martínez,

Te felicito, muy impresionante todas las imágenes

Empezado por Ñuño Martínez

recomendaré un par de weberías donde obtener información e ideas para empezar con cosas fáciles.

Por curiosidad : ¿Como puedo iniciar a aprender algo de esto?.

Mucha suerte en el concurso

Nelson.

[[Delphius]]

Empezado por Ñuño Martínez

Pues ya que te ha picado el bicho, voy a aprovechar a explicar un "truco del almendruco" muy usado en los videojuegos 3D.


Sí, sí, pero hay truco.

No sé a cuántos juegos has jugado, pero en algunos, si te fijas bien, verás que los objetos lejanos (y partes lejanas de los mapas) están dibujados de forma tosca y, si te acercas a ellos, hay un punto en el que cambian de repente y se dibujan de forma más definida. Esto se ve, sobre todo, en los juegos de PC, pero también en algunos de videoconsola.

Esto se hace, principalmente, para ganar velocidad (al tener menos vértices y caras o planos, pues evidentemente tarda menos en calcular y dibujar), pero en ocasiones también para ahorrar memoria, si merece la pena para los sectores lejanos del mapa sólo mantiene información mínima y carga la información detallada cuando te acercas (depende de lo grande del mapa, velocidad del disco y demás puede o no merecer la pena).

Si, se aprecia justo lo que comentas Nuño. Se que no lo hace a tan HD y lo hace con información mínima.

Por otro lado he estado buscando información sobre el debate de si Minecraft usa o no octree u otra estructura. Al parecer se ha discutido el tema, y como dices se han propuesto también la posibilidad de HashMap.
Y como tu experiencia lo dice, todo indicaría que emplearía una mezcla de HashMap, algo de RLE, mapa en caché. Pero con una fuerte presencia de estructura Damero (al menos eso es lo que interpreto de este otro documento.

Tal parece que dependiendo del tipo de juego hay muchas discusiones y alternativas para ver cual es la más adecuada. De ser así, tendré que ponerme a investigar muchísimo para saber a lo que me podría enfrentar si alguna vez al menos un prototipo elemental de mis ideas vieran la luz.
No se que tan alta será la tendencia... pero por momentos me tengo la impresión de que cada juego termina implementando su "propio" motor. De ser así la verdad, entonces yo terminaría haciendo uno propio.

Saludos,

[Ñuño Martínez]

Empezado por nlsgarcia

Por curiosidad : ¿Como puedo iniciar a aprender algo de esto?

Yo empecé con un libro maravilloso titulado "El Libro Gigante de los Juegos para Ordenador", de Tim Hartnell. Por desgracia está más que descatalogado, pero es el mejor libro para principiantes que he tenido el placer de leer. Los programas son para BASIC, sin (casi) gráficos, pero enseña perfectamente todo el proceso, desde que tienes la idea hasta que el programa está terminado.

Últimamente está complicado por la Maldición de Pascal (ya sabéis, que si es un lenguaje sólo para aprender, que si no es tan potente como C+*4...), pero puede empezarse por este tutorial. Está pensado para Lazarus+Free Pascal, pero creo que puede adaptarse fácilmente a Delphi. En los foros de esa web hay muchos proyectos, algunos lo suficientemente simples como para aprender con ellos.

Otra forma sería buscar información en "otro lenguaje", si eres valiente. Si lo eres, puedes buscar en FlipCode (mientras siga existiendo).

El problema es que es difícil encontrar información para novatos en Pascal. Pero lo mejor es apuntarse en Pascal Game Development, buscar en sus foros y blogs, y preguntarles a ellos.

Empezado por Delphius

Tal parece que dependiendo del tipo de juego hay muchas discusiones y alternativas para ver cual es la más adecuada. De ser así, tendré que ponerme a investigar muchísimo para saber a lo que me podría enfrentar si alguna vez al menos un prototipo elemental de mis ideas vieran la luz.
No se que tan alta será la tendencia... pero por momentos me tengo la impresión de que cada juego termina implementando su "propio" motor. De ser así la verdad, entonces yo terminaría haciendo uno propio.

Veo que le vas cogiendo gusto. Eso de hacer un motor propio tiene su encanto, y está bien, pero muchas veces se usan motores de otros, claro que siempre se busca el motor de juegos similares (DooM/Duke Nukem/Gears of War, por ejemplo). Depende del proyecto, del presupuesto, del tiempo, las necesidades, el personal, conocimientos...

[[nlsgarcia]]

Ñuño Martínez,

Gracias por la información

Nelson.

[[Delphius]]

Me parece que he encontrado el libro, alguien lo ha digitalizado ya que no se encuentra en ninguna librería o biblioteca.

Pero por lo que he estado viendo, no es que aporta una visión teórica sobre ciertos fundamentos, sino más bien que explica sobre maneras de encarar diversos juegos, ¡y en BASIC! BASIC le entiendo no es drama. Pero me esperaba algo más académico.
Tocará ir a Pascal Game Development y afinar mejor el inglés

Saludos,

[Ñuño Martínez]

No se me había ocurrido buscarlo en inglés. ¡Gracias Delphius!

Aunque no sea muy académico, es un buen libro. Explica muy bien fundamentos como la estructura de los juegos, estructura de los programas, cómo estructurar los datos, etc. Luego lo aplicas como necesites, en el lenguaje que quieras y el juego que quieras. Tim Hartnell tiene más libros similares, como el "Inteligencia Artificial: Conceptos y Programas", aunque este no está dirigido exclusivamente a juegos.

Tim Hartnell me gusta porque es sencillo y práctico, y todo es aplicable y extrapolable. De hecho, algunos conceptos de sus libros los he visto repetidos en "Programming Game AI by Example" de Mat Buckland, que es el libro de moda hoy en día (por lo que he visto por ahí). Eso sí, este último libro es bastante más complejo que los de Hartnell: ni acercarse sin tener una mínima experiencia.

[[Delphius]]

Empezado por Ñuño Martínez

No se me había ocurrido buscarlo en inglés. ¡Gracias Delphius!

Aunque no sea muy académico, es un buen libro. Explica muy bien fundamentos como la estructura de los juegos, estructura de los programas, cómo estructurar los datos, etc. Luego lo aplicas como necesites, en el lenguaje que quieras y el juego que quieras. Tim Hartnell tiene más libros similares, como el "Inteligencia Artificial: Conceptos y Programas", aunque este no está dirigido exclusivamente a juegos.

Tim Hartnell me gusta porque es sencillo y práctico, y todo es aplicable y extrapolable. De hecho, algunos conceptos de sus libros los he visto repetidos en "Programming Game AI by Example" de Mat Buckland, que es el libro de moda hoy en día (por lo que he visto por ahí). Eso sí, este último libro es bastante más complejo que los de Hartnell: ni acercarse sin tener una mínima experiencia.

Tendría que darle una nueva oportunidad al libro aunque como decía, me imaginaba algo que expusiera algo de teoría, que profundize sobre las estructuras de datos más avanzadas y apropiadas, que explique las formas, alternativas, y sobre técnicas. En resumen algo que aporte sustento, y no que vaya tomando juego a juego describiendolo y programando. Por ejemplo, como comentaste antes sobre Octree, sus porqués, cuando, donde, como es que surge, para que...
Yo de AI ya no recuerdo nada... en ese punto estoy flojo.

No quedará otra que ir a Pascal Game Development. ¿Es puro inglés? ¿No tienen algún sub-foro en español? Hace un tiempo visité el sitio de forma anónima y me sentí muy out.

Saludos,

[Ñuño Martínez]

Pues está todo en inglés. Ya sabes cómo está el Mundo. Sí se habló (en el viejo foro) de la posibilidad de abrir foros en otros idiomas, pero se desechó por poca asistencia.

Hay un foro de videojuegos en español al que asisto de vez en cuando: Game Art Spain (sí, lo sé, es irónico que el nombre sea inglés). Su mayor problema: la mayoría son forofos del C++ y están enamorados de C# y UnrealScript (un clon de C que se usa en los juegos basados en el motor de juegos Unreal). Aun así, su fundador es un tío la mar de majo al que tampoco le gusta mucho C++ (aunque de programación sabe poco, le va más el diseño).

Respecto a los libros de Hartnell, están más pensados para aficionados y principiantes, pero les veo su utilidad. Repito que yo aprendí mucho con ellos.