¿Debería compartir la misma estructura de mosaico para la visualización y la búsqueda de rutas?

8

Sé cómo mostrar un mapa 2D con mosaicos.

Sé cómo hacer un algoritmo de pathfinding usando A *.

Esas dos cosas exigen una estructura o una clase. Mi pregunta es: ¿utiliza la misma estructura para la visualización y la informática de ruta? Estructura de nodo para la demanda de búsqueda de ruta para agregar algunos datos: posición x, posición y, F, G, H más el nodo padre. La estructura de mosaico para mostrar se puede optimizar con casi una sola información: el valor del mosaico.

¿Utiliza una clase grande para sus mosaicos, que manejan tanto la visualización como la búsqueda de rutas, o utiliza un método diferente? Gracias por tus consejos !

path-finding tiles data-structure

— Raveline
fuente

Impresionante pregunta, realmente necesitaba aprender esto, pero no sabía qué preguntar.

— DFectuoso

6

Mi pregunta es: ¿utiliza la misma estructura para la visualización y la informática de ruta?

No lo hago Puede obtener cierta optimización calculando su A * directamente en el mapa de mosaicos, pero no puede usar fácilmente su algoritmo A * para cosas que no se asignan directamente a los mosaicos. Además, significa que no puede ejecutar el algoritmo A * simultáneamente en varios subprocesos, ya que terminan compartiendo los datos del mapa. Finalmente, ciertos métodos de movimiento no permiten la optimización tile = node; un vehículo que necesita espacio para girar podría llegar al mismo mosaico desde diferentes direcciones y tener diferentes opciones en cada caso: no se pueden combinar en una sola puntuación.

Entonces sugiero mantener los datos separados.

— Kylotan
fuente

Si bien es interesante mantenerlos separados, no es necesario utilizar un gráfico explícito para encontrar la ruta, podría tener un "mapa de mosaico" con solo la información de colisión / costo, totalmente separada de la representación y del modelo lógico. Por ejemplo, si agrega un objeto al mundo que no está almacenado en el mapa de mosaico, pero solo usando los coordenadas (x, y), aún podría colocarlo en el mapa de colisión y usarlo para encontrar rutas basadas en la cuadrícula.

— Trinidad

3

Desde la perspectiva del desarrollo de software, siempre es bueno mantener diferentes cosas separadas .

Para una solución rápida y sucia, reúna todo y comience a trabajar en los detalles del juego.

Para una solución extensible, mantenga las cosas separadas: ¡no desea cambiar las clases de mosaicos porque su algoritmo de búsqueda de rutas cambió! Mantenga dos estructuras: una que represente fichas de juego visibles y otra que represente la estructura de búsqueda de caminos. Idealmente, un algoritmo de búsqueda de ruta se mantiene en un nivel bajo, por lo que tal vez una matriz de puntos x, y como entrada para el algoritmo es una mejor idea que proporcionarle sus clases de mosaico. El algoritmo en sí mismo puede configurar matrices para valores F, G, H.

Creo que en este caso (y supongo que te esfuerzas por ser un buen programador), deberías optar por la solución extensible, porque no te llevará tanto esfuerzo extra pero mantiene tu código más limpio y obtendrás buenas prácticas experiencia.

— Nef
fuente

2

Una vez estaba construyendo un juego basado en fichas en el Amiga 500 con 512x512 fichas, pero el jugador solo podía mover 8 fichas, así que generé un "mapa de pared" de fichas "9x9". soldado. Si hubiera hecho esto con el mapa original, en primer lugar habría tenido que "aclararlo" después de cada cálculo + la cantidad de memoria necesaria para tener los dos datos de mosaico + los datos de búsqueda de ruta harían que 512x512 se convirtiera en un problema de memoria.

Así que no, mantenga las cosas lo más pequeñas posible y separadas para que pueda modificarlas pr. objeto / clase si es necesario. Otra cosa a tener en cuenta también podría ser que algunos de sus objetos en movimiento PODRÍAN moverse de manera diferente sobre ciertas partes del mapa. P.ej. lento en la arena, puede / no puede nadar, puede abrir puertas, etc.

— BerggreenDK
fuente