malzbie

Gerne!

Gerne.

Dein Problem könnte sein, dass ein Destroy nicht sofort passiert, sondern erst nach ablauf des Update-Loops. Du zerstörst also den letzten Level, welcher aber bis zum Ende des Loops noch da ist, instanzierst einen neuen Level, hast jetzt also 2 Level gleichzeitig drin, suchst nach deinen Punkten, die jetzt 2 Mal drin sind, und findest die alten, schon gefundenen, Punkte. Jetzt erst wird der alte Level aus der Szene raus genommen und deine gefundenen Punkte sind weg. Was dir helfen könnte, wäre ein DestroyImmediate. Das wird aber ausdrücklich nicht empfohlen! https://docs.unity3d.com/ScriptReference/Object.DestroyImmediate.html Suchen die Punkte doch einfach mal im LateUpdate und guck ob dann alles in Ordnung ist.

Mal ein anderer Ansatz. Du nutzt ja LookAt für die Ausrichtung. Was spricht dagegen, dass du dem "Ziel", zu dem sich die Rakete ja ausrichten soll, einfach einen Offset hinzufügst. Je weiter weg vom Ziel, desto größer kann der Offset sein. Dafür könntest du dann den Sinus nutzen. Also: Position des Ziels abfragen, Entfernung zum Ziel ermitteln, dann dieser Position auf der X-Achse, Y-Achse oder beiden über den Sinus einen Offset hinzufügen. Der Ausschlag des Offsets, ist abhängig von der Entfernung und wird immer kleiner, je näher du kommst. Die nun neu berechnete Position nutzt du als LookAt Target. Somit würde die Rakete zu Beginn recht stark schlingern und sich beim näher kommen immer mehr fokusieren. Sollte die Rakete an dem Ziel vorbei fliegen, würde sie sich weiterhin in Richtung Ziel (+Offset) ausrichten. Ich habe in meinem Spiel Cavatus ja auch zielsuchende Raketen drin, die eine gewisse Trägheit haben. Sie richten sich dem Ziel aus, aber eben nicht augenblicklich, sondern langsam. Dafür wird ständig ein Zwischenziel berechnet. Da könntest du ansetzen und den Sinus mit einbauen. Den Codeschnipsel kann ich dir ja mal anhängen: // das alles findet in der FixedUpdate statt myRigid.AddRelativeForce(0, 0, force * Time.deltaTime); // es wird dauernd in eigene Z-Richtung beschleunigt if (Player != null ) { Vector3 targetDirection = Player.transform.position - transform.position; // hier berechne ich die Richtung wo es hin gehen soll float step = rotationSpeed * Time.deltaTime; // hier berechne ich einen Winkel, den sich die Rakete pro Sekunde drehen darf Vector3 newDirection = Vector3.RotateTowards(transform.forward, targetDirection, step, 0.0f); // hier berechne ich ein neues Ziel, das ein Stück in Richtung des echten Ziels zeigt transform.rotation = Quaternion.LookRotation(newDirection); // in diese neue Richtung drehe ich mich nun } Ach so: Meine Raketen haben während des Fluges ( solange sie Treibstoff haben) die Gravity ausgeschaltet und einen recht hohen Drag, der die Rakete nicht unendlich beschleunigen lässt. Ja, ich nutze auch in der FixedUpdate die DeltaTime. Somit sind die Werte, die ich einstelle, immer pro Sekunde.

