Dungeon-Crawler-Labyrinthe erzeugen

[heinz]

Hallo Zusammen,

Vorgelaber: (Wer das nich haben moechte, weiter gehts bei "Die Aufgabe:")
Es ist wieder soweit.
Ich haette gerne (mal wieder) ein paar Denkanstoesse zum Programmieren von Euch.

Ich habe demnaechst zwei Wochen Urlaub und hatte die Idee, mir einen kleinen "Dungeon Crawler" in C/C++ mit SDL zu Schreiben, um nicht aus der Uebung zu kommen.
Was braucht man dafuer? ... Natuerlich ein Labyrinth!
Ich hab schon mal ein wenig angefangen und habe eine einfache Methode fuer eine Labyrintherzeugung geschrieben.

Erzeuge eine Aussenwand und befestige daran zufaellig ein paar Wandteile, die direkt an der Aussenwand "kleben".
Fuege weitere Wandteile per Zufall hinzu, aber achte darauf dass jede neue Wand eine bestehende Wand an einem Ende beruehrt und sein anderes Ende in einem nicht bebauten Teil des Labyrinths liegt.

Kleine Raeume im Labyrinth erzeuge ich, in dem ich mitten im Labyrinth einzelne Waende erzeuge, die ich nach der erstellung/berechnung wieder entferne.

Die so erzeugten Labs sehen sehr brauchbar aus und sind nach meinen ersten Tests auch immer "loesbar" (haben einen "gueltigen" Weg).

Was jetzt noch fehlt ist,

Die Aufgabe:
In einen "ordentlichen" Dungeon gehoeren natuerlich auch verschlossene Tueren.
Wie stelle ich sicher, das sich die zu den Tueren passenden Schluessel immer an zugaenglichen Orten befinden, damit keine unloesbaren Labyrinthe erzeugt werden.

Mein erster Ansatz dazu ist:
Zufaellig eine Tuere zu erzeugen und danach den noch begehbaren Teil des Labyrinthes zu erfassen um darin den Passenden Schluessel zu deponieren,
Diesen Vorgang koennte man dann so lange wiederholen, bis die gewuenschte Anzahl an Tueren im Dungeon verteilt sind.

Das wuerde sicherlich funktionieren aber koennte auch sehr eigenartige Dungeons erzeugen.
Extrembeispiel ist ein Dungeon in dem z.B. drei Tueren verteilt sind deren Schluessel direkt auf den ersten drei Feldern hinter dem Eingang liegen, weil auf dem vierten Feld die erste Tuere sitzt.

Was ich gerne haette:
Per Zufall erzeugte "ausgewogene" Labyrinthe mit verschlossenen Tueren, die aber immer auch "loesbar" sind.

Vlt. gibt es ja hier wieder mal jemand, der eine "supertolle" Idee hat auf die ich nie gekommen waere und mir dabei hilft eine Loesung zu finden.

Ich habe hier schon oft solch "seltsame" Fragen abgelassen und eigentlich immer Antworten erhalten die mich weitergebracht haben.
(Manchmal auch in Bereichen, die mit dem eigentlichen Thema ueberhauptnichts zu tun hatten... )
So hoffe ich auch dieses mal.
Es muss kein fertiger Code sein (obwohl ich diesen natuerlich nicht ablehnen wuerde ) sondern eher ein "zusammenwerfen" von Ideen, die mich zu einer Loesung bringen.
Es ist auch nicht "Lebensnotwendig" sondern nur ein Hobbyprojekt aus reinem Spass am Coden...

Ich freue mich auf Eure Antworten und habt schon mal vielen Dank fuers Lesen...

Vorweihnachtliche Gruesse,
heinz

[hikaru]

Zufaellig eine Tuere zu erzeugen und danach den noch begehbaren Teil des Labyrinthes zu erfassen um darin den Passenden Schluessel zu deponieren,

Es wäre interessant zu erfahren, wie die Erfassung der noch zugänglichen Bereiche funktioniert. Falls du topologisch einen Pfad zwischen Eingangs- und Ausgangstür des Bereichs kennst, dann könntest du für den Schlüssel eine Mindestdistanz von den Türen definieren. Schließlich wäre es auch doof, wenn der Schlüssel direkt vor der Ausgangstür liegt.

Eine Alternative sähe ich bei deinen Hilfswänden. Spielmechanisch würde es wohl Sinn ergeben, interessante Dinge wie Schlüssel bevorzugt in Räumen zu finden, nicht einfach irgendwo in Gängen. Also könntest du den Schlüssel an einer der Hilfswände deponieren, bevor du sie löschst.
Du solltest natürlich trotzdem sicherstellen, dass der Schlüssel nicht direkt vor der Tür liegt, indem du z.B. eine Mindestdistanz zwischen Raum (Hilfswand) und Tür definierst. Der Vorteil gegenüber dem ersten Ansatz wäre, dass du hier keinen topologischen Pfad von A nach B kennen musst, sondern einfach geometrisch auf dem gesamten Spielfeld ohne Rücksicht auf die Wände arbeiten kannst.

Insgesamt finde ich deinen deinen "Outside-In"-Ansatz interressant, also dass du erst ein Rahmenspielfeld generierst und dort dann Wände einziehst. Warum hast du den gewählt?
Spontan hätte ich mich wohl an "Inside-Out" versucht, also per Zufall einen Wegbaum erzeugt, ohne Rücksicht darauf, wie das Gesamtspielfeld am Ende aussieht. Topologie würde hier nebenbei abfallen. Ich kann aber auf Anhieb nicht abschätzen, ob das insgesamt einfacher oder schwieriger wäre.

[Meillo]

Ich habe demnaechst zwei Wochen Urlaub und hatte die Idee, mir einen kleinen "Dungeon Crawler" in C/C++ mit SDL zu Schreiben, um nicht aus der Uebung zu kommen.

Juhuuu!

Bitte lass uns weiterhin an deinen Fortschritten und Gedanken teilhaben. Ich finde die jedes Mal wieder toll zu lesen.


Zu deinem konkreten Problem kann ich nichts beitragen, aber bei deiner Beschreibung des inkrementellen Erstellens der Karte habe ich mich an ein Projekt von mir erinnert, bei dem ich einen solchen Prozess nebenbei schrittweise als animiertes SVG ausgegeben habe. Dann konnte ich hinter viel anschaulicher verfolgen wie es entstanden ist. Das hat mir geholfen, weil Visualisierungen manches besser vermitteln koennen. Am Ende habe ich das SVG dann in einen Film konvertiert, weil der sehr viel weniger Datenmenge braucht. Vielleicht macht sowas bei dir auch Sinn.


Jetzt bin ich schon gespannt den weiteren Verlauf deines Projektes mitzuverfolgen.

[heinz]

@hikaru

Erstmal Danke fuer Deine Antwort und Deine Zeit.

Es wäre interessant zu erfahren, wie die Erfassung der noch zugänglichen Bereiche funktioniert.

