Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

21

30.08.2016, 14:44

Wenn du Ideen und Ansätze brauchst, das was du da vor hast ist im Prinzip das selbe wie die Dungeongenerierung in Roguelikes. Da kannst du mal nach suchen. Da kannst du dir sicherlich die ein oder andere Idee abgucken.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

AintLarry

Frischling

  • »AintLarry« ist der Autor dieses Themas

Beiträge: 58

Wohnort: Hamburg

Beruf: Kaufmann für Versicherungen und Finanzen

  • Private Nachricht senden

22

30.08.2016, 14:47

Danke für den Tipp. Inspirieren lassen schadet ja nie.
Eventuell finde ich so auch noch die ein oder andere Verbesserung für meinen bestehenden Code.

AintLarry

Frischling

  • »AintLarry« ist der Autor dieses Themas

Beiträge: 58

Wohnort: Hamburg

Beruf: Kaufmann für Versicherungen und Finanzen

  • Private Nachricht senden

23

31.08.2016, 10:30

Hallo Leute,

da es heute tatsächlich mal nichts neues zu berichten gibt. Möchte ich nun dem Wunsch von GoldWingStudios nachkommen, und euch meine Methode zur "Kollisions"-Erkennung von Räumen vorstellen. Sicherlich mag es andere und auch bessere Varianten geben, dazu komme ich am Schluss noch einmal.





Mit Sicherheit hätte es auch schnellere, einfachere oder übersichtlichere Lösungen gegeben. Allerdings passt die von mir gewählte Variante in mein Spielkonzept und beeinträchtigt die Ladezeiten nicht, bzw. nicht merk- und messbar.

Denkbar wäre z.B. gewesen, ein Array der freien Felder zu erstellen, und nach erstellen eines Raumes die entsprechenden Felder hinauszulöschen.
wahrscheinlich würde die Kollisionsabfrage dann weniger Kollisionen finden, und somit nur seltener aufgerufen werden müssen. Allerdings benötigt dann das Array-Handling eine ähnliche Rechenleistung. Zudem haben erste Versuche gezeigt, dass die Räume dann weniger Zwischenräume besitzen, dies ist im späteren Verlauf eventuell einfacher für die Generierung der Gänge, aber in meinem Projekt nicht wünschenswert.

Ich hoffe ich konnte euch mein Projekt nun noch ein Stückchen näher bringen.

Henrik

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

24

31.08.2016, 10:52

Ich habe einige Anmerkungen zu dem gezeigten Code (abgesehen davon, dass ich nicht sicher bin, ob die Kollisionsprüfung generell korrekt ist oder ob es nicht Fälle gibt, in denen sie versagt):

1.) Ich würde dir empfehlen, etwas anderes als std::vector<int> zu benutzen, um ein Rechteck zu beschreiben. Erstens ist ein std::vector für dynamische Größen ausgelegt, also für Listen, wo du vorher nicht weißt, wie viele Elemente drin sein werden. Für die Liste der Räume ist das OK, aber nicht für einen Raum selbst. Wenn schon, dann sollte man std::array<int, 4> verwenden. Das wäre aber trotzdem nicht schön, weil der Code dadurch immer noch nicht "sprechend" ist. Man muss erst einmal wissen, dass [0] für x1 steht. Mach dir doch einfach eine Struktur mit 4 Membern x1, y1, x2, y2. Dann sieht dein Code auch direkt viel schöner aus.

2.) Du machst hier einen typischen, folgenschweren Anfängerfehler: Du übergibst die Vektoren nicht per (konstanter) Referenz an die Funktion, sondern "by value". Das heißt, dass bei jedem Funktionsaufruf eine komplette Kopie aller Räume erstellt und anschließend wieder gelöscht wird. Das ist natürlich unnötig viel Aufwand und erklärt auch, warum du Performance-Probleme hast. Schließlich wird die Funktion sehr oft aufgerufen. Du solltest dich also unbedingt mit Referenzen auseinandersetzen und auch mit dem const-Schlüsselwort.

3.) Die Art, wie du mit der for-Schleife durch den Vektor gehst, ist nicht schön. Dafür benutzt man entweder Iteratoren oder die "neuen" range-based for loops (Achtung auch hier: Konstante Referenzen benutzen!).

4.) Dein leeres else ist unnötig.

5.) Die 4 if-Bedingungen führen alle zu return true;, also kannst du sie durch das logische Oder || kombinieren.

6.) Die Abfrage, ob rooms.size() <= 0 ist seltsam, denn die Größe eines Vektors kann niemals negativ sein. Stattdessen solltest du einfach die empty-Methode nutzen.

Ja, viel Gemeckere, aber lass dich davon nicht entmutigen, sondern nimm es zum Anlass, mehr zu lernen und dich zu verbessern ;)

AintLarry

Frischling

  • »AintLarry« ist der Autor dieses Themas

Beiträge: 58

Wohnort: Hamburg

Beruf: Kaufmann für Versicherungen und Finanzen

  • Private Nachricht senden

25

31.08.2016, 11:33

Hallo David,

vielen Dank für dein Feedback.

Ich nehme das nicht als "gemeckere" auf, eher als nett gemeinte Verbesserungsvorschläge.

Ich werde mal schauen, welche von deinen Anmerkungen ich weiter umsetzen werde.

Auf jeden Fall will ich hier noch mit Referenzen arbeiten, das war sowieso geplant. Da ich in diesem Thema aber noch nicht sehr fit bin, habe ich es ersteinmal so geschrieben.

