Closed cagix closed 1 year ago
Hmm, das Level ist eigentlich erstmal Level, die von dir angesprochenen Geschichten sind eher LevelTools
die von den AITools
verwenden werden können.
Vorschlag daher:
Neue Klasse LevelTools
mit statischen Methoden zum Thema Path-Finding u.ä
Diese können dann in AITools
verwenden werden.
Alternative wäre, die Methoden in die Level-Interfaces mit aufzunehmen. Dann bring ich mir aber libGDX mit in diese ganze Struktur. Da gefällt es mir schon besser, das ganze in einer seperaten Klasse einzusperren. Vorteil wäre, das die Methoden nicht static sein müssten und ich immer direkt auf dem level agieren.level.pathFrom(a,b)
anstelle von LevelTools.pathFrom(a,b,level)
klingt doch sinnvoll. wichtig ist ja, dass diese pfad-sachen eher richtung level kommen, hat ja mit "ai" nicht viel zu tun. und eine util-klasse ist doch super (ich würde sie LevelUtils
nennen statt LevelTools
).
high prio, da einige Issues sich auf diese Methoden beziehen und ich durch ein vorzeites Abarbeiten dieses Issues einen haufen Merge-Konflikte umgehen möchte.
Die ganzen Pfad-Sachen gehören konzeptionell ins Level: Das agiert mit Kacheln und Positionen, und das Level wäre die richtige Stelle, um auch mit Pfaden zu arbeiten. Dazu kommt, dass der Pfad-Kram mit "AI" irgendwie so gar nichts zu tun hat.