Blood Red Ascent

Antworten
Endgegner
Beiträge: 48
Registriert: 19.12.2020, 18:43

Blood Red Ascent

Beitrag von Endgegner »

Teaser:

Tief unter einem einsamen Bergkloster haben Mönche finstere Kreaturen eingesperrt – Wesen, die existieren, aber nicht existieren dürften. Unter ihnen befindet sich auch der Spieler: ein uralter Vampir. Wird er es schaffen, sich aus seiner kalten Zelle zu befreien, sich an übernatürlichen Monstern und heiligen Kriegern vorbeizukämpfen und so den Weg in die Freiheit zurückzufinden?

Themenvorgaben
  • Schlagwörter: Vampir, Vier Elemente
  • Grafikstil: Top-down, wie die Karte eines Tabletop-Spiels
  • Spielmechaniken: NPC, Fog of War
  • Entwicklungszeit: drei Wochen
Ideen & Umsetzung

Geplant ist ein einfacher 2D Dungeon-Crawler (damit bin ich ja nicht allein, wie ich schon gesehen habe) bzw. ein Rogue-lite mit ein paar RPG-Elementen.

Der Spieler wird voraussichtlich über keine Attribute wie Stärke oder Geschick verfügen. Stattdessen ergeben sich all seine Fähigkeiten aus den Gegenständen, die er ausgerüstet hat (maximal vier davon). Die Eigenschaften der Gegenstände basieren auf den (nicht klassischen) vier Elementen Feuer, Eis, Blut und Stahl. Daraus ergeben sich auch verschiedene Vor- und Nachteile für den Spieler, z.B. erhöht Blut die Lebenskraft, zieht aber auch mehr blutrünstige Monster aus der Umgebung an.

Das Winter-Thema möchte ich mit dem Setting erfüllen, d.h. eisige Höhlen und Verließe und ein verschneites Kloster auf der Bergspitze. Natürlich wird es im tiefsten Dungeon auch viel Fog of War geben, in dem allerlei Gefahren lauern.

Soweit die Idee …

Gerne würde ich noch Dialoge mit anderen eingesperrten Kreaturen einbauen, aber ich weiß nicht recht, ob die Zeit dafür ausreicht (wahrscheinlich nicht). Vielleicht baue ich das noch im Nachgang ein. :)
Benutzeravatar
Schrompf
Moderator
Beiträge: 5220
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Blood Red Ascent

Beitrag von Schrompf »

Der Pitch ist jedenfalls schonmal der Hammer! Bin sehr gespannt.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
joeydee
Establishment
Beiträge: 1192
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Blood Red Ascent

Beitrag von joeydee »

Bin gespannt auf die Umsetzung :)
Benutzeravatar
woodsmoke
Establishment
Beiträge: 158
Registriert: 30.06.2023, 14:05
Wohnort: Ludwigshafen
Kontaktdaten:

Re: Blood Red Ascent

Beitrag von woodsmoke »

Nice, hatte auch überlegt andere 4 Elemente zu wählen, anstatt die klassischen 4. Auch sonst hört sich gut an.
scheichs
Establishment
Beiträge: 948
Registriert: 28.07.2010, 20:18

Re: Blood Red Ascent

Beitrag von scheichs »

Die Beschreibung macht auf jeden Fall schonmal was her!
Endgegner
Beiträge: 48
Registriert: 19.12.2020, 18:43

Re: Blood Red Ascent

Beitrag von Endgegner »

Wie schon anderswo angekündigt, setze ich dieses Projekt fort, weil mich die Idee dahinter inspiriert hat und ich meine kleine „Vision“ des Spiels noch umsetzen möchte. Von daher gibt es jetzt hier ein Update.

Im Einleitungspost habe ich geschrieben, dass die Dungeons optisch wie die Karte eines Tabletop-Spiels wirken sollen. Da womöglich nicht ganz klar ist, wie ich das meine, füge ich hier zwei Beispiele ein.

Im einfachsten Fall strebe ich den folgenden Look an:
https://dicegrimorium.com/small-random- ... attle-map/

Das sähe schon ganz gut aus, aber auch etwas langweilig, so ganz ohne Einrichtung und Beleuchtung. Deswegen möchte ich im nächsten Schritt die Optik etwas aufwerten, so wie hier:
https://dicegrimorium.com/ancient-crypt ... attle-map/

