Sascha

Jein. Aktuell nicht, aber da sie ja bereits gesagt haben, dass sie die ToS jederzeit nach Lust und Laune ändern wollen, kann immer noch alles passieren. Was nach dem aktuellen Stand (der sich durchaus wieder ändern kann) passiert ist, dass der Play Store dein Spiel zusammen mit allen anderen Unity-Spielen irgendwann einfach raus schmeißt, weil Unity-Apps gegen deren Regeln verstoßen. Aktuell sollen ja offenbar die Vertreiber, also Play Store, App Store, Steam usw. den Kram bezahlen. Das werden die ziemlich sicher nicht einfach so mit sich machen lassen. Ob existierende Apps, die z.B. seit dieser Woche auch keine Updates mehr kriegen, irgendwie geschützt sind... und sowieso alles andere... steht in den Sternen.

Für alle, die sich immer noch wundern, warum der Backlash so groß ist: Ein Spiel zu entwickeln, vor allem eines, das Geld verdienen soll, ist oft eine Angelegenheit von mehreren Jahren. Manchmal eines, manchmal mehrere, manchmal sogar zweistellig. Wenn man ein Spieleprojekt anfängt, und sogar noch mehr wenn man ein Studio aufbaut, das man dann nach und nach mit Menschen bestückt, die Spiele entwickeln können, dann ist die Wahl der Engine ein extremes Committment. Man geht, auch wenn man zuerst vielleicht nix bezahlt, eine Partnerschaft mit der Engine ein. Sollte Unity morgen nicht mehr existieren, würden dadurch in sehr vielen Studios überall auf der Welt jahrelange Arbeit und unfassbare Mengen an Geld über Nacht einfach weg sein. Deshalb ist die Wahl einer Engine für ein Spiel oder ein Studio etwas, das extrem auf Vertrauen basiert. Egal, wie gut die Engine ist - wenn die Firma dahinter nicht vertrauenswürdig ist, erhöht sich dadurch das Risiko, dass dein Projekt in die Brüche geht. Du setzt deine Existenz und/oder die deines Teams aufs Spiel. Was Unity diese Woche gemacht hat, ist ein unfassbarer Vertrauensbruch. Sie haben eine dumme Änderung angekündigt. Eine gute Metrik für die Bezahlung einer Middleware wie Unity ist immer "wenn du gewinnst, gewinnen wir mit dir". Auch wenn es sich um einen Randfall handelt (laut Unity selbst aber immerhin stolze 10% aller Entwickler!), dass man auf viele Installationen und niedrige ARPU (average revenue per user) setzt, hat das Unity-Management hier bewiesen, dass sie diesen Grundgedanken nicht verfolgen. Wer diese valide Schiene bisher gefahren ist, kann mit Unity schlicht keinen Gewinn mehr erzielen. Diese Entscheidung ist ein Beweis dafür, dass Unity die Unterstützung aller Entwickler nicht als Priorität versteht. Das Vertrauen, dass Unity Einsicht zeigen sollte, sollten sie irgendwann mal dir mit ihrer Idiotie Schaden zufügen, ist damit weg. die Änderung extrem schwach kommuniziert. Die Veränderungen warn sehr unklar und auch jetzt sind noch entscheidende Fragen offen. Die technische Umsetzung unterliegt der Geheimhaltung. Und wie zum Geier eine vermutlich nach Hause telefonierende Engine überhaupt unter europäischem Datenschutz funktionieren soll, versteht auch keiner. intern von vielen Mitarbeitern schon vor der Veröffentlichung große Kritik geerntet. Es heißt, dass vieles von dem, was Leute jetzt entrüstet schreiben, bereits vor Dienstag intern angemerkt wurde. Es hieß wohl "Antworten kommen". Stattdessen wurde der Plan einfach umgesetzt. Viele Unity-Entwickler kündigen jetzt. bereits auf Twitter angekündigt, dass sie jedes Jahr die Preise re-evaluieren und anpassen wollen. Das Committment, unvorhersehbar und unzuverlässig zu sein, ist stark. angekündigt, dass diese Änderung auch Leute betrifft, die sich schon von Jahren für Unity entschieden haben. eine ältere Version der TOS (terms of service) auf Github klangheimlich gelöscht, die besagt, dass man eine neuere TOS-Version ablehnen kann, wenn man auf der entsprechenden Engine-Version bleibt. Sie halten sich also nach Möglichkeit nicht an ihr eigenes Wort. Wenn das nicht illegal ist, weiß ich auch nicht weiter. Um das einmal klipp und klar zu sagen: Unfgefähr niemand beschwert sich darüber, Unity mehr Geld geben zu müssen. Das Problem, das wir hier haben ist, dass Unitys Chef-Etage der Welt bewiesen hat, dass sie weder die Fähigkeit, noch das Interesse haben, vertrauenswürdig zu sein. Und diese Vertrauenswürdigkeit ist, wie gesagt, extrem wichtig für eine Engine. Selbst, wenn Unity alles morgen wieder zurück nehmen würde, würde mir jeder, der professionell in der Spielebranche arbeitet, unterschreiben, dass Unity seit dieser Woche einfach einen unfassbaren Risikofaktor darstellt. Das hat dann auch nix mehr mit beleidigt oder wütend zu tun - das ist einfach eine ganz übliche wirtschaftliche Kalkulation. Dass Unity für viele Anwendungszwecke immer noch einfach die beste Engine ist, wird sie auf lange Sicht nicht davor retten, jetzt zunehmend in der Versenkung zu verschwinden. Mehr und mehr Studios kehren Unity den Rücken zu, also werden weniger und weniger Unity-Entwickler gesucht. Wer heute in die Spieleentwicklung will, kann sich gerne Unity anschauen, aber tut gut daran, mindestens noch eine andere Engine kennen zu lernen. Auch nicht zuletzt, weil Unity im Gegensatz zu mehreren Konkurrenten in den letzten Jahren technisch ziemlich stagniert ist. Glaubt mir bitte, dass ich hier nicht irgendwie leichtfertig Unity schlecht Rede. Ich benutze diese Engine seit 2008. 15 Jahre. Seit Version 2.3. Wenn Leute sich öffentlich entrüstet von Unity abwenden, dürft ihr davon ausgehen, dass hier nicht einfach nur die Gefühle hochkochen. Wegen wütend werden wirft man nicht 5, 10, 15 Jahre Erfahrungen über Bord. Ich schaue mir für mein aktuelles Hobbyprojekt gerade Godot an. Das passt ganz gut zum Projekt. Ansonsten warte ich ab, was mein neuer Arbeitgeber für das Studio entscheidet. Vielleicht bleibe ich ja dann dort bei Unity. Aber ein gutes Wort für sie einlegen werde ich, abgesehen von Fakten, in dieser Sache nicht.

