malzbie

Ich verfolge diese Diskussion schon eine Weile und ich weiss eigentlich immer noch nicht was genau das Problem ist. Mir kommt es aber so vor, als würdest du, @nordseekrabe, versuchen ein Scriptable Object (SO) wie ein normales Objekt zu nutzen. Das ist es aber nicht! Ein SO ist eigentlich nur ein Container mit diversen Dingen drin. Das muss schon an ein Game Object angehangen sein. Du willst scheinbar das SO in dein Inventory rein bringen und natürlich auch wieder instanzieren, obwohl es kein eigenständiges Objekt ist. Also, du hast da scheinbar Puzzleteile und über das SO gibst du jedem Puzzleteil seine Eigenschaft. Das könnten der Name des Teils, das Icon fürs Inventory, ein Gewicht und die Eigenschaft "stackable" sein. Dieses Puzzleteil ist jetzt also ein 3D Objekt, welches im Inspector ein SO bekommen hat. Daraus machst du ein Prefab. Diese zuvor erzeugten Prefabs (je Puzzleteil ein eigenes Prefab) nutzt du dann in deinen Szenen. Dieses Prefab kannst du jetzt anklicken und aufnehmen. Dabei werden die nötigen Eigenschaften des SOs "ausgelesen" und fürs Inventory genutzt. Das Prefab wird danach zerstört. In deinem Inventory könnte für jeden Slot auch ein SO als Eigenschaft genutzt werden, welches die ausgelesenen Daten aufnimmt. Es könnten aber auch Arrays, Listen oder Dictionarys genutzt werden. Worauf es ankommt ist, dass du nicht das SO des angeklickten Objektes da rein legen kannst und dabei sogar eine Eigenschaft überschreibst. Klar, du kannst Variablen de SO überschreiben. Aber jedes Objekt, welches "dieses" SO angehangen hat, bekommt dann "diesen" neuen Wert, denn ein SO ist keine Instanz. Willst du in deinem Inventory für jeden Slot ein SO nutzen, welches dann ja immer neue Werte bekäme sobald du ein Slot leerst oder einen anderen Slot stackst oder einfach nur Objekte im Inventory austauschst, dann muss für jeden Slot ein eigenständiges SO genutzt werden, denn das Ändern von Werten im SO wirkt sich auf alle Objekte aus, die dieses SO haben. Willst du in deinem Spiel auch wieder Objekte instanzieren, also aus dem Inventar wirder in die Szene bringen, dann nutzt du die vorgefertigten Prefabs dafür. Dann ist da wieder ein Gameobjekt mit angehangenem SO, welches genau so funktionieren wird, wie es gewünscht ist. Es kann jetzt natürlich sein, dass ich dein Thema verfehlt habe. Aber ein Versuch war's wert.

Schöne und interessante Morgenlektüre. Das Nested Worker Singleton ist nicht schlecht. Muss ich mal testen.

Ich habe nur mal kurz in dein Video rein geschaut, weiss jetzt also nicht, ob du die Bewegung über die Animation haben willst, oder ob das Kerlchen eben auf der Stelle laufen soll und du die Bewegung dann per Script selber erstelen willst. Z.B. mit Rigidbody.AddForce. Es gibt da jetzt viele Dinge die sein könnten. Aber! Ich hatte vor vielen Jahren mal eine Tutorialreihe zur Animation mit Mecanim und das Einbinden von MoCap Animationen gemacht, als das noch ganz neu war. Heute ist immer noch vieles ganz genauso wie damals. Gerade der Part, wo man die Animationstakes anpasst, damit er läuft und dabei auch in der Spur bleibt, könnte dich interessieren. Ich hänge dir mal hier den Part 2 der Reihe an. Da erzähle ich einiges darüber. Wie gesagt ist lange her und einige Dinge sind in Unity jetzt etwas anders oder an anderer Stelle zu finden.

Ich kann mir noch nicht so richtig vorstellen, wie du das genau gemacht hast. Kannst du mal ein zwei Bilder von den Takes zeigen und dann was in Unity raus kommt? Dann kann ich mal was nachbauen und einfach selber mal testen. Da du leere Spuren siehst, sollte es auch möglich sein alles rüber zu kriegen.

Ich wüsste jetzt nicht wie.... Ich weiss auch gar nicht, ob das jetzt ein FBX Problem ist, oder von Unity so importiert wird.... Hmmm. Wäre es zu viel Aufwand die Einzelteile mit eigener Animationsspur einzeln zu exportieren und in Unity dann zusammen zusetzen?

Ich tippe mal darauf, dass WebGL nicht alles unterstützt, was du normalerweise mit dem Post Prozess erreichen willst. Da du jetzt Global ausgeschaltet hast, wirkt sich der Post Prozess eben nicht mehr auf die ganze Szene aus. Fehlermeldung ist zwar weg, aber auch kein Post Prozess mehr da. Ganaues weiß ich auch nicht. Aber es gibt im Unity eigenen Forum einen Beitrag, der sagt, dass Post Processing nur mit WebGL 2.0 funktioniert. Kann dein Browser das? Ganz unten im Thread ist ist dann noch eine Seite verlinkt, die einige Tipps beinhaltet. Schaus dir mal an und berichte, ob der Thread dir weiter geholfen hat. https://forum.unity.com/threads/urp-webgl-and-post-processing.904226/