Mir stellte sich natürlich schnell die Frage: Wie und wo möchte ich solche Dungeons erstellen? Händisch? Prozedural? Mit einem externen Editor (z.B. Tiled oder LDtk) oder Ingame? Ich entschied mich letztendlich für einen Ingame-Editor, weil ich handgebaute Level schätze, der WYSIWYG-Aspekt auf diese Weise am besten erfüllt ist und ich auch eine Chance sah, endlich mal mein GUI voranzubringen. Ein funktionierender Ingame-Editor ist schließlich eine ganz gute Bewährungsprobe für ein GUI.

Hier seht ihr einen Screenshot des aktuellen Stands. Die Texturen sind alle nicht final und das gezeigte Level ist auch eher planlos zusammengeklickt. Aber man sieht ungefähr, wo die Reise hingehen soll.
Bildschirmfoto 2025-02-23 um 19.26.58.jpg
Der Editor arbeitet ebenenbasiert, wie man das beispielsweise aus Photoshop und anderen Grafikprogrammen kennt. Jede Ebene kann eine Tilemap, eine Fluidmap (Wasser, später auch Lava) und Entities enthalten. Auf dem Screenshot ist ein kleines Wasserbecken erkennbar, das ich mit so einer Fluidmap hinzugefügt habe.

Das Einfügen und Bearbeiten von Entities ist der nächste Meilenstein auf meiner Liste.
Benutzeravatar
Schrompf
Moderator
Beiträge: 5220
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: Blood Red Ascent

Beitrag von Schrompf »

Hübsch :-) Freut mich, dass Du weiter machst!
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2737
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Blood Red Ascent

Beitrag von Jonathan »

Endgegner hat geschrieben: 23.02.2025, 20:55 Wie schon anderswo angekündigt, setze ich dieses Projekt fort, weil mich die Idee dahinter inspiriert hat und ich meine kleine „Vision“ des Spiels noch umsetzen möchte.
Nice, sehr cool. Ich freu mich schon aufs Ergebnis.
Das sähe schon ganz gut aus, aber auch etwas langweilig, so ganz ohne Einrichtung und Beleuchtung. Deswegen möchte ich im nächsten Schritt die Optik etwas aufwerten, so wie hier:
Hmm, ich meine, das zweite Screenshot ist "aufwändiger" aber ich bin mir nicht sicher, ob es deswegen auch besser aussieht. Dynamische Beleuchtung passt irgendwie nicht so Brettspiel-Kacheln, es sieht für mich dann eher inkonsistent und damit nicht besser aus.

Klar ist der erste Screenshot langweilig, aber wenn es halt ein paar bunte Gegner und Gegenstände und mal Wasser oder Lava oder Goldmünzen etc. gibt, dann wird das schon ganz anders wirken. Ist natürlich vorab schwer zu sagen, aber ich würde ggf. erstmal die anderen Sachen fertig machen und dann später nochmal schauen, ob es wirklich Beleuchtung braucht. Oder versuchen, mit recht wenig Aufwand mal ein paar Art-Style Studien zu machen und zu schauen, was wirklich gefällt.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Endgegner
Beiträge: 48
Registriert: 19.12.2020, 18:43

Re: Blood Red Ascent

Beitrag von Endgegner »

Jonathan hat geschrieben: 24.02.2025, 09:34 Hmm, ich meine, das zweite Screenshot ist "aufwändiger" aber ich bin mir nicht sicher, ob es deswegen auch besser aussieht. Dynamische Beleuchtung passt irgendwie nicht so Brettspiel-Kacheln, es sieht für mich dann eher inkonsistent und damit nicht besser aus.

Klar ist der erste Screenshot langweilig, aber wenn es halt ein paar bunte Gegner und Gegenstände und mal Wasser oder Lava oder Goldmünzen etc. gibt, dann wird das schon ganz anders wirken. Ist natürlich vorab schwer zu sagen, aber ich würde ggf. erstmal die anderen Sachen fertig machen und dann später nochmal schauen, ob es wirklich Beleuchtung braucht. Oder versuchen, mit recht wenig Aufwand mal ein paar Art-Style Studien zu machen und zu schauen, was wirklich gefällt.
Aus technischer Sicht funktioniert die Beleuchtung schon. Da die Lichtquellen aber Entity-Komponenten sind, kann ich damit erst großflächig herumexperimentieren, wenn die Entities im Editor integriert sind.

