CONTEST: Mapgenerierung

[Drakes]

Ich bin jetzt nicht wirklich richtig fertig, hoffe jedoch, dass es trotzdem präsentierbar ist. :P

http://drakes.dr.ohost.de/dungeon_genotype/

Parameter:
rooms : Anzahl Räume (default: 10)
seed : Startseed (default: set by php)
collision : on / off (default: off)

z.B.:
http://drakes.dr.ohost.de/dungeon_ge...5&collision=on

collision ist auf default auf off, da sonst das ganze relativ langsam läuft (durch Portale geht trotzdem). Ausserdem ist noch keine Garantie da, dass sich die Räume nicht überschneiden und ein durchqueren unmöglich machen (falls collision auf on) ^^". Die Quelldateien werde ich auf Wunsch nachreichen, Zeit habe ich jetzt gerade aber keine.

[Jesus_666]

Hier ist, was der Wachstumsalgorithmus mit einer Rekursionstiefe von 32 Schritten hervorbringt. Der Kram ist natürlich arg beta und der finale Output würde hübscheres HTML erzeugen.

[Ergebnis] [mit Debugoutput (Achtung, große Datei)]

Was ich habe:
- Das Programm hat eine Liste von Tiles, jeweils mit erlaubten Nachbartiles.
- Es wird ein Tile gelegt und dann (sofern welche definiert sind und der Zielort frei ist) nach Norden, Osten, Süden und Westen weitergebaut.
- Wenn ein Tile gelegt werden soll, wird bei allen Nachbarn geprüft, ob diese das zu legende Tile erlauben.
- Wenn kein passendes Tile gelegt werden kann, wird "Geröll" (auf der Karte rot) gelegt. Dies ist ein Fehlerfall.

Was fehlt:
- Ich habe momentan nur die nötigen Tiles, um Räume zu modellieren. Gänge würden andere Tiles erfordern.
- Wenn kein passendes Tile gelegt werden kann, sollte das Programm Backtracking verwenden (sprich: das Legen des letzten Tiles rückgängig machen).
- Die Liste der Nachbartiles sollte gewichtet sein, so daß beispielsweise Wände dazu neigen, lieber andere Wände statt Ecken zu legen.
- Diese Gewichtung sollte eigentlich auch noch adaptiv sein, damit Räume nur kurz bevorzugt wachsen und dann auf einen Abschluß zustreben.
- Dadurch, daß der Zustand jedes Tiles im Speicher bleibt (weil ja alles rekursiv läuft) ist der Speicheraufwand bei großen Maps verhältnismäßig enorm. Das könnte man kompensieren, indem man blockweise arbeitet (es wird versucht, einen Block von X×X Tiles zu füllen; dann wird der Block als komplett angesehen und daneben weitergebaut).

Was momentan gar nicht modelliert ist:
- Der Algorithmus wächst einfach vor sich hin und ist nicht in der Lage, eine bestimmte Anzahl von Räumen zu erzeugen.


Eventuell wäre es allgemein einfacher, einen großen Haufen Tileblöcke vorzudefinieren und einfach die aneinanderzupappen.


PS:
So, hier habe ich noch einen Durchlauf mit 256 Schritten und etwas getweakten Listen (leere Flächen werden doppelt so gern angelegt). Achtung, die Seite selbst ist über ein Megabyte groß.
[Ergebnis 256]

[Manni]

Öhm Leute, wie wär's mal damit, den Thread endlich zuzumachen und einen Umfrage auf? Der Contest ist jetzt bald schon ne Woche vorbei...

[Ineluki]

So liebe Teilnehmer ...

Wir waren mit der Abgabezeit mehr als grosszuegig und haben Euch noch die letzte Woche spendiert. Heute Abend machen wir definitiv die Umfrage fuer die Abstimmung auf. Wer es bis dahin nicht geschafft hat, etwas abzugeben, der wird es wohl auch nicht mit einer weiteren Woche Zeit schaffen.

[Jesus_666]

Ich habe erfahren, daß mein Skript zur Wahl steht, obwohl es gar nicht die Bedingungen erfüllt. Naja, wenn ihr meint...

Hier ist der Code. PHP5.
Zip, bzip2'd tarball, LZMA/7zip


BTW; das, was vorher blau war, ist jetzt graubraun. Das ist die einzige Änderung gegenüber dem demonstrierten Kram (abgesehen von Kommentaren). Das Blau kriegt man zurück, indem man in Zeile 206 das "0h" durch "0x" ersetzt. Blau war ursprünglich als Signalfarbe für noch nicht bearbeitete (oder als Einschluß leer gebliebene) Felder gedacht, aber im Output sieht's aus, als sei da Wasser geplant. Daher die Umfärbung.


Edit: Die Links waren kaputt. Gefixt.