Die existiert im Moment noch nur als Idee in meinem Kopf.
Es gab/gibt ein "Modul" fuer den xscreensaver der Labyrinthe erzeugt und danach loest indem er einfach loslaeuft und den Weg dabei markiert wo er schonmal war.
Wenn in eine Sackgasse "gelaufen" wird, wird bis zum letzten Abzweig zurueckgegangen und eine neue Richtung benutzt. (Name weiss ich leider nicht mehr, war aber richtig klasse...)
Ich dachte mir diese Art fuer meine Zwecke zu nutzen.
Wenn ich in das Labyrinth zufaellig eine Tuere setze und die Wege vom Eingang her nach der obigen Methode "ablaufe" bis ich wieder am Ausgangspunkt/Eingang ankomme, habe ich so alle
zugaenglichen Felder im Labyrinth ermittelt in denen man den Schluessel (zufaellig) deponieren koennte.

Falls du topologisch einen Pfad zwischen Eingangs- und Ausgangstür des Bereichs kennst, dann könntest du für den Schlüssel eine Mindestdistanz von den Türen definieren.

Das ist ein interessanter Gedanke...
Ich muesste mir die genauen Wege sozusagen notieren, um dann einen Abstand ermitteln zu koennen. Werde mir da mal heute Abend ein wenig drueber sinnieren, wie das zu realisieren ist...

Schließlich wäre es auch doof, wenn der Schlüssel direkt vor der Ausgangstür liegt.

Naja, selbst bei Klassikern wie "Dungeon Hack" (altes DOS-Spiel, falls das noch jemand kennt) kam das hin und wieder vor... Aber Klar ist unschoen...

Also könntest du den Schlüssel an einer der Hilfswände deponieren, bevor du sie löschst.

Klasse! Auch eine tolle und einfach umzusetzende Idee. Da haetten auch eine menge Gegner platz, die den Schluessel "beschuetzen".

Du solltest natürlich trotzdem sicherstellen, dass der Schlüssel nicht direkt vor der Tür liegt, indem du z.B. eine Mindestdistanz zwischen Raum (Hilfswand) und Tür definierst. Der Vorteil gegenüber dem ersten Ansatz wäre, dass du hier keinen topologischen Pfad von A nach B kennen musst, sondern einfach geometrisch auf dem gesamten Spielfeld ohne Rücksicht auf die Wände arbeiten kannst.

Ich bin mir nicht sicher, ob ich das ganz verstehe.
Man muesste dann zuerst den Schluessel deponieren und dann vom Ausgang her einen Platz fuer die Tuere suchen? Hmm... Klingt auch Interessant und auch relativ einfach umsetztbar.

Insgesamt finde ich deinen deinen "Outside-In"-Ansatz interressant, also dass du erst ein Rahmenspielfeld generierst und dort dann Wände einziehst. Warum hast du den gewählt?

Das ist einfach beantwortet: Der fiel mir als erstes ein, war leicht zu Coden und lieferte gute Ergebnisse.

...also per Zufall einen Wegbaum erzeugt, ohne Rücksicht darauf, wie das Gesamtspielfeld am Ende aussieht. Topologie würde hier nebenbei abfallen. Ich kann aber auf Anhieb nicht abschätzen, ob das insgesamt einfacher oder schwieriger wäre.

Klingt fuer mich schwieriger, da ich mir unter dem Begriff "Wegbaum" und dessen Erzeugung nicht so richtig was vorstellen kann.
Das liegt aber sicher an mir...
Wie bringt man den "Wegbaum" z.B. dazu am Ausgang zu enden?

Vielen Dank nochmal fuer die Denkanstoesse...




@Meillo

Juhuuu!

*kaputtlach*

Bitte lass uns weiterhin an deinen Fortschritten und Gedanken teilhaben. Ich finde die jedes Mal wieder toll zu lesen.

Danke... Es ist immer wieder schoen sowas zu lesen und zu merken, das man nicht der einzige "Nerd" auf der Welt ist..

an ein Projekt von mir erinnert, bei dem ich einen solchen Prozess nebenbei schrittweise als animiertes SVG ausgegeben habe.

Das ist ein sehr guter Ratschlag und so Programmiere ich eigentlich auch fast immer. Ich muss immer sehen/anzeigen, was ich so zusammenschreibe. (Bringt auch oft neue Ideen.)
Und da ich auch sehr oft in Kombination mit SDL meine Programme entwickle, kann ich meinen "Dingern" immer gleich zuschauen was sie so treiben...

Vielleicht macht sowas bei dir auch Sinn.

Auf jeden Fall!

Jetzt bin ich schon gespannt den weiteren Verlauf deines Projektes mitzuverfolgen.

Ich bin auch gespannt, wie es damit weitergeht. Hoffentlich habe ich mir fuer 2 Wochen nicht zuviel vorgenommen...
Ab dem 24sten kann es auch erst "richtig" los gehen.
(So ein, zwei Stunden am Abend sind fuer mich einfach zu wenig. Das muessen bei mir schon komplette Abende sein um etwas zustande zu bringen.)

Auch Dir ein Danke fuer den Tipp. (Und auch fuer all die anderen, die ich ueber die Zeit schon von Dir bekam.)


Weitere Ideen und Kommentare sind willkommen.


Gruss,
heinz

[hikaru]

Du solltest natürlich trotzdem sicherstellen, dass der Schlüssel nicht direkt vor der Tür liegt, indem du z.B. eine Mindestdistanz zwischen Raum (Hilfswand) und Tür definierst. Der Vorteil gegenüber dem ersten Ansatz wäre, dass du hier keinen topologischen Pfad von A nach B kennen musst, sondern einfach geometrisch auf dem gesamten Spielfeld ohne Rücksicht auf die Wände arbeiten kannst.

Ich bin mir nicht sicher, ob ich das ganz verstehe.
Man muesste dann zuerst den Schluessel deponieren und dann vom Ausgang her einen Platz fuer die Tuere suchen? Hmm... Klingt auch Interessant und auch relativ einfach umsetztbar.

Das ginge wohl auch, aber ich meinte es eigentlich andersrum*:
1. Du erzeugst zuerst deine Hilfswände und danach die echten Wände.
2. Dann generierst du Türen, für die gilt, dass sie N Felder von der nächsten Hilfswand entfernt sein müssen. Um N zu ermitteln brauchst du irgendeinen geometrischen Algorithmus, welcher ist egal. Du könntest z.B. die minimale Anzahl der zu durchschreitenden Felder zwischen nächster Hilfswand und Tür bestimmen. Für einen Turm auf einem Schachbrett wäre das die Differenz der Felder in X-Richtung plus die Differenz der Felder in Y-Richtung (Tb2-e6 = 3+4=7=N). Das sind die beiden Katheten eines rechtwinkligen Dreiecks. Wenn du es etwas realistischer haben willst, könntest du stattdessen die Hypotenuse des Dreiecks nehmen (hier: N=5).
3. Danach generierst du Schlüssel, für die gilt, dass N=0 ist.