Bei meinen ersten Tests sahen die Lichter eigentlich ganz stimmungsvoll aus. Es handelt sich aber auch nur um ein einfaches, kachelbasiertes Beleuchtungssystem, ohne harte Schlagschatten. Im Grunde genommen eine sehr grobe Lightmap mit einer Auflösung von 1 px pro Kachel, mit weichen Übergängen.

Eine Entscheidung, die auf jeden Fall noch über das Ob und die Art der Beleuchtung entscheiden wird, ist der Stil der Wände:
Wall-Styles.jpg
(Beide Beispiele stammen wieder von Dice Grimorium.)
Top-down oder leicht angeschrägt im "Zelda-Style". Letzteres ist perspektivisch natürlich nicht korrekt, sieht aber gar nicht schlecht aus (meiner Ansicht nach), wenn man es damit nicht übertreibt. Ich werde beides einfach mal ausprobieren und sehen, wie sich das macht. :)
Endgegner
Beiträge: 48
Registriert: 19.12.2020, 18:43

Re: Blood Red Ascent

Beitrag von Endgegner »

Zeit für ein kleines Update!

Wie zuvor anvisiert, habe ich den Editor so erweitert, dass man darin Entities hinzufügen und bearbeiten kann. Mein Spiel basiert auf einem Entity-Component-System und für jede bearbeitbare Komponente habe ich ein GUI-Template erstellt, das die dafür benötigten Widgets bereitstellt. Ich musste hierfür noch ein paar grundlegende, aber bisher fehlende Widgets ergänzen, wie z.B. Texteingabefelder.

Ziemlich zufrieden bin ich mit den Modals, für die ich mittlerweile einige Anwendungsfälle gefunden habe. Auf dem folgenden Screenshot ist eines davon abgebildet.
bra-select-image-popup.jpg
Zufrieden bin ich deswegen, weil es kein eigenes Widget und keine spezielle Logik für Modals gibt, sondern alles über Styling und Layouts geregelt wird.

Modals dienen mir auch als Grundlage für Dropdown-Felder, die ich ursprünglich gar nicht umsetzen wollte: Da klappen Optionen in einem separaten Layer auf, der ggf. separat gescrollt werden kann... Uff. Dann kam mir die Idee, die Optionen einfach als Radiobuttons in einem Modal anzuzeigen:
bra-dropdown-modal.png
Bietet vielleicht nicht die beste UX, war aber viel angenehmer umzusetzen, weil ich auf bereits Vorhandenes zurückgreifen konnte. ;)

Es gab auch noch einige weitere Änderungen, die ich an dieser Stelle aber mal ausklammern möchte. Beispielsweise musste ich noch das ECS überarbeiten, weil es auf rundenbasiertes Gameplay ausgelegt war und nicht auf Echtzeit-Bearbeitung in einem Editor.

Wie auch immer – mit all diesen Änderungen kann man jedenfalls schon ganz passable Level bauen:
bra-level-snapshow-wip.jpg
Aktuell ist das noch eine wilde Mischung aus kostenlosen und selbst erstellten Assets, die stellenweise nicht so gut zueinander passen. Und bei der Treppentextur habe ich eine Stufe vergessen. Aber das werde ich noch alles angehen.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2737
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Blood Red Ascent

Beitrag von Jonathan »

Interessant, das sieht schon sehr cool aus! :)

Ich hab das auch immer gemocht, einen Editor zu schreiben mit dem man dann seine eigenen Levels für seine eigenen Welten für sein eigenes Spiel erstellen kann. Hat immer ein irgendwie erhabenes Gefühl.

Allerdings hab ich das auch schon lange nicht mehr gemacht. ECS hab ich auch, aber ich lade alle Eigenschaften nur noch aus JSON-Dateien, anstatt da einen Editor mit Kontrollelementen für zu schreiben. Einfach, weil man Textdateien halbwegs gut mit seinem Lieblings-Texteditor bearbeiten kann und weil GUI einfach immer so viel Zeit beansprucht. Und selbst wenn man seine Schieberegler und Knöpfe hat, sind Dinge wie Textsuche und mehrere Zeilen kopieren und einfügen, oder Kommentare, oder Multi-Line-Edit tatsächlich auch super nützlich und die hat man in der GUI halt nicht - außer man gibt sich wirklich ausgesprochen viel Mühe.

Letztendlich war aber vielleicht das Totschlagargument, dass der alte Editor in Qt geschrieben war - was ein wirklich furchtbares Framework ist, unfassbar fettleibig, nervig zu installieren, doof zu kompilieren, langsam in der Entwicklung und nichtmal starten kann man den Dreck am Ende, weil immer irgendwelche DLLs kaputt sind. Nein danke, nie wieder :D
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
scheichs
Establishment
Beiträge: 948
Registriert: 28.07.2010, 20:18

