search

Dungeon-CampusMinden / Dungeon

The "Dungeon" is a tool to gamify classroom content and integrate it into a 2D Rogue-Like role-playing game.
MIT License
16 stars 36 forks source link

Animation: Konzept/Strukturen und API überdenken #1453

Open cagix opened 7 months ago

cagix commented 7 months ago

Eine Animation hat mehrere Texturen (bzw. Pfade dorthin) und einen Namen (Ordner der Texturen?).

Animation sollte ein Builder-Pattern haben, so dass ich eine Animation per addPath schrittweise immer weiter um neue Texturen/Pfade ergänzen kann, und per build() kriege ich die fertige Animation.

Die gespeicherten Pfade weisen die Set-Eigenschaft auf: jede Textur kann nur einmal in einer Animation vorkommen. Außerdem sollen die Pfade (alphabetisch) sortiert sein - d.h. wir sprechen hier über eine TreeSet o.ä. ...

Die API sollte so gestaltet werden, dass das Nutzen des Builders und der Animation so einfach wie möglich wird. Sortieren kann die Animation selbst, das sollte nicht der Kunde erledigen müssen. Das ständige Wechseln zw. File, Path, IPath und String sollte ein Ende finden - was kennt der Kunde, was braucht später libGDX?

_Originally posted by @cagix in https://github.com/Dungeon-CampusMinden/Dungeon/pull/1366#discussion_r1518615253_

tgrothe commented 7 months ago

Das ständige Wechseln zw. File, Path, IPath und String sollte ein Ende finden - was kennt der Kunde, was braucht später libGDX.

Hm, libGDX benötigt einen String für Texturen und hantiert intern mit FileHandles... Ich sehe im Moment keinen Vorteil von unserem IPaths, also quasi den String-Wrappern.

Die IPaths könnten "weg". Stattdessen könnten wir nur Strings verwenden (für "genaue Pfade" und für "Teilpfade zu Ordnern") und wir könnten zusätzlich FileHandles verwenden, wenn dies notwendig sein sollte (zum Beispiel, um durch Resources-Ordner zu iterieren).

Was kommt vor? Wir verwenden zurzeit entweder direkte Pfade zu jw. genau einer Datei oder Teilpfade zu Ordnern, deren Inhalte wir komplett verwenden wollen.

Ich denke, wir sollten das Builder-Pattern mit ausschließlich Strings verwenden, um fertige Animationen zu bauen. Das Builder-Pattern könnte intern Paths, Files (das wäre naheliegend wegen WalkTree...) oder libGDX FileHandles verwenden, aber die Kunden sollten dies "von außen" nicht mitbekommen, denn die haben oder verwenden schließlich nur Strings.

Und wir sollten das Builder-Pattern an einer zentralen Stellen platzieren (zum Beispiel im Game-Subproject) und dann nur dieses Pattern verwenden, also keinen "Parallel-Builder" oder Ähnliches haben.

Dies sind nur ein paar Ideen und Anregungen (ungeordnet), auf die ich in #1366 gestoßen bin. Es ist keine vollständige Analyse und es soll auch noch keine konkrete Aufforderung sein, etwas zu tun oder nicht zu tun.

cagix commented 7 months ago

zwei gedanken:

(a) auf kundenseite hantieren wir mit file oder path, soweit ich das heute gesehen habe.

das wäre für mich grund genug, die api genau damit aufzubauen. eine konvertierung nach string oder sogar einem dedizierten libgdx-typen kann und sollte dann hinter der api passieren, da sollte sich nicht der kunde mit auseinander setzen müssen.

auf diese weise würde schon ziemlich viel von dem monstercode wegfallen, den ich heute beim erzeugen von animationen gesehen habe.

(b) der builder für die animationen liegt für mich direkt neben der animationsklasse. vielleicht ist das eine sogar ne innere klasse des anderen, wer weiß? und dann kann schrittweise an den stellen, wo es sich anbietet, der builder eingebaut werden. der alte code funktioniert dann ja weiterhin, der builder würde es nur einfacher und lesbarer machen.

ich weiß nicht, was du mit "zentral verankern" meinst.

tgrothe commented 7 months ago

ich weiß nicht, was du mit "zentral verankern" meinst.

Ja, genau das (b) meinte ich mit zentral verankern ... also neben die Stelle, wo die Animationen liegen, legen. ;) also so, dass der Builder dann von allen subprojects aus erreichbar wäre.