Mapas de masmorra recursivos, representados por uma matriz 2d elástica


8

Eu inventei um método para gerar recursivamente mapas simples de masmorra, começando com uma sala e conectando recursivamente novas salas adjacentes aleatoriamente.

Os mapas são representados como matrizes bidimensionais em que cada célula contém um valor de 0 a 15. 0 representa nenhuma sala enquanto cada direção é representada por norte = 1, leste = 2, sul = 4, oeste = 8.

Eu queria começar com um único quarto não ([[0]]) e depois expandir a matriz 2d conforme necessário para ajustar o mapa gerado. A dificuldade que encontro com essa árvore como recursão é que, se as matrizes tiverem que ser deslocadas para adicionar linhas e colunas à esquerda e à parte superior do mapa, tenho que ajustar a posição atual da função, em que linha e coluna ela está . Isso faz com que ramificações separadas não tenham conhecimento dos ajustes do índice de matriz de outras ramificações, apenas suas funções filhas saberão porque elas têm a posição ajustada passada como argumentos de linha e coluna.

Existe uma maneira de fazer isso? Tentei armazenar valores de deslocamento de linha e coluna fora da recursão, mas não funcionou por algum motivo.

Respostas:


5

Existe uma razão para você usar uma matriz 2D ou alguma tabela de hash ou outro tipo de mapa funcionaria? Então os índices x, y continuam no espaço negativo, mas isso não importa.

Se você está preocupado com a velocidade da memória ou da CPU, 1) Não fique, as tabelas de hash são muito eficientes em coisas como pares de números inteiros densos, 2) você pode criar o nível em uma tabela de hash e depois processá-lo em um matriz depois de saber o tamanho final.


então a função hash aceitaria um argumento x e ay e isso seria mapeado para basicamente uma matriz associativa com chaves como 1x1, -1x3, etc?

Sim. Em C ++, eu apenas usaria um std :: pair <int, int>; em Python, um ditado com (x, y) tuplas para chaves. Não tenho certeza de qual idioma você está usando.

2

Estou fazendo uma coisa semelhante, em Python. (Ou pelo menos a parte elástica).

Eu tenho um dicionário de (x, y) tuplas mapeadas para as células. No pseudo có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

Uma tabela de hash seria muito boa para esse tipo de coisa.


1

A solução de esforço mínimo é escolher um tamanho máximo (extensão X e Y) que você deseja que a masmorra atinja, colocar seu ponto de partida no centro disso e não permitir crescimento fora dela. Não há necessidade de fazer nenhuma mudança. Depende de uma extensão fixa ser aceitável, é claro.


-1

Você gostaria de usar um gráfico em vez da matriz 2D.

Cada sala seria um nó no gráfico e sabe quais outras salas são adjacentes a ele:

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

Dessa forma, você não precisa definir o tamanho do seu mapa.

As coordenadas x, y podem ser usadas como chave exclusiva em um hashmap para acesso rápido a cada sala. Adicionar uma nova sala apenas adicionaria entradas às listas de quartos adjacentes das salas próximas.

O gráfico também é ótimo para algoritmos de localização de caminhos, se você precisar deles.


Isso terá um desempenho ruim e exigirá muito mais contabilidade do que uma tabela ou matriz de hash. Não há benefício nas salas que possuem uma chave de hash X e Y e formam um gráfico direcionado.

Como você faria o acesso rápido às salas apenas com o gráfico direcionado? Como você faria a localização de caminhos apenas com uma chave de hash X, Y? Isso exigiria lógica adicional para determinar as salas adjacentes. A chave de hash é realmente apenas outra visão do mundo do jogo. Concordo que lidar com um gráfico é mais problemático, mas beneficiará algoritmos usando o gráfico. O desempenho depende do tamanho do mundo do jogo. Portanto, isso deve ser prototipado. Obrigado pelo voto negativo. Felicidades!
Stephen

Nada na busca de caminho impede o uso de um hash de pares X, Y. Estados sucessores são estados sucessores, não importa se você mantém um gráfico louco ou o procura em uma tabela de hash, exceto que a tabela de hash é mais rápida e usa menos memória.

A solução da chave de hash é menos abstrata. Como escrevi antes, o descobridor deve saber quais salas são adjacentes umas às outras, como calcular a distância até a sala de destino etc. Você colocaria o conhecimento sobre o mundo do jogo em seu algoritmo de busca de caminhos. Se a configuração do mundo do jogo mudar, por exemplo, é permitido o movimento de salas que são diagonais entre si ou se uma terceira dimensão for adicionada, você precisará alterar todos os algoritmos que acessam o mundo do jogo. Os gráficos abstraem isso. Nada louco por isso. Sempre há inconvenientes em todas as soluções.
Stephen

11
"Os gráficos abstraem isso." O mesmo ocorre com qualquer iterador, gerador, corotina ou método de criação de lista, e eles não exigem o inchaço da estrutura O (n) nem mais contabilidade em tempo de construção.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.