Re: Blood Red Ascent

Beitrag von scheichs »

Sieht auf jeden Fall schon stimmungsvoll aus.
Endgegner
Beiträge: 48
Registriert: 19.12.2020, 18:43

Re: Blood Red Ascent

Beitrag von Endgegner »

Danke euch!
Jonathan hat geschrieben: 11.08.2025, 18:11 Allerdings hab ich das auch schon lange nicht mehr gemacht. ECS hab ich auch, aber ich lade alle Eigenschaften nur noch aus JSON-Dateien, anstatt da einen Editor mit Kontrollelementen für zu schreiben. Einfach, weil man Textdateien halbwegs gut mit seinem Lieblings-Texteditor bearbeiten kann und weil GUI einfach immer so viel Zeit beansprucht. Und selbst wenn man seine Schieberegler und Knöpfe hat, sind Dinge wie Textsuche und mehrere Zeilen kopieren und einfügen, oder Kommentare, oder Multi-Line-Edit tatsächlich auch super nützlich und die hat man in der GUI halt nicht - außer man gibt sich wirklich ausgesprochen viel Mühe.
Bei mir werden Entity-Prefabs – also Entities mit einem vorgefertigten Satz aus Komponenten – aus einer Lua-Datei ausgelesen und im Editor über einen Prefab-Browser zur Auswahl angeboten. Nach dem Einfügen eines Prefabs in den Editor können die einzelnen Komponenten über den Editor bearbeitet werden. Den gewissen Komfort von Textdateien gibt es in dieser Hinsicht also noch immer.

Eine Prefab-Datei sieht beispielsweise so aus:

Code: Alles auswählen

Prefab("pushableObject") {
  title = "Pushable object",
  GridComponent = {
    pushable = true,
    blocking = true,
  },
  SpriteComponent = {
    imageKey = "assets/atlases/sprites.atlas:crate-banded",
  }
}

Prefab("switch") {
  title = "Switch",
  GridComponent = {
    blocking = true,
  },
  SwitchComponent = {
    variableName = "changeMe",
  },
  SpriteComponent = {
    imageKey = "assets/atlases/sprites.atlas:blue-counter",
  }
}
Was jedoch nicht geht: "Neue" Entities aus beliebigen Komponenten über den Editor zusammenklicken. Das hätte den Aufwand vergrößert und der Nutzen erschien mir eher gering, weil man alle gängigen Fälle über die Prefabs abbilden kann.

Aber es stimmt schon: GUI erfordert viel Zeit und starke Nerven. Wenn ich allein an das Texteingabe-Widget denke. Das hat sich als besonders undankbares Element herausgestellt. Man steckt viel Arbeit hinein und heraus kommt: Ein Texteingabefeld... Der Cursor blinkt, wow! Das reißt wirklich keinen vom Hocker. :D
Jonathan hat geschrieben: 11.08.2025, 18:11 Letztendlich war aber vielleicht das Totschlagargument, dass der alte Editor in Qt geschrieben war - was ein wirklich furchtbares Framework ist, unfassbar fettleibig, nervig zu installieren, doof zu kompilieren, langsam in der Entwicklung und nichtmal starten kann man den Dreck am Ende, weil immer irgendwelche DLLs kaputt sind. Nein danke, nie wieder :D
Mit Qt musste ich bisher keine nähere Bekanntschaft machen. Aber den QtCreator fand ich früher mal ganz charmant, ganz unabhängig von Qt an sich.

Ich habe jedenfalls versucht, ein kleines aber insgesamt feines GUI zu erstellen, das flexibel und angenehm anzuwenden ist. Habe ich das erreicht? Ich bin zufrieden mit dem Ergebnis. Nicht auszuschließen ist aber, dass alle anderen Menschen mein GUI total schrecklich finden würden, müssten sie es einsetzen. ;)

Aber so schlimm ist es nicht. Das ganze Styling des GUIs kann über eine Art "CSS für Arme" festgelegt werden:

Code: Alles auswählen

Style("root") {
  fontFamily = "assets/fonts/noto-sans.luaconf",
  fontSize = 16,
  fontVariant = "regular",
  textColor = white,
}

Style("h1") {
  fontSize = 24,
  fontVariant = "bold",
  padding = {bottom = 20},
}

