Sascha

+ "" erzeugt auch etwas Garbage. Wenn man also nur umwandeln und nicht konkatenieren will, ist ToString sogar etwas besser

Bei TextMeshPro als Typ immer die Typen nehmen, die mit TMP_ anfangen. Sollte für normale Texts, wenn ich mich recht erinnere, TMP_Text sein.

Kommt zu 100% auf deinen Hoster und dein Setup dort an. Die meisten Webhoster bieten PHP an, aber Web Backends kann man mit so ziemlich jeder Sprache machen. Musst dich mal informieren, was dein Hoster dir so anbietet.

Du kannst nicht einfach Dateien auf deinem Webserver überschreiben. Du brauchst Code auf dem Server, der die Daten entgegen nimmt und in eine XML-Datei speichert. Jedem dahergelaufenen uneingeschränkt Zugriff auf Dateien auf deinem Server zu geben wäre auch wirklich keine schlaue Idee

Layer scheinen mir schon sinnvoll dafür, damit du die Animationen kombinieren kannst. Man könnte jetzt natürlich überlegen, für jeden der Raketenwerfer ein eigenes Objekt mit eigenem Animator zu machen, aber Layer sollten auch gehen. Davon unabhängig ist Macanim aber schon dafür gedacht, dass du Parameter benutzt statt Play(). Dann kannst du auch vernünftig Transitionen zur Laufzeit debuggen.

Nimm statt WWW bitte UnityWebRequest. Ist ein bisschen schwieriger am Anfang, aber WWW ist veraltet. Generell ist die Antwort aber ja: Beide können POST-Anfragen schicken, mit denen du Daten übermitteln kannst.

Moin! So ohne Infos, wie du das gemacht hast (wie sieht dein Animator aus, wie sieht dein Code aus...) kann man dir da so ungefähr gar nicht helfen.

Wie du dein Backend schreibst, ist egal. php ist eine von viele Sprachen, mit denen du einen Webserver schreiben kannst, MySQL ist für Datenbanken. Die brauchst du nicht unbedingt um XML-Daten bereitzustellen. Was du brauchst, ist Code in deiner App, die nicht auf der Festplatte nach einer Datei sucht, sondern eine HTTP-Anfrage sendet und die Antwort empfängt. Da kann der StreamReader wohl auch irgendwie helfen, aber in Unity nimmst du dafür einfach den guten UnityWebRequest.

Sorry, mit Inkscape-Import kenne ich mich nicht aus. Uniforme Skalierung ginge jedenfalls und macht in vielen Fällen keine Probleme. DIe non-uniforme ist aber fast immer auffällig, wenn man untergeordnete Objekte hat. Ob du das in deiner Vektorgrafik, im Importer oder per Hand am importierten Objekt reparierst, musst du für dich herausfinden.

Das liegt daran, dass dein "Inky"-GameObject skaliert ist. Das Objekt wird dann erst gedreht und dann nach unten gestreckt, was ja aber dann nicht mehr "unten" aus Sicht des Sprites ist. Deshalb niemals einen Parent skalieren. Und schon gar nicht non-uniform (also unterschiedliche Werte auf den Skalierungsachsen). Es sei denn, du willst genau so etwas erreichen.

Sag ich ja. Es gibt aber keine Prefabs in einer Szene. Prefab = GameObject in den Assets. Wenn du ein Prefab in deine Szene ziehst, hast du eine Prefab-Instanz.

Vielleicht habe ich den hier beschriebenen Bug nicht ganz verstanden, aber... mein Bug Report bezog sich auf zwei unterschiedliche GOs: Das Prefab und die Prefab-Instanz. Die Instanz referenziert ein Prefab (also ein anderes GO), aber die Referenz ändert sich dann beim Start des Play Modes. Wenn man ein Prefab instanziiert, müssen natürlich alle Referenzen auf irgendein Objekt des Prefabs durch die äquivalenten Referenzen der Instanz geändert werden; ganz klar.

Du kannst auch eine "normale" C#-Klasse schreiben, die dann nicht als Komponente auf ein GameObject gezogen werden kann. Unabhängig davon kannst du zum Programmstart etwas ausführen mit [RuntimeInitializeOnLoadMethod] private static void Initialize() // Methodenname egal { // Zeug zum Programmstart hier hin } in einer (oder auch mehreren) beliebigen Klasse(n).

Moin! Pakete (sag ich lieber statt "Asset", weil ein Asset eine einzelne Datei ist) können unterschiedlich komplex sein. Ich hab schon ein Paket mit nur einem Script in den Asset Store gestellt; das hast du draufgezogen und dann hat es das gemacht, was du im Asset Store gesehen hast. Mein aktuellstes und Paket dagegen hat über 70 Klassen und ist dafür da, eine bestimmte Projektarchitektur besser verwenden zu können. Man sollte dafür also wissen, was man damit tun will, und wie. Entsprechend habe ich dafür eine ausführliche Anleitung geschrieben (aktuell 45 Seiten, wächst aber demnächst nochmal), habe eine API-Dokumentation generiert und Demo-Projekte gebaut, mit denen man das alles anschauen, erforschen und verstehen kann. So ein kompliziertes Paket, das dir aber nicht genügend Dokumentation gibt, um damit auch zu arbeiten, ist nicht viel wert. Das kannst du dann schlecht bewerten oder sogar dein Geld zurück verlangen. "Yippi Kawaii" ist aber kein kompliziertes Paket - es ist ein Paket mit 3D-Modellen und Animationen. Die Scripts, die du dabei hast, dienen daher nur dafür, die beigelegte Demo-Szene, zu befeuern. Unity schreibt vor, dass Pakete mit Art Assets so eine Demo-Szene haben müssen, in der die Inhalte präsentiert werden. Der beigelegte Code ist dafür da, dass in dieser Demo-Szene auch etwas passiert. Du kannst ihn dir anschauen und ihn ggf. als Vorlage für deinen eigenen Code sehen, aber er ist nicht dafür da, dass du ihn in deinem Projekt verwendest. Deshalb wird er auch kaum dokumentiert sein und sich schlecht in andere Systeme einbinden lassen.

Ich finde Unity als Programmier-Lernumgebung auch super. Aber das ist für jeden unterschiedlich.