Das ist richtig, aber: Time.deltaTime gibt, wenn du es in FixedUpdate benutzt, denselben Wert zurück wie Time.fixedDeltaTime. Es ist daher schön simpel, einfach überall immer Time.deltaTime zu benutzen.

Moin! Diese Zeile ergibt schon einmal nicht so viel Sinn: targetRotation += Vector3.Lerp(targetRotation, Vector3.zero, returnSpeed * Time.deltaTime); Du addierst da das Lerp-Ergebnis auf den Vektor obendrauf. Wenn returnSpeed * Time.deltaTime nicht gerade >= 1 ist, sodass sich targetRotation dadurch gar nicht ändert, dann wird dieser Vektor mit jedem Frame immer größer. Und zwar exponentiell. Ich nehme stark an, dass du da recht schnell irgendwelche float-Limits überschreitest, was dann zu den NaN-Werten führt. Und so nebenbei: Die Verwendung von Time.fixedDeltaTime kann hier auch keine sinnvollen Ergebnisse produzieren. Das ist einfach ne Konstante 0.02, sofern du das nicht anderweitig eingestellt hast.

Moin und Willkommen! Folgende Sachen brauchst du, damit du etwas hören kannst: Einen AudioListener (hast du standardmäßig auf deiner Kamera, aber schau lieber nochmal nach). Das ist quasi das Mikrofon, das den Sound in deiner Szene aufnimmt. Eine AudioSource (hast du) mit AudioClip (hast du), die auch läuft (hast du dank Play On Awake). Die AudioSource muss so eingestellt sein, dass du der AudioListener auch etwas hören kann. Es gibt einen Regler namens "Spatial Blend". Die "2D"-Seite bedeutet, dass der Ton positionsunabhängig ist. Die "3D"-Seite bedeutet, dass du den Ton nur hören kannst, wenn der AudioListener nah genug an der AudioSource dran ist. Wenn du den Regler ganz links hast, ist das schon mal nicht das Problem. Unity sollte nicht im System stumm geschaltet sein. Keine Fehlermeldungen in der Konsole. Wenn irgendetwas merkwürdiges schief gegangen sein sollte, könntest du eine Fehlermeldung gekriegt haben. Schau am besten mal in die Konsole (oben Window/General/Console), was du da so hast.