Nun ist sichergestellt, dass ein Schlüssel immer mindestens N-1 Felder von der nächsten Tür entfernt ist. Ein Schönheitsfehler ist, dass eine Tür nie direkt in einen Raum führt, sondern immer ein Gang mit mindestens der Länge N zwischen Tür und Raum liegt.

Das ist einfach beantwortet: Der fiel mir als erstes ein, war leicht zu Coden und lieferte gute Ergebnisse.

Klingt fuer mich schwieriger, da ich mir unter dem Begriff "Wegbaum" und dessen Erzeugung nicht so richtig was vorstellen kann.

Dafür gibt es sicher fertige Algorithmen. Spontan würde ich bei der Generierung nach folgenden Regeln vorgehen:
1. Jedes Feld hat vier Seiten.
2. Jedes Feld hat eine Eingangsseite über die es betreten wird. Diese Seite ist immer offen.
3. Die drei anderen Seiten sind entweder offen, verschlossen, oder haben eine Tür.
4. Ist eine Seite nicht verschlossen, dann betrete das Feld dahinter.
5. Brich ab, wenn du in 4. auf ein bereits erzeugtes Feld triffst.
6. Brich ab, nachdem du N Felder durchschritten hast. (N kann ein fixer Wert sein. Besser wäre aber, wenn es innerhalb eines definierten Bereichs bei jedem Abzweig per Zufall neu bestimmt wird.)

Dann würde ich mich, angefangen am Feld hinter dem Spielfeldeingang, nach diesen Regeln iterativ vorarbeiten.

Wie bringt man den "Wegbaum" z.B. dazu am Ausgang zu enden?

Indem du diesen Weg zuerst generierst. Hierzu wird 3. so modifiziert, dass jedes Feld mindestens ein Ausgangsfeld besitzt, bis du nach N Schritten am Spielfeldausgang ankommst. Die Position des Ausgangs ist hier nicht vordefiniert, sondern ergibt sich dynamisch bei der Wegfindung.

Ein Nebeneffekt den ich in diesem Algorithmus sehe ist, dass er ein offeneres Labyrinth generieren würde, in dem es auch so unsinnige Dinge wie eine Tür direkt neben einem offenen Durchgang, oder gar mitten in einem sonst leeren Raum geben kann. Vermutlich könnte man das mit verfeinerten Regeln zur Wandgenerierung abfangen, aber darüber müsste ich länger nachdenken.


*) Disclaimer: Ich habe bisher die Vorstellung, dass dein Spielfeld aus quadratischen Kacheln besteht, wie ein Schachbrett. Falls meine Vorstellung falsch ist, dann könnten auch meine Vorschläge unpassend sein.

[Meillo]

Es gab/gibt ein "Modul" fuer den xscreensaver der Labyrinthe erzeugt und danach loest indem er einfach loslaeuft und den Weg dabei markiert wo er schonmal war.
Wenn in eine Sackgasse "gelaufen" wird, wird bis zum letzten Abzweig zurueckgegangen und eine neue Richtung benutzt. (Name weiss ich leider nicht mehr, war aber richtig klasse...)

Wie der Screensaver heisst weiss ich auch nicht, aber dieser Algorithmus heisst Backtracking: https://de.wikipedia.org/wiki/Backtracking

... nur falls du das noch nicht wusstest.



@heinz: Heisst das, du bist derzeit noch in der Vorbereitungsphase, sammelst Ideen und machst dir einen Plan, damit du dann ab dem 24. durchstarten kannst?

[eggy]

@heinz: dürfen wir mitspielen?
https://www.jwz.org/xscreensaver/screenshots/
maze oder maze 3d vielleicht?

[Meillo]

@heinz: dürfen wir mitspielen?
https://www.jwz.org/xscreensaver/screenshots/
maze oder maze 3d vielleicht?

Nachdem eggy das gepostet hat, bin ich den Links dort mal in die Wikipedia gefolgt:

https://en.wikipedia.org/wiki/Maze_generation_algorithm
https://en.wikipedia.org/wiki/Maze-solving_algorithm

Gerade ersteres erscheint mir eine interessante Lektuere fuer dein Projekt zu sein.

[thoerb]

Ich habe vor ein paar Jahren mal ein Video zum Thema Prozedurale Levelgenerierung gesehen, das ich euch nicht vorenthalten möchte. Da ich mich selbst mit dem Thema noch nie beschäftigt habe, fand ich das ziemlich interessant.

Keine Angst, das ist kein Tutorial zur Programmierung, nur reine Theorie.

Hier das Video: Prozedurale Levelgenerierung - Let's GameDev

[heinz]

@hikaru

1. Du erzeugst zuerst deine Hilfswände und danach die echten Wände.
2. Dann generierst du Türen, für die gilt, dass sie N Felder von der nächsten Hilfswand entfernt sein müssen.
3. Danach generierst du Schlüssel, für die gilt, dass N=0 ist.
Nun ist sichergestellt, dass ein Schlüssel immer mindestens N-1 Felder von der nächsten Tür entfernt ist.

Ich denke/glaube es jetzt einigermassen zu verstehen...
Um dabei aber sicherzustellen das der Schluessel nicht in einem, durch die Tuere, unzugaenglichen Bereich zu liegen kommt muss man aber doch auch die moeglichen Wege beruecksichtigen...
Allein mittels des Abstandes zur Hilfswand, ist das doch nicht gegeben. Oder?
Es kann aber auch durchaus sein, das ich Dich komplett falsch verstehe...

Ich werde auf jeden Fall dieses WE versuchen die hier gesammelten Ideen in weiteren Code zu uebersetzen und kann dann auch ein Paar Bilder liefern.
(Ich kann mit optischem Anschauungsmaterial einfach besser...)

Spontan würde ich bei der Generierung nach folgenden Regeln vorgehen:

OK. Ich versuche zu folgen...

1. Jedes Feld hat vier Seiten.
2. Jedes Feld hat eine Eingangsseite über die es betreten wird. Diese Seite ist immer offen.
3. Die drei anderen Seiten sind entweder offen, verschlossen, oder haben eine Tür.

Soweit, so gut.

4. Ist eine Seite nicht verschlossen, dann betrete das Feld dahinter.

Bedeutet, ich muss mir alle weiteren offenen Seiten merken, um sie nach Abschluss des "ersten Weges" auf die gleiche weise zu verfolgen. Eine Art Stapel fuer offene Wege...
(Erinnert mich ein wenig an einen Grafik-Fuell-Algorithmus den ich mal geschrieben habe.)

5. Brich ab, wenn du in 4. auf ein bereits erzeugtes Feld triffst.

Oder auf eine Aussenwand.?

6. Brich ab, nachdem du N Felder durchschritten hast.
(N kann ein fixer Wert sein. Besser wäre aber, wenn es innerhalb eines definierten Bereichs bei jedem Abzweig per Zufall neu bestimmt wird.)

Puuh... Das ueberschreitet gerade mein Verstaendnis.
Bedeutet das nicht, das ich vorher nicht genau wissen kann wie gross das Labyrinth wird?

Die Position des Ausgangs ist hier nicht vordefiniert, sondern ergibt sich dynamisch bei der Wegfindung.

