Jump to content
Unity Insider Forum

Leaderboard


Popular Content

Showing content with the highest reputation since 01/17/2019 in all areas

  1. 2 points
    In diesem Fall solltest du keine Liste benutzen, sondern ein Dictionary. Ein Dictionary ist ein Datentyp, bei dem ein Wert zu einem Schlüssel zugewiesen werden. Typ von Schlüssel und Wert kannst du dir aussuchen. Es erlaubt dir, den Schlüssel hineinzustecken und den entsprechenden Wert herauszubekommen. Du definierst es so: Dictionary<TKey, TValue> wobei TKey der Typ des Schlüssels und TValue der Typ des Wertes ist. Da der Typ deines Items "InventoryItem" ist und der Wert eine Zahl (die Anzahl) sein soll, muss das so aussehen: Dictionary<InventoryItem, int> storedItems = new Dictionary<InventoryItem, int>(); So fragst du die Anzahl ab: storedItems[ip] // z.B. Debug.Log("Ich habe " + storedItems[ip] + " Stück " + ip); Gleichermaßen kannst du die Anzahl setzen: storedItems[ip] = 100; Wenn du ein Item anfragen willst, das aber gar nicht in der Liste ist, dann kracht es. Deshalb gibt es TryGetValue, falls du dir nicht sicher sein kannst: int amount; if (storedItems.TryGetValue(ip, out amount)) { // Es gibt dieses Item im Dictionary Debug.Log("Ich habe " + storedItems[ip] + " Stück " + ip); } else { Debug.Log("Ich habe kein " + ip + " in meinem Inventar"); } Auf diese Weise kannst du auch Dinge hinzufügen oder wegnehmen: public void ChangeAmount(InventoryItem item, int changeAmount) { int currentAmount; if (storedItems.TryGetValue(item, out currentAmount)) { // Das Item gibt's schon im Inventar var newAmount = currentAmount + changeAmount; if (newAmount > 0) { // Ändere die Anzahö storedItems[item] = newAmount; } else { // Lösche das Item aus dem Inventar storedItems.Remove(item); } } else { // Das Item ist noch nicht im Inventar if (changeAmount > 0) { // Füge das Item in das Inventar hinzu storedItems.Add(item, changeAmount); } } }
  2. 2 points
    Programmieren seit ~20 Jahren. Unity seit ~10, glaube ich. Aber glaube nicht, dass du 10-20 Jahre brauchst, um "gut genug" zu sein. Du hörst nie auf, dich zu verbessern. Ich selbst habe mich gerade letzte Woche hier im Forum korrigieren lassen müssen, weil ich falsch lag Ob es realistisch ist, in einem Jahr ein Spiel zu releasen, und das auch als anfänger, hängt komplett von dir, deiner Lernfähigkeit und deinem Projekt ab. Flappy Bird klatsche ich dir an einem Tag hin. Rechne das mal X weil du noch dies und das lernen willst oder musst, um das zu implementieren, und du bist vielleicht bei einer Woche. Wenn dein Projekt allerdings keine Kleinigkeit ist, dann kann's auch mehr als ein Jahr dauern, egal, wie gut du solo bist. Ich sitze jetzt seit etwas über einem Jahr an meinem aktuellen Projekt. Da geht zeitweise schonmal die Motivation flöten und dann wird eine Woche lang eher nur gezockt... aber naja. Anderes Thema. Solange du an den Erfolg deines Projekts glaubst, wirst du auch Fortschritte machen. Als Anfänger würde ich vielleicht nicht unbedingt deine finanzielle Sicherheit von einem Traumprojekt abhängig machen, aber solange du dir die Zeit nehmen kannst, weiter zu arbeiten, wirst du auch immer weiter kommen. Und dich währenddessen weiterentwickeln und verbessern.
  3. 2 points
    Lasst uns das Thema nicht allzuweit von der ursprünglichen Frage entfernen, aber: Ich habe gehört, MEC soll ganz gut sein. Vor allem ist es kostenlos, also schadet's sicher nicht. Grundsätzlich gilt allerdings, dass man sich über Performance nicht zu viele Gedanken machen soll, bevor sie sich als Problem entpuppt. Für die drei Coroutines in einem kleinen Projekt also unbedingt MEC einzubauen, ist zwar kein Fehler, aber eben Zeitverschwendung. Bei weiteren Fragen, die nicht allzu viel mit der Frage von @cncrete zu tun haben, gerne ein neues Thema aufmachen
  4. 1 point
    Hallo zusammen, also ich entwickle grade einen "Trainings Simulator". Man kann dort mit einem Charakter in einem Fitnessstudio trainieren und durch Training verändert sich der Charakter. Das Spiel soll erstmal für Android veröffentlicht werden. Jetzt zur eigendlichen Frage. Da alle Information zum Charakter auf einem Server gespeichert werden kann ich auch alle Informationen der Freunde die man geaddet hat(Freundschaftsliste ingame) leicht anzeigen lassen. Aber im Spiel gibts noch die Funktion das man gegen Freunde Bankdrücken etc. trainieren kann um zu schauen wer stärker ist. Nun frage ich mich ob es überhaupt Sinnvoll ist, das noch irgendwelche Informationen von Freunden angezeigt werden sollen, weil man halt schon vorher erahnen kann wie gut der Freund ist... Oder sollte ich mich nur auf das nötigste beschränken und nur den Level des Freundes anzeigen lassen??
  5. 1 point
    Ja mit Blender könntest du es machen. In Unity könntest du ein empty game object erstellen und es an die Unterseite deines Diagramm Cubes positionieren. Dann fügst du das Diagramm Cube als child zum empty game object hinzu. Wenn du dann das empty game object skallierst müsste das Diagramm nur in eine Richtung skalieren. Das ganze kann man natürlich auch mit einem Script erstellen. https://i.imgur.com/TNiMvxM.gif https://stackoverflow.com/questions/39216454/scale-gameobject-on-just-one-side
  6. 1 point
    Hallo! Ja, indem du dir Programmierkenntnisse aneignest, während du daran arbeitest. Schritt eins: Genau das überlegen. Es gibt keine festlegbare "gute" Reihenfolge dafür. Deshalb ist der erste Schritt immer, die Gesamtaufgabe in kleinere Aufgaben zu zerteilen. Ein Issue Tracking-System hilft dabei sehr. Repository-Dienste (Github, Gitlab, ...) haben so etwas normalerweise schon für dich parat, aber wenn du dich noch nicht mit so etwas beschäftigen willst, kannst du auch einfach mit Trello anfangen. Wofür Tutorials da sind. Womit wir wieder bei Frage 1 sind. Du darfst einfach nicht erwarten, dass du dir ein Spiel, das nicht komplett von der Stange sein soll, einfach zusammenklicken kannst. Darfst nur so-und-so viel Geld verdienen mit deinem Spiel, darüber musst du die Pro kaufen. Ansonsten nichts nennenswertes.
  7. 1 point
    Ja du könntest die Namen Vergleichen. Wenn du nur wissen willst ob es überhaupt doppelte Einträge in einer Liste gibt kannst Distinct nutzen: if(list.Count != list.Distinct().Count) { //doppelte Einträge vorhanden } Distinct entfernt doppelte Einträge von der Liste. Mit LINQ kann man auch komplexere Abfragen erzeugen, kenne mich damit aber nicht aus. Hier: https://stackoverflow.com/questions/18547354/c-sharp-linq-find-duplicates-in-list
  8. 1 point
    Du kannst auch eine Suppe mit einer Gabel essen.
  9. 1 point
    Öh... habe schon mehrere Male etwas geschrieben, hab's dann aber wieder gelöscht, ohne es abzuschicken. Anstatt groß darüber nachzudenken, würde ich die Herangehensweise leicht ändern. public static int RandomWithSteps(int min, int max, int interval) { var range = max - min; var maxIntervalCount = range / interval; var intervalCount = Random.Range(0, maxIntervalCount + 1); return min + intervalCount * interval; }
  10. 1 point
    ScriptableObject brauchste nicht, du kannst eine Textur direkt als .asset-Datei speichern. AssetDatabase.CreateAsset(myTexture, "Assets/My Texture.asset"));
  11. 1 point
    Eine weitere Möglichkeit bei einem Invoke auf ein String zu verzichten ist die Methode nameof die es ab C# 6.0 gibt. Damit wird der Name der übergebenen Variable, Typ oder Methode als Zeichenkette zurückgegeben. Statt Invoke("ResetValues", 1) schreibt man Invoke(nameof(ResetValues), 1). So kann der Compiler die bei Invoke übergebenen Methode erfassen und die bereits genannten Schwierigkeiten vermeiden. https://www.heise.de/developer/artikel/nameof-Operator-in-C-6-0-2391981.html
  12. 1 point
    Die HLAPI von UNet wird zukünftig als externes Paket ausgelagert, und hat bis 2021 Support, aber keine neue Features. Die LLAPI wird im laufe des 2019.x Zyklus von Unity entfernt, sobald die neue API stabil genug ist. Eventuell gibt es einen Wrapper für die HLAPI. Die HLAPI wird nicht ersetzt, stattdessen wird es eine Reihe von Paketen geben.
  13. 1 point
    Hallo, Das liegt am FBX Exporter von Cinema. Ich mache es so: 1. Das Model unter Rendern> Objekt backen Backen. 2. Das gebackte Model als FBX Exportieren. In Unity die Gebackte Texturen importieren, dann ein neues Material erstellen die Texturen den Kanälen zuweisen und nun dem Model zuweisen und mit Apply bestätigen. Auf diese Weise funktioniert es bei mir sehr gut. Gruß Jog
  14. 1 point
    Es klingt zumindest logisch nicht ständig eine längere Suche durchzuführen. Vor allem wenn das eigentlich nicht zwingend so sein muss. In der Dokumentation schreibt Unity nur "For performance reasons, it is recommended to not use this function every frame". https://docs.unity3d.com/ScriptReference/GameObject.Find.html Ich arbeite aktuell an einem Lernprojekt und musste bisher kein einziges mal die Find Funktion nutzen. War bisher nicht nötig. Über ScriptableObjects und das Event System lässt sich das alles schön referenzieren bzw. Objekte miteinander kommunizieren. Übrigens nochmal danke für dein Architektur Repo! Ist sehr nützlich.
  15. 1 point
    Ich bin gar nicht mal so der Performance-Freak. Mein Hauptaugenmerk bei Code ist "Code-Qualität". Das beschreibt Vorzüge von Code, die über das reine Funktionieren hinausgehen. Wichtige Begriffe sind Lesbarkeit, Robustheit (dass man Code später ändern oder erweitern kann, ohne dass gleich alles kaputt geht), Modularität, und einige andere. Strings haben generell das Problem, dass es Werte sind. "Player" ist ein String, und "PIayer" ist auch ein String. Siehst du den Unterschied? Beim zweiten folgt dem "P" ein großes "i". Der Compiler merkt sowas, denn er ist ein Computerprogramm... aber eben nicht bei Strings. Anders z.B. Klassen- oder Methodennamen. Wenn du so etwas schreibst: GetComponent<Lighht>() oder GetComponnent<Light>() dann wird dein Code nicht kompilieren und du kriegst eine Fehlermeldung, in welcher Zeile du etwas geschrieben hast, das nicht existiert. Oft sagt dir der Compiler bei solchen Fehlern sogar, welches Wort genau er nicht erkennt. Bei Strings kann er das nicht, da es Werte sind, und alle Werte sind erst einmal korrekt. Dein Code wird also kompiliert und ausgeführt. Dann kommt es zu "GameObject.Find" und er findet das Objekt nicht. Vielleicht, weil du dich vertippt hast und es dir keiner gesagt hat, vielleicht aber auch, weil irgendjemand in der Szene den Namen des Objekts kürzlich geändert hat, weil der neue Name besser passt - und schon funktioniert dein Code nicht mehr (Thema Robustheit, s.o.). Aber es kommt noch schlimmer: Bei solchen Funktionen kriegst du das gar nicht unbedingt direkt mit, wenn kein Objekt gefunden wurde. Oft geben die Dinger einfach null zurück und sind glücklich. Krachen tut es dann erst, wenn du das Objekt benutzt. Dann hast du als Fehlermeldung, dass du mit dem Objekt etwas machen wolltest, das dir rausgesucht wurde, das aber nicht ging, weil keines vorhanden ist. Der Fehler passiert also nicht bei GameObject.Find, sondern irgendwo später. Und dann darfst du suchen gehen, wo der Fehler ist. Zusammengefasst also: Warum solltest du dir Fehler aufhalsen, bei denen du selber recherchieren musst, was los ist? Du hast eine mächtige Rechenmaschine unter deinen Fingern, die diese Aufgabe viel besser bewältigen kann als du. Du musst nur deinen Code so schreiben, dass sie ihren Job auch machen kann. Und es gibt immer elegante Wege, GameObject.Find zu ersetzen. Wenn du mal nicht weißt, wie, frage gerne nach Hast du das mal gebenchmarked? Ich wäre mit solchen Aussagen vorsichtig. Ich meine mich zu erinnern, dass Unity zumindest für Tags eine vernünftige Beschleunigungsstruktur im Hintergrund laufen hat. Aber wie gesagt... um Performance geht's mir sowieso nicht. Und deshalb stellt sich mir die Frage gar nicht erst, wenn diese Funktionen sozusagen schon "eine Runde früher ausscheiden".
  16. 1 point
    Was ist eigentlich hiermit. Auch empfehlenswert? https://assetstore.unity.com/packages/tools/animation/more-effective-coroutines-free-54975 http://trinary.tech/category/mec/ Time taken to execute 100,000 empty coroutines Unity's Built in Coroutines: 110.53ms MEC Free: 9.62ms
  17. 1 point
    Ja, hast recht, @Sascha. Ich habe garnicht darauf geachtet, dass die Spielzeit auf 0 gesetzt wird. Obwohl ich es ja selber geschrieben habe! War zu spät gestern.
  18. 1 point
    Ich glaube, die haben andere Prioritäten. Abhilfe ist halt schnell geschaffen, wie du selber sagst. Andererseits bin ich aber scheinbar auch etwas radikaler als die, was Code-Qualität angeht. Die sind inzwischen selber einigermaßen vom GameObject.Find(WithTag)-Kurs runter, aber das hat auch schon eine Weile gedauert. Ich glaube, das kam damals in den ersten Versionen von der JavaScript-Kultur, an der sie sich orientiert haben. Naja, langer Rede kurzer Sinn: Strings sind bäh. Außer zum Ausgeben. Ach ja, kleiner Nachtrag zu @malzbies Coroutine - Es gibt WaitForSecondsRealtime, damit wäre das ebenfalls eine funktionierende Lösung.
  19. 1 point
    Das ist interessant! Ich mache durchaus regen Gebrauch von Invoke. Hat die Methode mit dem String als Methodenname irgendein oder wieso haben die Unity Entwickler das nicht bisher verbessert wenn es doch offenbar ohne großen Aufwand besser geht?
  20. 1 point
    Invoke benutzt Time.deltaTime, welches als Faktor Time.timeScale hat, welches wiederum 0 ist. Anders gesagt: Du hast die Zeit angehalten - und du kannst keine 2 Sekunden warten, wenn keine Zeit vergeht. Invoke ist sowieso Käse. Die von @malzbie beschriebene Coroutine hilft hier leider auch nichts, da WaitForSeconds ebenfalls über skalierte Zeit läuft, aber Invoke setzt nochmal einen obendrauf, weil es strings benutzt. Ieh! Nimm stattdessen meine Invoker-Klasse, die gibt's hier: https://gist.github.com/FlaShG/09b80bbc02a4bb6f9e2dda23ff9c5f8d. Einfach komplett herunterladen und irgendwo in deine Assets packen. Benutzt du dann wie Invoke, nur ohne Strings. Und damit das in Echtzeit abläuft, habe ich gerade noch InvokeInRealtime eingebaut. Statt Invoke("Methode", 2f); machst du damit StartCoroutine(Invoker.InvokeInRealtime(Methode, 2f)); Beachte: Der Name der Methode jetzt nicht mehr in Anführungsstrichen. Ansonsten ist absolut richtig und wichtig, was @malzbie sagt - du musst nochmal über die ganze Sache rüberschauen, dass du den Invoke-Befehl nicht jeden Frame auf's Neue ausführst.
  21. 1 point
    Was willst du eigentlich erreichen? Der Text, wer gewonnen hat, soll eine gewisse Zeit sehen bleiben und dann weg gehen? Wenn ja, dann machst du da was falsch, denn die Update Methode wird jedes Frame aufgerufen. Sobald der linke oder der Rechte Player einen Punkt haben, wird jetzt jedes Frame das Canvas Objekt aktiviert, die Timescale auf 0 gesetzt und ein entsprechender Text übergeben. Du rufst auch jedes Frame den Invoke Befehl auf. Ob nun der rechte oder der Linke Player gewonnen hat, alles was innerhalb der If Abfrage steht sollte nur einmal ausgeführt werden. Also brauchst du eine boolsche Variable, die in der If Abfrage mit berücksichtigt wird. Du fragst also zusätzlich den Zustand dieser Variable ab. Z.B. ob sie false ist. Wenn es so ist, dann wird alles innerhalb der Abfrage abgearbeitet. Dort schaltest du diese eine Variable auf true, damit beim Nächsten Frame nicht wieder alles abgearbeitet wird. Denn nun ist sie ja nicht mehr false und die Bedingung ist nicht mehr erfüllt. Wenn du jetzt eine Coroutine starten würdest, anstatt einer Methode, dann könntest du dort einen Wartebefehl einstellen, der 1-3 Sekunden wartet. Erst nach dieser Wartezeit würde die Coroutine die weiteren Einträge abarbeiten. Ja und da würdest du dann das Canvas Objekt wieder deaktivieren und das machen, was danach passieren soll. bool showWinner=false; void Update(){ if(ball.scorePlayerLeft>=1 && !showWinner){ showWinner=true; canvas.SetActive(true); Time.timeScale=0; text,text="Player left won!"; StartCoroutine(WaitAndReset(1)); } } IEnumerator WaitAndReset(float duration){ yield return new WaitForSeconds(duration); canvas.setActive(false); Time.timescale=1; showWinner=false; // hier weitere Dinge einfügen, wie z.B. ein Laden einer neuen Szene. // oder evtl. die Punkte zurück setzen, denn der Score ist immer noch >=1. }
  22. 1 point
    Ich weis nicht genau, aber eventuell hilft es ein Empty Game Objekt zu erstellen, welches 3 Child Objekte hat: 1x das zu bewegende Game Objekt und 2x ein Game Objekt mit den Collider und dem dann entsprechenden Script, in dem zu mit Inspectorzuweisung das zu bewegende Game Objekt einbindest.
  23. 1 point
    ^ ist nicht das Zeichen für "Hoch", es ist das Zeichen für "xor". Potenzrechnung machst du in Unity mit der Mathf-Klasse: Mathf.Pow(4, 2); // 4 zum Quadrat
  24. 1 point
    Gerade unerfahrene Leute haben starke Bedenken, wenn es um die Performance in Unity geht. Sie haben aus unterschiedlichen Quellen gehört, dass Dies oder Jenes schlecht sein soll und jetzt gehen sie total ängstlich an das Projekt heran. Denen möchte ich aber sagen: Macht euch nicht verrückt! Denn wie immer ist alles eine Frage von der Menge an leistungsfressenden Dingen, dem gewünschten Resultat und der Hardware, auf der das Spiel laufen soll. Viele Dinge beziehen sich auf Hardware, die kaum noch genutzt wird, wie z.B. das iPad1, welches nicht mehr als 120MB Ram für das Spiel zur Verfügung gestellt hatte. Oder aber es bezog sich auf veraltete Techniken bei denen Unity schon längst performatere Dinge gebastelt hat, wie die unterschiedlichen Lighting-Arten. Ich will mal versuchen, die einzelnen Bereiche abzuarbeiten. Das Grafische: Alles was ich sehen kann kostet Leistung. Mal mehr, mal weniger! Je mehr Realismus ich in ein Spiel rein bringen will umso mehr Leistung wird verbraucht. Denn jedes Poygon, jedes Licht, jede Schattenberechnung und jedes Material verbraucht etwas. Diese Dinge belasten meist die Grafikkarte, denn die ist es, die das ja anzeigen und vorher berechnen muss. Habt ihr ein Spiel mit üppiger Szenerie und schaut euch zur Laufzeit mal den Profiler an, dann seht ihr, dass der Grafikbereich die meiste Leistung schluckt. Unity ist von sich aus schon bemüht, sparsam zu sein und kann gleichartige Dinge zusammen fassen, wenn sie z.B. das gleiche Material haben und auch vom selben Licht bestrahlt werden. Das reduziert die Drawcalls, die einen Großteil der Performance ausmachen. Man hat die Möglichkeit Beleuchtungen und Verschattung vor zu berechnen und die Ausleuchtung einer Szene zu backen. Das reduziert ganz massiv die Last auf der Grafikkarte, kostet aber Speicherplatz und natürlich geht die Dynamik der Beleuchtung dadurch flöten. Aber was bringt es, wenn man genau diese Dynamik haben will. Genau, es bringt nichts! Mit Shadern sieht es genauso aus. Ein einfacher Shader mit nur einer Textur ist recht sparsam. Er gibt aber auch nicht viel her. Schöner ist er, wenn er glänzen kann, transparent ist, erhaben ist und eben realistisch aussieht. Will ich das haben muss ich ihn auch einsetzen. Die Geometrie eines Körpers sollte natürlich so sparsam wie möglich aufgebaut sein. Die Zeit, wo ein Oberarm aus 12 Polygonen besteht, ist aber längst vorbei. Ich kann zwar vieles mit einer NormalMap simulieren, aber wenn die Ränder des Polygons zu eckig sind, sieht man das und es wirkt einfach nicht. Also auch da muss ich mich den Qualitätsansprüchen stellen und mehr Polygone nutzen. Ich kann sogar DirectX11 einsetzen und aus wenigen Polygonen eine Million Polygone machen. Ja, aber eben nur auf einer Grafikkarte, die das auch kann. Egal, wollt ihr die Technik einsetzen dann funktioniert es eben auch nur auf einer Hardware, die das auch kann. Lasst euch also nicht zu stark einschränken. Ihr werdet natürlich irgendwann merken, dass das Ganze zu viel geworden ist und die Framerate einbricht. Meist lässt sich das aber mit etwas geänderter Beleuchtung, LOD oder anderen Dingen schon wieder beheben. Da aber niemand genau sagen kann, wo die Grenzen liegen werden, bringt es auch nichts, wenn man vorher seitenweise darüber diskutiert. Die Physik: Die physikalischen Berechnungen kosten Leistung, die der Prozessor bringen muss. Und es ist klar, dass viele Berechnungen auch viel Leistung kosten. Trotzdem ist das jetzt kaum ein Bereich, wo man "extrem" sparen muss. Unity kann ohne weiteres mehrere 100 Objekte gleichzeitig physikalisch berechnen. Einfach schauen, dass nur die Objekte einen Rigidbody bekommen, die auch einen haben müssen weil sie der Schwerkraft oder anderen Forces folgen sollen und/oder Kollisionen auswerten sollen. Collider so einfach wie möglich halten und lieber einen Box-Collider mehr nehmen, als einen Mesh Collider zu nutzen. Meist muss es nämlich gar nicht ganz genau sein. Merkt eh keiner. Der Code: Ja, hier kann und muss man aufpassen. Denn wenige Kleinigkeiten können das System ganz schön verlangsamen. Aber macht euch auch hier nicht verrückt. Denn auch hier ist alles eine Frage der Dosis. Ein paar extreme Dinge will ich aber mal aufzählen. Als Faustregel gilt, dass jede Unity-eigene Funktion, die im Script steht, auch durchlaufen wird. Egal, ob innerhalb dieser Funktion etwas drin steht oder nicht. Die OnGUI Funktion ist die hungrigste, weswegen man so wenig Scripte wie möglich mit dieser Funktion bestücken sollte. Legt also nur die Funktionen an, die auch wirklich nötig sind, auch wenn das einsparpotential hier (außer bei der OnGUI) nur gering ist. Immer wenn aus einem Script heraus ein anderes Objekt oder dessen Komponente gesucht wird, kostet es Performance. Es hilft aber nichts. Manchmal muss man einfach nach anderen Objekten oder Komponenten suchen. Um jedoch so wenig Leistung wie möglich zu verbrauchen, sollte man nur einmal danach suchen und einfach die Referenz des Gesuchten in eine Variable speichern. Manche Befehle sind recht hungrig, wie z.B. die Entfernungsmessung über Vector3.Distance. Da sollte man sich überlegen, ob denn wirklich in jedem Frame die Entfernung gemessen werden muss oder reicht es vielleicht auch, wenn es nur wenige Male pro Sekunde passiert. So eine Messung würde ja in jedem Frame eine gewisse Grundlast verursachen, die nicht unbedingt sein muss. Und gerade wenn viele Objekte viele Entfernungsmessungen machen, ist es sinnvoll das Ganze in der Zeit aufzuteilen um die Grundlast zu verringern. So ist das natürlich auch mit komplexen Berechnungen die in einer Schleife ausgeführt werden. SendMessage ist ein teurer Befehl, der an ein gewisses Objekt und an all seine Komponenten etwas sendet. Egal ob die Komponente damit etwas anfangen kann, oder nicht. Diesen Befehl sollte man wirklich nur sparsam nutzen. Will ich einem anderen Script jedes Frame etwas mitteilen, dann ist dieser Befehl dafür total ungeeignet. Für ein einmaliges oder seltenes Senden ist er aber voll ok. Für das ständige Übergeben von Informationen bietet sich an, die Komponente, also das andere Script, vorher zu suchen und als Referenz in eine Variable zu speichern. Jetzt kann ich auf alle Public Variablen oder Funktionen des anderen Scripts zugreifen und sie aufrufen oder manipulieren. Das kostet nicht oder kaum mehr, als wenn es eine Variable des eigenen Scripts wäre. Alles das, was ich da aufgezählt habe macht sich erst ab einer gewissen Menge bemerkbar. Je schwächer die Hardware ist, desto früher merkt man es. Nur weil etwas viel Performance kostet, müsst ihr nicht darauf verzichten. Ihr solltet aber weise damit umgehen. Nur weil ich etwas jedes Frame tue, muss das nicht schlecht sein. Es kommt halt immer darauf an, was ich da tue und wie viele Objekte das gleichzeitig machen. Macht euch vorher Gedanken, was ihr für euer Spiel alles braucht und wie ihr das am besten lösen könnt. Aber lasst euch durch diese Planung nicht blockieren. Fangt einfach an. Vieles ist im Nachhinein leicht änderbar. Spiele, die auf einem PC schön aussehen sollen und können, können nicht unbedingt genauso für ein Handy übernommen werden. Es macht aber nicht unbedingt Sinn, sich auf den kleinsten gemeinsamen Nenner zu einigen. Manchmal muss man einfach mehrere Versionen für ein und das selbe Spiel bauen, weil die Qualitysettings nicht ausreichen werden. Fazit: Es ist also alles gar nicht so schlimm!
  25. 1 point
    Tja... das ist einzig und allein eine Frage deine Spieldesigns. Frag dich doch selbst mal was du gerne an Infos sehen würdest. Vielleicht macht es ja sogar Sinn, wenn man gewisse Infos nur sieht, wenn man z.B. einen Menüpunkt aufklappt.

Announcements

Hy, wir programmieren für dich Apps(Android & iOS):

Weiterleitung zum Entwickler "daubit"



×