Hi! Da deim Player und auch der Background (und sowieso jedes GameObject) eine Transform komponente haben, kannst du ganz einfach die Positionen der Objekte auslesen und nutzen. Es gibt jetzt viele Möglichkeiten um die 2 Objekte miteinander kommunizieren zu lassen. Aber egal wie, ein Objekt muss ein anderes kennen um Daten abzufragen und zu manipulieren. Ich zähle mal ein paar Möglichkeiten auf: 1. Beide Objekte sind zu Beginn in der Szene und beide Objekte werden nie zerstört. Dann kannst du entweder bei Objekt Background eine public Transform Variable erstellen und den Player im Inspector das rein fallen lassen. Diese Referenz kann dann der Background abfragen und sich anhand der Werte selbständig anpassen. Du kannst das auch andersherum machen, indem der Player eine Transform Refernz vom Background hat, diese würde dann vom Player aufgrund seiner eigenen Position angepasst werden. 2. Es gibt ein Vermittlungsscript auf irgendeinem Objekt in der Szene, wo der Player seine Y Position in eine öffentliche float Variable rein schreibt und der Background diese Variable für seine eigene Positionsänderung abfragt. In diesem Fall müssen beide Objekte dieses Vermittlungsscript kennen, also eine ReferenzVariable dafür haben. Wenn der Player innerhalb dieser Szene zerstört werden kann und neu instanziert würde, dann muss der Player natürlich immer beim entstehen nach diesem Script suchen und selbstständig die Referenz bilden. Das kannst du dann nicht im Inspector per Hand festlegen. 3. Fast wie bei 1. aber der Player kann im Spiel zerstört werden und wird dann wieder Instanziert. Jetzt ist da das Problem, dass der ursprüngliche Player weg ist und als neues Objekt wieder entsteht. Eine Referenz vom Player ist somit verloren gegangen und falls der Background eine Referenz vom alten Player hatte, wird eine "Null Referenz Exception" als Fehlermeldung kommen, denn das Objekt von dem du die Position wissen willst existiert nicht mehr. Hier bietet sich an, dass der Player, immer wenn er entsteht, sich eine Referenz vom Backgroundscript bildet. Ja, von einem Script und nicht von der Transformkomponente. Ich gehe davon aus, dass dein Background zu Beginn nicht die selbe Y Position wie den Player hat. Du also einen Versatz (offset) zwischen den beiden Objekten. Dein Background Script bekommt jetzt eine öffentliche Methode, in die das Playerscript rein springen soll. Damit es das kann muss es das Script erst einmal in der Szene finden und referenzieren. Das geht recht leicht, wenn dein Background einen Tag hat. Wie das in den Scripts aussieht zeige ich gleich. Jedenfalls sucht der Player einmalig nach dem Backgroundscript und springt dann in jedem Updatezyklus in die Methode vom Backgroundscript rein um seine Y Position zu übermitteln. In der Methode vom Backgroundscript wird der übermittelte Wert genutzt um seine eigene Y Position an die Y Position vom Player anzupassen. Beim allerersten Mal ermittelt diese Methode auch diesen Offset, der dann immer bei der Verschiebung mit berücksichtigt wird. So, hier die Einträge im Script für den Background. bool hasOffset= false; // diese Variable wird nach dem ersten Empfangen auf true gesetzt float myOffset; // hier steht dann der Unterschied der beiden Objekte in der Y Position drin. public void SetPlayerY(float playerYPosi){ // der Player wird hier rein Springen und einen Wert übergeben if(!hasOffset){ // nur beim ersten Mal machen, deswegen wird das gleich auf true gesetzt. myOffset = transform.position.y - playerYPosi; // Unterschied ermitteln. hasOffset = true; } Vector3 myNewPosi= transform.position; // kurz meine Positionswerte ermitteln myNewPosi.y = playerYPosi + offset; // den Y Wert verändern transform.position= myNewPosi; // Der Transform Komponente die neue Position übergeben } Und hier das Playerscript, welches an den Background was senden soll: backgroundScript theBackground; // backgroundScript ist nur ein Beispielname. Musst du so ändern, wie dein Script heißt void Start(){ theBackground = GameObject.FindGameObjectWithTag("Background").GetComponent<backgroundscript>(); // einmal nach dem Obj mit dem Tag suchen und das Script verknüpfen if( theBackground == null){ Debug.LogError("kann das Background Script nicht finden!"); } } void Update(){ if(theBackground != null){ theBackground.SetPlayerY(transform.position.y); // bei jedem Update meine Y Position an die Methode im BackgroundScript übergeben. } } Das ist alles. Der Player sagt dem Background einfach wo er sich auf der Y Achse im Raum befindet und der Background passt sich diesem Wert an. Das ist nur ein Beispiel ohne, dass ich es getestet habe. Könnten also Fehler drin sein. Gerade beim Offset bin ich mir nicht 100%ig sicher...sollte aber gehen. Trotzdem wird es dir helfen. Wie du dass dann machst, ist egal. Hauptsache du verstehst wie es geht.