Eigentlich wollte ich den Ein- und Ausgang vorher bestimmen aber nach dem ich jetzt nochmals darueber nachdenke erscheint es mir nicht mehr so wichtig...

Ich habe bisher die Vorstellung, dass dein Spielfeld aus quadratischen Kacheln besteht, wie ein Schachbrett.
Falls meine Vorstellung falsch ist, dann könnten auch meine Vorschläge unpassend sein.

Deine Vorstellung ist absolut korrekt!

Wie bereits geschrieben, werde ich dieses WE mal an dem Labyrinth "weitermachen" und sehen was sich so ergibt.

Vielen Dank fuer Deine Ideen und Deine Zeit!



@Meillo

Wie der Screensaver heisst weiss ich auch nicht, aber dieser Algorithmus heisst Backtracking:

Danke!

Heisst das, du bist derzeit noch in der Vorbereitungsphase, sammelst Ideen und machst dir einen Plan, damit du dann ab dem 24. durchstarten kannst?

Ich habe die letzten Wochen immer mal wieder ueberlegt, wie ich vorgehen muss/soll und was man so dafuer braucht. (Meisst abends im Bett...)
Da jetzt zwei Wochen Urlaub auf mich zukommen habe ich letztes WE dann mal angefangen etwas Code zu generierern der das besagte Labyrinth erzeugt.
(Eingang, Ausgang, Einzigartiger Weg und Raeume/Kammern) Ganz primitiv mit ASCII-Ausgabe.
Dabei stiess ich auf das Tuer/Schluessel problem und dachte mir:
Begluecke doch mal wieder die netten Leute im Debianforum mit deinen Spinnereien.
Vlt. hat ja jemand eine zuendende Idee oder liefert Denkanstoesse die mich weiterbringen.
(Waere ja nicht das erste mal. Deshalb tauche ich hier auch immer mal wieder auf. Lesen tue ich hier fast Taeglich aber schreiben nicht so oft.
Da mein Lieblingsbereich >>Softwareentwicklung und -paketierung, Scripting<< in letzter Zeit auch nicht mehr so gut besucht ist (Gefuehlt).
Und bis ich abends dazu komme hier reinzuschauen, sind auch die Fragen meisst schon beantwortet... (Fuer die Fragesteller ist das natuerlich klasse und soll auch so bleiben. ))

https://en.wikipedia.org/wiki/Maze_generation_algorithm
https://en.wikipedia.org/wiki/Maze-solving_algorithm

Danke fuer die Links. Werde mich da mal "durchkaempfen"...



@eggy

@heinz: dürfen wir mitspielen?

*lach* Tust Du doch schon... Nette Leute sind immer willkommen...

maze oder maze 3d vielleicht?

Jaa! Maze, wie passend auch...
Hab ihn gleich mal wieder laufenlassen. Ist immer wieder unterhaltsam zuzuschauen...



@thoerb

Ich habe vor ein paar Jahren mal ein Video zum Thema Prozedurale Levelgenerierung gesehen, das ich euch nicht vorenthalten möchte.

Auch Dir vielen Dank. Werde ich mir ansehen...



@all

Wie schon geschrieben werde ich mich dieses WE mal weiter mit der Labyrinth-Erzeugung beschaeftigen und mich (hoffentlich) mit Bildern derselben wieder melden.
Da an der Idee >Dungeon-Crawler< aber auch noch eine Menge anderes "Zeug" haengt, wollte ich mich eigentlich damit nicht allzu lange "aufhalten".
Ich werde auch versuchen das Programm so zu schreiben, dass man einzelne Teile, wie die Labyrintherstellung, auch einfach spaeter gegen eine andere erstellungsmethode austauschen kann.



Herzlichen Dank nochmal an alle die hier Geschrieben haben und mir ihre Zeit fuer meine "Spinnereien" gegeben haben!


Wird fortgesetzt...

Gruss,
heinz

[hikaru]

Um dabei aber sicherzustellen das der Schluessel nicht in einem, durch die Tuere, unzugaenglichen Bereich zu liegen kommt muss man aber doch auch die moeglichen Wege beruecksichtigen...
Allein mittels des Abstandes zur Hilfswand, ist das doch nicht gegeben. Oder?

Richtig. Die zugänglichen Bereiche musst du vorher bestimmen. Wie man das ohne Topologie macht weiß ich nicht. Das hatte ich nicht zuende gedacht.

4. Ist eine Seite nicht verschlossen, dann betrete das Feld dahinter.

Bedeutet, ich muss mir alle weiteren offenen Seiten merken, um sie nach Abschluss des "ersten Weges" auf die gleiche weise zu verfolgen. Eine Art Stapel fuer offene Wege...
(Erinnert mich ein wenig an einen Grafik-Fuell-Algorithmus den ich mal geschrieben habe.)

Ja, genau. Das ist dann der Wegbaum den ich meine. Ich vermute, genau hierfür gibt es fertige Algorithmen.

5. Brich ab, wenn du in 4. auf ein bereits erzeugtes Feld triffst.

Oder auf eine Aussenwand.?

Wenn es Außenwände im Sinne fester Spielfeldgrenzen gibt, dann ja. Die muss es aber nicht zwangsläufig geben.
Da fällt mir noch ein, du müsstest nach der Generierung des Spielfeldausgangs das Feld dahinter für weitere Wege tabu machen. Sonst könntest du von hinten auf den Ausgang stoßen. Das muss zwar spielmechanisch nichts bedeuten, wäre aber komisch.

6. Brich ab, nachdem du N Felder durchschritten hast.
(N kann ein fixer Wert sein. Besser wäre aber, wenn es innerhalb eines definierten Bereichs bei jedem Abzweig per Zufall neu bestimmt wird.)

Puuh... Das ueberschreitet gerade mein Verstaendnis.
Bedeutet das nicht, das ich vorher nicht genau wissen kann wie gross das Labyrinth wird?

Ja, das bedeutet es. Es sei denn, du führst z.B. eine globale maximale Pfadlänge vom Spielfeldeingang aus ein. Und das solltest du tun, denn sonst könnten deine Labytinthe theoretisch unendlich groß werden, was bei endlichem RAM irgendwann zum Problem wird.

[Meillo]

Wenn man das Labyrinth als Graph betrachtet, dann kann man es frei im Raum entwickeln. Ich glaube, das ist hikarus Sicht darauf. Bei Dungeon-Crawler-Spielen ist es aber wohl eher ueblich, dass man eine rechteckige Grundflaeche hat und diese (teilweise) mit einem Labyrinth fuellt. Gespeichert wird das dann in einem zwei dimensionalen Array: Jeder Wert ist eine Art von moeglichem Inhalt ... Wand, leerer Raum/Gang, Tuer, Schatz, Monster, ...