Man kann in unity alles machen. Man hat sogar mehrere Möglichkeiten. Für den Anfang ist hier mal ein Link zum Inputsystem von Unity: https://docs.unity3d.com/ScriptReference/Input.html Unity hat zwar seit einiger Zeit ein neues Inputsystem, aber das ist nicht ganz so einfach zu verstehen, wie das Alte. Und da du anfängst, gehe ich jetzt einfach mal auf das alte System ein. Also, du willst einen einzelnen Schuss bei einem Tastendruck abfeuern. Das geht z.B. mit : if(Input.GetKeyDown(KeyCode.T)){ // kugel instanzieren und nach oben/vorne fliegen lassen } Es gibt Input.GetKey(), Input.GetKeyDown() und Input.GetKeyUp() . Bei GetKey ohen Up oder Down, wird der Tastendruck ständig ausgewertet. Also so lange du die Taste drückst, würde eine Abfrage dieser Taste true ergeben. Bei Input.GetKeyDown() wird nur dieser eine Moment ein true ergeben, bei dem Die Taste runter gedrückt wird. Also in letzten Update-Zyklus war die Taste noch nicht gedrückt, jetzt ist sie es aber. Intern wird also der Wechsel von false auf true überprüft und das passiert nur ein einziges Frame über. Bei Input.GetKeyUp() wird das gehenlassen der Taste ausgewertet. Also eben war sie noch gedrückt, jetzt nicht mehr. Mit diesen drei Abfragen kannst du viele nette Dinge machen. Mit GetKeyDown machste z.B. einen Einzelschuss wie bei einer Pistole. Mit GetKey hättest du ein Dauerfeuer wie bei einem Laser. Mit GetKeyUp könntest du einen Bogen simulieren, bei dem du den Pfeil erst abschießt, wenn du gehen lässt. Ja und mit der Kombination aller 3 Möglichkeiten könntest du eine aufladbare Waffe mit Down starten, sie so lange aufladen wie du drückst und dann beim Up abfeuern. Beispiel : if(Input.GetKeyDown(KeyCode.T)){ // starte Aufladung und starte dafür einen Sound // die Variable "ladung" bekommt einen Grundwert } if(Input.GetKey(KeyCode.T)){ // zeige Fadenkreuz und Ladebalken an. //Die Variable "ladung" wird erhöht. } if(Input.GetKeyUp(KeyCode.T)){ // schieße Energie ab. // Stoppe den Lade-Sound und spiele einen Schuss-Sound ab. // Instanziere ein Geschoss und übergib ihm die Ladung. }

Da bleibt dir wahrscheinlich nichts anderes übrig, als die Grafiken zu zerstückeln und die einzelnen Elemente auf unterschiedliche Ebenen zu legen. Beim oberen Objekt würde ich 4 Teile draus machen. Die Lauffläche (Rechteckig bis zum unteren grünen Saum), die Stirnwand (nur das Grün bis zu den Wölbungen rechts und links) und die Wölbungen selbst. Bei den Rampen würde ich die Grafiken einfach verdoppeln und übereinander legen. Die vordere Grafik ist ab den grauen Steinen (also nach hinten hin) transparent.

Also wörtlich übersetzt sagt dir Unity, dass die Timestamp Werte nicht wie erwartet sind und dass das Video höchstwahrscheinlich nicht richtig abgespielt wird. Wenn ich es richtig sehe, müsste die Meldung gelb sein und nicht rot. Also könnte das Video trotzdem laufen. Wie auch immer. Beim Umwandeln nach H.264 ist etwas schief gelaufen. Es könnte sein, dass Handbreak noch ein paar Einstellungsmöglichkeiten hat, die du probieren kannst. Es kann aber auch sein, dass man nur schlecht oder gar nicht von H.265 nach H.264 umwandeln kann. Es ist ja oft so, dass neuere Versionen irgendwelche Datenformate nicht zurück gewandelt werden könne, weil in ihnen Infos drin sind, die bei alten Formaten einfach nicht berücksichtigt werden. Ich würde an deiner Stelle mal ein Videobearbeitungsprogramm wie z.B. Premiere versuchen. Solche Programme müssten in der Lage sein alles zu wandeln bzw neu zu erstellen. Wenn aber das VR an sich eine Sache ist, die in H.264 nicht existiert, dann wird's nix! Versuch macht kluch!