Style("tonedButton") {
  fillColor = surface10,
  fontVariant = "bold",
  cornerRadius = 6,
  padding = {5, 10},
  textColor = white,
  [WidgetState.HOVERED] = {
    fillColor = surface20,
  },
  [WidgetState.FOCUSED] = {
    fillColor = surface20,
  },
  [WidgetState.PRESSED] = {
    fillColor = surface10,
  },
  [WidgetState.SELECTED] = {
    fillColor = primary40,
    textColor = black,
  },
  [WidgetState.SELECTED + WidgetState.HOVERED] = {
    fillColor = primary50,
    textColor = black,
  },
}
Und die hierarchische Struktur des GUIs wird in (mehr oder weniger) deklarativen Template-Dateien definiert:

Code: Alles auswählen

return ColumnLayout {
  id = "collisionTool",
  Label {
    text = "Collision Map",
    styleName = "h1",
  },
  GridLayout {
    columns = 2,
    gap = 10,
    RadioButton {
      group = "currentFieldType",
      styleName = "tonedButton",
      value = "none",
      Label {
        text = "None"
      }
    },
    RadioButton {
      group = "currentFieldType",
      styleName = "tonedButton",
      value = enums.FieldType.FLOOR,
      Label {
        text = "Floor"
      }
    },
    RadioButton {
      group = "currentFieldType",
      styleName = "tonedButton",
      value = enums.FieldType.BARRIER,
      Label {
        text = "Barrier"
      }
    },
    RadioButton {
      group = "currentFieldType",
      styleName = "tonedButton",
      value = enums.FieldType.WALL,
      Label {
        text = "Wall"
      }
    }
  }
}
Die oben gezeigten Styles ergeben zusammen mit dem Template die folgende Darstellung:
collision-map-gui-example.png
collision-map-gui-example.png (9.09 KiB) 134 mal betrachtet
Ein gewisser Einfluss von HTML und CSS ist hier nicht von der Hand zu weisen.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2737
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Blood Red Ascent

Beitrag von Jonathan »

Oh, ich hatte erst naiv gedacht, die GUI wäre ein ImGUI Reskin. Respekt, das sieht echt nice aus!

Ich hab für den Landvogt die GUI auch aus versehen selber gemacht. Erst war sie super minimalistisch, es gab bloß Buttons aus Bildern, dann kam eine Kleinigkeit nach der anderen hinzu und dann war ich an dem Punkt wo ich nicht mehr alles wegschmeißen und durch ein anderes Framework ersetzen wollte. Es ist immer noch alles recht simpel, es gibt nichtmal das Konzept des Widget-Fokus, d.h. Tastatursteuerung ist unmöglich, von Texteingabe ganz zu schweigen (nagut, es gibt einen Hack für wenn man genau ein Eingabefeld hat, etwa um sich in die Highscore einzutragen).

Vielleicht bin ich irgendwann motiviert das alles mal richtig zu machen, mal schauen.


Dein System mit den Lua-Dateien klingt auch schnieke. Ich wollte auch gar nicht sagen, dass Textdateien besser sind, sondern eher, dass sie überraschend wenig schlecht sind. Wenn man die Zeit investiert, ist ein ordentlicher Editor etwas sehr feines, aber ich investiere sie halt eben lieber in anderes.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Endgegner
Beiträge: 48
Registriert: 19.12.2020, 18:43

Re: Blood Red Ascent

Beitrag von Endgegner »

Heute mal ein kleiner Ausflug in das Thema der Validierung.

An mehreren Stellen des Editors möchte ich überprüfen, ob die Eingaben des Benutzers valide sind. Beispiel: Beim Erstellen eines neuen Levels öffnet sich ein Modal mit einem Texteingabefeld, in das der Name des Levels eingetragen werden muss. Wenn man auf den OK-Button klickt, möchte ich sicherstellen, dass das Eingabefeld nicht leer ist und noch kein Level mit dem angegebenen Namen existiert. Außerdem sollen entsprechende Fehlermeldungen angezeigt werden, damit man als Benutzer versteht, was überhaupt los ist.

