Jump to content
Unity Insider Forum

malzbie

Moderators
  • Content Count

    5,162
  • Joined

  • Last visited

  • Days Won

    366

malzbie last won the day on November 16

malzbie had the most liked content!

Community Reputation

1,579 Excellent

2 Followers

About malzbie

  • Rank
    Moderator
  • Birthday 10/30/1968

Profile Information

  • Gender
    Male
  • Location
    Kassel, Hessen, Deutschland

Recent Profile Visitors

23,996 profile views
  1. @Jog Das musst du mir mal erklären. Warum soll seine Art des Aufrufs langsamer sein, als die deine?
  2. Also ich weiß was er meint. Aber ich weiß nicht warum es nicht geht. Bist du sicher, dass du das Bild im Project Fenster abzulegen versuchst? Denn nur dort geht es. Es geht nicht im Hierachie Fenster.
  3. Moin! Ich habe jetzt schon lange nichts mehr gepostet obwohl ich an diversen Spielen dran bin. Nun will ich euch mal zeigen, woran ich hauptsächlich bastle. Es ist ein Arcade-lastiges Spiel, bei dem man mit Flugzeugen und nem Zeppelin Missionen erfüllen muss. Natürlich wird dabei geballert! Obwohl es ein 3D Game ist, bewegt sich alles nur auf 2 Ebenen. So wie bei alten Sidescrollern. Aber seht einfach selbst. Hier ist mal eine Minute aus meinem Prototyp.
  4. Das Erste gefällt mir besser, weil es klarer zu verstehen ist. Wobei du alles betitelt hast, nur nicht den Progress. Da überlässt du es dem Spieler, es richtig zu verstehen. Im zweiten Bild is der progress sogar im Outcome Bereich. Da hat er nix verloren. Bei beiden ist aber insgesamt zu viel Info vorhanden, die sich auf den ersten Blick gar nicht entschlüsseln lässt. Dass man zu 100% Holz bekommt sollte eigentlich klar sein, denn dafür ist die Werkstatt da. Aber was soll das mit den Sägespänen und Ästen? Es gibt ne 30-prozentige Chance Sägespäne zu bekommen aber dann gleich 8 Einheiten davon? Versteh ich nicht. Sägepäne gibt es immer, wenn was gesägt wird. Die Menge könnte natürlich variieren. Aber mal ganz ehrlich: Hat der Spieler einen Einfluss darauf ob zusätzliches Material anfällt? Oder kann er mit den Grundmaterialien die Menge des Zusatzmaterials verändern? Wenn nicht, kann die Info auch raus. Aber selbst wenn es so wäre, ist es nicht nötig das in dem Fenster extra darzustellen, denn es ist vom Zufall behaftet. Es würde reichen, wenn darüber in einem Glossar oder in der allgemeinen Spielanleitung darüber informiert werden würde. Wenn es entsteht, dann entsteht es und du kannst es im Lager sehen. Und wenn nicht, dann nicht! Dann hilft auch die Info nicht, dass es hätte entstehen können. Ich als Spieler mag Wirtschafts- und Aufbausimulationen. Ich mag es auch, wenn man Micromanagement betreiben kann. Grundsätzlich will ich aber klare Informationen haben. Deswegen ist das erste Bild besser, da es von oben nach unten zeigt, wer daran arbeitet, was an Grundstoffen da ist, welche Werkzeuge und Perks dafür genutzt werden, und wie weit der Fortschritt ist. Natürlich ist auch nett zu sehen, was dabei heraus kommt. Aber das ist eigentlich klar, denn es ist ja links schon zu sehen. Die zufälligen Abfälle (du nennst es Loot), die man evtl. woanders nutzen kann, brauchen da nicht zu sein. Es sollte aber zu sehen sein, wie sich die Anzahl der Arbeiter, das Werkzeug und diverse Perks auf den Prozess auswirken. Momentan ist eine Säge da. Würde es etwas ändern, wenn 3 Sägen da wären oder aber die legendäre Säge vom alten Zimmermann Waldemar Ast? Wenn ja, sollte dieser Boost sich in einem Faktor auswirken, den man auch im Bild sehen kann. Solllte die Wahl des Werkzeuges oder der Perk sich auf den Loot (!) auswirken, dann sollte das trotzdem nicht in den Outcome, sondern etwas separiert, z.B. in eine Art Bonusfenster, um klar zu erkennen, dass die Wahl der Waffen (Werkzeuge) dafür zuständig ist.
  5. Ich gehe davon aus, dass es ein Timingproblem ist. Ein Timingproblem deswegen, Weil OnTrigger in der FixedTime abläuft aber Input in der GameTime, also im Updatezyklus. Beide Zeitzyklen sind unterschiedlich schnell (oft) und somit kann es sein, dass das DownEvent nicht mehr ansteht, wenn der FixedTime Zyklus dran ist. Setze stattdessen in der OnTriggerEnter() (nicht Stay) Funktion einfach nur eine boolsche Variable, die bei OnTriggerExit() wieder zurück gestellt wird. Diese Variable nutzt du dann in der Update() mit deiner Input Abfrage zusammen, um die Lampe ein oder auszuschalten. MAAAN, eine Sekunde zuspät gedrückt.
  6. Dahinter steckt, dass Unity der Meinung ist, dass jemand mit einem Einkommen vom über 100.000$ in der lage sein sollte, eine kostenpflichtige Version zu nutzen. Kleine und Anfänger werden unterstützt. Verifizieren lässt sich das erstmal nicht. Schon gar nicht, wenn du Spiele als Nebengewerbe erstellst. Es sei denn, du hast ein Spiel erstellt was in aller Munde ist und deine Verkaufszahlen können eingesehen werden. Dann kann man ja ganz einfach rechnen. Was du sonst noch irgendwo her an Einnahmen hast, weiß nur das Finanzamt. Sonst keiner. Unity hofft jedenfalls auf die Ehrlichkeit der Leute.
  7. Ja, das ist natürlich eine ganz andere Hausnummer! Jetzt verstehe ich, was du da so machst. Trotzdem ist es nicht realistisch, dass sich der Preis eines Produktes wärend deines Marktbesuchs ändert. Schon gar nicht im Mittelalter! Wir sind ja schließlich nicht ander Börse mit Computerhandel. Aber selbst wenn sich der Preis ändern sollte, so kann es erst nach einem Handel sein. Also der Preis, den du vor einen Kauf siehst, bleibt solange bestehen, bis du eine gewisse Menge gekauft hast. Nach dem Handel, egal ob erfolgreich oder nicht, könnte er neu berechnet werden. Genauso darf es nicht sein, dass in dem Markt, wo du gerade bist, ein NPC wärend deines Handels den Preis oder die Verfügbarkeit des Produktes ändern kann. Du bis schließlich an der Reihe und nicht der NPC. Somit gibt es immer nur Änderungen nach einem Handel. Das betrifft die Reputation, den Preis und die Verfügbarkeit. Dass sich das Inventory des Players zur selben Zeit ändern kann, ist eh klar. NPC's sollten, meiner Meinung nach, wärend eines Handels in diesem Shop keinen Einfluss haben. Also: Sobald du dem Markt besuchst, setzen die NPC's erst einmal aus. Du siehst die Güter und deren Preise. Jetzt kannst du Güter in gewünschter Anzahl in deinen Warenkorb legen und versuchen einen guten Preis auszuhandeln. Egal ob es klappt oder nicht. Nach der Aktion werden die Shopdaten aktualisiert. Das bedeutet, jetzt könnten auch einmal alle NPC einen Handel ausführen. Also alle NPC, die auch am Tresen stehen und gewartet haben, handeln jetzt nacheinander (das alles passiert natürlich in einem Frame). Danach bist du wieder an der Reihe. Du siehst jetzt dadurch evtl. andere Güter und/oder andere Preise, weil sich das Lager verändert hat. Jetzt könntest du wieder handeln. Verlässt du den Shop, können die NPC machen was sie wollen. Es gibt also ein Event vor jedem Handel, welches den Shop aktualisiert indem er seine Datenbanken abfragt und dir die Veränderung anzeigt. Nach einem Handel gibt es 2 weitere Events. Eines für die Inventorys und eines für die Reputation. Und so müsste es dann auch für jeden NPC sein. (1) Shop wird aktualisiert, Handel wird getätigt, (2)Inventorys werden verändert und (3)Reputationen werden angepasst.
  8. Eine Meinung dazu habe ich schon, aber was soll ich sagen.... Ich hatte selber schon mal eine Art Wirtschaftssimulation begonnen und gemerkt dass es gar nicht soo leicht ist, die ganzen Dinge miteinander zu verknüpfen. Auch ich hatte da mit Events gearbeitet und sie für schlecht befunden! Also an sich ist das mit den Events schon klasse, wenn andere Systeme einfach nur drauf hören sollen. Sobald es aber (wie bei dir) hin und her geht, der Sender also auch ein Empfänger sein kann, wird es kompliziert. Ich denke, dass es nicht so viel Sinn macht alles in klitzekleine Module aufzuspalten, die dann alle miteinander kommunizieren müssen. Das hier würde ich anders machen: Der Market muss nicht beschrieben werden. Er ermittelt einfach, anhand der Anzahl der verfügbaren Dinge, einen Preis. Dieser Preis ändert sich nicht sofort bei jeder Transaktion, sondern erst nachdem der Besuch im Markt beendet wurde (oder nach einer gewissen Zeit danach). Also erst danach gibt es ein Event, damit der Market neue Preise generieren kann. Klar, wenn irgendwie neue Ware von woanders her rein kommt, kriegt er auch ein Event. Die Reputation ist eine Eigenschaft des Players, die sich ja beim Handeln normalerweise nicht verändert. Also muss sie bei Handelsbeginn einmalig abgefragt werden und als Berechnungsgrundlage für die Marktpreise einfließen. Inventory ist natürlich auf beiden Seiten wichtig. Der Mart hat eins und der Player auch. Bei jedem Kauf bzw. Verkauf ändern sich sofort auf beiden Seiten die Werte. Das Inventory des Players informiert also das Inventory des Marktes und umgekehrt. Nach verlassen des Shops werden die neuen Daten abgelegt und der Market bekommt ein Event, dass er die Preise neu berechnen kann. Jetzt "könnte" auch ein Event dafür sorgen, dass die Reputation sich verändert. Also: Market (readOnly) berechnet nur Preise anhand der Verfügbarkeit und der Reputation. Immer wenn sich das Warenlager verändert (oder zyklisch nach gewisser Zeit), entsteht ein Event, welches zur Neuberechnung der Grundpreise führt. Dieser Grundpreis wird über die Reputation des Players verändert. Markt schaut also in sein Lager und begutachtet sich den Player. Das macht er aber nur, wenn der Markt betreten wird. Reputation (read/write) wird vom Market ausgelesen und von anderen Dingen beschrieben. Wobei meiner Meinung nach der Handel nicht dazu gehört. Aber selbst wenn, dann erst nachdem der Markt verlassen wurde. Inventory (read/write) Liest zu Beginn die Daten aus dem Datenmodul aus. Es wird sofort nach jeder Transaktion verändert. Zum Inventory gehört wahrscheinlich auch das Geld. Ist also eine Ware nicht mehr verfügbar oder reicht das Geld für die gewünschte Transaktion nicht mehr aus, kann nicht gehandelt werden. Ob du jetzt auch noch irgendwelche Dialoge mit dem Händler führst, die einen Handel auch unterbinden könnten, weiss ich ja nicht. Ich gehe mal davon aus, dass das mit gescheitertem Hnadel meinst. Nach verlassen des Marktes werden die neuen Inventory-Daten dem Datenmodul übergeben. Fazit: Hier würde jetzt der Market nur aktiv werden, wenn der Player den Shop betritt. Er bekommt ein Event zur Neuberechnung und diese berechneten Werte können dann angezeigt und genutzt werden. Markt gehört dann wohl in den View Layer (auch wenn er rechnet). Die Reputation wird nur ausgelesen. Könnte aber nach verlassen des Shops ein Event bekommen um sich zu verändern. Das Inventory füllt sich beim betreten des Shops mit Daten. Jeder Handel, verändert diese Daten. Beim verlassen des Shops, wird das Datenmodul mit den veränderten Daten beschrieben. Viele Events würde es also nicht geben. Jedenfalls würden sich die Events nicht gegenseitig behindern. Wie du das jetzt in dein Blockschaltbild einbaust, musst du selber raus finden.
  9. Ich glaube das ist eher eine Frage der Philosophie. Ich persönlich habe keine signifikanten Performanceveränderungen zum alten System festgestellt. Aber das wichtigste an dem neue System ist die Tatsache, dass ich irre viel Zeit für die Entwicklung spare sobald es mal mehr als 3 Animationen sind. Und es werden garantiert mehr als 3 Animationen.
  10. Willst du echt das uralte Animationssystem nutzen und mit Animationsclips arbeiten? Das willst du nicht! Nutze den Animator Controller! https://docs.unity3d.com/ScriptReference/Animator.html https://docs.unity3d.com/Manual/Animator.html Es gibt unendlich viele Tutorials dazu im Netz und er ist auch leicht zu bedienen. Der Animator ist eine Komponente, die deinem Gameobject, welches irgendwas animieren will, hinzugefügt werden muss. Wie welche Animation abgespielt werden soll, stellst du im Animator ein. Dafür gibt es ein eigenes Fenster in dem du deine Animationen arrangierst und Mit Transitions verbindest. Die Transitions, also die Bedingungen um von einer Animation zur Nächsten zu gelangen, stellst du ganz einfach nach eigenen Wünschen ein. Du musst lediglich ein paar Parameter im Animator erzeugen, und sie vom Code aus ansprechen. Und wenn eine Animation gestoppt werden soll, dann hält sie eigentlich nicht an, sondern geht in eine andere Animation über. Also von einem State zum anderen. Ja und da reicht es schon aus, einen leeren State zu erstellen. Dafür musst du natürlich, eigentlich wie immer, ersteinmal den Animator bekannt machen, also eine Referenz bilden. public Animator myAnim; // Animator einfach hier rein ziehen Und im Code kannst du dann ganz leicht den Parametern im Animator gewisse Werte geben. myAnim.SetBool("walk",true); // oder myAnim.SetTrigger("stop"); Das sind jetzt nur Beispiele. Die Art des Parameters (trgger, bool, int, float) und dessen Namen musst du natürlich selber einstellen.
  11. Ja, du must selber rausfinden, von wo her die void angesprochen wird. Wenn das Script von dir ist, solltest du wissen, wo es her kommt, denn dann hast du die void ja nicht ohne Grund da drin. Wenn es nicht von dir ist, dann musst du dich durch die anderen Scripte pflügen. Es wird irgendwo beim Charactercontroller zu finden sein, schätze ich.
  12. Es kommt jetzt ein wenig darauf an, welche Rendermethode du nutzt. Auf jeden Fall musst du deinem UI Canvas auf "World Space" im Rendermode einstellen. Jetzt ist die UI wie ein 3D Objekt im Raum. Du kannst sie wie jedes andere Objekt imRaum bewegen und auch ausrichten. Jetzt brauchst du eine 2. Kamera, die in der Culling Mask nur die UI drin hat. Die 2te Kamera ist der MainCamera untergeordnet, damit sie sich mit dreht und sollte auch das gleiche FOV haben, wie die erste Kamera. Wenn du das herkömmliche Rendermodell nutzt, dann müstest du eigentlich nur bei der Hauptkamera bei Cullingmask die UI raus nehmen und bei Depth die Kameras so einstellen, dass die UI Kamera eine höhere Depth hat, als die MainCamera. Nutzt du die neuen Renderpipelines, dann ist das etwas anders. Hier musst du die UI Camera beim RenderType auf Overlay einstellen. Bei der MainCamera musst du in dem neuen Bereich "Stack" jetzt die UI Kamera einfügen. Du hast also bei beiden Modellen eine neue Kamera drin, die immer in die selbe Richtung wie die Main Camera guckt. Die MainCamera rendert jetzt aber nichts mehr, was den Layer UI hat. Die neue Kamera rendert nur noch den UI Layer. Die neue Kamera liegt über der MainCamera, was du entweder über den Wert Depth einstellst, oder indem du ein Stack bei der MainCamera erstellst und dort die UI Camera einfügst. Je nach Rendermodell.
  13. Ok. Dann musst du mal schauen, von wo aus in diese void rein gesprungen wird. Also bei welcher Bedingung das passiert. Kommt das vom CharacterController? Wird da evtl. eine Joystickachse abgefragt? Irgendetwas scheint genau an dem Punkt zu sein wo Crouching von true auf false geht. Du musst jetzt raus finden was das ist. Es kann von einem Eingabegerät, z.B.einem Joystick, kommen, es kann aber auch eine Entfernungsmessung mittels Raycast sein. Dein Animator macht jedenfalls keine Probleme, denn er verarbeitet nur die Signale die von außen rein kommen. Das macht er genau so, wie es sein soll. Die Signale sind das Problem!
  14. Ah, ja klar! Das hatte ich vergessen. Gut, dass du es gefunden hast.
×
×
  • Create New...