2º Desafío PGD

[Ñuño Martínez]

Como el Conejo de Alicia en el País de las Maravillas, llego tarde.

Quedan pocas horas para que comience El 2º Desafío PGD (http://www.pascalgamedevelopment.com/content.php?323-2nd-PGD-Challenge-Official-Announcement#article_content) que un año más convoca la güebería Pascal Game Development (http://www.pascalgamedevelopment.com/). Yo voy a participar con la intención de enseñar un poco qué se puede hacer con la última versión en desarrollo de Allegro.pas (http://allegro-pas.sf.net/), o en su defecto con la última versión estable.

A ver si el año que viene lo anuncio con más tiempo.

[ecfisa]

Hola Ñuño.

Como siempre, te deseo el mayor de los éxitos en el certamen. :)

Saludos.

[Casimiro Notevi]

Sabemos que eres el mejor. Si no ganas es porque no te gusta la fama :)

[Al González]

¡Mucha suerte, Ñuño! :)

Por cierto, ¿no te diste una oportunidad con Embarcadero?

[newtron]

Pues nada, suerte y al loro, ¿o era al toro? :confused:

[Ñuño Martínez]

Gracias, gracias. En ello estamos, y ya tengo cosas para enseñar.

Esto de aquí es un "octree (http://es.wikipedia.org/wiki/Octree)". Es algo así como un árbol binario, solo que cada nodo enlaza con ocho elementos. Lo que se hace es coger el espacio en un cubo, dividir ese cubo en ocho cuadrantes, y cada uno de estos en otros ocho... y así tienes dividido el espacio en "ramas" lo que permite que algunas operaciones sean más eficientes (si una rama está vacía, entonces no tienes que seguirla). La imagen en cuestión es para comprobar si crea el árbol correctamente o no.
https://p.twimg.com/ApT_M7xCQAExwQ7.png

Esta otra imagen es anterior a la del octree. Son sólo cubos en una prueba de concepto, pero el uso de la iluminación, los colores y la niebla hacen que quede bastante chulo, ¿a que sí? :cool:
https://p.twimg.com/ApPZji5CEAAIyBG.png

Sabemos que eres el mejor. Si no ganas es porque no te gusta la fama :) Es que no me gusta abusar... :rolleyes:

Por cierto, ¿no te diste una oportunidad con Embarcadero? Pues me la voy a dar, que por diferentes razones no he podido todavía. Menos mal que son pacientes.

[marcoszorrilla]

Igualmente te deseo mucha suerte Ñuño.

Un Saludo.

[Delphius]

Me encantaron esas imágenes Ñuño. ¿Eso es lo que logras hacer con Allegro.pas? :eek: ¿O es Allegro + "Algo"?

El concepto de octree me resulta interesante, aunque no lo comprendo del todo. Yo mucho fuerte sobre el tema de árboles no tengo. ¿Que aplicaciones tiene en lo que hace en particular al área del desarrollo de videojuegos?

Saludos,

[Caral]

Hola
Impresionante Maestro, pero no me extraña nada viniendo de ti.
Suerte en el certamen, se que estas mas que preparado y con esas imágenes si no ganas tendremos que poner una queja.
Saludos

[MAXIUM]

Ñuño, algo offtopic pero al caso. ¿Sabes como conseguir el código de Tyrian?. Se supone que fue programado en Pascal y es libre. ¿Se podría portar o hacerlo HD usando Allegro?

[Neftali [Germán.Estévez]]

Gracias, gracias. En ello estamos, y ya tengo cosas para enseñar.

Muy chulas las imágenes...
Mucha suerte Ñuño.

[fjcg02]

Esto para mi es una pasada, vamos, ciencia ficción....

Saludos

[Ñuño Martínez]

Gracias por los ánimos, gente, pero exageráis un poco. Que no soy John Romero, ni George Broussard... Bueno, un poco Broussard sí soy (chiste de jugón :p).

Me encantaron esas imágenes Ñuño. ¿Eso es lo que logras hacer con Allegro.pas? :eek: ¿O es Allegro + "Algo"? Sí, es Allegro + OpenGL.

Allegro inicia el contexto de OpenGL, carga texturas, controla las entradas del usuario, genera sonidos... Es decir, lo que no hace OpenGL, que es generar la imagen (le indico las matrices de transformación y la geometría de los objetos y OpenGL hace el resto).
El concepto de octree me resulta interesante, aunque no lo comprendo del todo. Yo mucho fuerte sobre el tema de árboles no tengo. ¿Que aplicaciones tiene en lo que hace en particular al área del desarrollo de videojuegos? Básicamente permite organizar los objetos que hay en un espacio, lo que hace que muchas operaciones sean más rápidas.