Dann stimmt vielleicht was bei der Line-Funktion nicht? Steht da ein LineRenderer hinter? Nutzt der vielleicht statt world space local space oder anders herum?

Nö, sieht richtig aus. Meine Vermutung wäre daher, dass irgendetwas anderes schief läuft. Setzt du vielleicht _directionRayLength.value irgendwo? Oder hast du vielleicht noch ein anderes Script, das eine Linie da hin malt? Oder eine zweite Instanz dieses Scripts mit anderen Werten?

Wie sieht denn dein Code aus? Aber ganz allgemein: meinVector.normalized gibt einen Einheitsvektor zurück, der dieselbe Richtung wie meinVector hat. Also derselbe Vektor, aber mit der Länge 1. Er wird verlängert oder verkürzt, um das zu erreichen. meinVector * Zahl gibt dir meinVector zurück, aber "Zahl"-mal so lang. Wenn meinVector also die Länge 2 hat und "Zahl" = 3 ist, dann kriegst du einen Vektor mit derselben Richtung und der Länge 6. Wenn du daher meinVector.normalized * zahl dann kriegst du meinVector, aber mit der Länge "zahl", egal wie lang "meinVector" vorher war, zurück.

Ach soo Na dann: direction = direction.normalized * _directionRayLength.value;

Der Ansatz klingt erstmal nicht schlecht, aber ich kann dir leider gerade nicht sagen, ob du damit zum Ziel kommst. Wenn du mit deinem Projekt nicht gerade unter Zeitdruck stehst, dann würde ich es an deiner Stelle einfach versuchen. Im Zweifelsfall lernst du bestimmt eine Menge. Dein Design kommt zuerst. Wenn du prozedural generierte Level oder einen Level-Editor haben willst, dann ist die Lösung raus. Deine Vision davon, wie das Spiel sein soll, für einen Kompromiss zu opfern, kommt meiner Meinung nach nicht in Frage, solange es noch andere Optionen gibt. Davon abgesehen könnte es durchaus funktionieren.

Es gibt noch Vector3.ClampMagnitude, welches einmal das Berechnen der Quadratwurzel einspart. Ist vielleicht auch minimal lesbarer. Aber das sind nur minimale Optimierungen gegenüber @Antragons Lösung.

