Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Sicher gibt es Lösungen und Workarounds. Offensichtlich habe ich die Projekte ja zu einem zufriedenstellenden Abschlus geführt.Ich bin mir ziemlich sicher, dass es auch für deine Fälle Lösungsmöglichkeiten gibt.
Siehe unten.Meiner Meinung nach hat Unity also nichts mit einem übermäßigen Aufsplitten der Funktionalität zu tun, sondern nur der Entwickler, der so vorgeht.
Das hat zumindest bei mir nicht funktioniert. Ich habe das dann so akzeptiert und halt entsprechend anders strukturiert. Man kann das ja recht einfach mit Strategy-Pattern umgehen.Wenn ich es nicht total falsch in Erinnerung habe, zeigt der Editor doch problemlos geerbte Properties etc. an. Wo klemmt es denn da bei Vererbungshierarchien?
Das würde mich mal interessieren. Kannst du mir mehr dazu sagen?Ich hab eine zeit lang rumprobiert, welche Konstrukte sich direkt über den Editor anzeigen und editieren lassen. Bin dann zu einer halbwegs guten Lösung gekommen, bei der ich für die Anzeige im Editor eine separate Klasse nutze. Mit Hilfe eines DI Frameworks lässt sich das dann einigermaßen bequem mit den Stellen wo sie benötigt werden verknüpfen. So bleibt auch (abgesehen von dem Editor Glue) der Code Unity frei.
Wie gesagt, ich finde Unity ist ein großartiges Werkzeugt um Spiele zu machen und im Gegensatz zu anderen Engies/Toolkits funktioniert es wirklich einwandfrei und hat tollen Support. Es ist eher meine persönliche Meinung und Stil, dass ich mich mit zusammengesteckten Lego-Bausteinen nicht so wohl fühle, wie mit mittelgroßen Klassen.Das Prinzip hört auf den Namen Entitiy-Component-System und wird recht häufig im Zusammenhang mit Spielen erwähnt und eingesetzt. Es macht bei Unity in Verbindung mit dem Editor auch unglaublich viel Sinn.
...
Und selbst wenn es nicht wiederverwendbare Komponente sind, macht es Sinn. Eine Herausforderung bei der Softwareentwicklung ist es, eine Struktur in den Code zu bringen, damit dieser besser lesbar aka wartbar ist. ... Hier muss man natürlich wieder aufpassen das man die Benennung und Aufteilung logisch nachvollziehbar macht.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Gegenfrage: warum überhaupt sauberen Code schreiben? Wenn's funktioniert, ist's doch prima. Es merkt später kein Schwein, ob man da nun händisch serialisiert oder nicht.Ich spiel mal Devil's Advocate:
"Warum sollte mans denn anders machen?"
Wenns funktioniert, ists doch prima. Merkt später kein Schwein ob du da nun händisch serialisiert hast oder nicht.
Die Entscheidungsgrundlage für oder gegen eine Engine oder ein Framework ist eher Featureumfang, mitgelieferte Tools, mitgelieferte Ressourcen, vorhandene Dokumentation und Support usw.Wer Unity nimmt, um dann möglichst sauber und fein programmieren, hat sowieso schon den ersten Fehler gemacht.
Bei der Entwicklung von Unity wurde wohl darüber nachgedacht, wie genau die Engine aufgebaut sein soll, bspw. dass es ein komponentenbasiertes System gibt, dass die Kommunikation unter den Komponenten mit SendMessage stattfindet, dass es eine Hirarchie innerhalb der GameObjects geben kann und noch viele weitere Apsekte. Ob nun Programmierer "sauber" oder "unsauber" vorgehen, kann die Engine vielleicht ein wenig beeinflussen, sie kann es aber beim besten Willen nicht steuern.Es ist nunmal nicht der Anspruch von Unity, perfekten Code zu schreiben den man sonst überall verwenden kann.
Das heißt nicht wie gesagt, dass man in Unity nur schludern kann, aber die Priorität liegt einfach woanders.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Gegenfrage: warum überhaupt sauberen Code schreiben? Wenn's funktioniert, ist's doch prima. Es merkt später kein Schwein, ob man da nun händisch serialisiert oder nicht.Ich spiel mal Devil's Advocate:
"Warum sollte mans denn anders machen?"
Wenns funktioniert, ists doch prima. Merkt später kein Schwein ob du da nun händisch serialisiert hast oder nicht.
Oh wait...
(Der Punkt der Serialisierbarkeit ist für den Editor relevant, da darin nur serialisierbare Elemente angezeigt und angepasst werden können bzw. da nur solche automatisch gespeichert und im Spiel selbst geladen werden können. Das hat also nur indirekt mit der Sauberkeit zu tun.)
Zitat
Die Entscheidungsgrundlage für oder gegen eine Engine oder ein Framework ist eher Featureumfang, mitgelieferte Tools, mitgelieferte Ressourcen, vorhandene Dokumentation und Support usw.Wer Unity nimmt, um dann möglichst sauber und fein programmieren, hat sowieso schon den ersten Fehler gemacht.
Die Sauberkeit der Programmierung ist also nicht Teil der Entscheidungsgrundlage, die Verwendung einer Engine ist aber keine Ausrede für den Verzicht darauf.
Zitat
Bei der Entwicklung von Unity wurde wohl darüber nachgedacht, wie genau die Engine aufgebaut sein soll, bspw. dass es ein komponentenbasiertes System gibt, dass die Kommunikation unter den Komponenten mit SendMessage stattfindet, dass es eine Hirarchie innerhalb der GameObjects geben kann und noch viele weitere Apsekte. Ob nun Programmierer "sauber" oder "unsauber" vorgehen, kann die Engine vielleicht ein wenig beeinflussen, sie kann es aber beim besten Willen nicht steuern.Es ist nunmal nicht der Anspruch von Unity, perfekten Code zu schreiben den man sonst überall verwenden kann.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »KeksX« (07.11.2014, 16:29)
Seinen Code grundsätzlich Unity-frei halten zu wollen halte ich nicht grundsätzlich für sinnvoll. Algorithmen, Strukturen und ähnliche Dinge kann man ohne Probleme so schreiben, bei allem anderen kommt man nicht sinnvoll drum herum.
Mich würde auch interessieren, was du da entwickelt hast und vor allem, für welchen Anwendungsfall du es einsetzt. Bisher klingt es nach Klassen mit dem Attribute [System.Serializable], was ich bisher kaum bis gar nicht benötigt habe.
Community-Fossil
Die von Unity vorgesehene Art der Kommunikation Aufrufe von SendMessage sind, wäre es nichtmal so abwegig.
Werbeanzeige