Por ejemplo, si lo que tienes es una lista con todos los objetos que hay en el "mundo" y quieres comprobar si un objeto concreto colisiona con algo, entonces debes comprobar la colisión con todos los objetos. Si los organizas en un árbol octal, sólo hay que comprobar la colisión con los objetos que hay en la misma rama en la que está.

Si quieres saber más, mejor que empieces por entender un árbol binario, luego un "quadtree" y así el octree "sale sólo" ya que es un quadtree sólo que tridimensional (el quadtree es bidimensional).
Ñuño, algo offtopic pero al caso. ¿Sabes como conseguir el código de Tyrian?. Se supone que fue programado en Pascal y es libre. ¿Se podría portar o hacerlo HD usando Allegro? Pues ni idea de cómo conseguir el código fuente (tampoco lo he buscado :rolleyes:).

Y lo de portar a Allegro... poder se puede, pero claro, depende de cómo esté el original. Si las bibliotecas que usan en el original siguen la misma filosofía entonces es fácil, pero si no...

[Delphius]

Gracias por los ánimos, gente, pero exageráis un poco. Que no soy John Romero, ni George Broussard... Bueno, un poco Broussard sí soy (chiste de jugón :p).

Sí, es Allegro + OpenGL.

Allegro inicia el contexto de OpenGL, carga texturas, controla las entradas del usuario, genera sonidos... Es decir, lo que no hace OpenGL, que es generar la imagen (le indico las matrices de transformación y la geometría de los objetos y OpenGL hace el resto).
Básicamente permite organizar los objetos que hay en un espacio, lo que hace que muchas operaciones sean más rápidas.

Por ejemplo, si lo que tienes es una lista con todos los objetos que hay en el "mundo" y quieres comprobar si un objeto concreto colisiona con algo, entonces debes comprobar la colisión con todos los objetos. Si los organizas en un árbol octal, sólo hay que comprobar la colisión con los objetos que hay en la misma rama en la que está.

Si quieres saber más, mejor que empieces por entender un árbol binario, luego un "quadtree" y así el octree "sale sólo" ya que es un quadtree sólo que tridimensional (el quadtree es bidimensional).

Gracias por la aclaración. Ya me hago un mejor idea. Vendría a ser como un mapa lógico en como están distribuidos los objetos que luego se traslada a la pantalla.

Es que yo estoy muy en cero en lo que es desarrollo de juegos.
Al tema de árboles lo conozco en parte porque lo ví en estructuras de datos. El concepto de árbol binario me es conocido, lo de quadtree ya no... Quizá en algún momento para curiosiar un poco investigue algo.
Admito que la idea de desarrollar un video juego me sigue atrayendo pero hasta el momento no me puse a meterme en los conceptos... lo veo más hacia laaargo plazo, y más como un hobbie que algo profesional. Aunque nunca se sabe para donde vaya mis rumbos de aquí a unos años.

¡Muchos éxitos en tu presentación!

Saludos,

[Ñuño Martínez]

Pues si te animas, Delphius, avisa con tiempo, que empezar a ciegas no es buena idea. Te (os) recomendaré un par de weberías donde obtener información e ideas para empezar con cosas fáciles.

[Delphius]

Pues si te animas, Delphius, avisa con tiempo, que empezar a ciegas no es buena idea. Te (os) recomendaré un par de weberías donde obtener información e ideas para empezar con cosas fáciles.

OK. Recuerdo que hace un tiempo recomendaste Pascal Game Development y otras más; y creo recordar (no estoy totalmente seguro) que hasta mencionaste un libro.
Yo primero creo que va a ser mejor repasar algo de cálculo; el otro día no recordaba como resolver un límite :eek: y reaprender inglés porque apenas logro darme mañas para entenderlo tras dos pasadas a un texto. :o

Saludos,

[Ñuño Martínez]

Vamos avanzando...
Mou1ihyLEiU
Aquí podéis ver cómo se moverá el jugador, y creo que también permite observar mejor cómo funciona el octree.

Llevo un poco de retraso, pero no es grave. Si esta tarde consigo que la nave sea capaz de "chocar", casi me habré puesto al día. :)

[Casimiro Notevi]

Sencillamente ¡¡¡IMPRESIONANTE!!! :eek:

