Sascha

Das ist doch genau das, was ich dir selber vor zwei Posts geraten habe. Ist aber eben nicht überall der Fall. Linq-Statements sind direkt als solche zu erkennen. Bei deiner Methode ist durch den Namen völlig unklar, was sie macht. Oh Mann, du hast Recht. Equals ist die Ausnahme von der Regel, hab ich übersehen. Mein Fehler! Zu 9.: Ich gehe folgende Liste durch: Wenn Objekte Dinge für sich selbst klären können, sollten sie das tun. Ansonsten: Wenn Objekte Dinge untereinander klären können, sollten sie das tun. Ansonsten: Wenn Mengen gleichartiger Objekte gemeinsam etwas tun müssen, dann reichen statische Variablen und Methoden in dieser Klasse. Ansonten: Wenn irgendein Objekt und irgendein andersartiges Objekt miteinander kommunizieren sollen, dann gibt es zwei Fälle: Die Identität des Dienstleisters ist relevant für den Klienten (Beispiel: Welche Tür der Knopf öffnet ist für den Knopf wichtig). In diesem Fall sollte der Dienstleister über den Editor gesetzt werden, nicht über Code. Dabei helfen entweder serialisierte Felder oder serialisierte UnityEvents. Die Identität des Dienstleisters ist nicht relevant für den Klienten (Beispiel: Der Spielfigur ist es egal, was für ein UI-Objekt seine HP anzeigt - oder ob es überhaupt eine solche Anzeige gibt). In diesem Fall sollte eine globale Variable oder ein Event-System her. Beides kann man eben durch Manager-Objekte implementieren, aber da geht wie gesagt Code-Qualität bei flöten. Ich sehe oft Manager-Klassen, und leider nicht selten bei allen diesen Fällen. Bei 1. bis 4.1. allerdings kann man mit ordentlicher Architektur wunderbar ohne auskommen. 4.2 ist der Fall, wo es etwas schwieriger wird, Manager zu umgehen, aber auch das geht - siehe Link zwei Posts weiter oben. Dafür wird aber erstmal ein gewisses Verständnis von Architektur wichtig, und zum anderen muss man den Kram erstmal brauchbar implementieren. Meine eigene Implementation landet vielleicht demnächst im Asset Store. Mal schauen. Bis man so eine Implementation hat, ist es halt okay, für Fall 4.2. Manager-Klassen zu verwenden, aber man sollte im Hinterkopf behalten, dass das nicht gerade elegant ist. Hier ist ein kleines Architekturbeispiel von mir dafür, wie man gänzlich ohne Manager auskommt: https://gitlab.com/FlaShG/Unity-Architecture Ausreden helfen nix, guter Code bleibt guter Code und schlechter Code bleibt schlechter Code. Mach dir halt bewusst, was Dinge tun, und dann schreib dir das auf. Eine Methode löscht Dinge, aus einer Liste, die nicht Eigenschaft X haben? Nenne sie "DeleteObjectsWithoutX" und fertig. Du sollst ja kein Kind benennen (auch wenn es Programmierphilosophien gibt, die besagen, dass du das genauso sorgsam tun sollst), sondern eine Beschreibung finden für das, was etwas tut. Ne allgemeine Lebensweisheit ist aber, dass es dir nix hilft, irgendwelche Schwächen vorzuschieben und zu sagen "joa ich bin Legastniker, ich kann da nix für". Arbeite daran oder du wirst hinter anderen zurückbleiben. Mein Verdacht waren die fehlenden Meta-Files im Repo, aber das ist eigentlich Quatsch, weil du die ja lokal auf jeden Fall hattest. Passiert das mit den gelöschten Namen bei allen ScriptableObjects oder nur bestimmten? Ich würde die Felder jedenfalls in "Title" umbenennen, damit keine Verwirrung entsteht. Das bezieht sich auf meine Liste weiter oben. Dinge sollten sich selbst beeinflussen, so weit es geht. Ein Flugzeug in einer Formation sollte lieber sich selbst im Bezug auf die anderen steuern, als dass ein abstrakter Manager alle Flugzeuge gleichzeitig unter Kontrolle hat. Zumindest in der Spieleentwicklung. Die Metapher ist mit Vorsicht zu genießen, da man sie gerade im Bezug auf ECS auch ganz falsch auslegen kann. Grundsätzlich gilt bei Programmierung, auch außerhalb von Unity: Je weniger verschiedene Einheiten (Klassen, Objekte) über die anderen wissen, desto besser. Je weniger ein Script funktioniert, sobald ein Fehler in einem anderen Script ist, desto schlechter.

