Jump to content
Unity Insider Forum

MaZy

Members
  • Content Count

    631
  • Joined

  • Last visited

  • Days Won

    26

MaZy last won the day on August 14

MaZy had the most liked content!

Community Reputation

177 Excellent

About MaZy

  • Rank
    Advanced Member
  • Birthday 02/20/1988

Profile Information

  • Gender
    Male
  • Location
    Hannover

Recent Profile Visitors

14,630 profile views
  1. Ich kann nur aus Erfahrung sprechen, dass viele gerne Ideen haben, die sie umsetzen wollen, weil sie während sie etwas zocken und dazu Ideen einfallen (ist bei mir auch so sehr oft), aber ich hab ca. 90% davon gesehen, wo die ihre Motivation schnell verlieren und aufhören, weil es Jahre dauern kann. Faktoren wie unerfahrener Programmierer bzw. weil man nicht hauptsächlich die Zeit dafür hat (z.B. wegen Job / Schule usw.) verlängern die Zeit. Es gab mal so eine Seite, da konnte man sogar sowas berechnen lassen, die Kosten oder Dauer. Einer von wenigen die tatsächlich was umgesetzt haben ist z.B. http://unknown-horizons.org/ - Anno Klon. Zufällig hab ich gerade gesehen, dass sie sogar auf Godot Engine wechseln wollen: We are working on an Port of Unknown-Horizons to the Godot Engine. Und daran arbeiten sie seit 2008 bis heute. Also 12 Jahre. Vielleicht aber nicht jeden Tag. Bin mir da nicht sicher. Ist auch Open Source. Würde daher erst empfehlen ausführlich ein Engine oder so auszutesten, wo man sich wohl fühlt. Kleine Prototyps zu entwickeln und dann loszulegen.
  2. Ich hab dort gemeint, wenn man jetzt ein GameObject mit Laserscript hat und als Child noch ein GameObject mit Collider mit aktivierten IsTrigger hat, dann wird bei Laser nie OnTriggerEnter ausgeführt. Deswegen könnte man ein Trigger Script schreiben, der quasi zu Laserscript dann weiter schickt, wenn ein Trigger entstanden ist. So als Pseude: LaserScript.OnHit(Collider targetCollider) TriggerScript.OnTriggerEnter(Collider targetCollider) { LaserScript.OnHit(targetCollider); }
  3. Oh du benutzt die selben Assets wie ich https://i.imgur.com/KcqYrEV.gifv Aber ich habe leider wenig Zeit für die Entwicklung derzeit.
  4. Hab den teil nicht genau verstanden, aber ich stelle mir eigentlich dein Setup so vor. Beispiel: Laser -LaserScript -LaserBoxCollider (GameObject mit Boxcollider als Trigger) --TriggerScript Asteroid -HealthScript -Rigidbody -Collider (ohne Trigger) 1. Wenn das so aufgebaut ist, dann kannst im TriggerScript ein Reference zu LaserScript haben, falls du dort die all das mit Kollision berechnest. Man kann dafür extra ein TriggerScript schreiben um alles zu dem Main Script zu senden (z.B. mit UnityEvents). Dann müsste das schon gehen. 2. Methode was ich bei schnelle Projektilen gemacht habe war einfach Raycast bei jeden Tick benutzen allerdings hab ich immer vor der Bewegung berechnet, ob ich kollidieren könnte (damit es nicht durchfliegt). Wenn es um Laser geht kann man gleich die Strecke abchecken, ob es eine Kollision gibt 3. Das was Sascha meint, soweit ich verstanden habe, einfach gucken, ob es ein Treffer ergeben könnte, wenn ja bis dahin animieren. Soweit ich weiß, machen das viele Spiele wie Battlefield, aber keine Ahnung wie das machen, wenn es um bewegliche Ziele geht. Bei Spielen wie Counter-Strike wird direkt geguckt, ob es Treffer ist und wird direkt auch schaden abgezogen. Hier sieht man sogar, dass die erste und 2 Methode hier anwende: https://i.imgur.com/dIvr9De.gifv
  5. Ja kann an TCP liegen, aber muss nicht sein. World of Warcraft benutzt auch TCP und da sieht man solche Probleme nicht, außer in Worst Case Scenario, wo wirklich sehr viele in ein Haufen sind. Das gleiche hab ich bei Guild Wars 2 auch gehabt, aber ich weiß nicht ob die TCP oder UDP benutzen. Minecraft benutzt auch TCP. Minecraft lagt auch gerne bei schwachen Server, aber bei uns ging das mit 1000 Leuten damals mega gut. Ich kann leider nicht einschätzen, wann FPS runter gehen könnte, weil ja das auch an Grafik liegen kann oder allgemein an die Behaviourscripte. Ich weiß z.B. von Black Desert, obwohl da viele nur standen hat es trotzdem gelaggt und bei Bosse war das schon wirklich sehr weit unten mit der FPS. Bei TCP ist nur ein Schritt mehr als bei UDP und zwar die Bestätigung, dass etwas ankam, wenn nicht wird es wieder gesendet. RUDPs, wo es garantiert gesendet werden soll hat man ungefähr den selben Schritt. Wenn also jemand dich im Spiel schlägt, will man natürlich unbedingt so machen, dass du es mitbekommst. Im Endeffekt wäre man also bei der gleichen Sache, egal ob UDP oder TCP. Aber ist nur eine Spekulation. Vllt denken sich auch Entwickler, egal, wenn man ein Schlag nicht sieht, oder mal die Tür zu bleibt oder so. Es gibt da verschiedene Arten wie man hier vorgehen kann. Beispiel Algorithmen wie Nagle, NoDelay, Cork können CPU Last erhöhen oder reduzieren. Dafür kommen die Daten langsamer oder schneller an bzw. die Verarbeitung ist schneller oder langsamer. Auch Größe des Pakets ist wichtig. Kann man nicht so große Daten senden, so müssen sie gesplittet werden. In Mirror gibt es ein Benchmark, wo bei mir 4.500 Figuren rum laufen. Dort kann man testen, ob der CPU ausgelastet wird oder lags entstehen. Ich konnte das leider übers Internet nicht testen, da mein V-Server sehr schwach ist. Es schafft locker. Aber es ist halt kein realer Test, weil hier keine Effekte sind, keine Umgebung usw. Allerdings schafft unity da nicht mehr. So viele Figuren ist auch krass auf ein Fleck. Zuletzt eigene Erfahrung. Ich hatte mal ein Spiel prototyped. Da das Spiel hat gelaggt sobald ich im Weltraum geschossen habe. Später hab ich gemerkt, dass es an Particle Effects lag. Und hier sieht man sogar von mir selbst entwickelten Netzwerk System wo TCP benutzt wird. https://i.imgur.com/EU7gugy.gifv Dabei war es bei dem Gif noch nicht optimiert. 2000 Objekte zwischen ein server und zwei clients. Das wurde sogar auf einem v-server auch getestet. Man sieht kleinen Ruckler, aber das war der Editor selbst. Wenn da das Fenster kommt mit dem Spiel sieht man, dass es 60 fps hat. Ich glaube Mmax hab ich 3000-8000 geschafft, aber das schafft Unity nicht. Selbst 2k ist schon etwas krass. Wenn da physic und so dabei wäre, wäre das nur am laggen. Da muss man ECS benutzen :D. Aber das war halt mit Telepathy. Apathy soll ja 3x mal schneller sein weil es mit native C geschrieben wurde.
  6. Zu TCP und UDP Ich tendiere zu TCP und man kann dafür benutzen, aber empfohlen wird dennoch UDP. UDP und TCP zusammen funktionieren nicht, aber man kann trotzdem programmieren, dass die Daten die von TCP kommen durch UDP weiter geleitet werden können, aber sowas tut man nur, wenn man keine andere Wahl hat (z.B. Browser unterstützen nur TCP). UDP ist allgemein schneller, aber nicht so verlässlich wie TCP. Für schnelle FPS kann UDP besser geeignet sein. Mirror Entwickler haben z.B. UDP benutzt für ihren Mmmorpg Packet im AssetStore und es gab da sehr viele Probleme. Beste Entscheidung für sie war TCP am Ende. Zitat: "Telepathy was originally designed for uMMORPG after 3 years in UDP hell.". Telepathy ist deren TCP library. Unitys UNet ist veraltet wird nicht mehr entwickelt. Ja hatte gute und schlechte Seiten, aber mehr schlechte. Mirror bzw. https://github.com/vis2k/Mirror hat UNet sehr früh schon übernommen und eine eigene Version gemacht. Heute finde ich es als das beste High Level API Network System was kostenlose Networks angeht, da. Aber kann das auch nicht 100%ig beurteilen, weil da noch einige andere gibt, wo ich nur bisschen angeschaut habe. Es gibt sogar Entwickler, die "neidisch" auf Mirror sind und Blogeinträge posten warum ihre wohl besser ist. Hab selber gelesen und teilweise Sachen stimmten nicht. Falls dir High Level API nichts sagt bedeutet das einfach nur, dass du kaum was programmieren musst, um ein Netzwerk spiel zu entwickeln. Dies drum herum ist schon alles fertig. Mirror hat sehr aktive Discord Community. Bin da auch voll oft aktiv (nur in letzter Zeit nicht so). Mirror unterstützt alle Transports (TCP, UDP, Websockets, Steam usw). Man kann sie schnell auswechseln oder alle zusammen verwenden. Schau dafür das Bild an. Libuv2k soll angeblich einer der schnellsten Transports werden (noch in Entwicklung).
  7. Unity arbeitet an was neuem. Das ist auch gut so, denn das neue soll auf jeden Fall besser. Vielleicht nicht so krass anfänger-freundlich, aber es bietet Sachen an, die man bei UNet gebraucht hat. Aber so viel will ich nicht beurteil, da ich nur ein paar Videos dazu gesehen habe und das ja auch noch nicht ganz fertig ist. Wie gesagt ist Photon PUN für mich "Kinderspielzeug". Es funktioniert auch nicht offline. Das heißt man verbindet mit dem Photon Netzwerk. Bei Photon kann man auch nichts serverseitig programmieren. Da kann man Sachen aber schnell entwicklen testen. Bei Mirror oder anderen dagegen muss man mehr tun um schon etwas hinzukriegen. Ist trotzdem anfänger-freundlich aufgebaut. Man muss aber nicht nur Mirror benutzen, da gibt es noch andere Dinge: https://assetstore.unity.com/packages/tools/network/forge-networking-remastered-38344 https://assetstore.unity.com/packages/tools/network/mirror-129321 https://assetstore.unity.com/packages/tools/network/dotsnet-102633
  8. Also wenn du Anfänger bist und gar kein Plan hast würde ich auch erst mal Photon PUN empfehlen, da das vieles abnimmt. Aber wenn du da bisschen mehr machen willst z.B. auch eigenen Server programmieren, wo ein Spieler dann dahin joinen kann um zu Spiele (wie die meisten Spiele), dann kann man Mirror oder so benutzen. Wenn du noch komplexer haben willst. Quasi von ganz weit unten fangen, dann kann auch direkt mit Transport Layer benutzen wie Telepathy, DarkRift 2, Lidgren (die spontan mir so einfallen). Bei Splitscreen brauchst du eigentlich keine davon. Ja UNet wird gar nicht mehr weiter entwickelt. Ein paar Ergänzungen, da ich aktiver Mirror-Nutzer bin. Mirror wird bereits seit 2016 parallel zu UNet entwickelt, weil der Entwickler nicht mit UNet zufrieden war, aber sehr hohen Potenzial sah. Mirror bzw Unet arbeiten nämlich mit weaver bzw. Code Generation. Heißt Sachen, die wir eigentlich programmieren müssten und der Aufwand dazu sehr krass länger wäre wird automatisch gemacht. Das ist wirklich cool. Mirror hat eine aktive Community. Mirror hat 3-5 aus Programmierer. Mirror Entwickler (Chef kann man sagen) ist der selbe wie von der beliebten Assets wie uMMORPG, uSurvival usw. Man kann aber durch GitHub mithelfen, wenn man z.B. Pull Request wegen Bugs machen will oder so (was ich z.B. mal gemacht hab). Mirror wird durch spenden finanziert, die aber als Kunden betrachtet werden. Spenden nämlich erlauben bzw. geben dir die Lizenz bestimmte neue Tools, Services zu nutzen. Z.B. seit neustem Cloud Hosting (ich glaube mit Google oder so). Bereits ab 5$ Dollar pro Monat (5$, 20$, 200$, 1000$) kriegt man die Lizenzen. Mirror wird schnell entwickelt. Täglich Veränderungen und Neuerungen werden eingebaut. Selbst mein Request (was aber öfter durch andere auch angefragt wurde) was eigentlich aufwendig und nicht so einfach war, wurde eingebaut. Mirror ist auf keinen Fall perfekt, aber verglichen zu andere finde ich das wirklich gut. Es gibt Dinge, die mag ich nicht so daran, aber das ist Geschmackssache. Es hat auch keinen Masterserver oder so. Sowas muss man selber machen. Ist nicht so schwer. Hab bereits selber gemacht. Wenn man professionellen Weg gehen möchte, dauert es bis man da das Wissen zusammen hat, wie man am Besten vorgehen kann, aber danach ist es leicht. Was mit Mirror programmiert wurde und ich gerne sogar ab und zu spiele: https://www.thelast.io/ (#werbung :D). Ist ein Battle Royal 2D spiel, hat Matchmaking Service, Loginsystem.. so eigentlich alles was man von modernen spielen kennt. Alles durch Mirror bis auf den Matchmaking Service soweit ich weiß. Das soll angeblich über Java laufen.
  9. Würde ich auch sagen, aber ich habe einige APIs gesehen, die wollen einfach nur Passwort ohne Verschlüsslung. Ich glaube den Rest erledigt SSL selber? Bin da auch nicht so der Schlauste.
  10. Moin nochmal. Es gibt ja unter Preference eine Möglichkeit auch VS Projekte für Packages zu erstellen. Damit lässt sich das auch wunder weiterentwickeln. Jetzt brauche ich doch nicht zwei Unity Projekte erstellen. Hätte ich das vorher gewusst
  11. Ich habe nun erstmal die erste Methode genommen. Also in einem separaten Projekt entwickeln und damit wird auch automatisch im aktuellen Projekt, wo man diese Packages braucht auch aktualisiert (solange ich lokal benutze und nicht übers git).
  12. Mach das aber die Arbeit nicht bissel "nervig"? Wenn ich Beispiel in dem aktuellen Projekt etwas habe, wo ich eine Verbesserung in mein Script brauche, dann könnte ich das gar nicht in der ProjektTools testen. Müsste immer hin und her switchen und auch per git pushen und so weiter. Ein Beispiel ich habe sowas wie InputExtension geschrieben, welches mit einige Sachen erleichtert was Cursor / Mouseposition angeht. Eine Funktion davon ist TryGetAtCursor<T>(out T target, float radius = 1f) Hier brauche z.B. ein Custom Component um dies zu testen. Wenn ich jetzt in ProjectTools auch noch das vorbereiten müsste, dann würde das ja von Zeit her richtig krass bremsen , obowohl das aktuelle Projekt das auch bereits hat. Daher würde ich ja eher wollen, dass ich diese lokale Dateien was mit git commited werden kann, direkt im Package Manager mit VS bearbeiten kann (was theoretisch geht nur halt ohne intellisense usw). Muss zusätzlich sagen, dass es echt viele Scripte sind und gemischt sind. Paar habe ich schon raussortiert, aber kommt immer noch einiges zusammen.
  13. Il2CPP supported das nicht steht da. Könnte daran liegen. Ich glaube aber so oder so allgemein andere Verbindungen außer Websocket ist gar nicht bei WebGL möglich. Bin da aber nicht 100%ig sicher.
  14. Hallo. Ich habe sehr viele Ordner mit sehr vielen Scripte die mir wirklich das Programmieren in Unity sehr erleichtern. Nun hab ich angefangen die ordentlich zu sortieren, was ich immer brauche und was vllt mal brauche und mache daraus nen Package für Unity. Nun ist bei mir aber so, dass dennoch daran öfters etwas ändere und weiter entwickle. Wie sollte man das am besten Strukturieren, wenn man auch noch das per Git machen möchte (derzeit ist es noch alles lokal ohne Git). Wenn es im Package Manager geladen ist, dann zeigt mir VIsual Studio vieles weiß an - also sie sind nicht resolved und kann nicht da richtig programmieren. Ich weiß nicht, ob man das lösen kann. Meine eigene Idee war daher, dass ich ein Projekt "Tools" habe, wo nur diese Sachen drin sind. Wenn ich nun ein Projekt Tools habe, wo genau diese Sachen sind und ein Projekt B habe wo ich gerade einem Spiel entwickle und denke: ah das fehlt dort und wird ergänzt, dann müsste ich die Datei vom lokalen Ordner (wo Package ist und mit Git arbeitet) nun zu Projekt Tools verschieben, weil ja Project Tools Asset Ordner selber kein Git ist. bzw. zu dem Ordner wo Git ist. Aber dies ist mir zu riskant. Was wenn ich vergesse zu verschieben? Deswegen frage ich mich, wie man das am besten da machen kann. Was ich mein mit not resolved oder weiß wie auch immer ist das:
  15. Also die Regeln lauten bei zwei GameObjects mit Collidern muss einer davon Rigidbody haben, damit sie mit einander kollidieren können und da wird auch OnCollision usw. gecallt. Daher komisch, dass es bei dir nicht mehr geht, wenn man Rigidbody hinzufügt. Muss dein Code kritisieren . Jedes mal contactPoints = new List<Vector3>(); zu machen finde ich nicht gut, aber ist in dem Beispiel ist es nicht so schlimm. Man kann dennoch da contactPoints.Clear() benutzen. New Object lässt den GarbageCollector arbeiten. Wie gesagt: In dem Beispiel ist das jetzt nicht schlimm, aber hätten wir 500 Objekte, die mit einander Kollidieren dann vllt schon. Warum ich generell das nicht machen würde ist, wenn man Logger.contactPoints = contactPoints hat und man nun contactPoints = new macht.. dann ist Logger.contactPoints nicht null, sondern hat noch den Reference zu alten Speicher von contactPoints. Das heißt wenn man nun contactPoints.Add macht würde Logger.contactPoints nicht mehr sich ändern. Ich wiederhole, ist hier in dem Beispiel aber ok. Ich hab trotzdem das mal abgeändert und auch Clean-Code-Prinzip eingebaut. using System.Collections; using System.Collections.Generic; using UnityEngine; public class DrawCollider2D : MonoBehaviour { private List<Vector3> contactPoints = new List<Vector3>(); private List<Vector3> normalPoints = new List<Vector3>(); void OnCollisionEnter2D(Collision2D collision) { contactPoints.Clear(); normalPoints.Clear(); ContactPoint2D[] contactPoint2d = collision.contacts; foreach (ContactPoint2D contactPoint in contactPoint2d) { contactPoints.Add(contactPoint.point); normalPoints.Add(contactPoint.normal); } } void OnDrawGizmosSelected() { if (contactPoints.Count > 0) { Gizmos.color = Color.blue; foreach (Vector3 contactPoint in contactPoints) { Gizmos.DrawWireSphere(contactPoint, 0.02f); } } if (normalPoints.Count > 1) { Gizmos.color = Color.red; int i = 0; foreach (Vector3 normalPoint in normalPoints) { Gizmos.DrawLine(contactPoints[i], contactPoints[i] + normalPoint); i++; } } } }
×
×
  • Create New...