Mapas recursivos de mazmorras representados por una matriz elástica 2D

8

Se me ocurrió un método para generar recursivamente mapas sencillos de mazmorras comenzando con una habitación y conectando recursivamente nuevas habitaciones adyacentes al azar.

Los mapas se representan como matrices bidimensionales donde cada celda contiene un valor de 0-15. 0 no representa espacio, mientras que cada dirección está representada por norte = 1, este = 2, sur = 4, oeste = 8.

Quería comenzar con una sola habitación que no sea ([[0]]) y luego expandir la matriz 2D según sea necesario para que se ajuste al mapa generado. La dificultad que enfrento con este árbol como la recursión es que si las matrices tienen que ser desplazadas para agregar filas y columnas a la izquierda y la parte superior del mapa, tengo que ajustar la posición actual de la función, en qué fila y columna se encuentra. . Esto hace que las ramas separadas no estén al tanto de los ajustes del índice de matriz de otras ramas, solo sus funciones secundarias lo sabrán porque les han pasado la posición ajustada como argumentos de fila y columna.

¿Hay alguna forma de hacer esto? Intenté almacenar valores de desplazamiento de fila y columna fuera de la recursión, pero no funcionó por alguna razón.

software-engineering game-mechanics level-design

5

¿Hay alguna razón por la que deba usar una matriz 2D, o alguna tabla hash u otro tipo de mapa funcionaría? Luego, los índices x, y continúan en el espacio negativo, pero no importa.

Si le preocupa la memoria o la velocidad de la CPU, 1) No se preocupe, las tablas hash son muy eficientes en cosas como pares de enteros densos, 2) puede construir el nivel en una tabla hash y luego procesarlo posteriormente en un matriz una vez que sepa el tamaño final.

entonces la función hash aceptaría un argumento x y ay y esto se mapearía básicamente a una matriz asociativa con claves como 1x1, -1x3, etc.

Si. En C ++ simplemente usaría un std :: pair <int, int>; en Python, un dict con tuplas (x, y) para claves. No estoy seguro de qué idioma estás usando.

2

Estoy haciendo algo similar, en Python. (O al menos la parte elástica).

Tengo un diccionario de mapeo de tuplas (x, y) a las celdas. En pseudocódigo:

map = dictionary( (0,0) : cell at (0,0), (1,0) : cell at (1,0) ... (2, 2) : cell at (2,2)
getCell(x,y):
    return map[(x,y)]
    catch error if out of bounds:
         map[(x,y)] = new cell and return

Una tabla hash sería muy buena para este tipo de cosas.

— El pato comunista
fuente

1

La solución de esfuerzo mínimo es elegir un tamaño máximo (extensión X e Y) que desea que alcance la mazmorra, poner su punto de partida en el centro de eso y no permitir el crecimiento fuera de él. No es necesario hacer ningún cambio. Depende de que una extensión fija sea aceptable, por supuesto.

— caos
fuente

-1

Desea utilizar un gráfico en lugar de la matriz 2D.

Cada habitación sería un nodo en el gráfico y sabe qué otras habitaciones están adyacentes a ella:

Room {
    long x;
    long y;
    List adjacentRooms;
}

De esa manera no tiene que definir qué tan grande puede llegar a ser su mapa.

Las coordenadas x, y se pueden usar como clave única en un mapa hash para un acceso rápido a cada habitación. Agregar una nueva sala solo agregaría entradas a las listas adyacentes de las habitaciones cercanas.

El gráfico también es excelente para los algoritmos de búsqueda de rutas, si los necesita.

— Stephen
fuente

Esto funcionará mal y requerirá mucha más contabilidad que una tabla hash o matriz. No hay ningún beneficio en las habitaciones que tienen una clave hash X, Y y que forman un gráfico dirigido.

¿Cómo haría un acceso rápido a las habitaciones con solo el gráfico dirigido? ¿Cómo haría la búsqueda de ruta con solo una clave hash X, Y? Esto requeriría una lógica adicional para determinar las habitaciones adyacentes. La clave hash es realmente solo otra vista del mundo del juego. Estoy de acuerdo en que manejar un gráfico es más problemático, pero beneficiará a los algoritmos que usan el gráfico. El rendimiento depende del tamaño del mundo del juego. Entonces esto tiene que ser prototipo. Gracias por el voto negativo. ¡Salud!

— Stephen

Nada en la búsqueda de caminos impide el uso de un hash de pares X, Y. Los estados sucesores son estados sucesores, no importa si mantiene un gráfico loco o si lo busca en una tabla hash, excepto que la tabla hash es más rápida y usa menos memoria.

La solución de la clave hash es menos abstracta. Como escribí antes, el buscador de caminos debe saber qué habitaciones están adyacentes entre sí, cómo calcular la distancia a la habitación objetivo, etc. Debería poner conocimiento sobre el mundo del juego en su algoritmo de búsqueda de caminos. Si la configuración del mundo del juego cambia, por ejemplo, se permite el movimiento desde habitaciones que son diagonales entre sí o se agrega una tercera dimensión, deberá cambiar cada algoritmo que acceda al mundo del juego. Los gráficos resumen esto lejos. Nada loco por eso. Siempre hay inconvenientes para cada solución.

— Stephen

1

"Los gráficos resumen esto lejos". Lo mismo ocurre con cualquier método de iterador, generador, corutina o creación de listas, y no requieren una estructura O (n) hinchada ni más contabilidad en tiempo de construcción.