Jump to content
Unity Insider Forum

runner78

Members
  • Content Count

    111
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by runner78

  1. In der Regel verwendet man bei solchen Sachen immer Miniaturen. Z.B. in Kerbal Space Programm, da wird intern das Sonnensystem mit double vectoren berechnet, die Darstellung aber mit skalierten Miniaturen. In der Map sieht man die Planeten wenn man heraus zoomt nur Markierungspunkt, und der Planet erscheint erst wenn weit genug hinein zoomt. In der Normalen Ansicht wird nur die unmittelbare Umgebung in echter Größe dargestellt, Himmelskörper werden mit eine anderen Kamera von einem skaliertem Model aufgenommen. Der Planet Kerbin hat so eigentlich nur einen durchmesse von 100 Units. Zum Teil verwendet KSP bis zu 7 überlappende Kameras.
  2. Das Problem dürfte weniger an diesem Script liegen, als an den Objekte die du erstellt. Start() wird nur ein einiges mal aufgerufen und hat keine Auswirkung auf die FPS.
  3. Unity hat auch einen eigenen JSON serailizer, der ist zwar nicht so umfangreich wie der von Newtonsoft, soll aber performanter sein (nicht getestet). Microsoft hat sich für ASP.NET core 3 übrigens auch von Newtonsoft getrennt und entwickelt eine eigenen performanteren serializer.
  4. Ich lasse bei if Anweisungen fast nie die Klammern weg, ich finde das tatsächlich oft weniger lesbar. Einzig bei reinen Einzeiler mach ich das manchmal methode() { if (istWahr) return; }
  5. Das kommt ein wenig auf den Kontext an, beim oberen Beispiel würde ich den langen code bevorzugen. Ich benutze die kurze Schreibweise des öfteren beim zuweisen von Variablen mit default-Werten.
  6. Texture2D hat übrigens die nützliche Methode "Resize": https://docs.unity3d.com/ScriptReference/Texture2D.Resize.html
  7. Ein Vorteil für JSON wäre eventuell ein einfacher Mod-Support .
  8. Link habe ich Grad keinen, aber z.B ECS benutzt den C# Standard (mit Ausnahme der neuen "math" Bibliothek)
  9. Unity will sich jetzt ja auch an die C# Standard halten, aber um nicht alles zu mischen, haben sie sich entschlossen im "alten" Namespace (UnityEngine/UnityEditor) den alten Stil zu verwenden, im neuerem "Unity" Namespace sich an den Standard zu halten.
  10. Mit var_dump() oder var_export() kannst du dir den Inhalt von $_FILES ausgeben, praktisch für schnelles debuggen. Ich hoffe du baust da auch eine Validierung ein, die speicherst eine Datei ohne zu überprüfen ab, da kann alles drin sein, und dazu hast du auch indirekt den Link zu deinem Script hier gepostet. Ich habe zum Test eine Textdatei gepostet, gab keine Fehler Das WWW System von unity ist veraltet, es gibt ein neueres System: https://docs.unity3d.com/Manual/UnityWebRequest-SendingForm.html
  11. 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.
  12. Bei WoW wird glaube ich beides verwendet. Bei TCP wird sichergestellt, dass Daten-Pakete in der richtigen Reihe auch wirklich ankommen. Das beuteutet auch, das der Server warten muss bis der Empfänger zurückgibt das das Paket gekommen ist, und im schlimmsten Fall das Paket nochmals senden, wenn es verloren geht. Dadurch entsteht eine nicht unerhebliche Zeitverzögerung. TCP hat auch einen größeren Header und braucht deshalb auch mehr Bandbreite. UDP schickt einfach die Pakete ohne sicherzustellen ob und in welcher Reihenfolge die Pakete ankommen. Z.B. bei Spielerpositionen kann es auch mal egal sein wenn mal ein Paket verloren geht. Während bei TCP der Server das mittlerweile veraltete Paket nochmal schicken muss, hat bei bei UDP der Client vermutlich bereite aktuellere Pakete erhalten. TCP macht dann Sinn wenn Performance keine Rolle spielt, und man Sicher gehen will, dass die Daten auch ankommen, z.B beim Senden von Benutzereingaben zum Server. Beim FPS Example wird übrigens beim Senden von Benutzerangaben auch die Versionsummer des letzten empfangenen Paketes mitgesendet, somit weiß der Server wann der User eine Aktion ausgeführt hat und passt die Server Simulation Rückwirkend an.
  13. UNET verwendet UDP, nicht TCP (bei Multiplayer üblich). UDP ist schneller, allerdings kann es zu Packetverlusten kommen. Wenn ich mich richtig erinnere, wird beim FPS example jedem Paket eine Versionsnummer mitgesendet.
  14. Stimmt nicht, Formate wie DXT liegen auch komprimiert im Grafikspeicher, genau dafür sind solche Formate gemacht.
  15. Das liegt dann daran, das dein Input nur funktioniert wenn er durch 3 Teilbar ist.
  16. Wenn du 2 Gruppen von 3 Elementen in dem Array hast, dann hat das Array einen index range von 0 - 5 Bei ersten Durchlauf wird Index 0, 1 und 2 als Daten für den Score verwendet. dann nach wird i auf 2 gesetzt. 2 ist kleiner als die Länge des arrays, also nächster Durchlauf: Bei zweitem Durchlauf wird Index 2, 3 und 4 als Daten für den Score verwendet. dann nach wird i auf 4 gesetzt. 4 ist kleiner als die Länge des arrays, also nächster Durchlauf: Bei dritten Durchlauf wird Index 4, 5 und 6 als Daten für den Score verwendet. 6 ist aber außerhalb des ranges des arrays und du bekommst einen Fehler. Versuch mal: // Daten-Objekte füllen void FillHighscore(string[] input) { highscore.Clear(); int length = input.Length; for (int i = 0; i < length; i+=3) { Score score = new Score(); score.email = input[i]; score.PlayerName = input[i+1]; score.Points = input[i+2]; highscore.Add(score); } }
  17. Um genau zu sein vor 5 Jahren mit PHP 5.5.0 als veraltet markiert und vor 3 Jahren mit PHP 7.0.0 entfernt. Man sollte beim googlen vielleicht auch auf das Alter diverser Anleitungen schauen. Ich würde aber generell zum Gebrauch von etablierten Bibliotheken raten, wie doctrine https://www.doctrine-project.org/
  18. "Einbrüche" ist relativ, ich habe eine schnelle CPU und SSD, da hatte ich fast konstant bei 70-80 fps. Es gab aber manchmal spikes mit 15 fps. Bei schächeren PCs oder verallem Mobile, da könnte die Framerate etwas problematischer werden. Mit Visual Studio kannst du auch Teile des code automatisch in neue Methoden auslagern. Sie dir auch an ob die wiederholende Code-Bereiche hast, dann kann man dann gut ein eine einzelne Methode zusammenfassen. Ich kenne mich mit UNET jetzt nicht aus, aber ich habe gesehen du benutzt ja Network Identity, das ist aber Teil der high-level API und hat mit low level nichts zu tun. So ein Kartenspiel könnte man auch sehr gut mit ECS/C# Jobs und dem neuen Unity Networking performant realisieren.
  19. Wie gesagt, netwoking kenne ich mich nicht so aus, allerdings würde ich hier einen anderen Ansatz wählen. Trenne Die Darstellung und die Spiellogik. Die Animationen sind bei allen die selbe, das musst du nicht per Netzwerk synchronisieren. Ein Ansatz wäre (cheating sicherer): Nur der Server kennt alle Karten Ein Spieler Client kennt nur die Karten die aufgedeckt sind. Ein Client sagt dem Server den nächsten Zug Der Server sagt dem anderen Client das Ergebnis. Animationen und visuelle Positionen der Karten simulieren die Clients lokal. Änderungen gehen beim beenden verloren, sie eigenen sich daher für Einstellungen die du im Editor machst, oder auch um Daten zwischen verschiedenen Gameobjects/Komponenten auszutauschen.
  20. Für Leute die sich weniger mit der Zukunft von Unity beschäftigen mal ein kleines update zur Performance von Unity die zukünftig mit ECS Möglich ist. Zur Unite LA 2018 hat Unity eine Demo Project Vorgestellt namens Megacity, die Eckdaten der Scene: 4.500.000 Mesh renderer 100.000 individuelle Audioquellen 5.000 dynamische Fahrzeuge Constant 60 fps https://www.youtube.com/watch?v=j4rWfPyf-hk
  21. Fast eine Jahr Später: Mit Unity 2018.3 kommt schon C# 7.3
  22. Ich bekomme übrigens bei spielen die Meldung beim Zug der AI: Zum Networking und Mobile muss jemand anderes was dazu sage, da habe ich keine Erfahrung darin. Das ist nicht unsinnig, und der Koordinationsaufwand wird irgendwann auf diese Weise sogar größer. Wenn das Spiel wächst und du mehr Funktionen einbaust, wird es immer unübersichtlicher und wenn du mal nach einigen Wochen Abstinenz mal wieder in der Code zurück kehrst, dann kennst du dich selbst nicht mehr aus. Die Ausrede "es ist nur ein kleine Projekt" zählt nicht, da man sich sonst nie einen sauberen Programmierstil angewöhnt. Pack bitter generell nicht mehrere Klassen in eine Datei. Eine Datei pro Klasse. Es gibt Order und Namespaces. Ich habe momentan nicht die Zeit den genau den Workflow deines Spiele zu analysieren, aber wenn du variablen über Find zuweisen musst, dann hast du schon ein Konzeptionelles Problem. Mit ScriptableObject kannst du dir als Asset im Asset-Ordner erstellen sie wie Prefabs einer Komponente zuweisen. Du könntest dir deine Karten hier definieren, anstatt Hardgecodet. So könnest du auch Variationen mit anderen Motiven erstellen. Im Spiel "Tales of Berseria" gibt es ein Hanafuda Minispiel mit Charakteren auf vorherigen Spiele der Reihe als Motive.
  23. Mich hat es ein wenig gewundert, dass du die alte OnGUI verwendest und nicht die neuere Unity UI. 2019 kommt mit UIElements auch schon die nächste UI auf XML und CSS basis. Gerade wenn eine Funktion sehr umfangreich ist, ist es besser sie aufzuteilen, oft wiederholen sich bestimmte Codeblöcke die man so wiederverwenden kann und man hat dann auch wenig code. Die Settings könnte man als ScriptableObject anlegen. Es spricht nichts gegen Statische Helfer-Klassen, aber man sollte sie der Übersichtlichkeit Logisch strukturieren, siehe die Math Klasse aus .NET (Mathf float variante in Unity) Spezifische Sachen haben aber wiederum nichts in einer Global statische klasse zu suchen wie z.B Global.HoverCard, pack die Logik dort hin wo sie hin gehört. Zur Performance kann ich momentan nicht viel sagen, aber ich glaube hier gibt es noch sehr viel Spielraum nach oben. Du solltest z.B. alle "GameObject.Find()" aus der Update() rausbekommen. Da solltest du mal dein Spiel mit dem Profiler anschauen. Siehe https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members#names-of-fields ECS steht für Entity Component System, und ist eine neue Art um Gamecode in Unity zu programmieren. Befindet sich aber noch in Preview.
  24. Ich habe nur mal kurz reingeschaut, was mir aber aufgefallen ist bezüglich Code Qualität: Die Scripts sind zum Teil unübersichtlich. Vor allem die AI.cs. Die Update() ist über 400 Zeilen lang, hier würde das aufsplitten in mehrere Methoden alles etwas übersichtlicher machen und das unschöne goto wäre nicht nötig. Die Global ist ein Sammelsurium aus Settings und anderen Statischen Funktionen. Eine logische Trennung wäre grundsätzlich anbracht, habe keine Angst mehrere Dateien Anzulegen. Keine einheitliche Namensgebung von Feldern, mal camelCase, mal PascalCase Öffentliche (dazu gehört auch protected) Felder und properties werden in der Regel PascalCase geschrieben, Unity hält sich mittlerweile bei neuen Sachen z.B. ECS selbst daran (meistens zumindest). Für private Felder und properties gibt es keine Namingconvention, allerdings sollten sie im Projekt konsistent sein.
  25. Für alle die in Unity Projekten noch mit JavaScript oder Boo Programmieren, habe erst heute gesehen, dass es in der letzten Beta für 2018.3 eine weitreichende Änderung gab: Es gibt hier ja immer wieder Neulinge, die hier mit JavaScript ankommen (über alte Tutorials oder Kursen)
×
×
  • Create New...