Gerne.

Hi! Die Time.deltaTime gibt die einen Zeitwert zurück, der zwischen 2 Frames vergangen ist. Also nachdem alles Mögliche berechnet wurde und dann alles schön dargestellt wurde. Das wird dazu genutzt um alles schön gleichmäßig zu bekommen. Egal, wie schnell der Rechner ist und egal was der Rechner noch so tut. Damit das funktioniert muss die deltaTime natürlich in jedem Updatezyklus auch ermittelt bzw. genutzt werden und nicht nur einmalig beim Start. Da du deine zufällige xAenderung beim Start einmalig mit der deltaTime multiplizierst, ist dieser Wert dann in der Update eine Konstante. Startest du das Game und hast in Unity mehrere Ansichten auf, dann muss unity ganz viele Dinge doppelt machen und das verlangsamt das System. Im Vollbildmodus braucht es ganz viele Dinge nicht tun und dadurch wird es schneller. Deswegen hast du bei den unterschiedlichen Ansichten auch unterschiedliche Geschwindigkeiten, weil die ermittelte Zufallszahl unterschiedlich groß ist, denn die deltaTime ist je nach Modus unterschiedlich groß. Je schneller ein Frame abgearbeitet wird umso kleiner ist die deltaTime und umgekehrt. Du musst also die deltaTime aus der Start raus nehmen und dafür in der Update nutzen. In der Start schreibst du : xAenderung = (Random.Range(0.4f, 0.8f)) ; // hier nimmst du die deltaTime weg und in der Update: float xNeu = transform.position.x + xAenderung * Time.deltaTime; // hier fügst du sie an, damit xNeu immer auf die Framerate angepasst wird. Jetzt sollte die Bewegung immer gleich sein, egal ob Vollbild oder nicht. Wenn es jetzt insgesamt zu schnell oder zu langsam ist, musst du noch die Werte anpassen oder einfach mit einem weiteren Wert multiplizieren. Time.deltaTime kannst du gleichsetzen mit pro Sekunde. deine Position auf der x Achse wird also um xAenderung pro Sekunde verschoben. Vielleicht hilft das.

Dein Screen Befehl ist schon ok, aber das wirkt sich nur im Build aus. Im Editor siehst du immer nur die Auflösung die du gerade fährst. Du kannst dir aber im Szeneview unterschiedliche Auflösungen einstellen und die dann auch nutzen. Da siehst du dann wenigstens, was man im Spiel sehen würde, wenn die Auflösung direkt angezeigt würde. Da kannst du auch Ratios einstellen, sowas wie 4:3. Das ist im Endeffekt, das gleiche wie deine Auflösung, aber da geht es dann eben um das Format. Es gibt ja auch unterschiedliche 16:9 Auflösungen (HD, UHD). Wenn du die Auswirkungen der Auflösungen richtig erleben willst, musst du ein Build erstellen. Im Editor wird das alles nur simuliert.

