¿Por qué las mazmorras a menudo se crean de forma subcontractiva en lugar de aditiva?

Estoy teniendo dificultades para decidir cómo generar procesalmente un piso de mazmorra. La forma en que lo he estado haciendo hasta ahora es así:

  • Rellena la list de Salas con alto y ancho aleatorio.
  • Coloque la primera habitación en la list en (0, 0).
  • Agregue espacio a una list temporal de habitaciones que se han colocado con éxito.
  • Coloque la siguiente habitación adyacente a una habitación elegida random de la list temporal antes mencionada
  • Continúa repitiendo el paso anterior hasta que la habitación se coloque con éxito y luego pasa a la habitación contigua.
  • Repita los dos pasos anteriores hasta que se hayan colocado todas las habitaciones.

Después de eso, se crean las puertas entre las salas y se toman varias medidas para asegurar que la colisión funcione correctamente, pero mi pregunta es: ¿por qué parece ser una práctica común crear primero un área grande de células que estén "completadas" y para luego 'tallar' salas y pasillos en lugar de generar mazmorras a mi manera? No digo que mi path sea mejor, me gustaría que alguien me diga qué estoy haciendo mal y por qué debería hacerlo de otra manera. Solo me resulta más fácil manejar las distintas salas y celdas de mi mazmorra. También significa que no tengo un montón de células "inútiles" al otro lado de las panetworkinges de la mazmorra que no hacen más que acaparar el poder de procesamiento, eso es algo que nunca entendí.

Solo quiero crear una mazmorra que equilibre la eficiencia y el layout.

Si es fácil para ti, mantenlo. Nadie dice que tienes que hacerlo de cierta manera, o que el tuyo está mal.

La razón por la que típicamente se hace de esta manera – de manera sutil o como se dice, "tallado" – es muy probablemente debido a la influencia de roguelikes, que posiblemente fueron algunos de los primeros juegos en generar mazmorras. En roguelikes, el jugador puede hacer un túnel en cualquier lugar dentro del espacio rectangular del nivel, por lo que cada celda, incluso si no se puede caminar, se registra como una ficha en el map, en caso de que se pueda recorrer más tarde. Por lo tanto, los mosaicos también pueden comenzar como espacios cerrados con potencial para ser abiertos.

Otro género muy frecuentemente asociado con los maps de mosaico es el RTS, donde la mayoría de las áreas están abiertas por defecto, y en las que tiene sentido simplemente generar el map como todas las fichas abiertas. Los RPG Overland son similares a este respecto. Entonces esto es ciertamente otra influencia en el enfoque típico.

Su enfoque se adapta mejor a un juego en un espacio interior donde no se producirá un túnel dynamic, es decir, una vez que se han creado las salas del nivel, éstas permanecerán siempre iguales. Obviamente, entonces podemos tener varias matrices en 2D muy pequeñas, cada una de las cuales representa las fichas de una sala, y estas se pueden conectar de forma gráfica. Esto es mucho más eficiente desde el punto de vista de la memory, pero una vez más, hacer un túnel en los espacios grandes entre los límites de la sala es, si no imposible, más difícil de lograr (al less, necesitaría crear nuevos nodos en su gráfico de salas, y la asignación podría no ser sea ​​intuitivo ya que no sabe cuán amplia / alta será la sala en cuestión). La memory no es un problema para la mayoría de los niveles de juego, dado el bajo costo por ficha y la memory que tenemos disponible en estos días (gigabytes).

Esto es informativo en términos del gran número de enfoques diferentes para la generación de laberinto.