Wenn du in Unity bist, haut er die Daten immer in den Unity\UnityEditor Bereich rein. Wenn du ein Build von deinem Spiel machst und das Spiel spielst, dann wird der oben genannte Speicherort verwendet. Das verwenden der 2 unterschiedlichen Ort ist also normal. PlayerPrefs. DeleteAll() sollte trotzdem in beiden Bereichen funktionieren. Unity setzt aber selber noch einige Playerprefs-Daten in die Ordner rein. Ob diese Daten mit DeleteAll() auch gelöscht würden, kann ich nicht sagen.

Die einzige Referenz, die du nicht haben kannst, kann ja nur das UI Text Element sein. Hast du denn das Textelement im Inspector auch in den Slot rein gezogen? Warum machst du eigentlich ein neues Thema auf und antwortest nicht im alten Bereich? Alle, die das hier lesen und den anderen Thread nicht gelesen haben, wissen gar nicht worum es geht.

Der gaaanz einfache Weg ist: ZahlText.text= ""+Summe; Einfach so tun, als wäre es ein String, wass du mit den 2 Anführungszeichen hinkriegst und dann + Summe zu schreiben. Est wird dann aus dem leeren String und der Summe ein Kompletter String gemacht. Du kannst auch sowas machen: ZahlText.text= "Die Zahl lautet: "+Summe+" und ist ganz schön groß!";

Das kommt immer ganz drauf an. Cavatus ist momentan nicht der Burner, weil ich anfangs den Preis doch zu hoch gesetzt hatte. Außerdem war mein Veröffentlichungszeitpunkt nicht gut. Da kamen viele große neue Spiele auf den Markt und der Wintersale stand an. Interesse ist da, was ich an der Wishlist und den Downloads der Demo sehen kann. Aber da sie nicht kaufen, ist der Preis wohl immer noch über der Grenze, was man für solch ein Genre bezahlen will. Liegt auch an der momentanen Lage. Bei vielen ist das Geld doch knapper als vor einem Jahr. Meine Pinball Collection läuft, obwohl schon 5 Jahre draußen, deutlich besser. Aber auch von der kann man nicht leben. Das hat MiniJob Charakter. Man kann aber durchaus gutes Geld verdienen, wenn man ein Spiel erschaffen hat, welches den Zeitgeist trifft. Dorfromantik ist so ein Game. Die Jungs hatten vorher schon mal was veröffentlicht, was gefloppt war. Dorfromantik hat aber gezogen und hat sich weit über 500.000 mal verkauft. (Genaue Zahlen hab ich auch nicht) Die Jungs sind also Millionäre geworden. Du siehst, man kann! Die Wahrscheinlichkeit ist aber gering. Das Problem ist doch, dass die großen Konzeren nach ganz kurzer Zeit ein Spiel so stark rabattieren, dass man als kleiner Inide Entwickler dagegen einfach nicht ankommt. Ich habe das vorletzte NeedForSpeed im Sommer für rund 5€ gekauft. 5€!!! Was willst du da für dein Spiel nehmen? Wenn es nicht herausragend künstlerisch ist, musst du es verramschen und schon ist der geplante Verdienst dahin. Denn entweder du verkaufst einige Games für ganz kleines Geld oder du verkaufst ganz wenige Games für einen angemessenen Preis. Tja, soll ich dir Raten bei Steam zu verkaufen? Keine Ahnung. Die Plattform ist gut und hat eine riesen Reichweite. Die Konkurrenz ist aber auch riesig. Wenn du selber nicht der Meinung bist, dass es sich verkaufen wird, dann kannst du dir die Mühe eigentlich sparen. Wenn du aber langfristig etwas aufbauen willst, dann solltest du Steam schon nutzen. Jedes Maß an Bekanntheit ist gut!