[Ñuño Martínez]

Gracias compañero.

Pero lo más impresionante es que, cuando intenté hacer lo mismo hace años en C++ me tire meses y tuve que dejarlo por imposible... Con esto llevo poco más de dos semanas y desde cero, casi.

Luego dicen que no importa el lenguaje que uses. Ya, claro... :rolleyes:

[Delphius]

Se ve bueno amigo, :)
Ahora me queda mucho más claro el uso de un octree. Se ve bien en que, porqué y para que se usa.

Saludos,

[acertij022]

Muy interesante y lo que seria mas interesante (cuando creas oportuno) crear un hilo mostrando paso a paso una creación tuya mostrando el código. Va mas que una propuestas es un deseo :D

[Ñuño Martínez]

Sí, a mi también me gustaría hacerlo, acertij022, porque lo tengo pendiente. Cuando termine el concurso voy a seguir con mi plan de profesionalización y en uno de los apartados del plan está ese: el informar de los avances día a día. Difícil va a ser. :rolleyes:

Por ahora, acabo de terminar una prueba hecha en BASIC de un algoritmo para saber en qué dirección está un objetivo en relación con la dirección en la que está mirando. En principio es algo fácil, pero tiene su miga.
https://p.twimg.com/AqxqNQICMAAq08N.png:large
La dirección la da en valores 0..7, siendo 0 el frente y aumentando en sentido horario (2 derecha, etc). En la imagen se da la posición relativa del objetivo en rosa respecto al ángulo indicado por la línea blanca. En este caso dice "3", es decir, atrás a la derecha. Puede parecer que no, pero con esto es más fácil y rápido hacer luego la inteligencia artificial de los enemigos.

Hubiera preferido usar QuickBASIC, que es más estructurado, pero aun así ha ido muy bien y algo más rápido que usando Pascal.

[Casimiro Notevi]

¿basic?, ¿más rápido que pascal? :confused:

[roman]

¿basic?, ¿más rápido que pascal? :confused:

Deberíamos expulsarlo del Club. ¡Vaya sacrilegio! :mad:

:p:D

// Saludos

[Casimiro Notevi]

Deberíamos expulsarlo del Club. ¡Vaya sacrilegio! :mad:
:p:D // Saludos

Y que lo digas, ¿pero has visto ese código en gwbasic?, pero si hay hasta "goto"? :eek:



:D:D:D

.

[roman]

Sí, es una vergüenza para este sitio. Llevemos el asunto al foro de moderadores. ¡Juicio sumario! :D

// Saludos

[ecfisa]

Hola.

Esta vez estoy totalmente en desacuerdo con ustedes.

Y es más, propongo que Ñuño sea promovido a Miembro Estoico de Club Delphi por haber tenido la entereza de ánimo necesaria para desarrollar la aplicación en ese lenguaje. :D


Saludos. :)

[roman]

Síguele y también te vas, ja, ja, ja.

¿Qué no leyeron el juramento del moderador?


3. No programarás, promoverás ni defenderás nngún código Basic.


:D :D

// Saludos

[Casimiro Notevi]

Nada, nada, ¡¡¡a la hoguera!!! :D

[marcoszorrilla]

CLS
LOCATE 12,33
PRINT "ENHORABUENA ÑUÑO"
GOSUB 1980
GOTO 4500
REM Beginner's All-Purpose Symbolic Instruction Code
CLS
PRINT "UN SALUDO"
END

[Delphius]

Agradezcan que no lo está haciendo en VB o NET, es preferible que utilice BASIC y no su versión "visual". :D

Ñuño, ¿por casualidad no utilizas también algo de LISP, o para ese proyecto sobra más de lo que puede dar?

Saludos,

[Ñuño Martínez]

Si lo sé, no digo nada. :mad:

Como dice Delphius, agradezcan que no fuera VB. :p De todas formas, QuickBASIC sigue siendo uno de mis favoritos. Si no lo he usado es porque no tengo el QBasic disponible.
¿basic?, ¿más rápido que pascal? :confused: Me refería a que es más rápido para probar algoritmos, no en ejecución de código.

Ñuño, ¿por casualidad no utilizas también algo de LISP, o para ese proyecto sobra más de lo que puede dar? De LISP sé nada o menos. Pero sí se va a utilizar un lenguaje "auxiliar" para definir el comportamiento de los enemigos y la definición de las misiones. Pero no va a ser nada sofisticado, de hecho el "parser" va a ser un TStringList tal cual... :D
_______________________________