Man kann es natuerlich auf beide Arten machen. Vermutlich wird diese Entscheidung aber auch die Algorithmen beeinflussen. Wenn man sich das von thoerb verlinkte Video anschaut, so wird deutlich, dass der Typ nicht mit einem Graphenansatz arbeit, sondern das Raster durchgeht und darin sucht. Das ist im allgemeinen Fall vermutlich ineffizienter, aber bei ueberschaubaren Leveln in gewisser Weise bequem, weil man einfach mit Brute Force draufschlaeft und sich die verlinkten/indirekteren Datenstrukturen spart.

[hikaru]

Wenn man das Labyrinth als Graph betrachtet, dann kann man es frei im Raum entwickeln. Ich glaube, das ist hikarus Sicht darauf.

Ja.

Bei Dungeon-Crawler-Spielen ist es aber wohl eher ueblich, dass man eine rechteckige Grundflaeche hat und diese (teilweise) mit einem Labyrinth fuellt. Gespeichert wird das dann in einem zwei dimensionalen Array: Jeder Wert ist eine Art von moeglichem Inhalt ... Wand, leerer Raum/Gang, Tuer, Schatz, Monster, ...

Danke für den Hinweis! Ich glaube ich habe heinz doch missverstanden, was das Spielfeld angeht. So wie du es hier beschreibst, ist eine Wand ein Feldinhalt, mit einer Ausdehnung von 1*1. Ich hatte es bisher so verstanden, dass eine Wand eine Kanteneigenschaft eines Feldes ist, mit einer Ausdehnung von 0*1. Meine Wände hätten also keine Dicke.

Das ändert im Prinzip nichts, man müsste aber den Algorithmus zur Graphengenerierung anpassen, denn zwei parallel laufende Gänge müssten mindestens ein Feld Abstand voneinander haben, damit eine Wand dazwischen passt, und ein neuer Gang der auf einen alten trifft, würde zwangsläufig die Wand durchbrechen.

[dakuan]

Ich habe das jetzt einmal durchgelesen und leider nicht alles behalten, was mir dazu eingefallen ist. Kann auch sein, das einige meiner Gedanken schon angesprochen wurden. Dafür entschuldige ich mich schonmal vorsorglich.

Wenn das Spielfeld aus Quadraten besteht und eine äußere Begrenzung hat, kann man zum Überprüfen, ob es einen Weg von A nach B gibt, den Lee-Algorithmus verwenden (einer meiner Lieblinge). Man braucht dafür eine Matrix (hier Spiefeld) und ein FIFO.

Anmerkung, In dem Artikel steht zwar, dass man viel Speicher benötigt, aber das bezieht sich auf Leiterplatten. In einem Labyrinth mit Wänden ist das vernachlässigbar.

Und wenn man für die Entfernung nur die X- und Y-Distanz berücksichtigt, ist das die Manhattan-Distanz.

Nachtrag: Man ließt darüber auch viel "Blödsinn". Den Zähler z.B. muss man nicht monoton bis Unendlich hochzählen. Wenn es 4 Nachbarfelder gibt, braucht man nur von 1 bis 3 zu zählen. Da reicht dann eine 2-Bit Matrix.

[eggy]

Gibt schönere, u.a.
A-Star (auch A-Stern, A*) https://de.wikipedia.org/wiki/A_Stern
Bellman-Ford https://de.wikipedia.org/wiki/Bellman-Ford-Algorithmus
etc

Und wenn man das Graphenzeug eh schon eingebaut hat, bekommt man die Monster-AI praktisch für umsonst mitgeliefert. Ein "ja, das Viech kann notfalls schwimmen, ist aber wasserscheu"-Wegfindung lässt sich via Kantengewichte für schwieriges Terrain dann auch ganz leicht umsetzen.

[eggy]

@heinz: Mitspielen in Form von Codefortschritt mitlesen dürfen ... falls es nen git gibt, wär das extra klasse

(@Meillo: Adventszeit ist dieses Jahr dann eben nach Weihnachten)

[Meillo]

@heinz: Dein Dungeon-Crawler-Projekt und die Labyrinth-Ueberlegungen haben mich jetzt doch ziemlich begeistert. Gestern Abend im Bett ist die Ueberlegung entstanden, dass ich auch etwas derartiges programmieren koennte. Nach ein bisschen brainstormen habe ich nun ein Konzept, das tragfaehig erscheint und das mich reizen wuerde. Technologisch wuerde ich C und ncurses verwenden, weil ich schon lange was mit ncurses machen will, und C weil es fuer mich keine schoenere Sprache gibt (naja von awk vielleicht abgesehen ). Die Hauptherausforderung fuer mich ist die Zeit. Ich kann derzeit leider noch nicht sagen wie ich in den naechsten zwei Wochen Zeit haben werde. Es kommt auch darauf an wie gut die Programmierung dann flutscht.

Wie ist nochmal dein Zeitplan genau? Du hast was von zwei freien Wochen geschrieben. Sind die von jetzt bis zum Jahresende?

Vielleicht haben noch mehr User Lust etwas zu programmieren. Dann koennte das eine Art DFDE-Programmier-Challenge sein: Von jetzt bis Neujahr irgendeine Art von Dungeon-Crawler- oder Labrinth-Software zu programmieren, sei es nun ein Spiel oder ein Levelgenerator oder irgendein sonstiges Labyrinth-Programm. Anfang des neuen Jahres koennten wir unsere Ergebnisse dann gegenseitig austauschen -- nicht als Wettbewerb sondern mehr als Ausstellung.

Gibt es denn weitere Personen die Lust haetten, eine Teilnahme zu versuchen?

[heinz]

@hikaru

Vielen Dank fuer Deine ausfuehrlichen Antworten.
Anscheinend haben wir ein wenig aneinander vorbeigeredet, weil ich es zu Beginn nicht richtig erklaert habe.
Meillo hat es richtig erfasst, zwei dimensionales Array aus Feldern, die entweder Weg, Wand oder sonstwas sind.
Ich habe bei meiner Netzrecherche ein paar Beispiele gefunden, wie Du es meinst. Jetzt verstehe ich auch den Begriff "Wegbaum" etwas besser.
Die Art das ueber Graphengenerierung zu loesen uebersteigt mein Wissen/Koennen allerdings etwas...
OK, etwas viel...
Hab jetzt mal etwas zusammengebastelt. Siehe weiter unten...



@eggy

@heinz: Mitspielen in Form von Codefortschritt mitlesen dürfen ... falls es nen git gibt, wär das extra klasse

Ohjeh, natuerlich stelle ich meinen Code gerne zur Verfuegung. Allerdings bin ich, wie schon geschrieben, nur Hobbycoder und mein Code sieht fuer andere wohl ziemlich "uebel" aus.
Ich mische in meinen C-Code oft auch C++ "Dinge" und habe, da ich mir das Programmieren selbst beigebracht habe, eine eigene "Ordnung" die moeglicherweise fuer andere sehr unuebersichtlich ist. (Besonders auch waehrend der Erstellung...)
Es gibt auch kein makefile (wollte ich mir schon laenger mal anschauen wie man das macht, aber wie es halt so ist...) sondern eine Zeile wie:

Code: Alles auswählen