Moin! Deine Kugel rollt ja nicht horizontal, sondern ein wenig nach unten. Das macht die Gravitation, die jedes Physik-Update draufgerechnet wird. Und die willst du ja auch haben. Dass du trotzdem horizontal bleibst, liegt nur an den Collidern unter der Kugel, mit denen du in jedem Frame aufs neue kollidierst. Das Problem entsteht dadurch, dass die Kugel je nach Umstand nicht mit der Oberseite, sondern mit der vorderen Kante eines Cubes kollidieren kann. Die Kugel rollt hier von links nach rechts. Schwarz ist die aktuelle Position, rot die Zielposition, bevor Kollisionen aufgelöst werden. Links betritt sie den rechten Cube durch die Oberseite (Kontakt-Areal ist orange), rechts geht's durch die Ecke. Die Physik-Engine versteht leider nicht, dass der linke Collider die Kugel eigentlich davon abhält, die vertikale Seite des rechten Colliders zu berühren. Deshalb wird eine Kollision an einer vertikalen Wand ermittelt. Je nach Winkel springt die Kugel deshalb nach oben oder bleibt komplett stehen. Du kannst in den Physik-Einstellungen in den Project Settings eine Einstellung ändern, die den Mindestwert eines Kollisionsimpulses beschreibt. Wenn du ihn höher stellst, dann ignoriert die Engine kleinere Hüpfer. Das hilft natürlich nicht so richtig, weil du immer noch drüber kommen kannst, aber auch, weil damit das Stehenbleiben nicht behoben wird. Mal davon abgesehen kannst du damit Impulse kaputt machen, die du eigentlich behalten wolltest. Das war aber leider auch schon die einzige simple Lösung. Wesentlich sinnvoller, aber leider auch schwieriger, wäre "Skin Width". Da kriegt der Collider noch eine Speckschicht außen herum, und wenn da etwas hinein gerät, wird deine Kugel einfach so weit verschoben, dass die Schicht wieder frei ist - ohne dabei einen Impuls zu erzeugen. Leider können Rigidbodys das meines Wissens nach aber nicht. Du kannst sonst noch ein bisschen mit der Form der Collider experimentieren. Eigentlich brauchst du da ja keine Würfel. Aber so richtig endgültig wird auch das nicht sein. Wenn du da nicht selber so richtig tief einsteigen willst, kann noch ein Blick in den Asset Store helfen. Leider ist ausgerechnet so etwas simples wie ein rollender Ball gar nicht mal so einfach umzusetzen.

Moin und willkommen! Du kannst deinen Autos, wenn sie das nicht schon haben, Collider geben. Die sind nicht nur für Physik und Kollisionen da, sondern werden auch dafür benutzt, dass du in die Szene klicken kannst und dann wird geschaut, was du getroffen hast. Die professionellere Variante ist das jetzt nicht, aber für den Anfang reicht es aus, deinem Auto-Prefab ein Script zu geben (bzw. ein vorhandenes zu erweitern), das eine OnMouseDown-Methode hat: private void OnMouseDown() { Debug.Log(name + " wurde geklickt"); } Wenn das soweit funktioniert, kann man da was sinnvolleres reinschreiben. Z.B. kannst du das markierte Auto in einem statischen Feld referenzieren. Statisch bedeutet, dass nicht jede Instanz dieses Script (also jedes Auto für sich) dieses Feld (Variable) hat, sondern es das Feld nur einmalig im Programm gibt. Wenn du da also "hineinschreibst", welches Auto gerade markiert ist, dann kann immer nur eines zur Zeit markiert sein. // "NameDesAutoScripts" = Name dieses Scripts hier public static NameDesAutoScripts selectedCar; private void OnMouseDown() { selectedCar = this; } Und in deinem Code, der Autos bewegt, kannst du dann diesem Auto sagen, dass es sich bewegen soll: NameDesAutoScripts.selectedCar.MoveTo(position); ...oder wie auch immer dein Code da aussieht. Jedenfalls kannst du mit "NameDesAutoScripts.selectedCar" von überall im Code das aktuell ausgewählte Auto abfragen und damit machen, was du willst. Ist alles etwas rudimentär - für eine Stelle als Entwickler solltest du dich mit diesem Code eher nicht bewerben. Sollte aber funktionieren. Nur nicht drauf verbeißen

Ja, das ginge auch. Sehen vermutlich nicht super überzeugend aus, aber wenn es gut genug aussieht, dann ist es eben gut genug Und wenn du dir bei der Variante ordentlich Coding-Stress sparst, dann ist wäre das auch ne gute Sache.

