2º Desafío PGD

[[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

[Ñ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.

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.

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 Noteví]

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

[roman]

Empezado por Casimiro Notevi

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

Deberíamos expulsarlo del Club. ¡Vaya sacrilegio!



// Saludos

[Casimiro Noteví]

Empezado por roman

Deberíamos expulsarlo del Club. ¡Vaya sacrilegio!
// Saludos

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





.

[roman]

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

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


Saludos.

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