Sascha

Was weiß ich denn, wie dein Spielfeld auszusehen hat? Ich weiß ja nichtmal, was das für ein Spiel ist oder welche Regeln es hat. Bin nicht in deinem Kopf drin Werden denn die Karten gelöscht, die bereits existieren, wenn du die Szene wechselst?

Wir haben da mal ne Weile rumprobiert, aber das Plugin hat sich mega quergestellt... ich benutze einfach C, ist ähnlich genug Coroutines laufen auf MonoBehaviours, also deinen Script-Komponenten. Wenn die Komponente zerstört wird, sei es direkt, durch Zerstörung des GameObjects oder durch das Entladen der Szene, dann läuft sie natürlich nicht mehr weiter. Wenn eine Coroutine nach Laden einer neuen Szene noch läuft, dann liegt das daran, dass die MB-Komponente, auf der sie läuft, noch existiert, also durch DontDestroyOnLoad am Leben gehalten wird. Ich weiß ehrlich gesagt nicht, wo dein Fehler liegt. Ich sehe da einen Screenshot mit nem Hintergrundbild, nen Haufen Karten und etwas IMGUI drüber. Da ich nicht weiß, was du eigentlich haben willst, weiß ich nicht, wo der "abartige Effekt" ist

Weil es die Dissonanz zwischen visueller Wahrnehmung und Gleichgewichtssinn ist, die Schwindel verursacht. Gibt ein paar Leute, die damit keine Probleme haben, aber ein sehr großer Teil der Spieler kann ein Spiel direkt weglegen, wenn die Kamera nicht nahezu ausschließlich durch den Kopf kontrolliert wird.

Es ist sehr wichtig, dass du Regel Nummer eins nicht brichst: Dass die Kamera niemals von durch unberechenbare Faktoren außer dem Kopf des Spielers beeinflusst wird. Wenn der Spieler seinen Kopf in die Wand hält, dann darfst du ihn davon nicht abhalten. Was du allerdings machen kannst ist, das Bild schwarz zu machen, bis der Kopf wieder aus der Wand raus ist. Coolere Implementationen zeigen noch simple Fixpunkte an, damit du nicht die Orientierung verlierst und deinen Kopf wieder aus der Wand herauskriegst.

Du hast dir auch gerade eine etwas ungewöhnliche Zielsetzung gemacht, so für den Anfang. Da ist nichts schlimmes dran, aber du musst hier mehrere Dinge auf einmal lernen, bevor du dein erstes Ergebnis zu sehen bekommst. Du hast jetzt zwei Möglichkeiten: Entweder, du machst Pause und arbeitest das eine oder andere Tutorial durch, damit du Schritt für Schritt deine verschiedenen Werkzeuge kennenlernst; oder du bleibst bei diesem Projekt. An beiden Wegen ist nichts auszusetzen, aber bei Variante zwei musst du dich drauf einstellen, dass die ganze Sache etwas nerviger wird, weil du mit lauter Sachen jonglierst, die du gerade noch kennenlernst. Ob du if-Abfragen brauchst, lässt sich nicht eindeutig beantworten, da viele Wege nach Rom führen. Meine Einschätzung wäre: Wenn du es irgendwie™ machst, dann ja, wenn du eine elegantere Lösung baust, dann nicht mehr, und wenn du eine richtig professionelle Implementation machst, dann sind wieder welche drin

Die Scene View-Kamera hat einen Fokuspunkt, den du auch in die Tiefe verschieben kannst, und ein Zoom-Level relativ zu diesem Fokuspunkt. Wenn dein Fokuspunkt hinter dem Objekt liegt, das du anschauen willst, dann verschwindet es beim Heranzoomen irgendwann. Du kannst auf das Objekt von Interesse in der Hierarchie Doppelklicken; du kannst es auch markieren und F drücken. Dann wird der Fokuspunkt auf den Objektmittelpunkt gesetzt.

Ein Canvas wird Standardmäßig über dem gesamten restlichen Spiel gerendert. Das kannst du ändern, indem du beim Canvas von "Screen Space" auf etwas anderes stellst. Bei "Camera" verhält sich der Canvas immer noch so wie vorher relativ zu einer Kamera, die du angeben kannst. Es wird dann aber als Teil der Welt gerendert, mit einem einstellbaren Abstand zur Kamera. Wenn dein Partikelsystem aber eigentlich nur Teil des UI sein soll, kann dein Canvas im Screen Space bleiben. Du solltest dann meines Wissens nach einfach dein Partikelsystem in den Canvas hineinverschieben können.