Ist eine nachvollziehbare Vermutung.

Oha Okay... 1. Es geht um Component und ScriptableObject. Außerdem erben noch GameObject und alle Asset-Typen (Mesh, Texture2D, AudioClip, ...) davon, aber von denen wiederum erbst du ja nicht. 5. Geht mir weniger um Yakus, als darum, dass vällig unklar ist, was die Methode macht. Da ist kein Verb im Namen der Methode. Löscht sie Yakus? Filtert sie sie? Sortiert sie sie? Vermutlich sucht sie keine raus, denn der Rückgabewert wird nicht benutzt, aber wer kann sich da schon sicher sein...? 7. Wenn du den Namen von etwas brauchst, dann verwende für die Variable einen Typ, von dem du weißt, dass du dessen Namen erfahren kannst. Also statt ein "Auto" als Parameter zu erwarten und dann zu checken, ob es ein "Polizeiauto" ist, damit du die Sirene anwerfen kannst, verwende gleich "Polizeiauto" als Paramtertyp. 9. Manager-Klassen (und Singletons!) sind problematisch, da sie ungefähr alle Codequalitäten auf einmal senken. Er wird weniger robust, schlechter bis gar nicht testbar und vor allem geht die Modularität flöten. Immer, wenn jemand eine Klasse namens "GameManager" in seinem Code hat, oder eben etwas vergleichbares, sehe ich gleich schlechten Code. Singletons sind zumindest im Unity-Kontext so lange erträglich, bis man bessere Lösungen verinnerlicht hat. Außerhalb von Unity wird man für Singletons zurecht schräg angeguckt. Manager-Klassen sindwesentlich seltener "nötig", als man anfangs glaubt, wenn man mal schaut, welche Klassen die Arbeit stattdessen übernehmen können. Aber wenn du dich für den geilen Kram bereit fühlst, der beides komplett überflüssig macht, empfehle ich mal das hier. 10. Das ist ja gut, dass du dafür eine erklärung hast, aber es geht ja um die Namen. Ein Handler und ein Manager ist dasselbe, darum muss man entweder deinen Code oder eine Erklärung wie deine gerade lesen, um zu verstehen, wie das gemeint ist. Bei gutem Code muss man das nicht. Warum heißt der "YakuHandler" nicht einfach "Yaku"? Deine aktuelle Klasse "Yaku" könnte "YakuData" heißen. Alternatic kannst du den "YakuHandler" auhc "YakuDisplay" nennen, dann ist auch klar, was die Klasse macht. Aber "Handler" ist halt "macht Dinge damit", das hilft einem immer nicht weiter. Zum anderen Post... Bin mir nicht sicher, was du da genau machst, aber... Verwende keine Namen von UnityEngine.Objects. Wir reden hier im Zweifelsfall vom Dateinamen des Assets, der muss sich ändern können, ohne dass dein Projekt in die Luft fliegt. Mach das Feld "Name" private und knall ein [SerializeField] drüber. Dann kannst du dir sicher sein, dass schon einmal keine deiner anderen Klassen daran herumfummelt. Ich habe gerade nicht einmal gefunden, wie du deine "Yaku"-ScriptableObjects erstellst. Wie erzeugst und speicherst du sie?

