Dungeon: Systeme und Items im DevDungeon anpassbar machen

[Flamtky]

Im DevDungeon (und wahrscheinlich auch in anderen Spielen, die auf dem Dungeon basieren sollen) werden andere Items und Systeme benötigt.

Wäre es sinnvoll, manche Systeme als nicht final zu setzen und die Items überhaupt nicht final zu machen?

Dadurch könnten Spieleentwickler die Items einfach mit eigener Logik überschreiben und Systeme anpassen.

[cagix]

@Flamtky ich bin neulich über "echte" ecs-frameworks gestolpert und fand die idee sehr charmant, dass systeme keine eigenständigen klassen sind, sondern nur in der gameloop zyklisch aufgerufene funktionen ... siehe #1591 ...

was hältst du davon? wenn man von system-klassen erbt, ist das mit dem ergänzen von verhalten sowieso so eine sache. es gibt keinen richtigen eingriffspunkt, eigentlich müsste man das über eine art template-method anlegen... vermutlich würde man in der praxis immer alles nochmal neu definieren. mit dem funktionsansatz ist man zumindest deutlich schlanker unterwegs.

die items sind nochmal ne andere sache. meine vermutung ist, dass das am ende einfach ortsfeste entitäten sind und nicht lauter eigenständige klassen. hmmm.

[Flamtky]

Ich finde die Idee, Systeme als zyklisch aufgerufene Funktionen statt als eigenständige Klassen zu implementieren, sehr interessant. Das könnte für mehr Flexibilität sorgen.

Bei den Items stimme ich zu, dass sie als ortsfeste Entitäten besser zu handhaben wären.

Bezüglich meines ursprünglichen Anliegens: Soll ich dann erstmal bei den Systemen, die ich überschreibe, das final entfernen, sodass der Dungeon erstmal reinkommen kann? Oder soll ich mir überlegen, wie das auch ohne geht, bzw. einen Workaround erstellen? Und wegen der Items, die ich verändere, wäre es vielleicht auch sinnvoll, die direkt im Dungeon anzupassen. Dann wären sie gebalanced und eventuell etwas interessanter.

[cagix]

Bezüglich meines ursprünglichen Anliegens: Soll ich dann erstmal bei den Systemen, die ich überschreibe, das final entfernen, sodass der Dungeon erstmal reinkommen kann?

ja, mache das.

wie irgendwo neulich schon gesagt: das entfernen des final schadet nicht.

ich bin mir auch ehrlich gesagt nicht sicher, wieso das überhaupt reingeschrieben wurde 🤣 der halbe dungeon ist auf string-basierten hashmaps aufgebaut (statt mal richtige typen zu definieren und typsicher zu arbeiten), aber das blöde final steht wirklich überall, teilweise sogar an int-parametern 🫣 bestimmt, weil das intellij so vorschlägt 🤯 genauso wie überall exceptions geworfen werden, nur um dann eine ebene höher gefangen und als runtime-exception neu geworfen zu werden 🤔

ein gedanke war möglicherweise, dass die systeme nie wirklich für vererbung modelliert waren, und deshalb das final. die frage ist nämlich, was du bei der aktuellen implementierung bei einer vererbung von dem alten verhalten übernehmen könntest und wie du da reingrätschen könntest. nach meinem verständnis ist das ziemlich schwierig, man bräuchte sowas wie eine art template-method-pattern, damit die ableitenden klassen sich einklinken können ...

also mach dir wg. dem final wirklich keine gedanken!

Und wegen der Items, die ich verändere, wäre es vielleicht auch sinnvoll, die direkt im Dungeon anzupassen. Dann wären sie gebalanced und eventuell etwas interessanter.

was jetzt adhoc einfacher ist.

für später wird es sowieso ein refactoring geben, und es kann gut sein, dass dabei einige dinge aus devdungeon nach contrib wandern, einfach weil sie universell nützlich sind.

[Flamtky]

ich bin mir auch ehrlich gesagt nicht sicher, wieso das überhaupt reingeschrieben wurde 🤣 der halbe dungeon ist auf string-basierten hashmaps aufgebaut (statt mal richtige typen zu definieren und typsicher zu arbeiten), aber das blöde final steht wirklich überall, teilweise sogar an int-parametern 🫣 bestimmt, weil das intellij so vorschlägt 🤯 genauso wie überall exceptions geworfen werden, nur um dann eine ebene höher gefangen und als runtime-exception neu geworfen zu werden 🤔

Vlt. wäre es dann sinnvoll gewesen das man eine gemeinsame Code-Style Konfig erstellt hätte 😅

Soll dann dieser Issue geschlossen werden, da voraussichtlich das Problem mit in #1591 beschrieben/behoben wird?

[cagix]

ich bin mir auch ehrlich gesagt nicht sicher, wieso das überhaupt reingeschrieben wurde 🤣 der halbe dungeon ist auf string-basierten hashmaps aufgebaut (statt mal richtige typen zu definieren und typsicher zu arbeiten), aber das blöde final steht wirklich überall, teilweise sogar an int-parametern 🫣 bestimmt, weil das intellij so vorschlägt 🤯 genauso wie überall exceptions geworfen werden, nur um dann eine ebene höher gefangen und als runtime-exception neu geworfen zu werden 🤔

Vlt. wäre es dann sinnvoll gewesen das man eine gemeinsame Code-Style Konfig erstellt hätte 😅

da ist so viel "historisch gewachsen", das glaubst du gar nicht. und es waren auch ziemlich vielen personen beteiligt, rückblickend definitiv zu viele und teilweise auch nicht unbedingt gute entwickler. da hilft auch kein coding-style. im gegenteil, wir hatten mal einen checkstyle, den wir dann aber wieder abschalten mussten, weil sonst gar nichts mehr passiert wäre. das hauptproblem sind aber die leute, die ich immer gern als "autocomplete-coder" bezeichnen möchte: möglichst nicht nachdenken, weder über das problem noch über den lösungsraum noch über lösungsansätze, sondern erstmal loscoden und auf die vorschläge von intellij warten. und ich vermute, das wird in zukunft mit copilot noch schlimmer werden.

Soll dann dieser Issue geschlossen werden, da voraussichtlich das Problem mit in #1591 beschrieben/behoben wird?

neee. lass mal offen, hier sind ja schon nochmal andere ideen drin.