Die Verwendung des std::vectors liegt eigentlich noch darin zurück, dass die Funktion zuerst ein wenig anders aufgebaut war und mehrere Räume gleichzeitig überprüfen sollte. So wie er jetzt ist, mach ein struct natürlich viel mehr Sinn, da geb ich dir Recht.

Zu deinem dritten Punkt kann ich eigentlich nur sagen, dass ich es nicht besser wusste und es so funktionell genug für mich war. Ich werde mich aber in die von dir genannten Vorgehensweisen einmal einlesen. Das Durchlaufen eines Arrays mit einer For-Schleife kommt noch an einigen anderen Stellen in meinem Code vor.

Dass das leere else unnötig ist ist korrekt. Dies habe ich Zeitweise für eine Konsolenausgabe zu Testzwecken genutzt, nun könnte es natürlich weg.

Das Verbinden der If-Abfragen ist natürlich möglich und eigentlich auch logisch, allerdings finde ich persönlich den Code so lesbarer. Das ist aber eine Geschmackssache. Da ich allerdings keinen Nachteil sehe, werde ich das so lassen.

Die Überprüfung ob der Inhalt des Arrays <= 0 oder =0 ist führt zum selben Ergebnis. Die empty-Mothode kannte ich so nicht, macht hier aber natürlich auch zwecks Lesbarkeit viel mehr Sinn.

Danke noch einmal für deine Anregungen.

Henrik

Goldwing Studios

Treue Seele

Beiträge: 359

Wohnort: Heidelberg

Beruf: Softwareentwickler, Vertriebler

  • Private Nachricht senden

AintLarry

Frischling

  • »AintLarry« ist der Autor dieses Themas

Beiträge: 58

Wohnort: Hamburg

Beruf: Kaufmann für Versicherungen und Finanzen

  • Private Nachricht senden

27

31.08.2016, 13:00

Natürlich auch an dich ein großes Dankeschön. ;)

Feedback ist, solange es konstruktiv ist, immer die beste Möglichkeit sich selbst zu verbessern und zu lernen.

AintLarry

Frischling

  • »AintLarry« ist der Autor dieses Themas

Beiträge: 58

Wohnort: Hamburg

Beruf: Kaufmann für Versicherungen und Finanzen

  • Private Nachricht senden

28

05.09.2016, 10:18

Hallo Leute,

aus gegebenem Anlass erscheint heute, auch ohne erwähnenswerten Fortschritt, ein kleines Update.

Leider habe ich die nächsten Tage, eventuell auch Wochen, weniger Zeit als momentan. Dies liegt an zwei Ehrenämtern, welche (natürlich nach meinem Job) höchste Priorität für mich haben.

Nichts desto trotz werde ich an dem Projekt natürlich kontinuierlich weiterarbeiten. Weiterhin fast täglich, nur nicht so umfangreich.

Aktuell bin ich dabei, eine Methode zur Überprüfung der Verbindungen der Räume zu schreiben. Dabei nutze ich, wie von mehreren Forenmitgliedern vorgeschlagen, eine Flood-Fil-Methode. Diese habe ich der Gang-Generierung erst einmal vorgeschoben, da diese für die Generierung benötigt wird.

So weit erst einmal von mir, ich halte euch auf dem Laufenden.

Henrik

AintLarry

Frischling

  • »AintLarry« ist der Autor dieses Themas

Beiträge: 58

Wohnort: Hamburg

Beruf: Kaufmann für Versicherungen und Finanzen

  • Private Nachricht senden

29

09.09.2016, 08:57

Update 09.09.2016

Aufgrund dem aktuellen Zeitmangel für dieses Projekt, habe ich die Flood-Fill-Methode erst einmal bei Seite gelegt. Hierfür benötige ich Konzentration, Ruhe und Zeit.

Stattdessen habe ich am gestrigen Abend eine Klasse geschrieben, welche als Bild abgelegte Layer (als Schema, wie mein Test-Output) einlesen und als Map verwenden kann.

Dies ermöglicht mir später z.B. ein Tutorial-Level welches vordefiniert ist, zu verwenden. Außerdem wäre es theoretisch Möglich, in einem Level zu speichern, obwohl dies aktuell nicht vorgesehen ist.

Henrik

AintLarry

Frischling

  • »AintLarry« ist der Autor dieses Themas

Beiträge: 58

Wohnort: Hamburg

Beruf: Kaufmann für Versicherungen und Finanzen

  • Private Nachricht senden

30

12.09.2016, 09:26

Ich freue mich, euch mitteilen zu können, dass ich am Samstag mal wieder etwas mehr Zeit gefunden habe, mich diesem Projekt zu widmen.

Die FloodFill-Methode zur Überprüfung der Erreichbarkeit aller Räume ist nun fertig und funktioniert nach zahlreichen Tests einwandfrei.

Da die Generierung der Gänge noch nicht existiert, habe ich die Überprüfung mit von mir erstellten Maps vorgenommen, welche ich mit meiner neuen MapReader-Klasse eingelesen habe. Auch diese funktioniert aktuell einwandfrei.

Nächstes Primär-Ziel ist nun die Erstellung der Methode(n) zur Generierung der Verbindungsgänge. Da ich aber auch hier viel Zeit und Ruhe für brauchen werde, werde ich als Sekundär-Ziel nebenbei an den ersten "Pixel"-Texturen für die Maps arbeiten.

Ich freue mich schon jetzt darauf, euch nach diesen beiden Zwischenzielen die ersten, hoffentlich schick anzusehenden, Karten präsentieren zu können.

Henrik

Werbeanzeige