Venga, va, a pesar de todo os pongo otro vídeo. Ya tiene naves que se mueven, explosiones, sonido... El problema es que mi capturador de vídeo no pilla esto último. :(

La razón del vídeo es que estuve haciendo muchísimas pruebas para comprobar velocidades, distancias, tamaños... Incluso he modificado algo los controles, permitiendo giros en diferentes velocidades y tó.
BjOevZqi09c

[Delphius]

Si lo sé, no digo nada.
De LISP sé nada o menos. Pero sí se va a utilizar un lenguaje "auxiliar" para definir el comportamiento de los enemigos y la definición de las misiones. Pero no va a ser nada sofisticado, de hecho el "parser" va a ser un TStringList tal cual... :D

Pensé que sabías sobre LISP, CLIPS o alguno de sus "derivados", porque recuerdo que comentaste algo sobre el tema en unas ocasiones. O quizá soy yo quien recuerda mal.
Y bueno, si el TStringList te sirve, pues ándale :)
_______________________________


Venga, va, a pesar de todo os pongo otro vídeo. Ya tiene naves que se mueven, explosiones, sonido... El problema es que mi capturador de vídeo no pilla esto último. :(

La razón del vídeo es que estuve haciendo muchísimas pruebas para comprobar velocidades, distancias, tamaños... Incluso he modificado algo los controles, permitiendo giros en diferentes velocidades y tó.
BjOevZqi09c
Me ha gustado mucho este nuevo video, se ve genial. Se que estás avanzando y te quedan más cosas para ir agregando, pero tengo unas dudas... ¿a ese espacio o "mapa" lo tienes almacenado en memoria y en alguna estructura de datos a nivel lógica, o es generado por simplemente a modo de presentación en pantalla? Es decir, tienes algo como Mapa(X,Y,Z) := Nave[i] para hacer las asociaciones y correspondencias y los cálculos junto con el octtree o directamente tienes el octtree con los objetos y el mapa se genera solamente en pantalla. A lo que voy es en entender como es que te basas para unir la parte lógica con lo que es interfaz.
Ando tratando de unir cosas a ver si le pillo. :D

Mi segunda duda, es ¿que tan grande, lejos, está esa nebulosa? Porque cuando avanzas hacia ella no veo como si se acercara. Me da la impresión de que no cambia de tamaño. ¿O es que eso justamente define el límite del espacio o mapa? Se que estás recién avanzando pero es que resultó curioso ese detalle menor.

Saludos,

[Ñuño Martínez]

Pensé que sabías sobre LISP, CLIPS o alguno de sus "derivados", porque recuerdo que comentaste algo sobre el tema en unas ocasiones. O quizá soy yo quien recuerda mal.
Y bueno, si el TStringList te sirve, pues ándale :) Pues no recuerdas mal porque lo he nombrado alguna vez. Lo que pasa es que de LISP conozco lo que se puede hacer, pero nunca lo he usado ni me he puesto a aprender a usarlo.
_______________________________

Anda que no pides nada tú:

Me ha gustado mucho este nuevo video, se ve genial. Se que estás avanzando y te quedan más cosas para ir agregando, pero tengo unas dudas... ¿a ese espacio o "mapa" lo tienes almacenado en memoria y en alguna estructura de datos a nivel lógica, o es generado por simplemente a modo de presentación en pantalla? Es decir, tienes algo como Mapa(X,Y,Z) := Nave[i] para hacer las asociaciones y correspondencias y los cálculos junto con el octtree o directamente tienes el octtree con los objetos y el mapa se genera solamente en pantalla. A lo que voy es en entender como es que te basas para unir la parte lógica con lo que es interfaz.
Ando tratando de unir cosas a ver si le pillo. :D
Simplificando, tengo una lista (TObjectList) que contiene todos los objetos del universo sin orden ni concierto. Los objetos contienen su posición en coordenadas P = {x, y, z}. Por otro lado tengo el árbol Octree en los que cada nodo tiene una lista con referencias a los objetos que están en ese nodo (recuerda que cada nodo del Octree es un "cubo"). Uso la lista de objetos cuando tengo que recorrer todos los objetos, mientras que el Octree lo uso cuando necesito alguna referencia espacial -- por ejemplo, saber qué partes son visibles y cuales no.