c++ hero_quest.cc hero_quest -I/usr/include/SDL -lSDL_image -lSDL_gfx -lSDL -lSGE -Wall

um es zu erstellen.
Ich habe auch immer ein Script am laufen, welches das Programm immer neu Compiliert wenn ich es speichere und sich auch sonst um alle meine SDL-Programm-Projekte "kuemmert".

Ich werde hier mal als eine Art "Test" die Datei mit dem Code fuer die Klassen reinstellen (Da sind auch die Labyrinth-Dinge drin.)
und wenn Du/Ihr schlau daraus werdet und mich fuer meinen Programmierstiel nicht Toetet werde ich das Projekt natuerlich gerne als .tbz zur Verfuegung stellen...
41549



@Meillo

Dein Dungeon-Crawler-Projekt und die Labyrinth-Ueberlegungen haben mich jetzt doch ziemlich begeistert.

Das freut mich...

Wie ist nochmal dein Zeitplan genau? Du hast was von zwei freien Wochen geschrieben. Sind die von jetzt bis zum Jahresende?

Mein letzter Arbeitstag ist der 23.12.21. Dann hab ich Urlaub bis zum 10.01.22. Sind etwas ueber 2 Wochen.
Habe aber auch nicht jeden Tag Zeit und vlt. auch nicht jeden Tag lust, moechte aber trotzdem vorankommen mit diesem Projekt.
(Gehe auch ein paarmal mit meinem Kumpel weg und der Tag danach bringt dann oft leichte Konzentrationsprobleme mit sich... )

Vielleicht haben noch mehr User Lust etwas zu programmieren. Dann koennte das eine Art DFDE-Programmier-Challenge sein:

Das waere mal wirklich klasse! Aber vlt. jetzt gerade etwas kurzfristig?
Sollten wir sowas nicht etwas besser Planen? So nach dem Motto "Was machen wir eigentlich?", "Wer macht was?" und "Wie sehen die Schnittstellen aus?".

Aber die Idee irgendein DF-Gemeinschaftsprojekt zu machen finde ich richtig Klasse!

...nicht als Wettbewerb sondern mehr als Ausstellung.

Oder nicht als Ausstellung sondern etwas was alle gerne haetten. Ein Programm fuer einen bestimmten Zweck oder ein Spiel oder sonst irgendein "krass nuetzliches Tool"...



@all

Mein Code ist jetzt soweit, das "anscheinend gueltige" Labyrinthe dabei rauskommen.
Die im Moment eingestellt Groesse ist: 40x30 Felder, 2-8 Raeume (Obwohl man die nicht gut sieht) und 4-10 Tueren.
Die Kacheln/Felder sind (fuer diese Testausgabe) 25x25 Pixel.

Hier sind mal ein paar Screenshoots von 5 nacheinander erstellten Labyrinthen mit:

Code: Alles auswählen

Eingang    : gruener Pfeil
Ausgang    : roter Pfeil
Wand       : Steine
Weg        : grauer Kies
Tuere      : brauner Balken
Schluessel : blauer Schluessel

Die Nummern ueber den Tueren/Schluesseln sind die Zugehoerigkeit. (Schluessel 0 passt in Tuer 0 usw.)








Vielen lieben Dank fuer das rege Interesse und Eure unermuedliche Unterstuetzung.
Schoenen Sonntag noch...
Gruss,
heinz

[eggy]

-o file
Place output in file file. This applies to whatever sort of output is being produced, whether it be an executable file, an object file, an assembler file or preprocessed C code.

somit einfachstes Makefile für Deinen Compilelauf

Code: Alles auswählen

machwas:
	c++ hero_quest.cc hero_quest -I/usr/include/SDL -lSDL_image -lSDL_gfx -lSDL -lSGE -Wall -o dungeondings
	./dungeondings

Das "target" wird gefolgt von einem Doppelpunkt, die Befehle darunter, eingerückt jeweils mit genau einem Tab.
"make" ohne target ruft das oberste target auf, "make machwas" würde das auch tun.

(ordentliches Makefile versteckt sich wohl noch hinter nem anderen Türchen)

[Meillo]

Ohjeh, natuerlich stelle ich meinen Code gerne zur Verfuegung. Allerdings bin ich, wie schon geschrieben, nur Hobbycoder und mein Code sieht fuer andere wohl ziemlich "uebel" aus.
Ich mische in meinen C-Code oft auch C++ "Dinge" und habe, da ich mir das Programmieren selbst beigebracht habe, eine eigene "Ordnung" die moeglicherweise fuer andere sehr unuebersichtlich ist. (Besonders auch waehrend der Erstellung...)

Du bist nicht der einzige, dem es so geht. Da koennen alle -- auch du selbst -- etwas daraus lernen. Auch wenn den Code nicht so gut ist, du bist immerhin derjenige unter uns, der tatsaechlich etwas programmiert und die meisten labern und kritisieren nur rum. Somit gebuehrt dir die Achtung.

Es gibt auch kein makefile (wollte ich mir schon laenger mal anschauen wie man das macht, aber wie es halt so ist...) sondern eine Zeile wie:

Code: Alles auswählen

c++ hero_quest.cc hero_quest -I/usr/include/SDL -lSDL_image -lSDL_gfx -lSDL -lSGE -Wall

um es zu erstellen.

Na, das ist doch eine super Gelegenheit dir von einem Forenuser ein Makefile schreiben zu lassen. Hier ist die Zeile und nun, liebes Forum, es waere super, wenn jemand ein Makefile dazu liefern koennte.

@Meillo

Vielleicht haben noch mehr User Lust etwas zu programmieren. Dann koennte das eine Art DFDE-Programmier-Challenge sein:

Das waere mal wirklich klasse! Aber vlt. jetzt gerade etwas kurzfristig?
Sollten wir sowas nicht etwas besser Planen? So nach dem Motto "Was machen wir eigentlich?", "Wer macht was?" und "Wie sehen die Schnittstellen aus?".

Aber die Idee irgendein DF-Gemeinschaftsprojekt zu machen finde ich richtig Klasse!

...nicht als Wettbewerb sondern mehr als Ausstellung.

Oder nicht als Ausstellung sondern etwas was alle gerne haetten. Ein Programm fuer einen bestimmten Zweck oder ein Spiel oder sonst irgendein "krass nuetzliches Tool"...

Wenn wir ein Gemeinschaftsprojekt anstreben, dann ist es zu kurzfristig, da stimme ich dir zu. Aber wenn jeder fuer sich etwas programmiert, das nur irgendwas mit Labyrinthen zu tun hat, dann kann jeder seinen eigenen Interessen nachgehen, wir muessen uns nicht abstimmen und doch koennen wir uns dazu austauschen. Am Ende kann jeder zeigen was rausgekommen ist, egal wie fertig es geworden ist. Ich denke, so ein Modus waere in der kurzen Zeit machbar.