Ich habe mir jetzt das Tutorial nicht angeschaut und jetzt auch nicht genau geschaut, was du so machst, aber ich kann dir sagen wie ich es mache. In der Klasse (in dem Script) wo das JSONUtility ausgeführt wird, müssen public Variablen liegen, die die Werte, die gespeichert werden sollen, beinhalten. Der Variablenname wird zum Schlüsselname im JSON File und der Wert der Variable wird dann zum Wert im JSON. Warum diese Variablen public sein müssen, weiss ich nicht, aber ohne macht er es nicht. Es sollte auch so gehen, wie du es versuchst, die Daten von wo anders zu holen, aber da hatte ich auch Schwierigkeiten. Ich sammle meine Daten auch in einem anderen Script und muss die Daten dann ins LoadAndSave Script rüberholen um die Werte zu speichern. Genau so muss ich beim Laden der Werte, diese dann in mein anderes Script übergeben. Ich nutze StreamReader und StreamWriter um den JSON String abzuspeicher und zu laden. Die JSON Funktionen die ich nutze sind: .toJson() und .fromJsonOverwrite() So mache ich das: using System.Collections; using System.Collections.Generic; using UnityEngine; using System; using System.IO; public class LoadAndSaveGame : MonoBehaviour{ StreamReader str; // der Reader fürs Einlesen string inhalt; // der erzeugte String zur Übergabe an JSON StreamWriter stw; // der Writer fürs Speichern public int score; // irgend eine Variable // weitere Variablen //... public void SaveGame(string saveName){ string line = GenerateString(); // siehe unten //schreiben stw = new StreamWriter(Application.persistentDataPath + "/" + saveName + ".txt"); stw.WriteLine(line); stw.Flush(); stw.Close(); } public void LoadGame(string saveName){ // lesen str = new StreamReader(Application.persistentDataPath + "/" + saveName + ".txt"); inhalt = str.ReadLine(); MindUebergabe(inhalt); // siehe unten str.Close(); } public string GenerateString(){ score = mind.score; // Wert aus dem mind Script holen und meiner Variable übergeben // hier kämen dann weiter Variablen dran return JsonUtility.ToJson(this); // string wurde gebildet und wird zurück gegeben } public void MindUebergabe(string savedData){ JsonUtility.FromJsonOverwrite(savedData, this); // JSON holt sich die Werte aus dem String und setzt sie in die Variablen. mind.score = score; // Wert ins mind Script schreiben // ... } } Natürlich ist das doppelte Ablegen der Daten eigentlich blöd und ich hätte auch gleich die Variablen im LoadAndSave Script nutzen können.

Also ich glaube, dass deine Tortenstücke nicht alle am selben Punkt anfangen. Hast du Images verdreht oder ist der Start nicht bei 0°? Mach dir doch mal ne Pause rein, so dass du erkennen kannst, wie ein Image nach dem anderen entsteht. Dann wirst du den Fehler bestimmt finden.

Er meint, dass nicht gleichzeitig Sceneview und Gameview zu sehen sein sollen.

Das kannst du nicht sagen! Auch wenn ein Fehler nicht direkt mit dem Gezeigten zu tun hat, so kann sich dieser Fehler eben auf die Ausführung von anderen Codebereichen auswirken. Kümmere dich immer darum, dass keine dieser Fehler auftreten. Das ist die einzige Möglichkeit um sicher zu sein, dass alles sauber abgearbeitet wird. Denk immer daran, dass ein "index out of range" Fehler ein Build sofort beenden würde. Das ist also etwas Schwerwiegendes! Soviel zur Fehlersuche. Jetzt mal zu deinem Versuch das ats Tortendiagramm darzustellen: Wenn ich das richtig sehe, legst du mehrere Images übereinander und drehst die im 90° Winkel? das kann nicht gehen, wenn du eine ungerade Zahl an Stücken darstellen willst (außer die 1 natürlich). Das sind so Informationen, die uns weiter helfen würden! Ich hab gar nicht erkannt, dass du das mit dem Unity UI Image machst. Ja, das wird so nicht gehen. Das Einzige, was du machen kannst, wenn du denn das fillable Image als Grundlage weiter nutzten willst, ist, den Tortenstücken ihren eigenen Wert und die Werte der davor ermittelten Stücke ermitteln zu lassen. Den Wert der vorherigen Stücke ziehst du vom Vollkreis ab. Die Images bleiben in ihrer Ausrichtung wie sie sind. Beispiel: Du hast 3 Werte. Der erste Wert hat 25%. Der zweite Wert hat 60% und der dritte Wert hätte dann den Rest also 15%. Du brauchst eine Variable, die zu Beginn auf 0 ist und als Zähler dient. Du fährst deine Schleife ab und jedem Tortenstück wird der Wert des/der vorigen Stücke(s) abgezogen. Du hast einen Stapel Images, die von unten nach oben ihre Werte bekommen. Das erste Tortenstück hatte keinen Vorgänger, der Abzug (Zähler-Variable) ist also 0 und das Image bekommt somit einen Vollkreis. Der Wert dieses Stückes wird aber jetzt der Zähler-Variable übergeben. (25%) Das zweite Stück hatte einen Vorgänger, somit wird diesem jetzt der Wert des Vorgängers abgezogen. Es ist also zu 75% gefüllt (der erste Wert war ja 25%). Die Variable bekommt den Wert des aktuelle Trotenstücks übergeben. ( 25% + 60%). Dem letzten Stück wird auch wieder der Wert der Variable abgezogen und somit ist es nur noch 15% gefüllt (100%-85%). Da liegen jetzt also 3 Images übereinander. Ein Vollkreis unten, ein Kreis der zu 75% gefüllt ist in der Mitte und ein Kreis zu 15% gefüllt darüber. Für dich sieht es aber so aus, als wäre da ein 25% Teilstück linksoben, ein 60% Teilstück unten und ein 15% Teilstück rechtsoben. Wenn deine Torte die Werte der Reihe nach im Uhrzeigersinn darstellen soll, dann musst du .fillClockwise auf false setzen. Versuchs mal. Wenn du jetzt noch von groß nach klein sortieren willst, musst du vorher mittels eines Hilfsarrays oder einer Hilfsliste die Werte sortieren. Aber das sind Dinge, die später wichtig werden. Erstmal muss alles dargestellt werden.

Der Fehler unten in der Zeile sagt es dir eigentlich. Der Index ist außerhalb des Bereiches! Du fährst also eine Liste oder ein Array ab und bist über die Grenze hinaus gekommen. Sind die Längen von ImagePieChart und ValuesToSet gleich? Du gibst als index den Zähler i von ImagePieChart weiter und nutzt den dann beim Return ValuesToSet. Ich schätze der Index wird größer sein als ValueToSet Einträge hat. Das musst du mal vergleichen.

Ich möchte noch eine kleine aber entscheidende Ergänzung machen, da hier im Forum doch hauptsächlich Nutzer der Free Version unterwegs sind. Wer die Free Version nutzt, wird nun doch nicht auf die Erlöse des Spiels berechnet, sondern hier bleibt es beim Jahreserlös der Firma! Dieser Wert wurde auf 200.000$ im Jahr angehoben, Die Free Version hat dann also die Bedingungen, die die Plus Version momentan noch hat. So wie ich es verstehe, muss beim Überschreiten des Wertes dann ,wie zuvor, auf die Pro Version gewechselt werden. Das alles gilt aber erst mit der LTS Version, die in 2024 raus kommen wird. Das wird dann die Version 2023LTS oder später sein. Das Abschalten des Splashscreens bezieht sich auch auf diese Versionen. Wer also momentan die Plus Version nutzt, so wie ich, um das Unity Logo abschalten zu können, muss wohl auf die neue Version updaten, sobald das Plus Abo abgelaufen ist und man sein altes Spiel neu builden will. Hier ist die Tabelle mit den neuen Bedingungen: Ich persönlich bin recht zufrieden mit der Entscheidung. Was ich besonders gut finde, ist die Entscheidungsmöglichkeit entweder 2.5% des Erlöses zu zahlen oder aber die gestaffelten Cent-Beträge zu nutzen. Gerade die Devs, die Handyspiele machen und nur wenige Cent pro Spiel einnehmen, wären mit den festen Cent-Beträgen pleite gegangen. Aber auch alle anderen, die ihre Spiele für kleines Geld anbieten (1-5€), haben jetzt die Möglichkeit auf die 2.5% zu wechseln und einen besseren Schnitt zu gekommen. Klar, Unity hat Vertrauen verspielt und viele Studios sind jetzt erstmal weg. Alle anderen sind vorsichtig geworden und gucken sich schon mal nach Alternativen um. Mit der neuen Ankündigung kann man aber gut leben und weitere Änderungen werden in der nächsten Zeit wohl nicht zu erwarten sein. Man hat also eine gewisse Zeit lang etwas Sicherheit.

@Damon93 Laut jetzigen und geplanten Regeln nicht! Wie Sascha aber anmahnt, ist das Vertrauen in die Firma nicht mehr da. Natürlich könnten die ihre Bedingungen immer anpassen und neue Kriterien setzen. Aber: Dass Unity Geld von dir verlangen wird, ohne dass du Geld eingenommen hast, wird nicht passieren. Sowas ist rechtlich überhaupt nicht abzubilden und außerdem würde das deren komplettes Geschäftsmodell zerstören und mit einem Schlag zum Untergang von Unity führen. Unity hat mit dem letzten Move sowieso schon so viel zerstört, dass die Zukunft dieses Unternehmens recht ungewiss ist. Wie Sascha schreibt ist das Vertrauen in Unity mächtig zerstört worden und das lässt sich nur schlecht wieder herstellen. Die Geldpolitik ist nicht so problematisch. Das war zwar der Hauptgrund für den Shitstorm, weil total schlecht kommuniziert wurde und sogar die obrige Tabelle zu Beginn anders beschriftet war. Es war nicht klar, dass es um die Einnahmen eines Spiels geht und es war auch nicht klar ob dann jeden Monat alle Einheiten wieder gezählt werden. Da haben manche Leute ausgerechnet, dass sie Millionen zu bezahlen hätten! Da war schon was los im Netz. Nachdem dann aber raus kam, dass man die TOS auf GitHub gelöscht hatte, ist den Leuten aufgefallen, dass es um viel mehr geht! Die Statements der Spielefirmen drehen sich jetzt nur noch um das verlorengegangene Vertrauen. Man kann nicht einfach ein neues Modell erstellen, was rückwirkend greift, also alle älteren Unityversionen mit beinhaltet, und stillschweigend die alten Vereinbarungen dazu löschen. Selbst wenn Unity zurückrundern würde, werden sie den Schaden spüren. Viele größere Firmen werden sich von Unity trennen. Dier Börse sieht das ähnlich. Der Aktienkurs ist seiter der Ankündigung um rund 10% gefallen. Ich könnte wetten, dass die Datenschützer inzwischen Witterung aufgenommen haben und sich jetzt mal anschauen werden, wie Unity denn die Installationen von Spielen überwacht. Das wird spannend! Ich warte einfach mal ab. Ich habe aber auch schon überlegt zu wechseln. Es ist aber so, dass Unreal sein Augenmerk auf AAA gelegt hat. Tolle Sache, wenn man was mit hochauflösenden Landschaften und grandioser Beleuchtung machen will. Im 2D Bereich sind die aber schwach. Dazu kömmt die Programmierung in C++ oder mit Blueprint. Godot ist im 2D Bereich super, aber 3D is dafür mangelhaft. Dann haben die auch noch schwächen im Importbereich. Alles was es sonst noch so gibt, ist recht nieschig. Ein Wechsel kostet viel Einarbeitungszeit, die ich als kleiner Entwickler eigentlich nicht habe. Ich bin schon seit ende 2009 mit Unity unterwegs und bin inzwischen richtig gut damit. Bis ich so gut mit einer anderen Engine umgehen könnte, würde sehr lange dauern. Aber was soll's. Wenn's sein muss, werde ich auch wechseln.

Gerne!

Viele von euch werden es wohl mitbekommen haben. Unity ändert seine Preispolitik. Ab 2024 will Unity etwas vom Kuchen ab haben. Momentan ist es so: Man nutzt die Free Version von Unity. Bis zu einem Firmenverdienst von 100.000$ ist alles ok. Verdient man mehr, muss man eine Kaufversion erwerben. Man nutzt die Plus Version (kostet ~ 300€). Hier hat man bis zu 200.000$ keine Probleme. Verdient man mehr, muss man sich die Pro kaufen. Man nutzt gleich die Pro Version. Ab 2024 wird es so sein: Die Einnahmen sind jetzt nicht mehr auf die Firma bezogen, sondern auf das Spiel selbst. Egal welche Version man nutzt, die Einnahmen, die man mit einen Spiel generiert werden jetzt wichtig! Bei der Free Version gibt es eine Einnahmengrenze von 200.000$ (in den letzten 12 Monaten pro Spiel). Bei der Pro sind ein 1.000.000$ (in den letzten 12 Monaten pro Spiel). Zusätzlich zu den Einnahmen werden auch die Verkäufe des Spiels gezählt. Diese werden erst ab 2024 gezähl. Alles was davor Verkauft worden ist, soll nicht berücksichtigt werden. Es gibt ab dann keine Plus Version mehr. Nur noch die Free Version und die Pro bzw. Enterprise Version. Bei beiden Versionen gibt es einen Schwellenwert der verkauften Spiele, ab dem es überhaupt erst dazu kommen kann, dass Unity an dir mitverdienen wird. Die Free Version hat einen Schwellenwert von 200.000 Die Pro einen Wert von 1.000.000 Einheiten. Gezählt wird, wie gesagt ab dem Januar 2024 ab dann für immer. Was bedeutet das jetzt? Wenn ihr ein Spiel erstellt habt und es verkauft, dann wird jeder Verkauf gezählt. Sobald dieses Spiel irgendwann den Schwellenwert überschritten hat, ist eine Bedingung für den mitverdienst erfüllt. Ab jetzt wird geschaut ob ihr in den letzten 12 Monaten mehr als die Obergrenze verdient habt. Wenn nicht, müsst ihr auch nichts abgeben. Wenn es aber so ist, wird geschaut, wie viele Spiele ihr den letzten Monat verkauft habt. Und für jedes Spiel will Unity dann etwas von euch haben. Habt ihr die Free Version, dann müsst ihr (pro verkauftem Spiel im letzten Monat) 20 Cent bezahlen. Habt ihr die Pro Version, dann ist der Preis gestaffelt. Es fängt mit 15 Cent für die ersten 100.000 Spiele an und verringert sich dann auf 7 Cent und dann noch weiter. Die Enterprise hat noch billigere Tarife. Siehe Tabelle. Hier ein kleines Beispiel: Ihr habt die Free Version. Euer Spiel wurde insgesamt 210.000 mal verkauft. - Bedingung 1 ist erfüllt. Ihr habt damit in den letzten 12 Monaten 350.000$ eingenommen. - Bedingung 2 ist erfüllt. Im letzten Monat habt ihr 10.000 Spiele verkauft. Dann müsst ihr 10.000 * 0.2 = 2.000$ an Unity bezahlen. Im nächsten Monat wird wieder geschaut, wieviel ihr in den letzten 12 Monaten eingenommen habt. Seid ihr dann wieder über der Grenze, dann wird wieder geschaut, wieviele Einheiten verkauft wurden und von diesen Einheiten bekommt dann Unity wieder seinen Anteil. Fallt ihr aber aus der Obergrenze raus, weil die starken Verkaufsmonate jetzt länger als ein Jahr her sind, braucht ihr für dieses Spiel auch nichts mehr bezahlen. Ist das jetzt gut oder schlecht? Zum einen ist es gut, weil man jetzt pro Spiel berechnet wird und die Grenze nach oben geschoben wurde. Die meisten von uns werden niemals 200.000$ mit einem Spiel in einem Jahr einnehmen. Es ist aber auch schlecht, denn wenn man wirklich mal einen Glückswurf haben sollte und ein Spiel richtig abgeht, denn dann kann es richtig teuer werden. Den es ist ja so, dass Spiele von kleinen Studios für viel weniger Geld verkauft werden als die Spiele von den großen Studios. Es macht einen Unterschied, ob man die Einkommensgrenze mit ganz vielen billigen Verkäufen überschreitet, oder mit wenigen teuren. Wenn das Spiel 10$ kostete, dann sind 20 Cent pro Verkauf 2%. Bei 60$ sind es aber nur 0,3% ! Um die Einnahmengrenze zu sprengen muss man aber bei 10 Euro 6 Mal soviel EInheiten verkaufen. Und dies würde sich dann auch in der Kalkulation niederschlagen. Es ist also ein unfaires Prinzip, weil es nicht um den Preis einer Einheit geht, sondern nur um Summen. Was mich persönlich ärgert ist der Wegfall der Plus Version. Ich habe die eigentlich nur, weil ich das Unity Logo nicht im Intro haben wollte. 300€ waren ok. Aber knappe 2000€ für ne Pro zahle ich nicht. Jedenfalls nicht, wenn ich nicht an die Einnahmengrenze ran komme. Wenn ich da ran käme, dann würde ich die Pro kaufen, denn dann hätte ich die Grenze auf ne Million angehoben und da muss man erst mal hin kommen. Es gibt noch viele Unklarheiten, denn Unity sagt nicht, wie sie an die Zahlen der Einheiten kommt. Es ist klar, dass jedes Spiel an Unity was sendet. Aber was das alles beinhaltet weiß nur Unity selbst. Demoversionen sollen nicht mit einberechnet werden. Mehrfach installationen sollen auch nicht mit einberechnet werden. Wir werden sehen, was die Zukunft bringt.

Willkommen! Also: Die Transform.position ist die Position, die ein Objekt in der Szene hat. Der genaue Punkt des Objektes ist aber abhängig von dem Pivot. Also dem Achsenmittelpunkt des Objektes. Dieser Pivot muss nicht zwangsläufig in der Mitte eines Objektes liegen. Zur Transform.position gibt es auch noch die Transform.localPosition. Diese Position wird dir im Inspector angezeigt. Wenn ein Objekt ein Vaterobjekt ist, also keinem anderen Objekt untergeordnet ist, dann ist die die localPosition das gleiche wie die position. Ist das Objekt einem anderen Objekt untergeordnet, also ein Kind des Vaters, dann ist das nicht mehr das gleiche. die localPosition, die dir im Inspector angezeigt wird, bezieht sich jetzt auf den Vater. Wenn da also bei XYZ 0,0,0 steht, dann hat das Kind die gleiche Position wie der Vater. Steht da 0,1,0 dann ist das Kind um 1 auf der Y-Achse zum Vater verschoben. Hätte der Vater die Position 10,2,0 dann hätte das Kind die Position 10,3,0 im Raum. Also bei Y 1 mehr und das ergibt die 3. Ich sehe bei deinem Aufbau, dass deine Objekte verschachtelt sind. Es sind also alles Kinder vom Lückentext und einige dieser Kinder haben weitere Kinder. Die sind alsi für die weiteren Kinder der Vater. Wenn du jetzt ein Objekt per Drag aufnimmst und bewegen willst, dann wird im Code wahrscheinlich das Objekt an die Maus geschoben, weil es beim verschieben die Mausposition als eigene Position übergeben bekommt und der Pivot der eigenen Position ist wohl die obere linke Ecke. Wenn du den Pivot nicht verschieben kannst (Was bei UI elementen eigentlich geht), dann musst du einen Offset einbauen. Also den Unterschied der Mausposition beim Klick zur Position des Wortobjektes beim Klick merken und bei der Bewegung immer mit einberechnen. Objektposition = mausposition + Offset. Beim Ablegen übergibst du dem DragObjekt die Koordinaten der Lücke. Das ist eigentlich ok. Aber ich kann nicht sehen, ob deine Lücke vielleicht doppelt so hoch wie der Blaue bereich ist. Genauso kann es sein, dass dein Vaterobjekt oder irgend etwas anderes als Zielobjekt genutzt wird. Du musst dir mal anschauen, wo deine Pivots liegen. EInfach das Objekt anklicken und im Inspector schauen, wo das Koodinaten-Kreuz angezeigt wird. Vielleicht findest du da schon den Grund der falschen Position.

Gerne!

Ich habe das Toolkit System noch nicht verwendet, habe mich aber eben eingelesen und ein paar kleine Videos geschaut. Das was du das in dem Flex-Bereich einstellst ist erstmal nur für das Unterlement wichtig. Das hat nichts mit der Auflösung des Screens zu tun. Bei Toolkit ist alles verschachtet, also alles bezieht sich auf das Vater objekt, wie es scheint. Ja und da musst du ansetzen. Beim UGui System hast du ja den Canvas als Vater, bei dem du einstellen kannst, ob und wie die unterelemente skaliert werden können/sollen. Das ist beim Toolkit in den Panelsettings zu finden. Dort gibt es einen Scalemode und 2 Referenzfelder wo du DPI ( Dots-Per-Inch) oder ähniches einstellen kannst. Beim UGUI kannst du sagen wie er skalieren soll, wenn ein Screen von der Referenzgröße abweicht. Das sollte beim Toolkit genauso sein. Es gibt da die eine Einstellung, wo es um konstante Physikalische Größe geht und da hast du dann als Referenzwerte DPI. Hier werden dann die Bildpunkte festgelegt. Im Endeffekt ist das auch nichts Anderes, als wenn du 2 24 Zoll Monitore vergleichst, wo der Eine eine HD Auflösung hat und der Andere 4K darstellen kann. Der eine Monitor hat soundsoviel Dots pro Inch, der andere Monitor hat 4 mal so viel. Nimmst du als Referenz die HD Auflösung, wird beim 4K Monitor alles vergrößert. Wo vorher ein Pixel geleuchtet hatte, sind es jetzt 4. Es ist also alles genau so scharf bzw. grob wie vorher. Wenn du aber als Referenz eine 4K Auflösung nutzt, dann wird sie beim 4K Monitor auch super scharf daher kommen. Beim HD Monitor wird aber alles unschärfer, weil er viel weniger Bildpunkte hat und dann jeder Punkt einen Mittelwert zugewiesen bekommt. Das alles natürlich nur, wenn du über ScreenSize skalierst. Wenn du auf konstante Pixel Größe oder konstante physikalische Größe einstellst, dann wird die Ui abhängig von den Pixeln, die da sind, angezeigt oder aber abhängig von den Dots angezeigt. Viele Pixel oder Dots auf dem Display bedeutet, die UI Elemente sind kleiner. Weniger Pixel oder Dots, die Elemente werden größer sein. Also wenn auf jedem Handy alles ungefähr gleich groß zu sehen sein soll, dann musst du mit ScreenSize skalieren. Gleich groß bedeutet, dass auf jedem Screen die gleiche Information zu sehen ist. Hast du einen kleinen Screen, ist alles natürlich klein. Logisch. Wenn du Constant Pixel Size nimmst, dann werden immer die Pixel im Bezug zu Pixel per Unit gleich groß angezeigt. Das muss nicht mit den Bildpunkten deines Screens übereinstimmen. Wenn du Constant Physical Size nimmst, dann geht es um die echten Bildpunkte (DPI). Du kannst in Unity ja unterschiedliche Auflösungen für dein Gameview einstellen und auch neue hinzufügen. Nimm dir mal gängige Handys und guck, was die so für Auflösungen haben. Und dann teste mal.

Na siehste!

Du solltest einfach nur mal 1-2 Werte nehmen und damit versuchen, Balken zu bekommen. Dein Problem ist ja nicht die Daten auszulesen, sondern einfach nur Balken zu erzeugen, die vom Minimalwert zum eingelesenen Wert gehen. Dein erstes Diagramm hat ja gezeigt, dass deine Werte gut interpretiert werden. Ich kann dir nicht sagen, wie das machen kannst, weil ich mit den Tools wie Igraph noch nichts gemacht habe. Ich gibt aber ein Tutorial von CodeMonkey, der in seinen Videos zeigt, wie man unterschiedliche Graphen erzeugt. Diese Videos sind nicht besonders gut gemacht, weil er viel zu schnell da durch rammelt und nicht viel erklärt. Trotzdem kannst du da bestimmt erkennen, wie er die Balken erzeugt und worauf es ankommt. Übrigens: Dein Thementitel hat eigentlich nichts mit deinem Problem zu tun. Ein Titel wie z.B.: "Wie erstelle ich ein Balkendiagramm" wäre bestimmt besser gewesen.

Hmm... Du musst dich noch ein wenig einlesen. Es ist alles nicht so einfach, wie man zuerst denkt. Ich will mal ein paar Dinge erklären: Unity hat eine Physik Engine, die hauptsächlich mit Collidern, Triggern, Raycasts und vorallem dem Rigidbody funktioniert. Der Rigidbody ist die Komponente, die einen Collider bewegen kann, mit anderen Collidern kollidiert, Trigger auslöst und alle Kräfte ( Reibung, Federung, Masse, Beschleunigung im Raum) erst ermöglicht. Der Character Controller (kurz CC) ist "kein" Bestandteil dieser Physik. Er macht zwar ähnliche Dinge, die Auswertung der Kräfte erfolgt aber ganz anders und ist auch unvollständig. Trotzdem kann der CC auch mit Collidern zusammenstoßen und Triggerevents auslösen. Er kann auch springen. Er kann aber nicht von irgendeinem Kollider abgestoßen werden, nur weil dieser Collider ein Gummimaterial hat. Es gibt eine Möglichkeit um mit einem CC auch von einem RB abgestoßen zu werden. Dafür musst du eine gewisse Option aktivieren: https://docs.unity3d.com/Packages/com.unity.charactercontroller@1.0/manual/dynamic-body-interaction.html?q=physical material Wie gut das funktioniert kann ich nicht sagen. Aber im Text steht ja schon, dass es zu einem kleinen Lag kommen kann. Ob die Eigenschaften eines physikalischen Materials richtig ausgewertet werden, weiss ich nicht. Übrigens: selbst wenn ein Collider kein phys. Material zugewisen bekommen hat, so hat er doch default Eigenschaften. Einen CC mit einem Rigidbody zu kombinieren, ist meines Wissens keine gute Lösung, weil dann 2 Dinge verknüpft werden, die sich gegenseitig stören. Ich muss aber gestehen, dass ich im Bezug auf den CC nicht mehr auf dem neuesten Stand bin.