Jump to content
Unity Insider Forum

malzbie

Moderators
  • Content Count

    5,037
  • Joined

  • Last visited

  • Days Won

    343

malzbie last won the day on October 16

malzbie had the most liked content!

Community Reputation

1,544 Excellent

2 Followers

About malzbie

  • Rank
    Moderator
  • Birthday 10/30/1968

Profile Information

  • Gender
    Male
  • Location
    Kassel, Hessen, Deutschland

Recent Profile Visitors

20,272 profile views
  1. Eines der beiden Objekte braucht einen Rigidbody.
  2. Tja, was soll man denn sagen? Man kann so ein Spiel mit 40 Szenen bauen oder aber nur mit einer Szene. Liegt ganz an den Vorlieben des Erstellers und an den Ressourcen, die einem der Rechner zur Verfügung stellt. Sascha hat dir ja schon eine Möglichkeit genannt. Einfach alle Szenensprites in die Szene rein, und je nach Raum das entsprechende Sprite aktivieren. Das vorige aktivierte Sprite muss natürlich zur selben Zeit deaktiviert werden. Mit den Objekten, mit denen du interagieren kannst, machst du das genauso. Du könntest also Für jede Szene einen Überordner in der Hierachie anlegen und ihn RaumX nennen. Dort legst du alle Objekte rein, die für den RaumX wichtig sind. Mit den anderen Räumen machst du das so ähnlich. Gehst du von RaumX zu zu RaumY wird der ganze Ordner RaumX deaktiviert und RaumY akiviert. Jetzt nur noch deine Spielfigur an die richtige Eingangsposition verschieben und fertig isses. Das passiert alles in einem Frame, ist also sofort geschehen. Probiers einfach mal aus.
  3. Ja genau. Wobei >0 natürlich sofort ist, sobald sich etwas leicht bewegt.
  4. Transform.forward ist ja auch die Richtung in der Welt. Das ist nix anderes als Vector3(0,0,1). Ist also einfach in Z Richtung der Welt. Das kannst du mit Norden vergleichen. Du guckst natürlich nicht immer nach Norden. Also einfach mal die Scriptingreferenz befragt, was es denn alles für Transform Befehle gibt, und schwupps kommt das bei raus: https://docs.unity3d.com/ScriptReference/Transform.TransformDirection.html Und nutzen kannst du das so: transform ich =Camera.main.transform; Vector3 meinVorneImBezugZurWelt = ich.TransformDierction(ich.forward);
  5. Weils keine Taste ist, sondern eine Achse. Die Trigger sind nichts anderes als ein Joystick, der von rechts nach links oder von oben nach unten geht. Der Sinn dieser beiden Tasten ist es ein Fahrzeug zu beschleunigen oder zu bremsen und sowas soll ja auch nicht wie ein Schalter passieren, sondern wie ein Pedal. Aber egal. Dein Problem liegt entweder im Verständnis, wie man aus einem quasi analogen Signal ein digitales Signal macht, oder aber an der Animation selbst. Hast du denn mal probiert dein gewünschtes Szenario mit ein Button hin zu kriegen? Wenn nein, dann mach das mal, denn ich kann nur vermuten was bei dir nicht funktioniert. Ob ich damit richtig liege kann ich nicht sagen, denn außer deinem Code habe ich nichts gesehen und auch jetzt erst von deinem Zauber erfahren. Und das wäre eine wichtige Info gewesen. Also teste es mal mit nem Button. Wenns da auch nicht geht, brauchen wir über den Trigger nicht mehr reden.
  6. Ist das vielleicht eine Loop-Animation? Hier mal ein paar Basics: Zum Spielstart ruft der Animatior eine Animation auf. Das ist die orangene Animation, die als Default State markiert ist. Bei einer Character Animation ist das meist die Idle Animation, wo die Figur da so steht und eigentlich nicht viel tut. Diese Animation ist im Inspector meist auf Loop gestellt, weil er dieses Atmen und runstehen ja die ganze Zeit tun soll. Ein State muss aber nicht unbedingt eine Animation beinhalten. Das kann auch ein empty State sein, von dem aus dann andere Animationen gestartet werden. Soweit so gut. Du übergibst per Code dem Animator irgendeinen Parameterwert, auf den der Animator reagieren soll. Dieser Parameterwert wird bei einer Transition dazu genutz um in einen anderen State überzublenden. Damit überhaupt von einem State zum anderen State übergeblendet werden kann, muss natürlich eine Transition von jetzigem State zum anderen State bestehen. Kleines Beispiel: Du hast eine Idle-Animation, eine Duck-Animation und eine Hüpf-Animation. Von der Idle gehen Transitions zu Hüp und auch zu Duck. Von Duck und Hüpf geht es auch wieder zurück zu Idle. Aber von Hüpf zu Duck (und umgekehrt) gibt es keine Transitions. Würde also z.B. ein Duckparameter anstehen, würde von Idle aus zur Duckanimation geblendet werden. Wenn jetzt auch ein Jumpparameter anstehen würde, dann würde nichts weiter passieren, den Jump kann nur von Idle aus erreicht werden. Der Animator muss also erst irgendwie wieder zur Idle blenden um dann zur Hüpfanimation gehen zu können. Soll aber direkt von Hüpf zu Duck geblendet werden können, musst du extra Transitions anlegen. Es gibt einen vorgefertigten State der AnyState heisst. Das ist ein besonderes Dingen, denn wenn es eine Transition zur Hüpfanimation gibt, würde bei entsprechendem Parameter auch zum HüpfState geblendet werden, egal in welchem State die Figur gerade ist. Das kann gut sein, muss es aber nicht. Da der Animator nur das macht, was du ihm sagst, musst du für jedes Überblenden auch Bedingungen (Conditions) abfragen (oder einfach nur die Exittime der Animation nutzen, falls angehakt). Gibt es keine Transition oder hat die Transition keine Bedingung, macht der Animator auch nix und bleibt in dem State, in dem er gerade ist. Ist die Animation da drin auf loop geschaltet, dann wiederholt die sich dauernd. Ist da kein Loop eingestellt, dann hört sie einfach auf. Willst du beim Drücken z.B. nur eine Salve abschießen und danach soll es wieder zu Idle gehen, dann brauchst du eine Bedingung um zurück zu kommen. Wenn jetzt kein Parameter kommt, der der Transition sagt, dass das Schießen nun vorbei ist, dann kannst du das noch über die Exittime der Animation steuern. Die Animation würde genau einmal durchlaufen und dann würde es automatisch zum anderen State gehen. Steht der Parameter für das Starten der Schussanimation dann aber noch an, wird sofort wieder da hin geblendet. Für dich sieht es dann vielleicht so aus, als würde der Typ dauernd schießen, ohne wieder zu Idle zu gehen. Das kannst du aber sehen, wenn du dein Spiel nicht im Vollbildmodus startest und nach dem Start mal den Komponente mit dem Animator anklickst. Da siehst du was sich im Animator gerade tut. Du kannst da auch manuell die Parameter steuern und zusehen, wie die Transitions funktionieren. Bei dir da oben, wird es wahrscheinlich so sein, denn du setzt eine Float Variable die erst dann zurück gesetzt wird, wenn du den Knopf wieder gehen lässt. Wie ich einige Beiträge davor schon geschrieben habe, kannst du deine Animation mit einem Event bestücken ( dieses senkrechte Rechteck) wo du dann einstellst, in welche public Methode reingesprungen werden soll. Wenn die Animation an dem Event angekommen ist, wird das Event automatisch ausgeführt und wenn dabei dann in eine Methode gesprungen würde, die einfach nur dem Animator sagt, dass LTFire wieder auf 0 gesetzt werden soll. Wäre alles schon gut. Oder du nutzt einen Trigger oder setzt den Parameter nach einer gewissen Zeit zurück.
  7. Ich habe das neue System noch nicht probiert. Ich nutze momentan XInput.net, weil es zu viele Probleme mit dem alten System gab. Zusätzlich gab es noch ein Problem mit der Tastatur, denn die 2 Shifttasten haben sich gegenseitig beeinflusst ( Was für einen Flipper sau doof ist). Das lies sich dann mit PInvoke lösen.
  8. Der Sascha hat dir doch das Cdebeispiel für das Drücken des Triggers gegeben. Für ein Gehenlassen des Triggers brauchst du natürlich auch wieder eine Abfrage. Jetzt ist aber die Bedingung if(wasPressed && !isPressed) Also war im Frame davor noch der Trigger gedrückt und ist es jetzt nicht mehr. Ja und wenn dem so ist, dann springst du z.B. in eine andere Methode rein. Die könnte OnTrggerUp heissen. Und dann brauchst du noch die dritte Art. Wenn ein Button oder Trigger gehalten wird. Denn dann ist im Frame davor gedrückt gewesen und jetzt auch. Also: if(wasPressed && isPressed) Alle 3 Abfragen springen entweder in eine Methode rein oder starten ein Event oder setzen eine Varaible auf true. Und da sich alle 3 gegeneinander ausschließen, solltest du ganz einfach jede mögliche Taste oder Achse eines Eingabegerätes definieren können. Da du einem Spieler immer auch die Möglichkeit geben solltest, sich seine Tasten selbst zu definieren, musst du sowieso etwas bauen, was eine Funktion, wie der Jump, definiert und dann die vom Spieler eingestellte Taste oder Achse in ihrerem Status abfragt. Und da Achsen keine Button sind, musst du mit definierten Werten arbeiten und das Down, Up und Hold eben selbst definieren. Ach so: LT und RT heben sich gegenseitig auf. Denn der eine Hebel geht von 0 bis 1 und der Andere Hebel von 0 bis -1. Drückst du beide gleichzeitig ist der Rückgabewert die 0.
  9. Genau wissen tu ich's natürlich auch nicht!
  10. Das Problem liegt an der boolschen Variable. Sobald du drückst, wird die Jump Variable im Animator auf true gesetzt. Sie wird aber erst wieder auf false gesetzt, wenn du den Button loslässt. Da du den Button aber nicht loslässt, bleibt die Variable auf true. Im Animator hast du ja eine Transition von einem State zu dem Sprungstate, wo genau dieses true der Jump Variable abgefragt wird. In der Regel baut man den Animator ja so auf, dass vom Jump State automatisch, nach abspielen der Animation, zurück geblendet wird, z.B. in eine Idle Animation. Wenn das bei dir auch so ist, wird wahrscheinlich dort wieder eine Transition zum Jump sein, und weil ja Jump immer noch true ist, gehts sofort zurück zur Jump Animation. Du hast da mehrere Möglichkeiten, dagegen an zu gehen. Du kannst z.B. die Transition die von Jump zurück geht auf Jump== false hören lassen. Dann musst du erst den Knopf gehen lassen, bevor du wieder in die Idle kommst. Die Jumpanimation würde dann im letzten Frame stehen bleiben, wenn sie nicht loopt. Du kannst aber auch eine Trigger Variable anstatt der boolschen Variable nutzen. Ein Trigger wird einmalig ausgeführt und setzt sich von alleine zurück. Du kannst aber auch im Code die Variable ganz schnell zurück setzen, nachdem du sie gesetzt hast, z.B. nach einer 10tel Sekunde. Oder aber du erzeugst ein Event innerhalb deiner Animation, bei dem in eine Methode im Script rein gesprungen wird. In dieser Methode würde dann die Variable auf false gesetzt. Was der beste Weg ist, hängt von dem Aufbau deines Animators ab und wie komplex das alles ist.
  11. Ich meinte Ansehen und Ruf.
  12. Der neue Flippertisch ist inzwischen schon gut spielbar. Es fehlen jetzt nur noch einige Dispalyanimationen und die Sounds. So sieht er aus: Und das ist das fertige Spielfeld:
  13. Ich fange in der Regel immer wieder von vorne an, außer bei meinem momentanen Projekt, bei dem ich Flippertische baue. Da sind ganz viele Dinge einmalig erstellt und können in jedem neuen Tisch wiederverwendet werden. Aber da ist auch ganz viel neu (Texturen, Sounds, Musik und Objekte), da ja immer auch ein anderes Thema entsteht. Somit würde ich sagen, dass ca. 80% der Logik und 40% der Objekte wieder Verwendung finden. Ich fange aber auch aus einem ganz bestimmten Grund immer wieder neu an: Ich gehe nämlich anders an die Sache heran, da ich das Ziel habe ein Spiel fertig zu stellen! Ich arbeite also mit vielen Platzhaltern und nur manche Dinge mache ich schon komplett fertig. Es wird erst ein simples Grundgerüst gebaut, dann wird dieses verbessert und wieder als Grundgerüst genommen ( jetzt ist das zwar schon verbessert, aber immer noch nicht final). Wenn alles so läuft, wie ich es mir vorstelle, dann bildet sich langsam ein richtiges Spiel heraus. Es kann natürlich passieren, dass ich auch mal eine Idee auf Eis lege und was ganz Anderes anfange. Das wird dann aber nicht vom selben Spielprinzip sein und deswegen gehts beim neuen Spiel wieder von vorne los. Das alte Projekt hebe ich mir aber auf, denn wer weiß... irgendwann mache ich vielleicht weiter. Das Einzige was man immer recyclen kann, sind gewisse Klassen die allgemeine Bereiche abdecken, wie z.B. das Laden und Speichern von Daten. Objekte und Grafiken lassen sich meist nicht in neue Spielthemen integrieren. Und das, was nutzbar wäre ist vom Aufwand her so gering, dass ich es einfach nochmal neu erstelle. Ich würde niemals ein aufwendiges Terrain mit Vegetation erstellen, wenn die Spielemechanik nicht komplett wäre. Es würden immer nur die Objekte auf dem Terrain sein, die auch wichtig für die Mechanik sind. Da reicht es aus, einen kleinen Tümpel zu erstellen, um z.B. schwimmen gehen zu können. 3 Unterschiedliche Uferzonen würde der Tümpel bekommen, um gewisse Stelheiten zu haben und die Bewegungsmechanik darauf hin auszulegen. Ob der super realistisch aussieht, wäre mit jetzt noch komplett egal. Aber ich schreibe schon wieder viel zu viel. Du musst deinen eigenen Weg finden und du wirst irgendwann seber erkennen, was du vielleicht einmal als Asset abspeicherst, um es in einem neuen oder veränderten Projekt nutzen zu können. Als ich noch ganz jung war und ich mit meinem VC20 die ersten Spiele gebaut hatte, fing ich immer mit dem Intro und dem Spielmenü an. Leider sind die Spiele fast nie fertig geworden, weil sogut wie ich immer den Speicher gesprengt hatte. Aber ich hatte echt immer tolle Intros und Menüs!
  14. Willkommen! Also wir haben eigentlich keine feste Regel, wie deine Fragen gestellt werden sollten, also ob darin auch mehrere Fragen vorhanden sind. Wenn es so eine allgemeine Sache ist, wie hier in deinem Thema, ist es ganz ok mehrere Sachen zusammen abzuhandeln. Wird es spezifischer, solltest du für jeden Bereich ein neues Thema aufmachen. Denn das Forum lebt ja davon, dass man in den einzelnen Themenbereichen sucht und meist dann schon einmal eine passende Info bekommt. Sind in den Themen mehrere Fragen drin, kann es sein, dass eine wichtige Antwort nicht gefunden wird, weil sich der Titel vielleicht nur auf die andere Frage bezieht. Außerdem sollte jede Frage auch in dem richtigen Unterbereich des Forums gestellt werden. Sind unterschiedliche Bereiche in ein und demselben Thema drin, geht's schon los. Wir Moderatoren und Admins würden uns dann spätestetens Melden. Also: Für jede Frage bitte ein eigenes Thema aufmachen. Zum anderen Thema: Es ist ganz normal, dass man am Anfang einfach nur mit der Engine rum spielt. Dir scheint es zu gefallen, erst mal eine Landschaft zu bauen und da drin umher zu laufen. Ist ok. Wenn du aber immer wieder andere Dinge innerhalb einer Landschaft austesten willst, dann wäre es schon toll, dass du die Landschaft an sich als Asset abspeicherst. Dann kannst du sie immer wieder in einem neuen Projekt einladen und hast deine kleine Basis fertig. Andererseits ist es ja oftmals so, dass man unterschiedliche Genres testet. Da müsstest du natürlich jedes Mal neu anfangen, geht ja nicht anders. Die Frage ist halt: Möchtest du gewisse Mechaniken erlenen oder geht es dir vorallem um das Visuelle? Beim Visuellen ist es halt so, dass man alles baut. Wenn du aber der Meinung bist, dass du gewisse Teile gut wiederverwenden kannst, dann machst du dir als erstes ein Prefab draus um es in anderen Szenen dieses Projektes wider nutzen zu können. Hast du mehrere Dinge fertig, die man vielleicht gut zusammen immer wieder nutzen könnte, dann speichere sie als Asset auf deine Platte. Du hättest dann einen schönen Start für ein neues Projekt. Beim lernen von Mechaniken, würde ich fast gar keine Szenerie bauen, sondern nur mit wenigen Grundkörpern etwas basteln, damit es gerade mal so zum Testen ausreicht. Später, wenn du die Mechaniken gebaut hast und dann meinst dass daraus was werden könnte, solltest du dich um das Beiwerk kümmern. Aber auch jetzt noch nicht zuviel Energie afwenden. Erst wenn du sagen kannst, dass man die Spielerei jetzt zum vollwertigen Spiel machen sollte, solltest du dich um den Feinschliff kümmern. Auch Platzhalterobjekte oder noch unfertige Dinge kann man als Prefab speichern und/oder als Asset für spätere Projekte speichern. Ich empfehle dir außerdem nicht für jede Kleinigkeit ein neues Projekt zu starten, sondern einfach nur ein Spielerei Projekt, wo dann mehrere Szene drin sind, um gewisse Dinge unabhängig voneinander zu testen. Wenn du dir diese Prefabs erzeugt hast, kannst du sie ja auch immer in anderen Szenen nutzen. Und wenn bei deinen Spielereine dann etwas Gutes raus kommt, dann erzeugst du einfach wieder ein Asset, für spätere Projekte.
  15. Ich bin zwar noch kräftig am malen, aber der neue Tisch kann sich schon sehen lassen.
×
×
  • Create New...