Moin und willkommen! Ich glaube, das geht schlicht nicht. Zumindest nicht einfach so. Ich vermute, dass bei der Anforderungsanalyse damals (ist schon ein Weilchen her, dass an dem System was gemacht wurde) heraus kam, dass das zu selten gebraucht wird. Ich sehe aktuell höchstens die Möglichkeit, dass du ein Objekt immer wieder (vermutlich in FixedUpdate) an eine Position verschiebst, die du aus Cloth.vertices ziehst. Dort hast du die Positionen aller Vertices drin. Wie du die richtigen Indizes heraus findest, weiß ich gerade nicht mit Sicherheit. Vermutlich ginge aber ein initiales Iterieren durch die Vertices. Da schaust du für jeden Bommel, ob das aktuelle Vertex das nächstgelegene ist und wenn ja, merkst du dir das für den jeweiligen Bommel. Ich würde dafür eine Bommel-Komponente machen: public class Bommel : MonoBehaviour { private Vector3 attachedVertexIndex = -1; private float attachedVertexDistance = Mathf.Infinity; public void OverrideClosestVertexIfCloser(Vector3 vertex, int index) { var distance = Vector3.Distance(vertex, transform.position); if (distance < attachedVertexDistance) { attachedVertexDistance = distance; attachedVertexIndex = index; } } } Die kommt auf jeden Bommel drauf. Dann gibt's hier so einen Code, um durch alle Vertices durchzugehen: for (var vertexIndex = 0; vertexIndex < vertices.Length; vertexIndex++) { foreach (var bommel in attachedBommels) { bommel.OverrideClosestVertexIfCloser(vertices[vertexIndex], vertexIndex); } } Ich nehme stark an, dass das Vertex-Array allerdings im Local Space ist. Da muss man also nochmal Transform.TransformPoint oder so drauf schmeißen. Da das performance-mäßig nicht so knorke ist, sollte man das vielleicht in ein Editor-Tool packen. Hast nen Knopf, drückst drauf, er macht das einmalig im Editor und merkt sich die Ergebnisse einfach. Dann muss der Rechner, auf dem das Spiel läuft, das nicht bei jedem Spielstark machen. Dafür müssen die beiden Felder in der Bommel-Klasse noch [SerializeField, HideInInspector] abkriegen. Ist jetzt nicht mehr so wirklich Anfängerkram, aber soweit ich das sehen kann, gibt es dafür leider einfach keine anfängerfreundliche Lösung.

Da fällt mir direkt keins ein. Ist aber eigentlich nicht so komplex. Du hast halt Entitys (hier "GameObjects"), die keine eigene Semantik haben, sondern nur Container für Komponenten sind. Diese Komponenten definieren dann, was das für ein Objekt ist. Eine Unterkategorie davon sind MonoBehaviours, also deine Scripts. Die klinken sich in Events ein, die aus der Engine kommen und kriegen so ihre Impulse, um irgendetwas zu tun. Wann du was auf welches GameObject packst, ist nicht fest definiert, aber es gibt natürlich Ansätze, die schlauer sind als andere. Z.B. sollten Objekte sich so weit wie möglich selber managen. Ein Hubschrauber hat dann eine Komponente, die sich um das Einsteigen können kümmert und eine weitere für's Fliegen. Vermutlich noch die eine oder andere mehr, um's single purpose und modular zu halten. Wenn du so etwas abstraktes hast, das eigentlich gar nicht so richtig Teil deiner Szene ist, dann kannst du das Ding auf irgendein ansonsten leeres GameObject schmeißen. Oft kann man die Komponente aber auch direkt mit auf den Button kleben, der deinen Code auslösen soll. Man kann aber auch überlegen, ob man das überhaupt als Komponente braucht und ggf. stattdessen einfach eine normale Klasse bauen.

Also, wenn die Exception bei "this.myText.text = ..." fliegt, dann sehe ich im Code kein Problem, das dazu führen könnte. Entsprechend würde ich sagen, dass kein Objekt durch Drag and Drop im Inspektor referenziert wurde. Wenn du das doch gemacht hast, ist das wahrscheinlichste Problem, dass du dieses Script hier mehrfach in deiner Szene hast, und die Instanz, bei der diese Methode aufgerufen wird, da nichts zugewiesen hat.

Moin! Würde helfen, wenn du den relevanten Code einmal zeigen würdest