Assets, die in einer Szene benutzt werden, werden nicht in einer Szene gespeichert. Deine Szene beinhaltet daher keines deiner Scripts, keine 3D-Modelle außer die Unity-Standard-Dinger und auch sonst nichts. Ich nehme stark an, dass das "Throwable"-Script mit Collidern arbeitet, also anhand von Collidern festellt, ob etwas berührt wurde oder nicht. Ich nehme außerdem an, dass dein GameObject keinen Collider hat.

Witzig, genau das Thema hatte ich gerade schon in einer anderen Community. Endless Runner, Klebenbleiben an Plattformen. Die Sache ist die: Du willst bei einem Endless Runner zwar konstant nach rechts (oder geradeaus) bewegen, aber eben nur, bis eine Wand getroffen wird. In diesem Fall gibt es zwei Möglichkeiten: Der Spieler verliert das Spiel oder die horizontale Bewegung hört auf. In beiden Fällen kannst du mit OnCollisionEnter prüfen, ob der getroffene Collider vor der Spielfigur ist oder eben nicht (z.B. bei einem Boden). Im Falle einer Kollision mit der Wand kannst du dann so reagieren, wie du es für dein Spiel für richtig hältst.

Wie der Name der Eigenschaft sagt, handelt es sich um Kollisionsdetektion. Das Verhalten deines Rigidbodys bezüglich Reibung usw. hat mit dieser Eigenschaft nichts zu tun. Ich nehme an, du redest von seitlicher Bewegung, und dass dein Charakter mit Rigidbody gegen eine Wand fliegt und dann nicht herunterrutscht. Wenn dem so ist, liegt dein Problem in deinem Bewegungsscript. Ein reales Objekt, das gegen eine vertikale Wand fliegt, verliert seine horizontale Geschwindigkeit. Je nachdem, wo die Energie hingeleitet wird, geht sie gegen null oder wird zurückgegeben und das Objekt prallt ab. Dieses Verhalten kannst du durch Bounciness einstellen. Aber auch die Standard-Bounciness von 0 bedeutet kein Hängenbleiben, das ist also nicht die Lösung. Du wirst ein Bewegungsscript haben, das den Rigidbody horizontal beschleunigt. Hier liegt das Problem wirklich - auch, wenn der Charakter gegen eine Wand prallt, fügt dieses Script weiterhin Kraft in Richtung Wand hinzu. Stelle dir eine Wand vor, die dich mit künstlicher Schwerkraft anzieht. Vielleicht kennst du ja sogar die Stargate-Folge . Da rutscht du auch nicht dran herunter, weil die Kraft, die dich zur Wand zieht (oder drückt) stärker ist als die normale Schwerkraft. Die Lösung ist daher, nicht mehr konstant horizontale Kraft hinzuzufügen, sondern z.B. während eines Sprungs die horizontale Bewegung des Rigidbodys in Ruhe zu lassen.

Dann schau ich mal... da ich da nur so drüber gucke, schreibe ich nur, was ich anders machen würde. Also nicht wundern, dass ich nicht auch Dinge lobe. Geht schneller Von UnityEngine.Object erbende Klassen sollte man nie zu mehreren in eine Datei tun. Dein Projekt hat keine .meta-Dateien im Repo. Die solltest du aber dringend mitcommitten, sonst funktioniert nichts. Du verwendest einen Mix aud deutschem und englischem Code. Lieber nicht Du bist außerdem sehr inkonsistent mit deinen Namen. Mal groß, mal klein, mal Unterstrich - und kaum etwas davon entspricht dem C#-Standard. Die Namen sind hier und da nicht sonderlich sprechend. Ich habe z.B. nicht einmal ansatzweise eine Idee, was das hier sein soll, und so etwas ist auch nicht so gut Du identifizierst Objekte über ihre Namen oder Tags. Davon ist abzuraten. Du identifizierst Objekte über ihre Typen. Davon ist dringend abzuraten. Du verwendest OnGUI. Du verwendest (gleich mehrere!) Klassen, die global den Spielverlauf beeinflussen. Das ist kein guter Stil. Teilweise sind diese Klassen sogar gefühlt für denselben Zweck. Warum gibt es "YakuHandler" und "YakuManager"? Du hast Code im Projekt, bei dem in der Summary "veraltet" steht. Du benutzt jetzt git. In git wird kein veralteter Code aufbewahrt, er wird einfach gelöscht Das wäre erstmal alles, was mir so aufgefallen ist. Wenn du zu irgedetwas eine Frage hast oder eine Erklärung möchtest, sag Bescheid.

