Animation: Konzept/Strukturen und API überdenken

[cagix]

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 #1366 (comment)

[tgrothe]

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]

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]

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.