Btw: Ich habe vorhin angefangen. ... kann schon den Cursor bewegen, ein ASCII-Grafik-Level aus einer Datei einlesen, rumlaufen (nicht mehr durch die Wand) und Gold einsammeln. Derzeit ist es recht Nethack-artig. Mal sehen wie es sich entwickelt. Derzeit sind die Level gemalt aber ich wuerde sie auch gerne noch generieren. Zudem haette ich gerne Fog-of-War, was nicht allzu schwer sein sollte. Dann muss natuerlich auch noch ein Spielmodus dazu kommen ... vermutlich Zeug einsammeln um zum naechsten Level zu kommen.

Vorher habe ich noch nie mit Ncurses programmiert. Ich stelle fest, dass das viel einfacher ist als ich gedacht habe. Bislang hacke ich das Zeug mehr zusammen als wirklich einen Plan von Ncurses zu haben, aber es macht Spass und ich komme voran.

@all

Mein Code ist jetzt soweit, das "anscheinend gueltige" Labyrinthe dabei rauskommen.
Die im Moment eingestellt Groesse ist: 40x30 Felder, 2-8 Raeume (Obwohl man die nicht gut sieht) und 4-10 Tueren.
Die Kacheln/Felder sind (fuer diese Testausgabe) 25x25 Pixel.

Hier sind mal ein paar Screenshoots von 5 nacheinander erstellten Labyrinthen mit:

Code: Alles auswählen

Eingang    : gruener Pfeil
Ausgang    : roter Pfeil
Wand       : Steine
Weg        : grauer Kies
Tuere      : brauner Balken
Schluessel : blauer Schluessel

Die Nummern ueber den Tueren/Schluesseln sind die Zugehoerigkeit. (Schluessel 0 passt in Tuer 0 usw.)

Coole Sache! Das sieht schon richtig nach was aus.

Bei den Gaengen wuerde ich wohl geradere Verlaeufe bevorzugen, auch wenn ich daran denke, dass man sich da durchnavigieren muss. Und vielleicht ohne Diagonalverbindungen, sondern immer eine volle Wandseite an der anderen. Dann wirkt es optisch wohl auf aufgeraeumter als derzeit.

Im konkreten Beispiel den Schluessel 0 fuer die Tuer 0 zu finden braucht einen Spieler mit viel Frustrationstoleranz. Du musst dir den konkreten Weg vom Eingang aus mal anschauen! ... aber das sind natuerlich nur Optimierungfragen, die du nach und nach angehen kannst. Mir gefaellt wie gut du voran kommst. Ich bin schon sehr gespannt wie es weiter geht.

[Meillo]

Hier mal ein Eindruck von meinem derzeitigen Stand.

Aus folgender handgezeichneter ASCII-Karte:

Code: Alles auswählen

################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
###########################                         ############################
#####################         H  F  S  L  C         ############       #########
>            #####     ####                     *   ############               *
##########          #######        $                ########           #########
###########################                         ######## ###################
###########################                         ######## ###################
###########################################   ##############          ##########
############################################# ##########     ######## ##########
############################################# ##########   ########## ##########
#############################################             ####### $   ##########
################################################################################
################################################################################
################################################################################
################################################################################

... wird diese Map:

Code: Alles auswählen

66:16                                   < >  gold:1         map: (BLACK)








                          .------------------------
                    .-----'
-------------.   .--'         H  F  S  L  C
>            '---'     .--.                     *          .---'
---------.          .--'  |                         |      |
         '----------'     |                         |      | .---------
                          |                         |      | '--------.
                          '---------------.   .-----'  .---'          |
                                          '-. |        |     .------. |
                                            | '--------'   .-'  .---' |
                                            |             .'    | $   |
                                            '-------------'     '-----'