Und ich hab mal die E-Mail-Adresse unkenntlich gemacht Das ist so die Art von Fehlern, wo man nur mit Glück eine Lösung findet. Ich hatte sowas auch nie. Lade dir mal Unity Hub herunter und versuche, dich damit anzumelden.

Unity nimmt nur Sachen mit in den Build, die dein Spiel auch wirklich benutzt. Und alles, was in einem Resources-Ordner ist. Du deaktivierst also effektiv Asset Stripping, und das völlig ohne Grund. Ich glaube außerdem, dass du deine Ladezeiten damit beeinflussen dürftest.

Joa... Dinge, die drei Jahre alt sind, sind sehr oft nicht mehr richtig/aktuell bei Unity. Kannst du Unity Hub benutzen und dich da anmelden?

Ja, das geht. Du kannst mit Rechtsklich auf einen Tab ein neues Fenster deiner Wahl hinzufügen und deine Vorlieben dann als Layout speichern. Es gibt auch bereits vorgegebene Layouts (siehe Link) mit mehreren Scene Views.

Code läuft in einem Stück ab. Deine Schleife läuft 20-Mal durch und danach wird das Spiel erst neu gerendert. Es wird eben nicht bei jedem Mal, wo ein Objekt seine Position ändert, neu gezeichnet. Wenn du einen solchen Ablauf haben willst, empfiehlt sich eine Coroutine. Damit kannst du die Ausführung deines Codes mit "warte einen Frame" in jedem Schleifendurchlauf versehen.

Ich weiß nicht, wo du das mit der "Proxy-Variable" her hast, aber es scheint mir eine sehr merkwürdige Lösung zu sein. Erzähl doch erstmal: Welches Betriebssystem? Welche Unity-Version? Unity Hub, ja oder nein?

Edit: Joa, mal wieder zu langsam, aber dafür etwas mehr in-depth Kollisionsdetektion bestimmt, wie genau der Rigidbody schaut, ob er mit etwas kollidiert ist. Letztenendes geht die Physik-Engine ja nur bei jedem FixedUpdate zu allen Rigidbodys und bewegt sie einmal entlang ihrer aktuellen velocity. Das ist auch der Wert, der von AddForce und Gravitation beeinflusst wird. Vorher ist der Rigidbody hier, danach ist er da. Wenn er "da" dann in einem Collider hängt, wird das als Kollision gewertet und der Rigidbody reagiert entsprechend. Ist der Rigidbody allerdings vorher nicht in einem anderen Collider und hinterher auch nicht, dann gibt es keine Kollision, selbst wenn zwischen "hier" und "da" eine Wand ist. Das ist die Ausgangslage, wenn man den Kollidions-Detektions-Modus auf "Discrete" stehen lässt. Kostet dafür aber auch schön wenig Performance. Stellt man den Wert jetzt nach oben, werden zusätzliche Maßnahmen eingeschaltet, in solchen Fällen doch noch zu kollidieren. "Continuous" macht dabei einen SweepTest und bemerkt statische Collider "im Vorbeiflug". "Continuous Dynamic" bemerkt sogar andere, sich bewegende Rigidbodys. "Continuous Speculative" ist ähnlich wie "Continous Dynamic", aber performanter und eben mit kinematischen Rigidbodys kompatibel.

Ja, hab mir das auch vorgestern oder so runtergeladen und mein Projekt darauf eingestellt. Der Workflow mit den Dingern ist der Hammer. Einmal benutzt, dann kann man nie wieder zurück.