spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich hab von den Entwicklungsprozessen nicht viel Ahnung, aber warum erbt "SoundManager" von "CollisionManager"? Die beiden haben doch nicht viel gemeinsam, oder wie meinst du das? Ich würde ja den "CollisionManager" einfach wie bei Unity "GameObject" nennen.

Und du nennst die oberste Klasse "MyScene", warum nicht einfach "Scene", "MyScene" klingt so nach einem Objekt der Klasse "Scene".

Also unter Mockup stelle ich mir ja immer was grafisches vor. Das da ist eher ein... nicht sehr durchdachtes und äußerst unvollständiges UML-Diagramm. So viele Manager halte ich für ziemlichen Unfug. Die Abhängigkeiten irgendwie auch.

Wo liegt der Unterschied zwischen "Obstacle" und "Enemy"? Warum für jeden einzelnen Typen einen eigenen Manager, wenn sie Ihr Verhalten wahrscheinlich sowieso selbst implementieren?

Was genau macht der CollisionManager? Prüft er jedes Objekt mit jedem anderen und löst ein Event aus? Oder beinhaltet er auch die komplette Logik, was passiert, wenn der Player beispielsweise auf einen "Star" trifft?

Aber ja, das Diagramm ist auch für eine Darstellung der Kommunikation etwas seltsam. Löst der CollisionManager jeden Soundeffekt und jeden Partikeleffekt aus? Bekommt das HUD die Daten vom CollisionManager?

Dann ist es eben kein UML-Diagramm. Es bleibt dabei, dass die Abhängigkeiten/Bekanntheiten sehr schlecht und vermutlich unvollständig sind.

Ich finde schon, dass es ein UML-Diagramm ist. Es ist halt ein UML Kommunikations Diagramm. Da gibt es auch Programme, die das erstellen könnten. Vielleicht erleichtert dir das dann das neue Erstellen eines solchen Diagramms.

Ich habe es auch erst als solches interpretiert. Aber wenn er sagt es ist keins dann ist es keins. Es ist kein UML-Diagramm, wenn man schon vom Standard ausgeht. An statt vielleicht ständig zu bemängeln, dass das angeblich ein UML-Diagramm ist sollten wir ihm lieber bei seinem Design helfen. Da wäre aber tatsächlich ein UML-Diagramm sinnvoll.

UML-Diagramme haben sich in der Praxis nur für eine Sache als wirklich tauglich erwiesen: Zur Dokumentation. Zur Planung von Software hingegen haben sie das übliche Problem, dass eben doch nicht jede Eventualität und Abhängigkeit bedacht wurde, was meist zu massiven Änderungen am Diagramm führen, wobei es hinfällig wird.
Allerdings muss man auch sagen, dass schlechte Entwürfe damit sicherlich schneller auffallen.