Ach, die Geschichte... Richtig. @Thariel Du hast natürlich Recht: Ein bewegtes GameObject ist nicht sofort an seiner neuen Position, sondern erst nach Ende des Frames. Da ein verschobenes Objekt letztendlich einiges mehr an Konsequenzen nach sich zieht, als man erwartet, arbeitet Unity alle Änderungen in der Szene in einem Rutsch ab. Dadurch müssen Dinge nicht doppelt und dreifach gemacht werden, wie es der Fall wäre, wenn diese Dinge nach jeder Transform-Änderung gemacht würden. In deinem Fall ist das natürlich schlecht. Du kannst diese Änderungen aber manuell auslösen, und zwar mit Physics.SyncTransforms. Das rufst du einfach nach dem Verschieben auf. Damit umgehst du zwar diese Optimierung, die es nicht ohne Grund gibt, aber wie immer gilt: Performance ist erst dann ein Thema, wenn es zum Problem wird. Optimalerweise würdest du dir eine eigene Datenstruktur bauen, die das Feld repräsentiert, und das ganze nicht über die Physik-Engine machen, aber wenn dein Spiel nicht zu groß ist, ersparst du dir mit dieser Methode einiges an Ärger. @Jomnitech Er löst den Raycast in Update aus - das heißt nicht, dass er das jeden Frame macht. FixedUpdate ändert hier auch nichts.

Der gesamte Mono-Teil (also der C#-Teil) deines Projekts ist single threaded, sofern du nicht ECS nutzt. Das heißt, dass deine Raycasts nicht gleichzeitig ablaufen, sondern der eine immer vor dem anderen. Man könnte z.B. den Collider direkt auf das freie Feld schieben und die Animation auf den sichtbaren Teil des Objekts beschränken, damit der nächste Raycast direkt den Collider des anderen NPCs trifft.

Mit riesigen Zahlen kann Unity nicht umgehen, weil 32-bit floating point numbers im Koordinatensystem verwendet werden. Im Millionenbereich kann dir bereits die erste Nachkommastelle flöten gehen. Im 10-Milliarden-Bereich gibt's schonmal Ungenauigkeiten im dreistelligen Bereich. Aber davon mal abgesehen: Wenn dein Objekt auf die gegebene Distanz zu klein ist, um gesehen zu werden, dann ist es zu klein, um gesehen zu werden. Wenn dein Objekt plötzlich größer ist, hat es ja nicht mehr die richtige Größe. Du schaust ja auch nicht in den Nachthimmel und beschwerst dich, dass du Deimos nicht erkennen kannst.

Absolut.

Darauf gibt es leider keine eindeutige Antwort. In C# gibt es ja, im Gegensatz zum nahen Verwandten Java, Properties. Das bedeutet in diesem Kontext, dass eine Zuweisung wie deine beliebig viele Seiteneffekte haben kann. Beim Setzen von transform.localScale könnten z.B. irgendwelche Hintergrund-Datenstrukturen der Szene neu berechnet werden - was genau passiert, könnte dann wiederum davon abhängen, ob du einen Renderer und/oder einen Collider auf dem GameObject hast. Kann natürlich auch sein, dass die Property schlau genug ist, gar nichts neu zu berechnen, wenn der neue Wert sowieso dem alten entspricht - so, wie du es oben vorschlägst. Nur eben in der Property anstatt außenherum. Leider gibt es keinen Weg, da einfach mal hineinzuschauen, wenn du keinen Source Code-Zugriff hast. Unity hat da in den letzten Jahren verstärkt optimiert, aber was genau da passiert... keine Ahnung. Es gilt also wie immer: Mach dir keinen Kopf um Performance, lass einfach ohne großen Drumherum den Code laufen und kümmer dich um Framerate, wenn sie anfängt, ein Problem darzustellen. In Sachen Code-Qualität würde ich sagen: Die beiden Varianten geben sich nicht sonderlich viel.

Tatsächlich ist das bei genauerem Hinsehen gar nicht so ganz einfach. Wenn zwei Flächen genau zur Kamera zeigen und eigentlich hintereinander sind, sind sie dadurch ja direkt aufeinander, und dann gibt's Z-Fights. Die einfachste Lösung wäre wohl, die Skalierung sehr klein, aber größer als 0 zu setzen, damit es flach aussieht aber nicht wirklich alles ineinander rutscht.

Die Textur wird so groß in den Speicher geladen, wie sie ist. Die Skalierung in den Import Settings (und in der Transform-Komponente) haben darauf keinen Einfluss. Du kannst allerdings in den Import Settings auch eine Maximalgröße per Plattform festlegen, und das ist dann wirklich die Größe des Textur-Assets, wie es in den Build gepackt wird. Bei Texturgrößen gilt: So groß wie nötig, so klein wie möglich.

Du kannst auf das Asset klicken und im Inspektor die Skalierung einstellen.