Moin! Static gibt's ja nicht nur einfach. "Static" steht für eine Vielzahl an einzelnen Flags. Einige davon haben mit Performance überhaupt nix am Hut: "Contribute GI", "Navigation Static", "Off Mesh Link Generation" und "Reflection Probe Static". "Occluder Static" und "Occludee Static" beziehen sich auf Occlusion Culling, also das Nicht-Rendern von Dingen, bei denen Unity sich sicher ist, dass sie sowieso gänzlich verdeckt werden. Das anzuschalten macht aber überhaupt nichts, wenn du das Occlusion Culling-System nicht auch nutzt. "Batching Static" erlaubt es Unity, das Rendern von Meshes mit gleichem Material in einem Rutsch in Auftrag zu geben. Das reduziert Draw Calls und kann gut für die Rendering-Performance sein. Damit da spürbar was passiert, müssen die Meshes sich aber eben ein Material teilen.

Ah okay... Dann schau dir mal das hier an: https://docs.unity3d.com/Manual/class-SpriteMask.html So ein Ding würde ich mit einem Tween schrumpfen lassen.

Für so simple Sachen ist es vernünftig, Tweens gegenüber "echten" Animationen in Erwägung zu ziehen. Anstatt da einen so derartig simplen AnimationClip überall zu verteilen, kannst du auch einfach mit einer Coroutine die Größe immer weiter runter schrauben. Oder, und das würde ich hier empfehlen: Du benutzt ein beliebiges Tween-System. Damit sagst du "nimm dieses Objekt und animiere es über die nächsten x Sekunden hinweg auf Größe 0". Dann kannst du noch die Zerstörung des Objekts an das "Tween fertig"-Callback dranhängen und fertig bist du.

Moin! Ich weiß nicht genau, wie du auf dieses Forum kommst, aber hier geht es um Spieleentwicklung mit Unity, nicht um First Level Tech Support. Für den Fall, dass trotzdem jemand was dazu sagen will, habe ich das Thema mal aus dem Entwickler-Bereich heraus verschoben.

Ich würde nur halt wollen, dass der Teil des Spiels, in dem ich wegen des Kampfes gerade nicht bin, eingefroren ist. Ich hätte keine Lust auf die Art von Bugs, die entstehen kann, wenn da noch irgendwelche Logik im Hintergrund weiter läuft.

Moin, bei UML geht's immer darum, dass andere verstehen, was du da gebaut hast und was du dir dabei gedacht hast. Drölf mal String zu schreiben gibt kaum eine sinnvolle Information; aber gar kein Parameter suggeriert dass da nur etwas committed wird und nicht dass du da erst deine Daten übergibst. Der einzige Grund, warum du nicht Variante 3 nehmen willst, ist, dass sie ewig lang ist. Aber das ist kein UML-spezifisches Problem, das ist einfach ein Problem mit deiner Methode. Wenn du so viele Parameter hast, ist das einfach eine unschöne Methodensignatur, UML hin oder her. Was üblich wäre, wäre eine "Person"- oder "Customer"-Klasse, und du übergibst einfach eine Referenz auf eine Instanz davon.

Moin! Mein letzter Stand ist, dass es nach wie vor keine Möglichkeit gibt, eine Szene zu deaktivieren. Was du machen kannst, ist alle Root-GameObjects der Szene zu deaktivieren, oder noch simpler, alle Root-GameObjects einem neuen GameObject unterzuordnen. Die zweite Variante ist ganz hübsch, aber es ist auch leider ein bisschen eklig, dass man dann immer drauf aufpassen muss, dass man nirgendwo den Parent auf null setzt, sonst fliegt das betroffene GameObject aus dem Deaktivierungs-System heraus. Naja gut - wenn in deiner theoretisch deaktivierten Szene immer noch irgendetwas passiert, hast du das Problem so oder so. In beiden Fällen hast du Scene.GetRootGameObjects als Einstiegspunkt. Du musst Variante 2 nämlich nicht unbedingt im Editor machen, sondern kannst in Start oder bei einer anderen Gelegenheit damit alle Objekte raussuchen und einem automatisch generierten GameObject unterordnen.