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
Zitat
Der RCCSWU (RandomCamelCaseSomtimesWithUndersquare) Stil bricht auch mal mit den veraltet strukturierten Denkmustern und erlaubt dem Entwickler seine Kreativität zu entfalten.
Das ist übrigens auch meine Sorge mit Unity: was, wenn ich an irgendeine Grenze stoße? Und wenn ich in den Facebook-Gruppen die Diskussionen über Performance von 3D-Szenen mitlese, bekomme ich den Eindruck, dass diese Grenzen bei Unity extrem früh kommen.
Unity-Programmierung ist ganz normale C#-Programmierung.
Deine "Scripts" sind stinknormale C#-Klassen, die ganz normal (schon wieder dieses Wort) kompiliert werden.
Ich schlage vor, du probierst es einfach mal aus.
PS: Und selbst wenn es nur ein "Script" wäre, dann wäre das doch auch Programmierung?!
Möchte man mit Templates arbeiten und Dinge eben noch "schön" im Unity Editor zusammenklicken können, kann man sich meistens nicht wie gewohnt Vererbungsstrukturen aufbauen, da das im Unity Editor aktuell nicht unterstützt wird (oder zumindest habe ich nicht herausgefunden, wie das funktioniert).
Ich habe oft das Gefühl, dass Unity den Nutzer ermutigt, nicht eine Player Klasse zu schreiben, die dann eben alles macht, sondern viele kleine Klassen wie PlayerMovementController, PlayerHealth, PlayerWeapons, SpriteFlash, SprieWobble, MoveOnGrid, CollisionController etc... die dann an das Player-Entity (ein Unity Objekt) "angehängt" werden.
Man kann jetzt sagen: "Na das ist doch super, composition over inheritance", aber irgendwie läuft das meinem Bauchgefühl für OOP zuwieder. Es fühlt sich einfach nicht so wirklich nach "echtem programmieren" an.
Das ganze sind natürlich C# Klassen, aber der Kontext, in dem sie benutzt werden, ist eben ein anderer.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Die Aussage stimmt rein prinzipiell schon, nur muss man bei Unity eben doch etwas aufpassen. Möchte man mit Templates arbeiten und Dinge eben noch "schön" im Unity Editor zusammenklicken können, kann man sich meistens nicht wie gewohnt Vererbungsstrukturen aufbauen, da das im Unity Editor aktuell nicht unterstützt wird (oder zumindest habe ich nicht herausgefunden, wie das funktioniert).
Ich habe oft das Gefühl, dass Unity den Nutzer ermutigt, nicht eine Player Klasse zu schreiben, die dann eben alles macht, sondern viele kleine Klassen wie PlayerMovementController, PlayerHealth, PlayerWeapons, SpriteFlash, SprieWobble, MoveOnGrid, CollisionController etc... die dann an das Player-Entity (ein Unity Objekt) "angehängt" werden.
Man kann jetzt sagen: "Na das ist doch super, composition over inheritance", aber irgendwie läuft das meinem Bauchgefühl für OOP zuwieder. Es fühlt sich einfach nicht so wirklich nach "echtem programmieren" an.
Das ganze sind natürlich C# Klassen, aber der Kontext, in dem sie benutzt werden, ist eben ein anderer.
Werbeanzeige