Anystate ist immer dann gut, wenn du unbedingt eine Animation ändern musst, egal wo der Animator gerade rum macht. Bei den UI Buttons ist das z.B. immer über Anystate gelöst. Da soll ja ein Button sofort animiert werden, sobald die Maus da drüber ist oder geklickt wird. Interessant wird Anystate dann auch, wenn du mit mehreren Layern arbeites, also zusätzliche Teilanimationen zu den Grundanimationen hinzu mischt. Z.B. wenn ein Player wärend des Laufens von einer Kugel getroffen wird und diesen Hit sofort mit einer Animation darstellen soll. Ich habe früher, als es noch keine Trigger gab, auch alles mit boolschen Typen gelöst. Der Vorteil dabei ist, dass die Variable immer wieder im Code gesetzt werden kann, weil sie ja true oder false ist. Und wenn sie true ist, bleibt sie true, egal wie oft du die nochmal true setzt. Nur, dann musst du die auch irgendwie zurück setzen. Problematisch wird es dann, wenn eine Animation nur einmal angestupst werden soll. Dann musst du entweder im Code nach kurzer Zeit das Dingen wieder auf false setzen, oder aber du baust dir ein Event in die Animationen ein, über den dann in eine Methode gesprungen wird die das Rücksetzen tut. Da ist der Trigger natürlich viel besser, weil er sich selber zurücksetzt. Du hast also 2 unterschiedliche Arten den Animator zu bestücken. Beispiel für einen Player der von Idle zu Walk und wieder zurück zu Idle animiert werden soll: Bei der boolschen Art gehst du in die geloopte Walkanimation rein, sobald die Variable true ist. Dort bleibt der Animator dann bis diese Variable wieder false ist. Idle -(wenn true) -> walk -(wenn false) -> Idle Bei der Trigger Art brauchst du 2 Variablen. Wenn der Trigger Walk kommt, gehts in die Walk, wenn Trigger Idle kommt gehts zurück in die Idle. Idle -(trigger walk) -> walk -(trigger idle) -> idle Für hin und zurück brauchst du also doppelt so viele Parameter. Du kannst den Trigger Idle aber auch bei anderen States nutzen. Der Player hat ja vielleicht ganz viel Tätigkeiten, die alle mit dem Trigger Idle beendet werden können. Ich persönlich vermische die Arten und nutze alles was für meine Zwecke gut ist. Im Entwicklungsprozess wird dann auch germe mal umgestellt, weil ein anderer Weg dann doch praktischer ist. So ist das! Man kann selten zu Beginn sagen was der richtige Weg sein wird. Du wirst deinen Weg finden!

Hi! Anystate ist für dein Vorhaben nicht gut. Anystate bedeutet ja, dass über diesen Pfad eine Animation gestartet werden soll, egal welche Animation gerade ausgeführt wird. Das würde z.B. Sinn machen, wenn in die Idle Animation gesprungen werden soll. Also egal, ob man gerade läuft, geht, tanzt oder schießt. Man kann zwar auch beim Anystate mehrere Bedingungen verknüpfen, aber eigentlich sind Animationen ja fortlaufend, so wie bei dir. Man muss sich ja erst hinsetzen, bevor man sitzen tut. Und wenn man dann sitzt, kann man nicht sofort laufen, denn man muss zuerste wieder aufstehen. Also sind die Transitions meistens von einer Animation zur nächsten, wie in einer Kette, aufgebaut. Dann ist es wichtig den richtigen Parametertyp zu wählen. Man kann zwar fast immer boolsche Typen nehmen, aber die muss man dann auch immer wieder zurücksetzen. Ein guter Weg ist es die boolschen Typen als obersten Zustand zu nutzen. Z.B. wenn du bei der Bewegung zwischen laufend, gehend oder hockend unterscheidest. Oder aber du hast unterschiedliche Animationsbereiche, je nachdem welche Waffe oder welches Werkzeug dein Player in der Hand hat. Du kannst das natürlich so machen, wie es dir am besten gefällt. Ob Trigger oder bool. Beide haben Vor- und Nachteile. Wenn du von Anystate her kommst, bietet sich der Trigger-Typ an. Den setzt man einmalig und er setzt sich selbst zurück. Steht also nicht dauernd an wie eine bool. Wenn du nur eine Bool nutzen willst, kannst du nicht von Anystate gehen, dann muss die Transition von einer anderen Animation wie z.B. die Idle Animation her kommen, weil eben sonst genau das passiert, was du da erlebst. Wenn Trigger "hinsetzen" gesetzt wurde oder die Bool "sitzen" true ist, wird die Hinsetzen-Animation abgespielt. Von dieser Animation geht es automatisch, also nach Ablauf der Animationszeit, zur Sitzen-Animation. Also stellst du bei der Transition "Has Exittime" an und stellst den Wert auf 1. Die Sitzen-Animation ist dann wahrscheinlich auf loop gestellt, die über eine andere Bedingung beendet wird. Hier dann "HasExittime" ausschalten. Wenn dann die Bool "sitzen" auf false geschaltet wird oder der Trigger "aufstehen" gesetzt wurde geht es zur Aufsteh-Animation, die wieder abläuft und automatisch zur Idle Animation geht.