Der Spieler ist nur der Cursor, darum sieht man ihn nicht. Ich sollte wohl auch noch ein `@' drunterlegen, wie in Rogue/Nethack.

Fog-of-War funktioniert. Gold einsammeln funktioniert auch. Waende funktionieren. Ausgang funktioniert.


Es gibt aber schon noch viel zu tun; ich habe ja auch erst angefangen. Nichts desto trotz bin ich erstaunt wie viel ich in den paar Stunden geschafft habe. (Momentan sind es nur um die 300 Zeilen Code.)

Naechste Schritte:
- Bugs fixen und Fehlerbehandlungen einbauen
- Grossthema: Karte generieren
- Fog-of-War in der Form eines Laternenmodus, wo es hinter einem wieder dunkel wird. Und vielleicht die Moeglichkeit eines Lichtschalters, der alles hell macht.
- Tragfaehigere Gesamtstruktur des Programms


@heinz: Ich bin richtig gluecklich, dass du mich auf diese Idee gebracht hast. In den letzten Stunden hatte ich eine Menge Freude am Programmieren.

[heinz]

@Meillo

Du bist nicht der einzige, dem es so geht. Da koennen alle -- auch du selbst -- etwas daraus lernen. Auch wenn den Code nicht so gut ist, du bist immerhin derjenige unter uns, der tatsaechlich etwas programmiert und die meisten labern und kritisieren nur rum. Somit gebuehrt dir die Achtung.

Danke fuer Deine Unterstuetzung und die motivierenden Worte!
(Komme mir immer wieder ziemlich "klein" vor, wenn ich sehe was andere hier so drauf haben... )

Vorher habe ich noch nie mit Ncurses programmiert. Ich stelle fest, dass das viel einfacher ist als ich gedacht habe. Bislang hacke ich das Zeug mehr zusammen als wirklich einen Plan von Ncurses zu haben, aber es macht Spass und ich komme voran.

Ncurses lief mir auch schon einige male ueber den Weg, konnte mich aber noch nicht recht aufraffen es mir mal genauer anzuschauen.
Es gibt einfach viel zu viel interessantes "Zeug" was man sich mal anschauen koennte (Was nicht unbedingt schlecht ist... ) aber viel zu wenig Zeit...
Habe erst vor ca. einem Jahr ein Spiel ala "WinTrek" (Wenn Du das noch kennst.) komplett als ASCII-Spiel geschrieben und dabei alle "Grafik" noch mit eigenen Ansi-Sequenz-Routienen geloest.
Dein Kommentar motiviert mich aber doch mal etwas Zeit darin zu investieren da auch einige meiner "Lieblings-Tools" ausgiebig davon gebrauch machen. (Z.B. mc oder dialog))

Coole Sache! Das sieht schon richtig nach was aus.
Bei den Gaengen wuerde ich wohl geradere Verlaeufe bevorzugen, auch wenn ich daran denke, dass man sich da durchnavigieren muss.

Hmm, das finde ich eigentlich nicht unbedingt schlecht. Ein Labyrinth soll doch unuebersichtlich, verwinkelt und verwirrend sein...
Der Spieler muss "gequaelt" und "geknechtet" werden, um am schluss sagen zu koennen "Jaaa! Ich habs geschafft!"

Und vielleicht ohne Diagonalverbindungen, sondern immer eine volle Wandseite an der anderen. Dann wirkt es optisch wohl auf aufgeraeumter als derzeit.

Da hast Du allerdings recht.
Beim zufaelligen Setzen der Wandstuecke suche ich im Moment einen 3x3 Felder groessen Bereich ab um die Gueltigkeit der Position zu bestimmen.
Besser waere hier wohl eine "oben, unten, links, rechts" Methode.
Danke fuer die Anregung!

Im konkreten Beispiel den Schluessel 0 fuer die Tuer 0 zu finden braucht einen Spieler mit viel Frustrationstoleranz.

Naja, wie gesagt ist das nicht gerade der Zweck eines Labyrinthes? So nach dem Motto "Verflixt! Schon wieder eine Sackgasse... WO IST DER VERDAMMTE AUSSGANG????"

Fog-of-War funktioniert. Gold einsammeln funktioniert auch. Waende funktionieren. Ausgang funktioniert.

Wow! Das ging schnell...

Naechste Schritte:
- Fog-of-War in der Form eines Laternenmodus, wo es hinter einem wieder dunkel wird...

Das waere doch aber nur sinnvoll, wenn sich Gegner im Labyrinth komplett frei bewegen wuerden/koennten.
(Was allerdings irgendwie auch nett waere. Hmmm...)

Und vielleicht die Moeglichkeit eines Lichtschalters, der alles hell macht.

Nix Lichtschalter... ZAUBERSPRUCH!

Oh mann, wenn das mit den Ideen hier so weiter geht, wird es wohl Weihnachten 2023 noch nicht fertig sein...

Habe auch am Sonntag abend noch etwas weitergemacht und die Bewegung in einer vergroesserten, scrollenden Ansicht des Labyrinthes und auch eine Art "Fog-of-War" realisiert.
Alles wo man schonmal war ist sichtbar, wird aber nicht wieder abgedunkelt wenn mann wieder weg ist.
Habe auch schon mit den Helden angefangen. Max 4 sollen es sein. Rechte Seite die 4 Portrais, mit Inventar und allem drum und dran. (Invertar geht noch nicht, da ich noch etwas ueberlege, wie ich es realisiere...)
Dachte auch, das man den ersten Helden (also mehr oder weniger sich selbst) selber erstellen kann und auf die anderen 3 dann nach und nach in den Labyrinthen trifft...

@heinz: Ich bin richtig gluecklich, dass du mich auf diese Idee gebracht hast. In den letzten Stunden hatte ich eine Menge Freude am Programmieren.

Das freut mich wirklich sehr... Viele schoene Stunden und Erfolg weiterhin.

Gruss,
heinz

[heinz]

Hallo Zusammen,

ich hoffe Ihr hattet ein paar geruhsame Tage und habt was auch immer Ihr vom Weihnachtsfest erwartet habt bekommen.


Kleines Update vom "Dungeon-Crawler-Projekt", bei Interesse:

Im Moment gibt es viel "Kleinkram" zu tun, der halt gemacht werden muss um weiter Code zu generieren.
Einfache Bildchen malen, damit das Programm was zum anzeigen hat. Listen schreiben, was fuer Eigenschaften die Helden und die Items haben.
Viel Tipparbeit halt, von der man im Moment nicht viel auf dem Bildschirm sieht...

Man kann Rumlaufen, jeder Held hat ein eigenes Inventar, man kann "Zeug" vom Boden aufheben und das Inventar umsortieren...



Was noch fehlt:
Items von Held zu Held austauschen.
Die Helden muessen das gefundene "Zeug" auch ausruesten koennen.
Gegner und Kampf (Das gibt nochmal einen ganz schoenen "Brocken")
Mehr "Zeug" zum finden.
Labyrinthe zusammenhaengend machen. (Stockwerke...)
Allgemeine Labyrinth-Verbesserung. (Keine diagonalen Verbindungen und was ich sonst noch hinbekomme...)
Bildschirm um seinen Helden zu erstellen. (Vlt. auch die anderen 3, die man trifft...)
Und vlt. auch noch ne kleine Geschichte drumrum... (Hier gibts doch bestimmt kreative Koepfe mit guten Ideen dafuer... )


Viele Gruesse,
heinz

[heinz]

Kleines Update:

Was noch fehlt:
Items von Held zu Held austauschen.
Die Helden muessen das gefundene "Zeug" auch ausruesten koennen.
Gegner und Kampf (Das gibt nochmal einen ganz schoenen "Brocken")
Mehr "Zeug" zum finden.
Labyrinthe zusammenhaengend machen. (Stockwerke...)
Allgemeine Labyrinth-Verbesserung. (Keine diagonalen Verbindungen und was ich sonst noch hinbekomme...)
Bildschirm um seinen Helden zu erstellen. (Vlt. auch die anderen 3, die man trifft...)
Und vlt. auch noch ne kleine Geschichte drumrum...

Davon die letzten Tage realisiert:

Items von Held zu Held austauschen geht jetzt erstmal ueber "auf den Boden legen".

Gegner und Kampf laeuft jetzt! Das zu realisieren hat super Spass gemacht
(Es ist noch nicht ganz fertig, weil die Helden ihre Items noch nicht anlegen koennen...)

Oben ist die Initiative-Leiste.
Die Figur in der Mitte ist einer meiner Helden auf dem Weg zu einem Gegner.
Zum Angreifen klickt man die Gegner einfach mit der Maus an.
Waehrend des Angriffs "wackeln" die Figuren hin und her, was echt lustig aussieht.
(Es fehlt halt noch eine gescheite Animation...)


Eine Woche hab ich noch. Ich hoffe ich schaffe es soweit damit es laeuft und alles soweit drin ist.
"Verschoenern" (gescheite Grafiken erstellen) kann man dann immernoch. Da ist man auch nicht so schnell raus wie beim Programmieren, wenn man mal ne Pause macht.

Gruss,
heinz

[Meillo]

@heinz: Wow, du bist ja toll voran gekommen!

Bei mir ist leider gar nichts passiert. Anfangs bin ich so gut gestartet, dann haben mich aber andere Themen beschaeftigt und die Programmiererei ist hinten runter gefallen. Allerdings hatte ich das ja auch nicht so fuer die Zeit geplant wie du. Nichts desto trotz ist meine Lust auf mein Spiel nicht geschrumpft. Sobald es wieder Raum dafuer gibt, werde ich es wieder anpacken. Darauf freue ich mich schon.


Du hast geschrieben, dass du in der verbleibenden Woche hauptsaechlich an der Spielmechanik arbeiten willst, also dass es auch funktioniert. Um was genau geht es da? Fehlen noch Features oder geht es mehr um die Verzahnung der vorhandenen Features?

Hast du an der Labyrinthgenerierung noch etwas geaendert? Falls ja, wie sehen die neuen Labyrinthe nun aus?

Wenn ich das anhand deines Screenshots richtig sehe, dann teilt sich das Spiel in zwei Modi: (1) Navigation durch's Labyrinth aus der Vogelperspektive. (2) Wenn man auf Gegner trifft einen Kampfmodus aus der Seitenperspektive. So kenne ich das aus anderen Spielen auch. Habe ich das richtig erfasst?

Ich bin schon sehr gespannt wie es weiter geht. Halte uns auf dem Laufenden!