Jump to content
Unity Insider Forum

Leaderboard


Popular Content

Showing content with the highest reputation since 12/21/2018 in Posts

  1. 4 points
    Mir ist dein anderer Thread dazu aufgefallen, also dachte ich mir, ich lass auch mal ein paar Worte fallen. Was das Alter angeht haben die anderen ja schon einiges gesagt. Das ist ziemlich irrelevant. Aus meiner Erfahrung ist das eine Eigenschaft von guten Programmierern. Die nehmen meistens Worte sehr genau. Ansonsten ist ein guter Programmierer meiner Meinung nach kein professioneller "Code-Schreiber", sondern ein Problemlöser. Probleme elegant und effizient zu lösen erfordert zum einen die Fähigkeit abstrakt zu denken, vor allem aber erfordert es Kreativität. Die guten Programmierer, die ich kennengelernt habe, denken oft outside of the box. Selbstreflexion ist ebenfalls eine wichtige Eigenschaft eines solchen Programmierers. Dabei geht es darum zum einen offen zu sein für neue Ansätze. Viele Programmierer, die leider oft auch in Senior Positionen sind, glauben, weil sie das seit 20 Jahren machen wissen sie alles. Aber man lernt niemals aus. Zum anderen treibt sie einen an sich selbst zu verbessern. Die besten Programmierer, die ich kenne, beschweren sich nicht bloß über fremden, sondern meistens über ihren eigenen Code Erfahrung ist natürlich viel Wert und über Programmierung gibt es viel zu wissen, aber im Endeffekt ist die Programmierung bloß eine weitere, anlernbare Fähigkeit, die auf solche Charaktereigenschaften aufbaut.
  2. 2 points
    ^ 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
  3. 2 points
  4. 2 points
    Wenn du eine Szene lädst, dann wird die alte Szene entladen (alle Objekte darin werden gelöscht) und die neue Szene wird danach geladen (alle Objekte darin werden instanziiert). Wenn du ein Objekt in Szene 1 hast und dann Szene 2 lädst, dann sind alle Objekte weg, die in Szene 1 waren. Dass du jetzt ein GameObject mit der gleichen Komponente darauf auch in Szene 2 hast, bedeutet nicht, dass es sich um dasselbe Objekt handelt - es ist ein neues Objekt derselben Art. Also das gleiche Objekt, nicht dasselbe. Entsprechend sind alle Einstellungen, die du am Objekt in Szene 1 vorgenommen hast, weg. Ich könnte jetzt mit dieser oder jener Lösung anfangen, aber hier gibt es noch einige andere Probleme. Ich erkläre mal, wo es hakt, und dann zeige ich darauf aufbauend eine mögliche Lösung. Fangen wir mit den drei Booleans an. Beim Programmieren können Fehler passieren. Wir sind halt Menschen und Menschen machen Fehler. Darum ist es gut, sich bestimmte Techniken anzugewöhnen, um "guten Code" zu schreiben. Guter Code tut mehr, als einfach nur zu funktioneren. Er minimiert zum Beispiel das Risiko, Fehler zu machen. Ein Spieler wählt eine Klasse aus. Er hat immer nur eine. Das heißt, dass es sinnvoll wäre, dass das Programm auch nur eine Klasse zur Zeit zulässt. Wenn du allerdings drei Booleans hast, dann ist es theoretisch möglich, dass zwei oder mehr davon true sind, und der Zustand deines Programms ergibt keinen Sinn mehr. Dass das möglich ist, bedeutet direkt Fehlerpotential, denn du musst zu jedem Zeitpunkt darauf aufpassen, dass das nicht passiert. Und je mehr es gibt, auf das du ständig achten musst, um keine Fehler zu machen, desto unmöglicher wird es, keine Fehler zu machen. Stattdessen wäre ein enum möglich, aber ich zeige gleich lieber eine andere Lösung. Das nächste Problem wären Strings. In diesem Fall benutzt du Tags. Ich schicke eines gleich voran: In meinen Projekten benutze ich niemals Tags. In jeder Situation, in der man sie gebrauchen kann, gibt es jeweils mindestens eine bessere Lösung. Trotzdem kann man sie erst einmal benutzen. Problem ist halt, dass man sich bei Strings immer vertippen kann oder sie sich ändern, ohne dass einem der Compiler sagt, dass etwas nicht stimmt. Wenn du im Code "Krieger" falsch schreibst, dann siehst du erst einmal nur einen Fehler im Test und musst danach im Code suchen, anstatt dass der Computer das für dich übernimmt. Dann kommt noch die if-else-Kette. Du hast jetzt eine Klasse, die nach dem Tag ihres GameObjects schaut und ein Boolean auf true setzt. Eine andere Klasse hat für jeden dieser Booleans eine if-Abfrage und ein Prefab, das gegebenenfalls instanziiert wird. Das heißt: Wenn du n Klassen hast, hast du n Tags, n Booleans und n if-Abfragen. Jedes Mal, wenn du eine Klasse in dein Spiel hinzufügst, musst du also einen Tag hinzufügen, ein Boolean in die eine Klasse einbauen und eine if-Abfrage in die andere. Das sind drei Arbeitsschritte für eine einzelne Änderung an deinem Spiel. Das klingt vielleicht nicht nach viel, aber wenn du einen dieser Schritte vergisst, hast du gleich wieder einen Fehler gebaut - und zwar wieder einen, bei dem dir der Compiler nicht helfen kann. Bei komplexeren Systemen gibt es dann noch mehr Arbeitsschritte pro Änderung, sodass das Fehlerpotential immer weiter steigt. Es sei denn, man geht grundlegend anders an die Sache heran. Nun zu einem Lösungsvorschlag. Was du letztenendes tust ist, dass du mehrere Objekte hast und jedes dieser Objekte steht für jeweils ein Prefab, das nach dem Laden immer derselben Szene instanziiert wird. Also Knopf -> Prefab, denn jeder Knopf steht für ein Prefab. Aktuell haben wir aber Knopf -> Boolean -> if-Abfrage -> Prefab, und wir können den gesamten Zwischenweg einfach rausnhemen. Wir ändern die Klassen wie folgt ab: Deine Knopf-Klasse, auf die man drückt, erhält eine Referenz auf das Prefab, für das es steht: public GameObject classPrefab; Anstatt jetzt den Tag des GameObjects einzustellen, ziehst du auf jeden deiner Klassen-Auswahlknöpfe das jeweils passende Prefab. Als nächstes nehmen wir uns das Script vor, das in Szene 2 dieses Prefab instanziieren soll. Es kriegt ebenfalls ein Feld für ein Prefab und spawnt dieses einfach nur: public GameObject prefabToSpawn; private void Start() { Instantiate(prefabToSpawn, transform.position, transform.rotation); } Ich habe für Position und Rotation hier die Position und Rotation des GameObejcts genommen, auf die du das Spawner-Script ziehst. Dann kannst du deinen Spawner in der Szene platzieren, um zu entscheiden, wo man spawnt, anstatt dafür den Code ändern zu müssen. Jetzt haben wir zwei sehr kleine Klassen. Wir brauchen nur noch eine OnMouseDown-Methode in der ersten, die das eigene Prefab als "prefabToSpawn" der zweiten Klasse angibt und die richtige Szene lädt. Du siehst vielleicht bereits die Vorteile der ganzen Sache. Jetzt haben wir ein Problem, und zwar dasselbe wie vorher auch schon. Das Objekt, dem wir etwas mitteilen wollen (nämlich das mit der Spawner-Klasse darauf in der zweiten Szene) existiert noch gar nicht zu dem Zeitpunkt, wo wir in Szene 1 auf den Knopf klicken. Hier gibt es mehrere Lösungen, wie man eine Information an einem Ort hinterlegt, der nicht zusammen mit der Szene gelöscht wird. Ich zeige dir mal die einfachste, auch wenn es andere mit zusätzlichen Vorteilen gibt. Das Schlüsselwort static wird oft missverstanden, sei also vorsichtig, wenn du selber noch einmal danach suchst. Ich erkläre mal: Wenn du ein Feld anlegst, also eine Variable außerhalb einer Methode, dann gehört sie zum Zustand des Objekts. So hat z.B. Unitys "Light"-Komponente ein Feld "color", das die Farbe des Lichts angibt. Wenn du zwei Lichter hast, dann kannst du das eine rot und das andere blau machen, denn "color" gehört zum Objekt. Wenn du ein Feld allerdings als "static" markierst, dann gehört das Feld nicht mehr zum Objekt, sondern zur Klasse selbst. Wäre "color" als "static" markiert, dann würden alle Lichter immer dieselbe Farbe haben. Dadurch, dass statische Felder eben nicht zum Objekt gehören, gehen ihre Werte bei einem Szenenwechsel nicht verloren; denn das passiert ja dadurch, dass die Objekte gelöscht werden. Wir ändern deshalb die erste zeile des Spawner-Scripts ab und fügen ein "static" ein: public static GameObject prefabToSpawn; private void Start() { Instantiate(prefabToSpawn, transform.position, transform.rotation); } Wenn wir die Farbe eines Lichts ändern wollen, dann müssen wir definieren, welches der vielen Lichter wir überhaupt meinen. Sonst weiß Unity ja nicht, welches Licht ab jetzt weiß leuchten soll. Das macht man über die Punktnotation, also "irgendeinLicht.color = Color.white;". Da statische Variablen eben nicht mehr zu den Objekten gehören, sondern nur noch einmalig Teil der Klasse sind, benutzt man die Punktnotation zusammen mit dem Klassennamen. Nehmen wir also an, das Script mit der statischen Variable heißt "PlayerSpawn", dann müssen wir schreiben: PlayerSpawn.prefabToSpawn = irgendeinPrefab; und genau das machen wir jetzt in OnMouseDown der Klassenauswahl-Knopf-Klasse: public GameObject classPrefab; private void OnMouseDown() { PlayerSpawn.prefabToSpawn = classPrefab; SceneManager.LoadScene("Welt_01"); } Wenn du also auf dieses Objekt klickst, wird das Prefab, das du beim jeweiligen Knopf im Inspektor reingezogen hast, in der PlayerSpawn-Klasse registriert. Wenn dann der Szenenwechsel passiert, hat das Feld "prefabToSpawn" immer noch dieses Prefab referenziert und die Start-Methode greift darauf zu. Das alles in wenigen Zeilen Code, ohne Strings, ohne Tags, und wenn du eine weitere Klasse zu deinem Spiel hinzufügen willst, dann baust du einen neuen Button und ziehst das Prefab der neuen Klasse hinein und bist fertig. Ich hoffe, das hilft dir weiter, vielleicht nicht nur bei diesem einen Problem
  5. 1 point
    Okay, also VVVVVV in 3D...? Ich muss zugeben, dass ich nicht verstehe. Denn genau das war doch das Ziel, oder nicht? Du willst, dass deine Spielfigur sich um die eigene Y-Achse dreht, und dazu noch um eine weitere Achse (hier die des Würfels), damit sie am Ende kopfüber ist und an der Decke läuft?
  6. 1 point
    Hast du Bilder? Ich kann mir das gerade nicht vorstellen.
  7. 1 point
    Was hältst du davon, ein GameObject zu haben, das sich einfach nur nach der Gravitation ausrichtet, und diesem Objekt die Spielfigur unterzuordnen - diese dreht sich dann relativ zu ihrem Parent?
  8. 1 point
    Ja, der Unterschied ist groß. Die 1060 (habe ich) ist ca. 3 Mal so schnell wie die 660TI (hatte ich). Da ich bei meinen Flippern die 660 als empfohlene Graka angegeben habe, schaue ich immer, dass meine Tische (in HD Auflösung und wenn alle Posteffekte an sind) immer über 180fps liegen. Dann kann ich sicher sein, dass sie auf der 660 mit 60fps laufen.
  9. 1 point
    Moin, wollte auch mal meine gesculpteten Modelle posten. Evtl - sofern jemand interesse hat, kann ich gerne den ein oder anderen in ein low poly Modell umwandeln und dann als GameAsset zur Verfügung stellen. Alle Modelle wurden in Zbrush erstellt.
  10. 1 point
    Wahrscheinlich bewegst du die Kugel nicht über die FixedTime sondern in der Update. Dadurch ist das Ganze nicht mehr synchron. Wenn du Rigidbodys bewegst, dann immer in der FixedUpdate und auch nur mit physikalischen Befehlen um die Physik im Spiel synchron zu halten und richtig berechnen zu lassen. Es sollte schon reichen, wenn du die Interpolation der Rigidbodies auf Interpolate stellst, um das Zittern zu umgehen. Warum hast du denn bei der Kugel die Schwerkraft an? Man sieht im hinteren Bereich des Films, dass die Kugel selbst am Zittern ist, also scheinbar die Schwerkraft gegen dein Bewegungsscript arbeitet.
  11. 1 point
    Ja, ganz am Anfang war es eine kleine Idee und ich habe einfach mal versucht die Physik in den Griff zu bekommen, denn es sollte ja alles physikalisch ablaufen. Nur Schwerkraft, Reibungen und Kollisionen. Inzwischen habe ich ganze 2 Arbeitsjahre in das Projekt investiert und ein gutes halbes Jahr wird es noch dauern, bis es komplett ist.
  12. 1 point
    Junge Junge! Ich habe hier ja ewig nichts mehr geschrieben, dabei gibt es viele Neuigkeiten zu berichten. Seit dem November ist mein neuester Flipper "Playground" erhältlich. Dieses Mal ist ein Spielplatz das Thema und alles ist farbenfroh, süß und recht einfach. Aber es ist noch viel mehr passiert. Mir war gar nicht bewusst, wie viele Leute es gibt, die sich einen virtuellen Flipper als Cabinett bauen, also quasi einen Flippertisch mit seitlichen Knöpfen und mit Display da drin. Zuerst meldete sich jemand, der sogar einen 21:9 Monitor verbaut hat. Für diesen Ultrawide-Monitor im Hochkantformat hatte ich gar keine richtige Auflösung parat. Denn damit das Spielfeld da richtig rein passt, muss eine extra Ratio erstellt werden und alle Kamerapositionen müssen viel höher liegen. Das ist zwar erstmal nur ein Prototyp, aber trotzdem geil. Auf dem Bild ist momentan noch keine 21:9 Auflösung zu sehen. Aber das geht inzwischen. Wenn ihr wissen wollt, wie man sowas baut, dann schaut hier: https://www.instructables.com/id/Flipperkonsole-Für-PC-Flipper-Pinball-Console-for-/ Ja und dann gibt es die Jungs, die komplette Flippertische bauen und das Ganze dann mit der Software PinballX betreiben. Die Jungs haben einen eigenen Monitor für den Flipperkopf, wo dann sogenannte Backglass und die Scoreanzeigen zu sehen sind. Damit das alles mit PinballX funktioniert, müssen die Flipper einzeln startbar sein. Das habe ich denen mit Command-Line-Befehlen möglich gemacht. Es ist jetzt also möglich die Tische direkt zu starten, ohne dass man in das Intro und das Menü rein kommt. Falls euch das Interessiert dann schaut hier vorbei: https://www.pinballx.com/ Dort git es einen Link zum Forum und im Unterforum "User Projects" wird beschrieben, wie man die Software bestücken muss, damit meine Tische super laufen. Ja und momentan bin ich an meinem neuesten Tisch dran. Aber bis der Fertig ist, dauert es noch ne Weile. Hier ist schon einmal das von mir gemalte Backglass zu sehen:
  13. 1 point
    Hallo, da der Server seit einiger Zeit ziemlich stabil läuft, habe ich mich entschlossen, ihn öffentlich zugänglich zu machen. Man kann zwar noch nicht von einer Fertigstellung sprechen, freue mich aber ankündigen zu dürfen, dass sich Canyonbreed in einer EarlyAccess Alphaphase befindet. Es ist online spielbar und der Server ist nun rund um die Uhr erreichbar. Ich lade jeden Interessierten dazu ein, sich den Client herunterzuladen und mal rein zuschauen. Nach Aussagen von einigen Testspielern ist bereits Spielcontent für mehrere Stunden vorhanden. Ich entwickle nach wie vor alleine, ein AAA-Titel sollte von daher nicht erwartet werden. Download: http://www.canyonbreed.de/download/ (Windows, 387MB) Discord-Link: https://discord.gg/agpTqyd Wie ihr Euch vorstellen könnt, nimmt so ein Projekt sehr viel Zeit in Anspruch und mache die Weiterentwicklung von der allgemeinen Resonanz abhängig. In der heutigen Zeit ist es unglaublich schwierig, ein Spiel wie dieses zu platzieren, gerade weil es vom Setting her eher eine Niesche ausfüllt. Ich habe jedenfalls enorm viel in Sachen Entwicklung und Multiplayer gelernt, es war also nicht vergebene Mühe und wusste von Anfang an, das es hart wird. Aber mal sehen, als Vorzeigeobjekt reicht es allemal. Sunroc
  14. 1 point
    Die XYValue-Objekte sind globale Variablen. Die sind potentiell für alle anderen Objekte einsehbar und existieren jeweils nur einmal. Oft ist das natürlich Quatsch, und man will stattdessen ganz normale Felder haben. Die XYReference-Klasse erlaubt es, Klassen zu schreiben, bei denen man pro Objekt entscheidet, was von beidem man benutzt. Beispiel Health-Klasse. Wäre doch super, wenn man einfach nur "Health" hätte, statt "PlayerHealth" und "EnemyHealth". Ein wichtiger Unterschied dieser beiden Klassen ist, dass die tatsächliche Lebenspunkte-Zahl beim Player eher eine globale Variable sein sollte, also z.B. IntValue, bei Gegnern allerdings ergibt das keinen Sinn. Nicht nur, dass die HP jedes einzelnen Gegners nicht relevant sind, sondern auch, dass es beliebig viele Gegner geben kann, man aber nicht beliebig viele IntValues für alle machen kann. Daher gibt man der Health-Klasse, die am Ende Spieler und Gegner benutzen, ein IntReference-Feld. Im Editor stellt man dann beim Player auf Value-Objekt und zieht das IntValue-ScriptableObject hinein, dessen Wert auch vom UI angezeigt wird, und beim Enemy-Prefab stellt man auf lokales Feld, sodass jede Instanz des Prefabs seine eigene Variable benutzt.
  15. 1 point
    Witzig, dass dein Benutzername auf einen Programmierer hinweist, wo wir jetzt sehen, wo deine wahren Stärken liegen
  16. 1 point
    Die Antwort wird dir vielleicht nicht gefallen, aber: Mit Direct Input geht das einfach nicht. Stattdessen musst du dir die XInput.dll besorgen und in dein Projekt einbinden. Die unterstützt separate Inputs für die beiden Trigger hinten, und dazu noch Kontrolle über die Vibrationsfunktion des Gamepads. NGHGNGHG mal wieder zu langsam wa. Den C#-Wrapper kannte ich aber auch noch nicht, ich benutze ja meinen eigenen. Gut zu wissen.
  17. 1 point
    Puh! Du musst echt noch ein wenig an deinem Codeverständnis arbeiten. Vorallem an der Logik von Abfragen und den Zuständen von Variablen, Komponenten und Gameobjekten. Vorneweg: Ich sehe jetzt selber keinen Grund, warum das eine geht und das andere nicht. Ich sehe aber auch nicht wo gameStarted gesetzt wird. Trotzdem werde ich dir mal den Code zerpflücken und dir hoffentlich etwas Klarheit geben. if (this.GameObject != null) This ist die Klasse selbst, in der diese Abfrage steht. Dieses Script liegt auf einem Gameobject in der Szene. Das muss sogar so sein, denn in einer Szene kann keine Komponente existieren, wenn sie nicht auch auf einem Gameobjekt liegt. Somit ist die Abfrage komplett sinnlos. Du denkst dir jetzt sicherlich, dass es doch auch Klassen gibt, die nicht auf Objekten in der Szene sein müssen und trotzdem funktionieren, so wie die Mathf. Klasse. Ja natürlich. Diese sind aber Static und laufen nicht selbstständig ab. Erben also nicht von Monobehaviour, und haben auch keine Awake/Start/Update Funktionen. if (this.GameObject != null && gameStarted) Irgendwo wird diese Variable aus irgendeinen Grund auf true gesetzt. Möglicherweise wird sie auch irgendwo wieder auf false gesetzt. Wo, wann und warum diese Variable ihren Wert bekommt, weiß ich nicht. Diese Variable könnte aber eben das Probelm verursachen. if (this.GameObject != null && gameStarted && backgroundMusic =! null) Hier fragst du ab, ob denn die Referenzvariable backgroundMusic, die vom Typ Audiosource ist, auch wirklich auf eine Komponente verweist. Das ist gut, denn wenn man eine Komonente ansprechen will, die nicht bekannt ist, wird ein Fehler ausgeworfen. Ich perönlich würde aber aus Debug-Gründen diese Abfrage einzeln und als erstes machen. if(backgroundMusic=!null){ if(irgendwas){// weitere mögliche Abfragen, wenn nötig // hier die Audiosource steuern } } else{ // Hier springe ich nur rein, wenn die Variable keinen Verweis auf eine Komponente hat. print("backgroundMusic hat keine Audiosource zugewiesen"); } Wenn du also keine Komponente zugewisen hast, würde der Code idr eine Meldung raus werfen. Damit hättest du eine Fehlerquelle schon einmal abgedeckt. if (this.GameObject != null && gameStarted && backgroundMusic =! null && !musicPaused) Wieder eine Variable, die du irgendwo setzt, wenn irgend etwas eintritt. Auch hier weiß ich nicht wo und wann das passiert. Diese Abfrage machst du gleich 2 Mal hintereinander, denn in der nächsten Zeile if(!backgroundMusic.isPlaying && !musicPause) steht sie wieder drin. Oder ist das etwa eine weitere Variable, weil musicPause ohne D da drin steht? Wenn's eine weitere Variable ist, dann ist es ganz blöd, davon gehe ich jetzt mal nicht aus. Du hast wahrscheinlich nur einen Fehler beim Übertragen des Codes gemacht. Da aber in deiner oberen Abfrage schon klar ist, dass der Code nur dann ausgeführt wird, wenn musicPaused false ist, ist eine weiter Abfrage sinnlos und verkompliziert nur den Code und dessen Lesbarkeit. Wenn alle deine Bedingungen wahr sind, den das macht ja eine if-Abfrage, das ermitteln ob alle Bedingungen zusammen true oder false ergeben, dann wird die verknüpfte Audiosource gestartet. Also nur, wenn deine Audiosource nicht schon was abspielt, wird sie gestartet. Du siehst also, dass es schwierig ist, deinen Code zu entschlüsseln, weil zu viele unnötige Abfragen da drin sind. Außerdem werden Variablen abgefragt, über dessen Zustände wir nichts wissen. Wann und vorallem warum wird musicPaused und gameStarted auf true bzw. false gesetzt. Sind diese 2 Variablen evtl. noch woanders mit der Audiosource verknüpft und hebeln sich dewegen aus? Ich weiß es nicht. Aber du kannst es rausfinden.
  18. 1 point
    Ich sag immer: Wenn du ein Script namens "GameManager" hast, läuft direkt etwas falsch. Aber dennoch ist dieser Weg sehr verbreitet. Man muss immer ein bisschen aufpassen - bei Unity gibt's wie bei PHP sehr viele Tutorials von Leuten, die selber nicht so richtig Ahnung haben.
  19. 1 point
    Ok , jetzt müsste es gehen, kA. aber es steht immer für Publikum und dann muss ich es immer nachträglich ändern. Wie immer sitzt das Problem zwischen Stuhl und Tastatur 😂. Lg Ricky-W P.S. Sollte ein Kinderspiel werden
  20. 1 point
    Wenn du mich fragst, dann schonmal nicht mit einem Script, das "GameManager" heißt Ich hab mal ein kleines Beispielprojekt für Architektur gemacht: https://gitlab.com/FlaShG/Unity-Architecture Schau dir da mal unten die Beschreibung an, da stehen ein paar Dinge, die ich für wichtig halte bei guter Architektur. Du kannst dir das Projekt auch herunterladen, ansehen, ausprobieren und auseinandernehmen.
  21. 1 point
    Also bei der Firma wo ich als Fachinformatiker für Systemintegration arbeite (was auch nicht nur Kabel am Monitor stecken ist, auch hier gehört nicht selten Skripting dazu) hat kürzlich ein Praktikant erfolgreich als Teil seiner Umschulung mit 40 Jahren es zum Fachinformatiker für Systemintegration gemacht. Bei seiner Umschulungsgruppe war er auch nicht der älteste. Dieser Praktikant hatte zuvor noch nie etwas mit IT zu tun gehabt. Ich arbeite eng mit der Nachbarabteilung Anwendungsentwicklung zusammen, tatsächlich besteht nur ein kleiner Teil deren Arbeit aus Programmieren. Es ist viel mehr Wartung, Administration und konfiguration von Applikationen und deren Anbindung an anderen Systemen. Ansonsten verbringen die Kollegen viel Zeit mit SQL-Abfragen. Das ist aber natürlich bei jeder Firma anders.
  22. 1 point
    Nö! Ich selber bin jetzt 50 und habe den Schritt in meine Selstständigkeit vor fast genau 2 Jahren gemacht. Klar ich habe in allen Bereichen, die ich brauche, Erfahrungen und Wissen. Aber dass ich jetzt irgendwo ein Meister wäre, kann ich nicht sagen. Muss man auch nicht unbedingt. Klar, warum denn nicht? 34 ist ja nun kein Alter! Wenn du dich Umschulen lässt, dann lernst du ja was dabei. Natürlich brauchst du immer auch Erfahrungen, die dich festigen. Aber die bekommst du sau schnell. Wenn du die Erfahrungen für die nächste Situation nutzt, also abrufen kannst, weil du sie nicht wieder vergessen hast, dann wirst du deinen Weg machen. Ich kenne Leute, die ihre Erfahrungen nicht abspeichern und somit immer auf einem Level bleiben. Solche Leute werden nix. Aber die sind auch selten. Das weißt nur du alleine. Du programmierst ja schon ne Zeit lang und kannst ja auf deine Anfänge zurück blicken. Hast du was gelernt? Ja? Dann bist du wahrscheinlich auch geeignet. Klar, es gibt natürlich Hürden in der Anwendungsprogrammierung, wenn es z.B. in die höhere Mathematik geht, oder der maximalen Optimierung des Codes und dessen Zeitverbrauch. Und natürlich ist es immer so ne Sache, wenn man z.B. ein Sicherheitssystem erstellen soll, was auf gar keinen Fall irgendwelche mögliche Lücken oder Fehler enthält. Trotzdem kann man alles lernen und irgendwann richtig schwierige Dinge bewerkstelligen. Man kann! Ob man es auch schafft in die oberste Klasse zu kommen, weiß niemand. Aber wenn man es nicht versucht, wird man es nie wissen. Wenn dir das Prgrammieren spaß macht, egal für welchen Bereich du programmieren wirst, dann versuche es. Irgendwas arbeiten, nur um Geld zu verdienen, kann man immer. Aber etwas, was einem auch Spaß macht oder was einen zufrieden stellt, dass sollte jeder tun, denn das ist das Beste! Egal ob der Verdienst dann besonders gut ist, oder nicht. Was sich daraus entwickeln wird, kann man eh nie sagen. Mal geht's ab wie ne Rakete, mal bleibt man stecken und meistens geht es zufriedenstellend weiter. Man sollte es aber wenigstens einmal versuchen! (Ist meine persönliche Meinung)
  23. 1 point
    Hey, auch wenn ich nicht in der gleichen Situation wie du steckst, will ich dir gerne meine Meinung und Ratschläge mitteilen. Ich selbst bin erst 22, studiere Wirtschaftsinformatik (davor reine Informatik(gewechselt)) und arbeite jetzt seit ca. 1 Jahr als Softwareentwickler (Werkstudent). Davor konnte ich schon als Dozent & Webentwickler tätig werden. Dabei ist mir aufgefallen das Alter nur eine Zahl ist. Lass dich also nicht von deiner Idee abhalten. In meinen ersten Studium hatte ich eine bekannte die mit 52 nochmal angefangen hat zu studieren, obwohl sie fest im Sattel saß und mehr als ausreichend Geld verdient. Aber ihr machte das Entwickeln/Knobeln/Umsetzen einfach Spaß und sie kann/konnte sich halt vorstellen als Entwicklerin zu Arbeiten. Auch habe ich einen Kollegen (34) der seine Ausbildung zum Anwendungsentwickler gerade erst beendet hat und er geht darin voll und ganz auf. Ob das auch für dich zutrifft? Schwer zu sagen. Zum professionellen Entwickeln gehört mehr als nur der Spaß am programmieren. Aus meiner Erfahrung sind das drei wichtigste Punkte: 1. Frustresistenz. Dir werden besonders zu Beginn viele Fehler unterlaufen und vieles wirst du auch einfach noch nicht verstehen können. Damit muss man umgehen können, den an der nächsten ecke wartet wieder eine Exception. 2. Googeln ist eine Fähigkeit! Ja ohne scheiß, du wirst lernen die Suchleiste von Google/Reddit/Stackoverflow vollständig zu missbrauchen. Denn für die ganzen Fehler die Auftreten, brauchst du Lösungen und manchmal ist es einfacher Google zu benutzen, als stundenlang selbst über die Lösung zu grübeln. 3. Wissen ist macht. Dir werden im Berufsleben viele Techniken über den weg laufen. Seien es Programmiersprachen, Entwicklungsformen (Agile Entwicklung, Prototyping, usw) oder Denkweisen (Objektorientiert, funktional, usw). Du kannst nicht alles wissen oder können, aber ist immer gut für neue dinge offenen zu sein und vllt. auch mal seine Arbeitsweise anzupassen. Ich hoffe ich konnte dir etwas helfen 🙂 Gruß Timm
  24. 1 point
  25. 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!

Announcements

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

Weiterleitung zum Entwickler "daubit"



×