Ja.... ich habe das nicht richtig abgeschrieben, Aber weisst ja wie es wirklich heisst. Nämlich so wie in dem Zitat. Wenn jemand einen Codevorschlag postet, so wie ich das getan habe, dann reicht es nicht ihn einfach zu kopieren. Du muss schon mitdenken, denn ich habe den Code nicht getestet. Ich habe dir einfach eine Möglichkeit gezeigt und deswegen dazu geschrieben ": Du schaffst das!

Erstmal zum While: Sobald die Schleife ausgeführt wird ( weil canJump true ist), wird gleich darunter abgefragt, ob canJump true ist. Und wenn ja ( ist ja, sonst wären wir nicht in der Schleife), dann wird es sofort auf false gesetzt. Somit ist die Schleife unnütz, denn sie wird immer nach einem Durchlauf beendet. In diesem Bereich "setzt" du die Velocity fürs Springen. Gleichzeitig setzt du die Bewegungs Velocity auf 0. Soll das so sein, dass er beim Springen nur senkrecht nach oben hüpft? In der FixedUpdate fragst du den Joystick ab und "setzt" wieder eine Velocity. Diesmal bekommt die x Achse einen wert und die Y Achse wird 0 ! Wird der Joystick nicht bewegt, dann setzt du beide Achsen auf 0, denn genau das bedeutet Vector2.zero. Solltest du gerade die Velocity fürs Springen gesetzt haben, wird sie hier auf 0 gesetzt. Egal ob du den Joystick bewegt hast oder nicht. Am Besten du setzt eine Vector2 Variable mit den RB Velocities die er gerade hat und änderst dann diese Variable auf der entsprechenden Achse ab. Dann nutzt du die veränderte Variable und übergibst sie dem RB. So etwa: void FixedUpdate(){ Vector2 isVelocity = rb.velocity; // Hilfsvarable mit Werten vom rb füllen if(movementJoystick.joysticVex.x !=0){ // wenn was am Joystick passiert dann... isVelocity.x = movementJoystick.x * playerSpeed; //nur den x-Wert der Variable überschreiben } if(buttonHeldDown && canJump){ // wenn der Button gedruckt ist und ich auch hüpfen darf... isVelocity.y = jumpForce; // nur den y-Wert der Variable überschreiben canJump= false; } rb.velocity= isVelocity; // der RB bekommt jetzt die neuen Werte komplett übergeben. Wurde kein Wert überschrieben, bekommt er die ausgelesenen Werte zurück } FixedUpdate und Update laufen zu unterschiedlichen Zyklen ab. Die Update macht das bei jedem Frame und die Fixed Update nach einer eingestellten Zeit. Das ist also so gut wie niemals zur selben Zeit. Man sollte alle Dinge die einen RB betreffen, egal ob du die Velocity setzt oder die Force addierst, in der FixedUpdate machen, damit das Ganze synchron mit allen anderen physikalischen Dingen wie Collidern oder Triggern oder der Schwerkraft passiert. Deswegen hab ich dir in meinem Beispiel alles in die FixedUpdate gepackt.