El sistema que defines tú (Mapa[x, y, z] = Nave ) se denomina [i]tilemap, mapa de teselas o damero. Se usa en algunos juegos, pero en este caso no funciona bien porque intento representar un espacio abierto muy grande e informe. Por lo poco que sé, el famoso Minecraft usa un sistema de damero.
Mi segunda duda, es ¿que tan grande, lejos, está esa nebulosa? Porque cuando avanzas hacia ella no veo como si se acercara. Me da la impresión de que no cambia de tamaño. ¿O es que eso justamente define el límite del espacio o mapa? Se que estás recién avanzando pero es que resultó curioso ese detalle menor. El fondo es lo que se llama un skybox (literalmente, caja celeste). Es una caja a la que se pinta el interior con el fondo y cuyo centro se coloca siempre donde esté la cámara. Por eso "no se mueve". Se utiliza para pintar "el infinito", con la ventaja de que es muy rápido dibujarlo y permite giros completos sin cálculos complicados.

Para evitar esa sensación de que no se mueve hay que añadir elementos de escenario que sirvan como referencia. Por ejemplo, añadir una gran nave espacial o un campo de asteroides.

[Delphius]

Gracias Ñuño por dedicar un tiempo a responder a mis interrogantes.
Ahora si que me quedó mucho más claro que el agua. Uniendo conceptos ya me hago una mejor idea de como relacionar la lógica con la interfaz y en como interviene el octree en el proceso. :)

No te preocupes, no te estaré molestando de nuevo... :rolleyes:

Ya me dan ganas de meterle mano a mi sueño de hacer un video juego. A ver si alguien se inventa una máquina de clonación para clonarme porque con los proyectos que tengo encima no creo que vea la luz siguiera un algún tic-tac-toe antes del 2015 :D

A si que ya sabes, vete pensando que en el 2013 o 2014 te estaré jodiendo para que me expliques con más detalles todo :p :D

Saludos,

[Ñuño Martínez]

Bueno, gente. Ya hace un tiempo que terminó el concurso; si no lo mencioné antes es porque ando algo descolocado.

Aquí tenéis un vídeo donde podéis ver el resultado. Los modelos 3D los ha realizado Rubén Deig, un aficionado que está estudiando que conocí en otro foro.

LYPHFHZclCQ

Cuando esté disponible para descarga, os aviso por si tenéis curiosidad, aunque por desgracia la versión actual no funciona en Windows, pero antes o después conseguiré que funcione.

[Casimiro Notevi]

Qué bueno, muy ágil... y el paisaje de fondo y las nubes es muy realista :)

[Delphius]

En la 1ra misión no se distingue mucho, pero en la 2da ¡GUAU! :eek:
¡Se pasan! Si eso hacen para una demo... :eek: ¡Como será una versión final! :)

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.

Saludos,

[ecfisa]

Realmente muy pero muy bueno, felicitaciones ;)

Saludos :)

[newtron]

Mola un montón, enhorabuena por el trabajo. :)

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

[Ñuño Martínez]

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

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.
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?

Por cierto... llevas fundidos los pilotos traseros, te van a multar los municipales intergalácticos. :p ¡Cáspita! :eek:

[Delphius]

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

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.


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".


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]

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 :D, más que nada porque es pago y no hay chauchas). Y tras ver algunos videos, como por ejemplos éste (http://www.youtube.com/watch?v=9u_-TLehtF0&list=PLF471AF281046734F&index=64&feature=plpp_video) 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 (http://ace-spades.com/) 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 (http://es.wikipedia.org/wiki/RLE), 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 (http://es.wikipedia.org/wiki/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]

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 :eek: 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.


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 (http://ace-spades.com/) 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 (http://es.wikipedia.org/wiki/RLE), 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 (http://es.wikipedia.org/wiki/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. :D

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.

(...) 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 :)

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]

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 :D 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 (http://0fps.wordpress.com/2012/01/14/an-analysis-of-minecraft-like-engines/) 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 (http://www.minecraftforum.net/topic/48094-space-and-time-optimisation-octree/).

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]

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 (http://www.pascalgamedevelopment.com/content.php?15-Artillery-Game-Tutorial-Part-1-Introduction). 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 (http://www.flipcode.com/) (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 (http://www.pascalgamedevelopment.com/), buscar en sus foros y blogs, y preguntarles a ellos.


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 (ftp://ftp.worldofspectrum.org/pub/sinclair/books/GiantBookOfComputerGames(BallantineBooks).pdf), 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 :p

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]

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? :D Hace un tiempo visité el sitio de forma anónima y me sentí muy out. :o

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 (http://www.gameartspain.es/foro/) (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. :)