Allerdings ist Validierung ein großes Thema, für das es eigene, spezialisierte Libraries gibt. Ein so großes Fass wollte ich jedoch gar nicht aufmachen. Deswegen habe ich überlegt, wie ich das Problem möglichst unkompliziert lösen könnte:
  • Die Validierung soll auf den Inhalt von Validation-Containern beschränkt sein, vergleichbar mit dem <form>-Element von HTML.
  • Widgets können ein onValidate-Callback festlegen, das im Falle einer fehlgeschlagenen Validierung die Fehlermeldung als String zurückgibt.
  • Der Validation-Container validiert rekursiv seine Kinder und sammelt die Fehlermeldungen.
  • Die Fehlermeldungen können mithilfe von Label-Widgets und reaktiven Data-Bindings angezeigt werden – diese gibt es bereits im GUI.
1. Der Validation-Container

Als Validation-Container kann jedes beliebige Widget dienen, das andere Widgets enthalten kann, im folgenden Fall ein Column-Layout:

Code: Alles auswählen

ColumnLayout {
  data = { errors = {} },
}
Mit data werden reaktive Properties definiert. Widgets können Bindings zu diesen Properties herstellen und dadurch auf Werteänderungen reagieren. Die errors-Property soll hier dazu dienen, die gesammelten Fehlermeldungen aus der Validierung zu speichern.

2. onValidate-Callbacks

Die Validierung für das Eingabefeld des Levelnamens:

Code: Alles auswählen

TextInput {
  id = "levelNameInput",
  onValidate = function (widget)
    local levelName = stringx.trim(widget:getValue())
    if levelName == "" then
      return "Level name is required"
    end
    if levelutils.doesLevelExist(levelName) then
      return "Level already exists"
    end
  end
}
3. Fehlermeldungen

Im Validation-Container habe ich die errors-Property zum Sammeln der Fehlermeldungen definiert. Nun kommen die bereits erwähnten Bindings zum Einsatz: Das Label, das für die Anzeige der Eingabefeld-Fehlermeldungen herangezogen wird, soll den Fehlertext aus errors übernehmen und natürlich nur dann sichtbar sein, wenn es eine Fehlermeldung zum Anzeigen gibt.

Code: Alles auswählen

Label {
  styleName = "error-text",
  bindings = {
    visible = {
      source = "errors",
      transform = function (_, errors)
        return errors["levelNameInput"] ~= nil
      end,
    },
    text = {
      source = "errors",
      transform = function (_, errors)
        return errors["levelNameInput"] or ""
      end,
    },
  }
}
4. Letzter Schritt

Jetzt braucht es nur noch einen Button, der die Validierung auslöst:

Code: Alles auswählen

PushButton {
  onClick = function (widget)
    if widget:checkValidity() then
      -- Validierung erfolgreich; Level erstellen :)
    end
  end,
  Label {
    text = "Create",
  },
}
gui-new-level-validation.png
Fertig! :)
Jonathan hat geschrieben: 13.08.2025, 06:06 Ich hab für den Landvogt die GUI auch aus versehen selber gemacht. Erst war sie super minimalistisch, es gab bloß Buttons aus Bildern, dann kam eine Kleinigkeit nach der anderen hinzu und dann war ich an dem Punkt wo ich nicht mehr alles wegschmeißen und durch ein anderes Framework ersetzen wollte. Es ist immer noch alles recht simpel, es gibt nichtmal das Konzept des Widget-Fokus, d.h. Tastatursteuerung ist unmöglich, von Texteingabe ganz zu schweigen (nagut, es gibt einen Hack für wenn man genau ein Eingabefeld hat, etwa um sich in die Highscore einzutragen).
Das GUI aus Versehen selber gemacht – das ist gut. :D
Manchmal werden die einfachen Zwischenlösungen zu etablierten Dauerlösungen.

Ein vollständiges Fokusmanagement habe ich übrigens auch noch nicht. Ich habe das bisher nur soweit umgesetzt, wie es für die Eingabefelder erforderlich war, d.h. beim Anklicken eines fokussierbaren Widgets erhält dieses den Tastaturfokus. Wenn man außerhalb des Widgets klickt oder das Widget nicht mehr fokussierbar ist (z.B. weil es entfernt oder ausgeblendet wurde), wird der Fokus wieder entfernt. Es ist noch nicht möglich, per Tastatur zum vorherigen oder nächsten Widget zu navigieren.

Ich weiß auch noch nicht, wie ich den ursprünglichen Fokus nach dem Öffnen und Schließen eines Modals wiederherstellen werde. Optimalerweise sollt dann wieder der Button fokussiert werden, der das Modal geöffnet hat. Vielleicht kann ich das ganz naiv mit einer Fokus-Historie lösen... Mal sehen.
Antworten