Ich versteh die Vorurteile gegenüber Engines. Das Unity-Intro zu vertonen war bei mir ja auch Jahrelang ein Running Gag und schon am Look vom Spiel erkennen zu können auf was für einer Engine ist läuft ist halt selten ein gutes Zeichen. Ich schau dich dabei an Unreal Engine 3. Allerdings kratz ich mir jedes mal den Kopf wenn jemand in den Steamforen fragt mit welcher Engine etwas erstellt wurde und man sich weigert etwas zu kaufen wenn es Unity sein sollte. Sobald du nicht auf einen Blick erkennst, dass es eine bestimmte Engine ist, ist es halt egal. Besonders aber der Konkurrenzkampf verschiedener Engines, ausgefochten von Leuten die nie auch nur einen Editor gestartet haben, geht mir auf die Nerven. Da hast du Leute für die Versionsnummern alles bedeuten und die beim Showcase von neuen Rendermethoden fragen wann das Spiel denn endlich rauskommt. Aber Logos von Technologie im Intro damit selbst ein Ottonormalverbraucher weiß wie die Engine heißt und diese im besten Falle mit einer guten Erfahrung assoziiert ist garantiert kein Versehen.
Selbst ich spiele Unity games wer ein recht gutes game sehen will und noch an Dinosaurier interessiert ist, sollte sich mal Prehistoric Kingdom ansehen^^ ich hab Über Unity damals fly like a Bird gespielt. da war man ne taube oder Schwan oder Falke oder Adler oder oder oder.Die games liefen einfach gut
Ich bin 32, handwerklicher Dienstleister, hab seit 4 Wochen einen PC und letzten Samstag mithilfe von Karel richtig Bock aufs Programmieren bekommen. Von mir wird auch mal ein Rotz-Spiel kommen 😅
@Cyronaut das ist eine Art Lernsoftware. Sie stellt dir Aufgaben, die du auch lösen kannst, ohne vorher einmal ein "Hallo Welt"-Programm geschrieben zu haben :)
@@diarykeeper dann aber bitte komplett an ILCA abtreten. Die Diamond&Pearl Remakes haben ja zu Release einige Probleme gehabt. Alle vermuten, dass es an dem strikten Zeitplan und anderen Entscheidungen lag, die GameFreak vorgegeben hat.
Ori and the Will of the Wisps wurde btw auch mit Unity entwickelt, läuft selbst auf der Switch in tadellosen 60 fps und ist eins meiner Lieblingsspiele aller Zeiten.
Danke für das informative und gute Video. Und deiner immer aufklärenden Art, woran es liegt wenn mal ein Spiel ruckelt. (Gerade bei Unity spielen) Aber bitte pass auf, du könntest bald Post von LEGO Anwälten bekommen, da du „LEGO“ statt „Klemmbausteine“ bei 8:02 gesagt hast.
Man könnte ja meinen, Unity bezeichnet sein Klemmbausteinsystem als Lego, weil es mit dem sympathischen Unternehmen, dessen Name nicht genannt werden darf, assoziiert werden möchte :^)
Danke für das Video, eines vermisse ich als langjähriger Unity Entwickler schon, in C++ benutzt man ja in der Regel keinen Garbagecollector, sondern verwaltet den Speicher selbst. Wenn man in C++ sauber entwickelt erzeugt man keinen Garbage, temporäre Daten werden einfach im Stack untergebracht und der Rest sauber im Heap selbst verwaltet. Ein Garbagecollector mag vielleicht gemütlich sein für nen Hobbyentwickler aber in großen Projekten, vorallem bei Spielen ists eigentlich Käse und meiner Meinung einfach ne falsche Entscheidung für eine Spieleengine. Unerfahrene Entwickler verleitet er dazu komplett die Speicherverwaltung aus den Augen zu verlieren. Eine alte Mono Version (Das C# Framework in Unity) führte zum Beispiel dazu dass selbst einfache Schleifen jeden Frame sinnlosen Garbage produzierten. Einige Probleme haben sie ja inzwischen gefixt und der inkrementelle Garbagecollector ist auch ne ernsthafte Verbesserung (was in dem Video vermutlich mit der Verbesserung der Mikroruckler gemeint ist). Bin ehrlich gesagt kein Fan von Unity. Unity schleppt massenweise Altlasten in seiner Engine mit noch aus Urzeiten (wie das genannte Terrainsystem) und schafft es nicht richtige Verbesserungen (ECS, Assetbundles ec.), die teilweise bereits seit längerem in unfertigen Zustand in Beta Versionen dümpelt entgültig sauber in Unity zu integrieren. Klar damit ginge die Abwärtskompatibilität verloren und viele Unity Projekte vorallem im Mobile Bereich leben davon Projekte über viele Jahre zu unterstützen. Also Unity hat es schon verdient wenn man ihnen deshalb die Mikroruckler der Engine etwas ankreidet.
@@xtrytry7174 interessant, in einem video, in dem es darum geht, nicht die engine für schlechte performance verantwortlich zu machen, stattdessen die programmiersprache verantwortlich zu machen... abgesehen davon, c++ wurde auch nicht "für spiele entwickelt" und dein kommentar ist viel zu verallgemeinernt
@@xtrytry7174 eigentlich habe ich dich in meinem vorherigen kommentar darauf hingeweisen, dass es eben doch mehr zu sagen gibt, und man nicht immer verallgemeinern sollte
Es ist wohl etwas verallgemeinert C# die Schuld zu geben. Aber ja, C# wurde nicht für performancekritische Software entwickelt und Spiele, die die Grafik technisch an ihr Limit bringen möchten leiden darunter. Aber die meisten Spiele benötigen nicht den letzten Prozent Leistung, sondern wollen durch Artdesign und Gameplay glänzen. Die meisten Systeme heutzutage haben ausreichend Leistungsreserven dass auch ein kleiner Mikroruckler nicht sehr auffällt. Wenn ein Spiel wirklich schlecht oder verbuggt ist, dann ist in der Regel mehr im Argen als dass es einen Mikroruckler an der falschen Ecke gibt oder ein unfertiges Feature von Unity für Kopfzerbrechen gesorgt hat. Unity kann man nicht für ein schlechtes Spiel die Schuld geben, es wurde eben nicht gebaut um den superneuen Grafikknaller zu erstellen. Das befreit Unity aber nicht von berechtigter Kritik.
also ich entwickle jetzt seit etwas über 2 jahren unity spiele und das regelmäßig. Hierbei ist es mir wichtig mich selbst weiterzuentwickeln und nicht code zu kopieren und andere solcher Dinge. Genau weil ich diese Herangehensweise habe wird mir oft gesagt, dass ich für meine "Erfahrung" eigentlich schon zu weit bin was das spieleentwickeln in unity angeht. Hier habe ich beobachtet, dass viele der "schlechten" Unity Spiele von Menschen gemacht wurden die entweder erst blutige Anfänger sind (ist ja keine Schande) oder die einfach keinen Wert darauf legen das gewisse Bisschen "Liebe" oder den "Feinschliff" auf den man stolz sein kann in das Spiel hineinzustecken. Unity ist schlicht weg leichter zugänglich UND weiter verbreitet, als andere Game Engines. Da ist es nur natürlich, dass es auch mehr von solchen Menschen gibt die Unity verwenden, als zB. Godot oder Unreal. Aber zu behaupten dass ein Spiel aufgrund der Engine "Ja so wie so schlecht sein muss" ist natürlich vollkommener Schwachsinn :D
Einfach mal ein danke an dich Christian für den tollen contend und an deine patreons die dafür sorgen das du dich um solche intressanten nichen themen Beschäftigten kannst.
Ich liebe deine Videos! Auch wenn viel Mist anfällt finde ich es gut, dass ein einfacher Einstieg möglich ist. Interesse wecken ist ein guter Anfang um gut zu werden. Was schön wäre, wenn "schlechte" oder "Anfänger" Projekte ein eigenes Label hätten wie "Junior Project"
1:14 dank Unity konnte ich Freelancer werden und arbeite seit Jahren schon für verschiedene Leute. Da ich seit 2013 Unity benutze kann ich sagen, dass es sehr wenig mit Unity zu tun hat, warum Spiele schlecht sind. Dabei bin ich kein Designer, sondern Entwickler und kriege selber schon etwas schöne Dinge hin. Habe sogar mit Leuten gearbeitet, die keine optimierte Version wollten, nur weil sie etwas "bequemer" fanden. Am Ende ruckelt es bei den auch. Also zu CharacterController muss ich sagen ist bissel übertrieben gesagt. Du hast nicht so wirklich die Nachteile genannt, was jetzt nicht so toll ist. Bis jetzt hab ich kaum welche gesehen, die sagten ich benutze es nicht. Selbst in VR games wo ich mitgewirkt habe wurden CharacterController verwendet. Ebenfalls die Levels funktionieren eig gut. Wir arbeiten einem Open World 2D game mit mehreren Scenen. Wir haben sogar Multiplayer Dungeon Instancen geschrieben (bzw ich ^^) und funktioniert richtig gut. Und das mit Unitys SceneManagement. Ist nicht perfekt, aber ist es eig. gut. Mich nervt nur das mit dem lokal raycast und globalen.. also quasi scene.Raycast oder Physics.Raycast. Nervig immer zu checken was benutzt werden kann. Die UI ist auch nicht mein Favorit, aber ich mag es. Wenn man es etwas versteht, wie LayoutSystem aufgebaut ist und sogar seine eigene programmieren kann z.b. Flexgrids dann ist das mega nice. Aber ganz ehrlich. Würde HTML und CSS viel eher haben. PackageManager ist eig. einer tollsten Sachen, was sie einführen konnten. Ziemlich am Anfang warst zwar nervig, aber mittlerweile geht es. Weniger Module, weniger Ladezeit. Ich hab z.B. immer das Problem gehabt, dass ich up-2-date sein wollte. Dank PackageManager kann ich das und auch wenn meine eigene Libraries update kriegen (lokal), dann ist es sofort auf den neusten Version. Klar nervig, wenn man nicht wüsste, dass etwas dort gab, was man braucht. aber sowas braucht halt seine Zeit. Was für mich persönlich in Unity fehlt, dass Sachen im Editor animiert werden, wie in Playmode. Das sieht bei Unreal Engine manchmal schön aus. Und Multi Scene Editing. Sprich, Ich kann mehrere Prefabs öffnen und mehreren Scenen in verschiedenen Fenster öffnen und daran arbeiten. Beispiel, ich möchte die UI nur in einem Fenster sehen.. sonst nix anderes. Das erleichtert mir die Arbeit und muss nicht immer mal rein zoom und rauszoomen. Laut Unity Team ist das überhaupt mit Unity nicht möglich.
Ich liebe Deine Videos, man findet leider viel zu viel Halbwissen im Internet, gut, dass Du das alles erklärst, auch generell bei Deinen anderen Videos👍😁
Ich glaube es gibt genauso viel schlechte Unreal Engine 4 Spiele wie es schlechte Unity Engine Spiele gibt. Das Problem ist nicht die Engine sondern derjenige der das Werkzeug falsch nutzt. VRchat ist mit Unity, Ori and the Will of Wisps ist mit Unity und noch viele weitere Spiele wo man es gar nicht erahnt.. Das mal vorab und nun schau ich mir das Video an xD
Ja... GTA Trilogy ist mit Unreal Engine gemacht, da meckert aber irgendwie keiner über die Engine :/ Da wird den Entwicklern/Publisher die Schuld gegeben.
Ich würde heucheln, wenn ich sagen würde, dass ich nie diese Vorurteile gegenüber Engines hatte, aber seit ich den Kanal verfolge, bekam ich mehr und mehr eine andere Sicht auf die Sache womit auch diese Vorurteile niedriger wurden bzw man weiß dann halt, wie diese Vorurteile entstehen.
Ich liebe dich soo sehr für den Vergleich zum zeichnen! xD *hust* Copics *hust* 🤣 IMMER WIEDER: Anfänger, wollen gleich die teuersten, besten Stifte haben, und wundern sich dann, warum das nicht wirklich viel besser aussieht als mit den Günstigsten stiften. Klar, sind nicht alle so... aber es ist in jedem Hobby, Berufszweig etc so. Es gibt eben jene, die sich da gefühlt selber ins aus schießen...
Cooles und informatives Video auch wenn ich nicht so ganz zustimme. Ich denke wenn viel Aufwand / Fehlerpotential dahintersteckt um Memory Leaks zu verursachen liegt das durchaus auch am Aufbau der Engine und nicht nur an den Entwicklern. Bin selbst Softwareentwickler wenn auch nicht im Gaming Bereich und bin froh das ich zu einem Großen Teil Programmiersprachen/Frameworks verwende bei denen man sich nicht andauernd manuell darum kümmern muss sondern nur in Ausnahmen. Auch hier muss man wissen was man tut und wann es solche Ausnahmen gibt aber so wie sich das Video anhört stellt Unity einen da wohl doch vor ein sehr großes Fehlerpotential.
Hallo ! Erstmal vielen Dank für dieses Video, das mich wieder einmal darin bestärkt hat, bei Unity zu bleiben. Ich muss dazu sagen, ich bin mit dem Erlernen von Unity noch ziemlich am Anfang. Konnte erst Anfang September letzten Jahres damit anfangen, aber je mehr ich da Einblick bekomme, desto mehr macht Unity Spaß. Mit der Unreal Engine hatte ich nur Probleme - ja, ich gebe zu, irgendwann hat mich Unity mal ziemlich gestresst und ich dachte, versuche ich die Konkurrenz mal, vielleicht geht es mit der einfacher. Von wegen. Die UE ließ sich auf meinem PC nicht einmal starten. Bei jedem Startversuch wollte sie mir erzählen, eine bestimmte .dll würde fehlen. Ich habe nachgesehen - diese DLL war auf meinem PC sogar 3 mal vorhanden (!), sogar in dem Order der UE, denn die wurde mit dieser herunter geladen. Und trotzdem erzählte die UE mir, die sei nicht vorhanden. Auch der Versuch, die UE wieder zu deinstallieren machte Probleme. Unter anderem, weil dieser Epic Launcher ständig im Hintergrund läuft, was ich damals noch nicht wusste und ich brauchte etwas Zeit, um herauszufinden, daß der eben das Problem mit dem Deinstallieren war. Ich musste, da sich der nicht einfach ausschalten ließ, wenn er mal läuft, den PC rebooten und dann konnte ich beides deinstallieren. Sowas halte ich für völlig daneben. Zu xTry try möchte ich z.b. noch sagen: 1. Ein Spiel mit 100 GB möchte ich nicht runterladen müssen ! Das würde bei mir ewig dauern ! Außerdem ist Speicherplatz noch immer kostbar. 2. PC-Spiele sind out. Wenn PC, dann kommt für Spieler eigentlich nur noch Online in Frage. Alles andere ist Mobil oder Spielekonsole. Und 3. Unity ist von den graphischen Möglichkeiten völlig okay. Als Beispiel möchte ich Book of the Dead (So heißt das, glaube ich) oder diverse Vergleichsvideos Unity Unreal Engine anführen: da ist grafisch praktisch kein Unterschied zu sehen. Und um gute Grafik zu produzieren, muss man die Engine, die man benutzt wirklich beherrschen, dabei ist es egal, ob es sich um Unity oder um die Unreal Engine handelt. Es benötigt Profis, um in beiden Engines exzellente Grafik hervorzubringen. 4. Ein gutes Spiel erreicht man nicht allein mit guter Grafik. Die Idee ist wichig. Ich habe Spiele, die sind fast 20 Jahre alt und machen mir immer noch Spaß, auch, wenn die hinter dem Standard heutiger Spielgrafik liegen. Um noch einmal kurz auf das Video einzugehen: Ja, was die Terrain Engine angeht, stimme ich völlig zu. Und da gibt es zum Glück das Asset-System von Unity, das ich gar nicht schlecht finde. Man kann sich da für ein Projekt wirklich rauspicken, was man auch wirklich benötigt, kann Assets ganz oder nur teilweise importieren, ganz, wie man es braucht. Und es gibt wirklich für alles ein Asset, und ich rede hier sogar von kostenfreien Assets, die in hoher Zahl im Asset Store zu finden sind. Und ich möchte hier all denjenigen Nutzern und Entwicklern einmal ausdrücklich danken, die diese hilfreichen Assets produzieren und anbieten !!!! Zur Steuerung von Avataren möchte ich noch kurz etwas sagen: Unity hat jetzt, getrennt von den Standard Assets, einen neuen Third -und First Person Controller frisch rausgebracht und die scheinen mir doch echt gut zu sein ... Kurz: Ich bin mit Unity echt zufrieden und wenn man mit dem "Paket" Blender+Unity arbeitet, dann kann man wirklich alles machen, da gibt es eigentlich keine Grenzen mehr. :)
Man sollte vlt erklären, dass C++ eine Sprache ohne Garbage Collector ist. Mikroruckler haben hier einen anderen Grund. Memory Leaks sind bei Sprachen mit GC nicht unmöglich, aber doch eher eine Seltenheit. Das Problem mit zu viel im Speicher, was vom GC aufgeräumt wird, stimmt natürlich. Darauf muss man achten.
Dass es eine kostenfreie Version von Unity gibt, ist doch super! Gerade damit man neue Entwickler züchten kann, ist so was wichtig. Das Problem ist, wenn Steam den ganzen Rotz, der nichts ist, ohne zufragen auch in den Katalog aufnimmt.
Wieviel man letztlich rausholt liegt dann eben doch am Anwender und nicht am Programm. Ich kann es aber verstehen dass auch Anfänger ihre ersten Spiele direkt der breiten Masse zugänglich machen wollen. Es ist einfach der beste Weg um Feedback zu bekommen. Oft überwiegt ja auch der Stolz darüber etwas geschaffen zu haben, auch wenn es technisch nicht perfekt ist. Ein sehr schönes Video was die Problematik gut veranschaulicht hat. Stark! Jetzt ist nur noch die Frage zu klären warum es so unglaublich viel Shovelware für die Wii gab ;)
Super Video, Schade dass du nicht ein paar gute Beispiele für Unity Genannt hast. Ich liebe deine Videos und gucke die meisten mehrfach. Gute "Unity" Spiele sind z.B die Ori Spiele.
Sehr schönes Video Mal wieder, ich bin gerade dabei mich das erste Mal tiefgreifender mit den ganzen Systemen von Unity zu beschäftigen, da ich in meiner Ausbildung ein Schulungsprojekt zu einer von mir ausgesuchten Software machen soll. Aus irgend einem von Selbsthass geprägten Grund kam ich auf die Idee Unity zu nehmen..... Naja, jetzt versuche ich gerade den Unity Shadergraph so zu verstehen, dass ich in snderen, die keine Ahnung haben erklären kann. Immerhin habe ich schon Mal ein kleines Spiel gemacht und muss deshalb nicht bei Null anfangen. Trotzdem sehr lustig....
Was ich noch zu der Liste hinzufügen würde, was bei Unity echt schrecklich ist: Das Serialization-System. Auch davon bekommt man als Spieler am Ende nichts mehr mit, genau wie die anderen von dir aufgezählten Punkte... aber meine Güte. Wenn man sich in dem Editor selbst mit der Serialization auseinander setzt.. das ist eine pure willkürliche Hölle, die mehrere eigene Studiengänge füllen könnte >_>
Das mit dem Garbage Collector stimmt nicht so ganz. C# hat einen implementiert in der Sprache selbst, C++ nicht. Wenn man also in C++ programmiert, dann gibt es 3 Möglichkeiten mit dem Speicher umzugehen. 1. Einfach alles im Speicher lassen. Funktioniert aber nur so lange bis der Speicher voll ist, danach schmiert das Programm ab . 2. Den Speicher manuell leeren. Dass heißt, immer wenn ein Objekt nicht mehr gebraucht wird löscht man ihn durch das Ausführen eines Befehls. Das ist somit das Beste was man programmieren kann. Dort muss kein Algorithmus drüber laufen, der schaut ob etwas noch gebraucht wird. Macht man jedoch einen Fehler, dann kommt es zu Memory Leeks oder Systemabbrüchen und dass passiert schnell. 3. Einen Garbage Collector implementieren. Der funktioniert so, wie im Video beschrieben. Sowohl Unity, als auch Unreal sind in C++ geschrieben und haben einen Garbage Collector implementiert. Und zugegeben es ist auch die beste Lösung, wenn man schnell und einfach Programmieren als Prämisse setzt. So gut wie jede Engine setzt auf dieses Prinzip. Natürlich kann man hier immer den Benutzer die schuld geben. Aber wenn eine Engine schlecht programmiert ist, dann bringt es auch nichts, wenn man der beste Programmierer der Welt ist. Produziert also eine interne Funktion viel Garbage, der nicht seien müsste, dann trägt die Engine zumindest eine Teilschuld. What's that? A new challenger approaches! Darf ich vorstellen: Rust. Gehen wir zurück zu 2. aber nehmen das manuell weg. Diese Sprache wurde von Anfang an um dieses Problem designt. Sie ist noch sehr jung (2010 bzw. 2015 die erste stabile Version), macht aber schnell und viele Fortschritte. Dementsprechend gibt es noch nicht viele und ausgereifte Engines, sind jedoch auf dem Vormarsch. Eine die ich aktiv verfolge ist "Bevy" eine ECS-Engine ohne Garbage Collector dank Rust. Ich muss hier als Programmierer weniger wissen und mache dennoch weniger Fehler.
Stimmt, ich habe es in dem Fall auch sehr versimplet dargestellt. Ich denke eben weil Unity und Unreal so verbreitet sind gibt es in dem Fall kaum interne Sachen, die viel Garbage erzeugen. Eher Funktionen von der Engine sollten beobachtet und die Dokumentation gut gelesen werden. Aber das meinte ich auch mit, dass es natürlich Optimierungen gibt. Früher z.B. hat Camera.main immer GameObject.FindWithTag("MainCamera") aufgerufen, was langsam war und Garbage erzeugte. Heute cachet die Engine das Ergebnis, was man eigentlich als Programmierer selbst machen sollte. Ich habe aber schon genug "professionellen" Code gesehen, der z.B. einen Typewriter Effect für Text erzeugte, in dem er via Substring immer einen neuen String erzeugt hatte, der einen Buchstaben mehr anzeigte. Ist alles grundsätzlich ein Thema, das ein eigenes Video bekommen könnte :)
@@Samb Ich finde, dass Camera.main sehr gut zeigt, dass sehr wohl die Engine eine Teilschuld hat. Programmiert man professionell, dann hat man sich an gewisse Darstellungsregeln zu halten. (Im Falle von C#) Variablen werden in lower Camel Case geschrieben und sagen somit aus, dass diese keine Logik ausführen. Hier bricht Unity durchgängig die Regel, denn durch das Zusammenspiel mit C++ sind die Variablen eigentlich Getter und Setter Funktionen und müssten in upper Camel Case geschrieben werden. Diese sogenannten Property Fields sind eine Mischung aus Variable und Funktion und sollten auch so behandelt werden. Dass heißt keine komplizierte, bzw. aufwendige Logik ausführen. Im falle von Camera.main ist das Cachen das professionelle Verhalten, anders wäre es bei Camera.main() (Man beachte die Klammern!). Damals als ich noch blutiger Anfänger war, habe ich auf die selbe Weise versucht den Typewriter Effect zu erzeugen. Zu der Zeit wusste ich noch nicht einmal, dass es einen Garbage Collector gibt. Und lange Zeit danach war ein String für mich ein Type wie Int und Float. Den Schreibeffekt durch Substrings zu erzeugen beherbergt aber auch noch ein anderes Problem und zwar das plötzliche springen des ersten Wortes der neuen Zeile. Dieses Problem habe ich damals versucht zu beheben und mein Gott war das damals schwer für mich. Ich weiß nicht ob sich in der Hinsicht mittlerweile etwas getan hat. Aber so wurde aus einem Effekt, der damals vielleicht 10 min Implementierungsdauer hatte, mehrere Tage.
@@Samb Ich stimme dir teilweise zu. Wenn man die Schwachstellen der Engine alle kennt, kann man sie ausbessern. Das macht einen guten Entwickler auch quasi aus. Als Anfänger war es für mich vor ein paar Jahren aber echt ein Pain diese Performance Issues alle überhaupt zu finden. Tutorials greifen meist ja nur den imperformanten Einsteiger-Weg auf, etwas zu tun und ohne meine erfahrenen Kollegen wäre ich hinter manches nie gekommen. Die Rider IDE erkennt jetzt ja immerhin viele der Bad-Practices und fixed diese für einen. Irgendwie frage ich mich aber trotzdem, wieso Unity da nicht selbst mehr tut oder zumindest mehr aufklärt. Sie wissen ja auch wo die Schwächen liegen. Deshalb hat quasi jeder offizielle Unity Talk Segmente wo es heißt "ja das haben wir selbst so und so gelöst, weil das in Unity nicht performant läuft".
Resourcenverwaltung mit RAII ist mMn in fast allen Fällen die beste Wahl. Das Schöne ist, es funktioniert nicht nur mit Speicherresourcen. Außerdem ist es viel einsehbarer als GC. Schade das es nicht so häufig wie GC ist.
Ich hab das Video noch nicht gesehen, aber ich hab mir gestern gedacht, dass ich gerne mal wieder ein Video auf diesem Kanal sehen möchte. Sind es bereits Entzugserscheinungen? :D
Das Ding ist Spiele die mit Unity erstellt wurden schrecken mich ersten Moment auch immer ab aber dann erinnere ich mich das Gris auch mit Unity erstellt wurde und ich das Spiel absolut geliebt habe
Reicht ja auch schon wenn der Handwerker das macht 😂 So jetzt mal wieder Spaß beiseite, ich finde es auch immer schade wenn leute unwissend etwas die Schuld geben ohne wirklich ahnung von der Materie zu haben. Mit Unity gab es schon einige meisterwerke, aber die gründe wieso das so ist wurden ja im Video ausführlich genannt.
Ich wusste gar nicht, dass es Leute gibt die Vorurteile haben. Um ehrlich zu sein habe ich wenn dann immer von schlechten Unreal spielen gehört und weniger über schlechte Unity spiele.
Meine Meinung woher das Problem stammt bevor ich das video sah: "es liegt an der großen Anzahl an Anfängertutorials in Kombination mit der großen Menge an kostenlosen oder leicht zu bekommenden Assets, die oft einfach nur kopiert werden ohne das man sich mit der Engine wirklich beschäftigt. Raus kommt ein zusammengeklauter/ kopierter Kram der dann schnell rausgehauen wird um wenigstens ein paar Käufer abzuzocken." So bin mal gespannt worauf das Video hinausläuft und ob mein Vorurteil bestätigt wird ;). Update: jope passt so, gutes Vorurteil :D
Ich habe in meiner Ausbildung Unreal gelernt und liebe es. Für Artists ist es super, man kann so viel erreichen ohne zu Programmieren. Gerade lerne ich Unity und auch C# und hasse es bisher -.- Selbst ein Anfänger Code braucht ewig bis er mal funktioniert und trotz Internet als Hilfe bekomme ich vieles nicht gefixed, mein Dozent braucht oft auch mehr Zeit als ich gedacht hätte. Und ich rede hier von einem max. 15 Zeilen Code. Mal schauen wie es weiter geht.
Wenn man weiß, wie, kann man mit Unity schon einiges reißen. Vor wenigen Tagen hab ich "Praey for the Gods" innerhalb von von 2 Tagen auf der PS5 durch gesuchtet. Das Game wurde vom 3-Mann-Studio No Matter Studios mit eben dieser Engine entwickelt und sie holten so ziemlich alles aus Unity raus, was möglich war.
Hatte neulich mit einem Arbeitskollegen das Thema bei dem ich sagte das die Entwickler das Problem sind und nicht die Hardware. Nach 15 Minuten habe ich aufgegeben da er ja schon etliche Videos gesehen hat in denen immer wieder gesagt wird wie schlecht doch diese und jene Konsole ist weil die Games nicht laufen. Optimierung ist das Zauberwort. Hab ihm sogar noch versucht ihn dazu zu bewegen sich mal ein paar deiner Videos anzuschauen, er war so in seiner Meinung drin dass ichs wirklich aufgegeben habe.
Beim "Garbage Collector" kam bei mir ein wenig der Hass hoch, wegen meines Informatik-Unterrichts. Ja, es ist dort alles Kinderkram, im Vergleich zu großen Spielen und Game Design technisch bin ich auch eher auf der künstlerischen Seite, auch wenn ich's studieren will, aber selbst ich blutiger Anfänger des Programmierens, dacht' mir nur "Was zur Hölle?" Wir haben momentan objektorientierte Programmierung in Java, sollten also mit ausgefüllten Vierecken und Kreisen ein Auto basteln und es "fahren" lassen sobald wir auf einen Knopf drücken. Nur wurde uns das so beigebracht, dass wir für jeden Frame 2 Autos generieren. Ein blaues, welches immer weiter nach rechts neu generiert wird und das gleiche nochmal, in weiß, so wie der Hintergrund, um das alte Auto zu überdecken. Also eine "programmierte Animation". Für 15 Frames dann 30 Autos, das sehen die schwachen Schulcomputer bestimmt gern. Ich jedenfalls nicht...
Ist der Lehrer aus den 70ern? Normalerweise malt man alles in ein BufferImage, das zuvor (gefülltes Rechteck) alle Inhalte gelöscht bekommt. Und wenn man fertig mit der Szene ist übermalt man den Fenster-Canvas mit diesem Buffer. Dadurch wird Flackern (halb gemalte Grafik) verhindert. Der Aufwand jedes mal ein "Löschauto" zu mahlen ist um einiges höher als die GPU ein Rechteck ausmahlen zu lassen. Das hat man vielleicht Anfang der 80er noch so gemacht.
Cool, dass du ein Video über die Unity Engine machst. Ich bin tatsächlich auch von diesem Vorurteil vorbelastet worden, da ich mir als Kind/Jugendlicher viele Spiele im Playstore runtergeladen habe mit der Hoffnung, ich würde ein gutes Spiel zocken. Aber nein, die meisten Spiele waren schlecht und wurden meistens mit Unity erstellt. Daher hab ich persönlich eher negative Erfahrungen durch das Branding bekommen. Nichtsdestotrotz glaube ich dir, dass auch gute Spiele mit dieser Engine bereits erstellt wurden.
Unity ist halt ein Werkzeug, genau so, wie Stifte und ein Blatt Papier Werkzeuge sind. Es kann natürlich sein, dass das Werkzeug nicht besonders gut ist, allerdings ist das ein Aspekt, welcher der Konsument meist nicht mitbekommt. Ich bin gerade im Anfang dabei, Unity richtig zu verstehen und daher kann ich deiner Aussage zustimmen: Unity Learn ist eine super Sache, wenn man ein Thema der Engine verstehen will, die Foren sind super aktiv und mit der Dokumentation hatte ich gute Erfahrungen. Allerdings gibt es so vieles, was Unity übernehmen will/muss als Engine, dass du gerne mal auch Probleme hast mit sehr spezifischen Sachen, welche kaum ein Anderer nutzt. Einfach, weil es so unglaublich viele verschiedene Anwendungen im Bereich von Genres und eigenen Ideen gibt, dass einfach nicht alles abgedeckt werden kann. Wie gesagt bin ich am Anfang und habe daher verschiedene Probleme bisher gehabt, welche ich zum Glück lösen konnte, einfach weil dies generelle Probleme waren wie das verstehen von Physik (wobei ich da immer noch nicht ganz den Dreh mit den verschiedenen Komponenten in dem Bereich raus habe), wie man Packages reinbekommt, wo man was findet usw. Allerdings bin ich da gespannt, wie es sein wird, wenn ich spezielle Anwendungsfälle habe, wo das bisherige System an seine Grenzen bringt. Das werde ich sehen. Ich kann auf jeden Fall etwas vorwegnehmen an meiner spezifischen Erfahrung: Unity ist verhältnismässig Einsteigerfreundlich und simpel. Aber dadurch, kommst du schnell in Situationen, welche nicht per se konfigurierbar genug sind. Und es muss viel zum Editor hinzugefügt werden, damit man das Spiel so hinbekommen will, wie man es in der Vision vor sich hat. Danke für das Video, welches noch einmal etwas mehr Klarheit gibt, welche Rolle Engines und auch andere Tools wie Videoschnittprogramme oder Bildbearbeitungsprogramme in der Erstellung der Produkte spielt: Keine zentrale. Grüsse gehen nebenbei noch raus an Chipflake, dessen süssen Katzencharakter durfte ich mehrmals in diesem Video bewundern.
Bist du irgendwie mit Chipflacke in kontakt oder einfach nur ein fan. Ich find ihn auch ziemlich sympathisch mir fällt es nämlich immer wieder in den Videos auf.
I will lediglich ein kleines Feedback abgeben weil es mir diesmal aufgefallen ist. Gleich am Anfang war eine große Bild-Ton-Schere für mich. Du hast von Digital Foundry geredet und hast ein Gameplay von Yooka-Lylee gezeigt. Ich bin mir unsicher ob der FPS-Test jetzt von Digital Foundry gemacht wurde oder nicht. Aber das passte in meinem Hirn nicht zusammen. Ansonsten wieder mal ein sehr gutes Video gemacht. Freue mich immer ein Video von dir zu sehen.
Ich arbeite seit einigen Wochen mit ein paar Leuten an der Hochschule an einem Unity 2D Projekt, wobei ich mich auch zunächst in Unity einarbeiten muss. Mein Eindruck bisher ist, dass Unity für den Anfang verhältnismäßig intuitiv, aber bei tiefgreifenderen Aspekten sehr "fummelig" sein kann. Dabei hab ich allerdings bei weitem noch nicht Alles wirklich kapiert. So verwirrt mich teilweise noch immer sowas wie Layering, und ich habe noch nicht wirklich Ahnung davon, wie ich Skripte schreibe, sodass manche Objekte auf bestimmte Weise miteinander interagieren können. Aber das kommt wohl mit Zeit und Übung. Abseits davon hat Unity denke ich das "Mario Maker"-Problem. Es ist äußerst zugänglich und bietet prinzipiell die Mittel, großartige Dinge zu erschaffen. Einige Perlen wurden damit bereits erstellt, hingegen gibt es auch viel, viel Müll, was aber eben dann eher die Schuld des Erstellers ist.
Das Problem ist halt auch, dass die Defaults in Unity oft einfach komplett kaputt sind :D Das Object Pooling hast du ja schon erwähnt, dass das normalerweise nicht dabei ist. Ein weiteres klassisches Problem ist, dass die Meshes nicht combined wurden und es kein Tool dafür in Unity gibt, um das per Laufzeit mal schnell zu machen. LODs zu erstellen ist auch ein Pain, wenn du nicht von Anfang an mit Nested Prefabs gearbeitet hast. Dann hast du zu viele Draw Calls und auch zu viele Triangles im Frame und die Objekte werden super teuer initialisiert. Ich glaube, dass es deswegen schon gerechtfertigt ist, Unity die Schuld zu geben. Bessere Defaults könnte die Qualität von allen Spielen anheben.
Ich hatte lange das Vorurteil, dass Charaktere aus der Unreal Engine 3 immer wie Plastikfiguren aussahen, oder dass Metall nie wie Metall, sondern nach Psydo-Plastik-Metall aussah. Erst mit dem allgemeinen Look der UE4 konnte ich mich wieder anfreunden. Ich denke, man kann Engines nicht einen grundsätzlichen Look absprechen, es sei denn, er ist enorm modifiziert. Ich habe halt sehr viele Spiele gesehen, die einen ähnlichen Look wie Gears of War hatten, weil sie halt die UE3 verwendeten. Auch die GoldSource-Engine (Half-Life) hatte einen sehr einprägenden Look, sodass man immer sagen konnte: Jup, das ist diese Engine. Gleiches Ding auch bei der Source Engine. Aktuell verschwimmt das aber zum Glück. Ich würde vielleicht noch sowas noch zur CryEngine sagen, kann aber nicht sagen, warum ich das so fühle. Das ist halt einfach ein Gefühl, dass sich auch nur selten täuscht. Natürlich kriegt man so einen Look wegmodifiziert, aber ich sehe das recht selten.
Ich mochte Unity seit ich vor vielen Jahren Besiege geschenkt gekriegt habe. Die vielen Physikobjeckte die Unity da schaukelt ist immer wieder beeindruckend. Wobei die Entwickler da entsprechend lange dran saßen das möglich zu machen.
Ich weiß dass "die Engine ist niemals Schuld" ein Grundsatz ist, der dir sehr wichtig ist und den du schon seit Ewigkeiten vertrittst. Auch wenn ich durchaus verstehe, was du damit aussagen möchtest und ich dir in vielen Punkten zustimme, muss ich trotzdem sagen, dass diese Sichtweise überhaupt nicht zu meiner eigenen Erfahrung als Entwickler passt und ich der festen Meinung bin, dass die Engine durchaus manchmal die Schuld trifft. Mal ein hypothetisches Beispiel: Sagen wir Toyota hätte ein Auto auf den Markt gebracht, das jedes mal ein einstündiges Beschwörungsritual benötigen würde, um den Gurt anzulegen. Das würde dann schnell dazu führen, dass einfach extrem viele Leute ohne Gurt losfahren würden, was zu deutlich mehr tödlichen Unfällen führen würde. Klar, letzten Endes würde die Schuld dafür bei den Fahrern selbst liegen, denn trotz beschissenem Auto bliebe ihre Verantwortung, sich anzuschnallen, ja bestehen. Es wäre natürlich auch ihre eigene Schuld gewesen, überhaupt erst so ein dummes Auto zu kaufen. Trotzdem fände ich es kurzsichtig, hier zu sagen, dass das Auto und dessen Hersteller nicht zumindest eine Teilschuld trifft, weil Tatsache wäre, dass das ganze nicht so weit gekommen wäre, wenn es besser designed gewesen wäre. Mit Game Engines sehe ich das genauso. Ich meine, alleine die Aussage "die Engine ist niemals Schuld, sondern der Entwickler" stellt für mich bereits ein Paradoxon dar, denn auch Engines werden ja nunmal von Entwicklern gemacht - und natürlich bauen auch die oftmals Scheiße. Genau wie die Endnutzer der Engine. Und die Scheiße, die die bauen, kann sehr oft und sehr leicht dazu führen, dass eine Engine gar nicht oder nur umständlich benutzt werden kann, ohne bestimmte Probleme zu verursachen. Du hast ja selbst sehr viele Beispiele dafür aufgezählt, worin Unity und UE abstinken und wie sehr man sich abfrusten muss, damit zu arbeiten. Meiner Meinung nach ist es da durchaus angemessen, zu sagen, dass die Engine ein Teil der Schuld trifft. Wenn ich erstmal die sieben Tore der Hölle durchqueren muss, nur damit ein bestimmtes Problem in einer bestimmten Engine nicht mehr auftritt, dann ist meiner Meinung nach da nicht allein der Entwickler dran Schuld, wenn er das nicht tut. Die Engine selbst müsste einfach smarter designed sein. Blöde Analogie dazu: Wenn ich eine tödliche Krankheit hätte, bei der ich jeden Tag drei Stunden Sport machen müsste, um nicht zu sterben, dann wäre letztendlich trotzdem die Krankheit Schuld an meinem Tod - und nicht die Tatsache, dass ich diese extremen Bedingungen einfach nicht umgesetzt habe, auch wenn ich ganz theoretisch drei Stunden Sport pro Tag machen könnte. Aus diesen Gründen benutzen wir intern überhaupt keine Game Engines von Außenstehenden, sondern machen alles selbst in C++, obwohl es deutlich aufwändiger ist. Da haben wir aber die volle Kontrolle drüber und können dann eben auch leicht verhindern, eine Engine zu machen, die einen durch ihr mieses Design quasi dazu nötigt, schlechte Spiele zu machen. Wenn dann am Ende trotzdem schlechte Spiele bei rauskommen - ja dann kann man wirklich mit Fug und Recht und ohne Wenn und Aber behaupten, dass die Schuld dafür zu 100% bei uns liegt. Übrigens noch zwei Kleingikeiten zum Thema Garbage Collector: "Den gibt's überall" stimmt ja so jetzt nicht ganz. Bin mir sicher, dass hast du nur zur Vereinfachung gesagt, um deinen Punkt zu verdeutlichen, aber zum Beispiel in C++ und ähnlichen Sprachen gibt es sowas von Haus aus überhaupt nicht. Da gibt es andere Methoden, Speicher zu verwalten, aber zumindest nativ keinen GC. Wir nutzen meist manuelle Speicherverwaltung mit fest vorgegebenen Größen. Das ist mehr Arbeit und weniger Bequemlichkeit, und es führt leichter zu Crashes, aber dafür ist auch alles durchlich planbarer und man merkt sofort, falls man irgendwo ein Budget überschreitet. Solche Ruckler durch Garbage Collection kann's natürlich auch nicht geben. Die zweite Kleinigkeit, die ich zum GC anmerken will, ist dass ich mir recht sicher bin, dass der nicht die einzige Quelle von Mikrorucklern in Unity (und anderen Engines) ist. Da gibt es sicher viel mehr. Zum Beispiel Streaming von Assets, oder bestimmte Tasks, die nur auf dem Main Thread ausgeführt werden können. Klar kann man auch da meist Workarounds nutzen, dass diese Ruckler nicht mehr auftreten, aber auch da ist es erfahrungsgemäß oft so, dass die Engine einem oft keine (oder keine brauchbaren) Alternativen gibt und die somit ein Teil der Schuld trifft. Aktuell arbeite ich beispielsweise an einem Spiel, dass ganz gerne und oft einfach mal Assets im Main Thread lädt, und das führt natürlich regelmäßig zu Freezes. Das ist aber in der Engine vom Spiel einfach so umgesetzt, und das ließe sich auch nicht fixen, ohne die Engine an sich komplett umzuschreiben, was sicherlich viele Mannmonate (wenn nicht Mannjahre) kosten würde. Wo ich wieder beim Punkt bin "die Engine trifft durchaus ein Teil der Schuld". Also... ja. Dem Grundsatz "die Engine ist niemals Schuld" kann ich allerhöchstens nur indirekt zustimmen, indem ich sage "sondern der Entwickler der Engine ist Schuld". Natürlich ist eine Engine am Ende des Tages nur ein Werkzeug, und natürlich ist man zu 100% selbst Schuld dran, wenn man ein Werkzeug falsch benutzt. Keine Frage. Wenn ich einen Hammer benutze, um damit ein Loch zu graben, dann ist es natürlich zu 100% meine eigene Schuld, wenn das besagte Loch scheiße wird, und nicht die des Hammers. Benutze ich hingegen einen Hammer, um einen Nagel in die Wand zu schlagen, und dabei zerbricht der Hammer und fliegt meinem Nachbarn ins Gesicht, dann ist da durchaus der Hammer Schuld dran, obwohl er nur ein Werkzeug ist. Dafür kann ich dann keine Verantwortung übernehmen, auch wenn ich ein anderes Werkzeug hätte nutzen können. Genau aus dem Grund kann ich auch nicht grundsätzlich die Ansicht teilen, dass immer der Entwickler einer Engine Schuld dran ist, wenn ein kaputtes Spiel bei rauskommt.
Wenn man mal drüber nachdenkt sind videogames einfach eine möglichkeit eine komplett eigene welt zu basteln in der man sich auch noch bewegen und aufhalten kann. Einfach unglaublich wenn man drüber nachdenkt 😄
Nein, dank dir nicht mehr. Ich weiß und verstehe jetzt, dass die Entwickler Schuld sind, oder eben die Publisher, die den Entwicklern nicht genug Zeit gaben für Anzahl an Entwicklern... Man siehe das aktuelle GTA Drama. Da wird es auch nicht Unreal Engine sein und ich glaube auch nicht, dass Grove Street Games die volle Schuld trifft. Sie waren einfach viel zu wenige, für solch ein großes Projekt. Erklärt übrigens dein "Unity" Ausdruck aus dem einen Video, wo du so viele schlechte Spiele angesehen hast. Es war die gratis Version von Unity.
Mich erinnern die Aussagen und Vorurteile gegenüber Unity an die frühen 2000er, da gab es nämlich eine Engine der es genauso ging, der RPGMaker2000. Nur waren da sogar noch die Entwicker so frech zu sagen, ja die Engine kann gar nicht mehr, sie schränkt uns ja extrem ein. Nein, tut sie nicht, man kann damit alles skripten, wenn man will. Was sehr viele Projekte gezeigt haben. Die Schwämme an Müllspielen kam heraus, als ein deutsches Spielemagazin aus dem Bauerverlag mit Bravo Branding meinte, diese Spiele zu pushen und sogar Workshops zu den Programm anzubieten, wenn man sich alleine das Beispiel-Spiel von denen anschaut, stellen sich schon die Nackenhaare auf. Dazu kam, dass der RPGMaker2000 lange Zeit gar nicht für den europäischen Markt gedacht war und nur in Japan zur Verfügung stand, ein russischer Entwickler hat das Ding dann ins Englische übersetzt und im Internet verbreitet, übrigens illegal und natürlich ohne Absprache des Entwicklers vom RPGMaker. Diese Version war jahrelang dann das Entwicklertool. Wenn man Leute aus dieser Zeit fragt was sie von RPGMaker Spielen halten, wird man im großen Kontext hören, dass diese Trash sind. Leider wurde der Ruf dieser Spiele, gerade im deutschsprachigen Raum, dauerhaft zerstört. Erst als mit "To The Moon" ein Spiel dieser Szene wirklich mal gezeigt hat, was im RPGMaker steckt, wenn auch schon ein Nachfolger vom RPGMaker2000, hat das Ganze zumindest ein bisschen geradegerückt.
@Walther Penne nanana, so pauschal zu sagen es geht nicht, gibts nicht. Viele Leute die damals behauptet haben x,y oder z geht mit den RPG-Maker nicht, war halt einfach nur Quatsch. Das Ding war damals in der 2000er Fassung schon ein extrem mächtiges Tool gewesen. Fähige Entwickler der deutschen RPG-Maker-Community haben komischerweise nie solche Sätze fallen lassen, eher Leute die nichtmal die grundlegenden Basics der Engine genutzt haben. Da du definitiv bei der Zeit gar nicht dabei warst, kannst du dich gar nicht dazu äußern wie sehr meine Aussage stimmt oder eben nicht. Pauschal zu sagen das meine Aussage nicht stimmt, ist einfach nur ein Armutszeugis und ziemlich dumm dazu.
Ich habe in meinen Leben in drei verschiedenen Firmen mit 3 verschiedenen Softwares gearbeitet (als Sachbearbeiter) und mir kam nie der Gedanke, dass das Entwicklungstool daran Schuld ist wie das System arbeitet (oder eben nicht), sondern diejenigen, welche die Kritik und Wünsche der Mitarbeiter einfach zur Seite schieben.
@@Andy_S79 Ein Hammer bleibt ein Hammer und wird nicht zum Schraubenschlüssel, wenn man gerade eine Schraube nicht mehr lose bekommt. Und Paint war nie Schuld an unserer Kritik :P
1:34 Der Kunst Vergleich hinkt gewaltig. Sicher verbessert man seine "Maltechnik" Aber ein - nicht digitales Bild - ist fertig wenn es fertig ist. Code kann man optimieren, Texturen komprimieren etc... Der Rest ist korrekt. DF hat bei mir ohnehin schon ordentlich and Respekt verloren, weil die sich bald /nur/ noch auf technische Details verlassen. Hard UND Software, muss im Einklang stehen. Das Ying und Yang der Softwareentwickler.
Eine Frage zum Garbage Collector, soweit ich weiß und mein Verständnis von C++ richtig ist, sollte es dort gar keinen geben, sei denn Unreal hat etwas sehr merkwürdiges mit c++ gemacht. In C++ muss jedes mit new (oder malloc, falls das noch irgendwer benutzt, was ich nicht hoffe) erstelltes Object, dass somit im Heap gespeichert wird, mit delete gelöscht werden. Das hat zum einen den Nachteil, dass der Programmierer sich selbst darum kümmern muss, wann das Objekt gelöscht wird, hat aber auch den Vorteil, dass das dann gemacht wird, wenn es weniger weh tut. Zudem werden dann nicht alle Objekte gleichzeitig gescannt, was auch Ruckler vermeidet.
Wenn es um Eigenheiten von Engines geht, muss ich immer an die Creation Engine denken. Die mir leider nach dutzenden Stunden Skyrim und Fallout immer die Savegames auffrisst. Zuerst dauert dann das Laden immer länger und irgendwann ist es dann vorbei und mein Spielstand ist tot. Dann fängt man an mit Savegameditoren rumzufummeln um die Objectlocations zurückzusetzen/löschen um doch noch irgendwie weiterspielen zu können. Wäre toll, wenn sie das bei Starfield mal abstellen würden.
Mal ne technische Frage: Kenne c# bislang nicht, bzw kann es noch nicht. Aber hat nicht nur Java einen garbage collector? Unreal läuft doch zumeist über c++ wo destructor selbst erstellt werden müssen. Oder verstehe ich da was grundlegendes falsch?
Danke für das Video. Die Zusammenfassung der Tools in Unity die dich nerven fand ich am interessantesten. Ich habe auch bereits ein paar Projekte mit Unity gemacht und bevorzuge C# und die UI in ihrer Bedienbarkeit aber schaue auch neidisch zur Unreal Engine für ihren Umfang und Shader-power. Was sind die Gründe für dich bei Unity zu bleiben @sambzockt ?
wäre mal cool wenn du eine must have packages liste erstellen könntest, falls du das nicht schon gemacht hast. Ich blick so gar nicht durch was es da so alles gibt um nen projekt gut zu starten.
Ich finde ein Aspekt, den du noch gar nicht aufgebracht hattest ist der, den die meisten auch nutzen, um z.B. über Unity zu meckern: Voreinstellungen. Sei es die Sonnenposition/Stärke/Farbe, die Physik-Geschwindigkeit oder die Überblendzeit von Kameras in Cinemachine. Viele viele viele Spiele nutzen einfach die Presets und dadurch sehen unglaublich viele Spiele sehr gleich langweilig aus, weil die Engine (zumindest bei URP) zunächst so eingestellt ist, dass es einen möglichst neutralen Look gibt.
@Walther Penne ... Das ist literally mein Job... Überleg bitte, was deine Aussage ist, du sagst hier nämlich, dass die Performance einer Applikation massiv beeinträchtigt wird, wenn die Sonne statt von links von rechts kommt oder statt Gelb Orange scheint...
Der Garbage Collector sollte in Unreal eigentlich eher weniger ein Problem darstellen, da C++ keine managed-language ist und man seinen Müll selbst aufräumen muss. Daher kann der Entwickler genau kontrollieren, wann was gelöscht wird. Dafür ist es auch leichter, Memory Leaks zu erzeugen. Ich möchte damit jetzt jedoch nicht sagen, dass Unreal in dem Punkt besser ist. Ich habe bisher lediglich ein paar Shader für Unity programmiert, kenne die Engine von innen daher zu wenig, um sie zu beurteilen.
Ich mein.. Unreal Engine hat einen Garbage Collector wie Unity und beide können entweder genutzt werden oder man deaktiviert sie und kümmert sich selbst darum. Man muss halt erst mal wissen, das solch Dinge existieren. Denke wäre der GC nicht immer automatisch an würden mehr Leute mitbekommen, dass ihr Code Humbug ist :)
Damals auf der PS3 lief Battlefield 4 nicht so toll. Da haben viele auch gesagt, es würde an der Frostbite Engine liegen. Zu dem Zeitpunkt war die Hardware der PS3 aber einfach veraltet.
hab vor 2sek dein metroid review geguckt und neues video am start 😀
Nur für dich hochgeladen :* :D
hi Max😂
Ich versteh die Vorurteile gegenüber Engines. Das Unity-Intro zu vertonen war bei mir ja auch Jahrelang ein Running Gag und schon am Look vom Spiel erkennen zu können auf was für einer Engine ist läuft ist halt selten ein gutes Zeichen. Ich schau dich dabei an Unreal Engine 3.
Allerdings kratz ich mir jedes mal den Kopf wenn jemand in den Steamforen fragt mit welcher Engine etwas erstellt wurde und man sich weigert etwas zu kaufen wenn es Unity sein sollte. Sobald du nicht auf einen Blick erkennst, dass es eine bestimmte Engine ist, ist es halt egal.
Besonders aber der Konkurrenzkampf verschiedener Engines, ausgefochten von Leuten die nie auch nur einen Editor gestartet haben, geht mir auf die Nerven. Da hast du Leute für die Versionsnummern alles bedeuten und die beim Showcase von neuen Rendermethoden fragen wann das Spiel denn endlich rauskommt.
Aber Logos von Technologie im Intro damit selbst ein Ottonormalverbraucher weiß wie die Engine heißt und diese im besten Falle mit einer guten Erfahrung assoziiert ist garantiert kein Versehen.
Er lebt.
timm du cooler mann wie gehts
Selbst ich spiele Unity games wer ein recht gutes game sehen will und noch an Dinosaurier interessiert ist, sollte sich mal Prehistoric Kingdom ansehen^^ ich hab Über Unity damals fly like a Bird gespielt. da war man ne taube oder Schwan oder Falke oder Adler oder oder oder.Die games liefen einfach gut
@@Blackclaw1000 Da klick ich ganz zufällig mal einen Kanal aus den Kommentaren an und es ist auch n Furry. Cool ::D
@@meta7517 japp Das bin ich :D son zufall aber auch
Ich bin 32, handwerklicher Dienstleister, hab seit 4 Wochen einen PC und letzten Samstag mithilfe von Karel richtig Bock aufs Programmieren bekommen. Von mir wird auch mal ein Rotz-Spiel kommen 😅
@Cyronaut das ist eine Art Lernsoftware. Sie stellt dir Aufgaben, die du auch lösen kannst, ohne vorher einmal ein "Hallo Welt"-Programm geschrieben zu haben :)
@Cyronaut genau :)
Kurz gesagt: Es sind zu 99,9% die Entwickler und nicht die Engine.
Laughs in GameFreak.
GameFreak nutzt ja auch nicht Unity, sondern ihre eigenen Engines.
@@PhilippHorwat nicht immer :)
Ja es scheint so, das Gamefreak unfassbar unfähig ist und war, wenn man die Geschichten kennt.
*Is happy about ILCA*
Die sollten die Reihe an die abtreten.
Sehr fähig.
@@diarykeeper dann aber bitte komplett an ILCA abtreten. Die Diamond&Pearl Remakes haben ja zu Release einige Probleme gehabt. Alle vermuten, dass es an dem strikten Zeitplan und anderen Entscheidungen lag, die GameFreak vorgegeben hat.
Ori and the Will of the Wisps wurde btw auch mit Unity entwickelt, läuft selbst auf der Switch in tadellosen 60 fps und ist eins meiner Lieblingsspiele aller Zeiten.
Hollow Knight auch
Ori hat massive FPS Drops auf der Switch und lädt extrem langsam, dieses Spiel bringt die Switch an ihre Grenzen.
Da dachte ich gerade, ich hätte Lust auf ein Samb Video, da kommt einfach ein neues! Wie super das einfach gepasst hat, ich freu mich!
Danke für das informative und gute Video. Und deiner immer aufklärenden Art, woran es liegt wenn mal ein Spiel ruckelt. (Gerade bei Unity spielen) Aber bitte pass auf, du könntest bald Post von LEGO Anwälten bekommen, da du „LEGO“ statt „Klemmbausteine“ bei 8:02 gesagt hast.
Man könnte ja meinen, Unity bezeichnet sein Klemmbausteinsystem als Lego, weil es mit dem sympathischen Unternehmen, dessen Name nicht genannt werden darf, assoziiert werden möchte :^)
Ich entwickle nicht, aber ich schaue gerne deine Videos. Sie sind sehr interessant.
Danke für das Video, eines vermisse ich als langjähriger Unity Entwickler schon, in C++ benutzt man ja in der Regel keinen Garbagecollector, sondern verwaltet den Speicher selbst. Wenn man in C++ sauber entwickelt erzeugt man keinen Garbage, temporäre Daten werden einfach im Stack untergebracht und der Rest sauber im Heap selbst verwaltet. Ein Garbagecollector mag vielleicht gemütlich sein für nen Hobbyentwickler aber in großen Projekten, vorallem bei Spielen ists eigentlich Käse und meiner Meinung einfach ne falsche Entscheidung für eine Spieleengine. Unerfahrene Entwickler verleitet er dazu komplett die Speicherverwaltung aus den Augen zu verlieren. Eine alte Mono Version (Das C# Framework in Unity) führte zum Beispiel dazu dass selbst einfache Schleifen jeden Frame sinnlosen Garbage produzierten. Einige Probleme haben sie ja inzwischen gefixt und der inkrementelle Garbagecollector ist auch ne ernsthafte Verbesserung (was in dem Video vermutlich mit der Verbesserung der Mikroruckler gemeint ist).
Bin ehrlich gesagt kein Fan von Unity. Unity schleppt massenweise Altlasten in seiner Engine mit noch aus Urzeiten (wie das genannte Terrainsystem) und schafft es nicht richtige Verbesserungen (ECS, Assetbundles ec.), die teilweise bereits seit längerem in unfertigen Zustand in Beta Versionen dümpelt entgültig sauber in Unity zu integrieren. Klar damit ginge die Abwärtskompatibilität verloren und viele Unity Projekte vorallem im Mobile Bereich leben davon Projekte über viele Jahre zu unterstützen.
Also Unity hat es schon verdient wenn man ihnen deshalb die Mikroruckler der Engine etwas ankreidet.
@@xtrytry7174 interessant, in einem video, in dem es darum geht, nicht die engine für schlechte performance verantwortlich zu machen, stattdessen die programmiersprache verantwortlich zu machen... abgesehen davon, c++ wurde auch nicht "für spiele entwickelt" und dein kommentar ist viel zu verallgemeinernt
@@xtrytry7174 eigentlich habe ich dich in meinem vorherigen kommentar darauf hingeweisen, dass es eben doch mehr zu sagen gibt, und man nicht immer verallgemeinern sollte
Es ist wohl etwas verallgemeinert C# die Schuld zu geben. Aber ja, C# wurde nicht für performancekritische Software entwickelt und Spiele, die die Grafik technisch an ihr Limit bringen möchten leiden darunter. Aber die meisten Spiele benötigen nicht den letzten Prozent Leistung, sondern wollen durch Artdesign und Gameplay glänzen. Die meisten Systeme heutzutage haben ausreichend Leistungsreserven dass auch ein kleiner Mikroruckler nicht sehr auffällt. Wenn ein Spiel wirklich schlecht oder verbuggt ist, dann ist in der Regel mehr im Argen als dass es einen Mikroruckler an der falschen Ecke gibt oder ein unfertiges Feature von Unity für Kopfzerbrechen gesorgt hat. Unity kann man nicht für ein schlechtes Spiel die Schuld geben, es wurde eben nicht gebaut um den superneuen Grafikknaller zu erstellen.
Das befreit Unity aber nicht von berechtigter Kritik.
Samb ist zurück!!🧸 Hab in Zwischenzeit deine alten Tweeklis kennengelernt…es war…interessant…
👀💦
Aaaawww! Das Chipflake Plush! Hoffe ihr 2 hattet viel Spaß zusammen ^^ und danke für das super Video, ich liebe deine Art zu präsentieren
also ich entwickle jetzt seit etwas über 2 jahren unity spiele und das regelmäßig. Hierbei ist es mir wichtig mich selbst weiterzuentwickeln und nicht code zu kopieren und andere solcher Dinge. Genau weil ich diese Herangehensweise habe wird mir oft gesagt, dass ich für meine "Erfahrung" eigentlich schon zu weit bin was das spieleentwickeln in unity angeht. Hier habe ich beobachtet, dass viele der "schlechten" Unity Spiele von Menschen gemacht wurden die entweder erst blutige Anfänger sind (ist ja keine Schande) oder die einfach keinen Wert darauf legen das gewisse Bisschen "Liebe" oder den "Feinschliff" auf den man stolz sein kann in das Spiel hineinzustecken. Unity ist schlicht weg leichter zugänglich UND weiter verbreitet, als andere Game Engines. Da ist es nur natürlich, dass es auch mehr von solchen Menschen gibt die Unity verwenden, als zB. Godot oder Unreal. Aber zu behaupten dass ein Spiel aufgrund der Engine "Ja so wie so schlecht sein muss" ist natürlich vollkommener Schwachsinn :D
Der Fehler sitzt vor dem Computer!
Ja ich freue mich auf neue Videos. Durch dich bekomme ich immer wieder Lust zum Programmieren. Ein fettes Danke. ^^
Einfach mal ein danke an dich Christian für den tollen contend und an deine patreons die dafür sorgen das du dich um solche intressanten nichen themen Beschäftigten kannst.
Ich liebe deine Videos!
Auch wenn viel Mist anfällt finde ich es gut, dass ein einfacher Einstieg möglich ist.
Interesse wecken ist ein guter Anfang um gut zu werden.
Was schön wäre, wenn "schlechte" oder "Anfänger" Projekte ein eigenes Label hätten wie "Junior Project"
1:14 dank Unity konnte ich Freelancer werden und arbeite seit Jahren schon für verschiedene Leute.
Da ich seit 2013 Unity benutze kann ich sagen, dass es sehr wenig mit Unity zu tun hat, warum Spiele schlecht sind. Dabei bin ich kein Designer, sondern Entwickler und kriege selber schon etwas schöne Dinge hin. Habe sogar mit Leuten gearbeitet, die keine optimierte Version wollten, nur weil sie etwas "bequemer" fanden. Am Ende ruckelt es bei den auch.
Also zu CharacterController muss ich sagen ist bissel übertrieben gesagt. Du hast nicht so wirklich die Nachteile genannt, was jetzt nicht so toll ist. Bis jetzt hab ich kaum welche gesehen, die sagten ich benutze es nicht. Selbst in VR games wo ich mitgewirkt habe wurden CharacterController verwendet.
Ebenfalls die Levels funktionieren eig gut. Wir arbeiten einem Open World 2D game mit mehreren Scenen. Wir haben sogar Multiplayer Dungeon Instancen geschrieben (bzw ich ^^) und funktioniert richtig gut. Und das mit Unitys SceneManagement. Ist nicht perfekt, aber ist es eig. gut. Mich nervt nur das mit dem lokal raycast und globalen.. also quasi scene.Raycast oder Physics.Raycast. Nervig immer zu checken was benutzt werden kann.
Die UI ist auch nicht mein Favorit, aber ich mag es. Wenn man es etwas versteht, wie LayoutSystem aufgebaut ist und sogar seine eigene programmieren kann z.b. Flexgrids dann ist das mega nice. Aber ganz ehrlich. Würde HTML und CSS viel eher haben.
PackageManager ist eig. einer tollsten Sachen, was sie einführen konnten. Ziemlich am Anfang warst zwar nervig, aber mittlerweile geht es. Weniger Module, weniger Ladezeit. Ich hab z.B. immer das Problem gehabt, dass ich up-2-date sein wollte. Dank PackageManager kann ich das und auch wenn meine eigene Libraries update kriegen (lokal), dann ist es sofort auf den neusten Version.
Klar nervig, wenn man nicht wüsste, dass etwas dort gab, was man braucht. aber sowas braucht halt seine Zeit.
Was für mich persönlich in Unity fehlt, dass Sachen im Editor animiert werden, wie in Playmode. Das sieht bei Unreal Engine manchmal schön aus.
Und Multi Scene Editing. Sprich, Ich kann mehrere Prefabs öffnen und mehreren Scenen in verschiedenen Fenster öffnen und daran arbeiten.
Beispiel, ich möchte die UI nur in einem Fenster sehen.. sonst nix anderes. Das erleichtert mir die Arbeit und muss nicht immer mal rein zoom und rauszoomen. Laut Unity Team ist das überhaupt mit Unity nicht möglich.
Ich freue mich schon auf ein Video über Garbage Collection bei dem über die gesamte Dauer Clips von der Müllabfuhr zu sehen sind :D
Erinnert mich total an die Musikindustrie, wo auch die Leute den Program oder den Effekten die Schuld geben, statt den Audio Engineer.
Ich liebe Deine Videos, man findet leider viel zu viel Halbwissen im Internet, gut, dass Du das alles erklärst, auch generell bei Deinen anderen Videos👍😁
8:13: Ein Blob Cat skin im Chipflake Design wäre genial.
Wie aufwendig ist es, das umzusetzten?
So viel geballtes Wissen! Danke Samb ✌
Ich glaube es gibt genauso viel schlechte Unreal Engine 4 Spiele wie es schlechte Unity Engine Spiele gibt. Das Problem ist nicht die Engine sondern derjenige der das Werkzeug falsch nutzt. VRchat ist mit Unity, Ori and the Will of Wisps ist mit Unity und noch viele weitere Spiele wo man es gar nicht erahnt..
Das mal vorab und nun schau ich mir das Video an xD
Ja... GTA Trilogy ist mit Unreal Engine gemacht, da meckert aber irgendwie keiner über die Engine :/
Da wird den Entwicklern/Publisher die Schuld gegeben.
@@AlryFireBlade Parade Beispiel für ein beschissenes Unreal Engine Spiel aus technischer Sicht.
ARK: Survival Evolved
@@Korofox oh ja, da wurde wohl einiges nicht gemacht um die Performance stabil zu halten.
Ist das ein Chipflake Plushie auf dem Tisch?
Ich würde heucheln, wenn ich sagen würde, dass ich nie diese Vorurteile gegenüber Engines hatte, aber seit ich den Kanal verfolge, bekam ich mehr und mehr eine andere Sicht auf die Sache womit auch diese Vorurteile niedriger wurden bzw man weiß dann halt, wie diese Vorurteile entstehen.
Ich liebe dich soo sehr für den Vergleich zum zeichnen! xD
*hust* Copics *hust* 🤣
IMMER WIEDER:
Anfänger, wollen gleich die teuersten, besten Stifte haben, und wundern sich dann, warum das nicht wirklich viel besser aussieht als mit den Günstigsten stiften.
Klar, sind nicht alle so... aber es ist in jedem Hobby, Berufszweig etc so. Es gibt eben jene, die sich da gefühlt selber ins aus schießen...
Ich wollte nicht die Marke nennen :D Aber ja, es ist da einfach sehr ähnlich
Legende, wer noch die alte Version des Videos kennt :)
Cooles und informatives Video auch wenn ich nicht so ganz zustimme. Ich denke wenn viel Aufwand / Fehlerpotential dahintersteckt um Memory Leaks zu verursachen liegt das durchaus auch am Aufbau der Engine und nicht nur an den Entwicklern. Bin selbst Softwareentwickler wenn auch nicht im Gaming Bereich und bin froh das ich zu einem Großen Teil Programmiersprachen/Frameworks verwende bei denen man sich nicht andauernd manuell darum kümmern muss sondern nur in Ausnahmen. Auch hier muss man wissen was man tut und wann es solche Ausnahmen gibt aber so wie sich das Video anhört stellt Unity einen da wohl doch vor ein sehr großes Fehlerpotential.
Ich hatte auch so ein Vorurteil gegenüber Unity, war dann jedoch komplett überrascht, als ich erfahren habe, dass Cuphead mit Unity läuft.
Hallo ! Erstmal vielen Dank für dieses Video, das mich wieder einmal darin bestärkt hat, bei Unity zu bleiben. Ich muss dazu sagen, ich bin mit dem Erlernen von Unity noch ziemlich am Anfang. Konnte erst Anfang September letzten Jahres damit anfangen, aber je mehr ich da Einblick bekomme, desto mehr macht Unity Spaß. Mit der Unreal Engine hatte ich nur Probleme - ja, ich gebe zu, irgendwann hat mich Unity mal ziemlich gestresst und ich dachte, versuche ich die Konkurrenz mal, vielleicht geht es mit der einfacher. Von wegen. Die UE ließ sich auf meinem PC nicht einmal starten. Bei jedem Startversuch wollte sie mir erzählen, eine bestimmte .dll würde fehlen. Ich habe nachgesehen - diese DLL war auf meinem PC sogar 3 mal vorhanden (!), sogar in dem Order der UE, denn die wurde mit dieser herunter geladen. Und trotzdem erzählte die UE mir, die sei nicht vorhanden. Auch der Versuch, die UE wieder zu deinstallieren machte Probleme. Unter anderem, weil dieser Epic Launcher ständig im Hintergrund läuft, was ich damals noch nicht wusste und ich brauchte etwas Zeit, um herauszufinden, daß der eben das Problem mit dem Deinstallieren war. Ich musste, da sich der nicht einfach ausschalten ließ, wenn er mal läuft, den PC rebooten und dann konnte ich beides deinstallieren. Sowas halte ich für völlig daneben.
Zu xTry try möchte ich z.b. noch sagen: 1. Ein Spiel mit 100 GB möchte ich nicht runterladen müssen ! Das würde bei mir ewig dauern ! Außerdem ist Speicherplatz noch immer kostbar. 2. PC-Spiele sind out. Wenn PC, dann kommt für Spieler eigentlich nur noch Online in Frage. Alles andere ist Mobil oder Spielekonsole. Und 3. Unity ist von den graphischen Möglichkeiten völlig okay. Als Beispiel möchte ich Book of the Dead (So heißt das, glaube ich) oder diverse Vergleichsvideos Unity Unreal Engine anführen: da ist grafisch praktisch kein Unterschied zu sehen. Und um gute Grafik zu produzieren, muss man die Engine, die man benutzt wirklich beherrschen, dabei ist es egal, ob es sich um Unity oder um die Unreal Engine handelt. Es benötigt Profis, um in beiden Engines exzellente Grafik hervorzubringen. 4. Ein gutes Spiel erreicht man nicht allein mit guter Grafik. Die Idee ist wichig. Ich habe Spiele, die sind fast 20 Jahre alt und machen mir immer noch Spaß, auch, wenn die hinter dem Standard heutiger Spielgrafik liegen.
Um noch einmal kurz auf das Video einzugehen: Ja, was die Terrain Engine angeht, stimme ich völlig zu. Und da gibt es zum Glück das Asset-System von Unity, das ich gar nicht schlecht finde. Man kann sich da für ein Projekt wirklich rauspicken, was man auch wirklich benötigt, kann Assets ganz oder nur teilweise importieren, ganz, wie man es braucht. Und es gibt wirklich für alles ein Asset, und ich rede hier sogar von kostenfreien Assets, die in hoher Zahl im Asset Store zu finden sind. Und ich möchte hier all denjenigen Nutzern und Entwicklern einmal ausdrücklich danken, die diese hilfreichen Assets produzieren und anbieten !!!!
Zur Steuerung von Avataren möchte ich noch kurz etwas sagen: Unity hat jetzt, getrennt von den Standard Assets, einen neuen Third -und First Person Controller frisch rausgebracht und die scheinen mir doch echt gut zu sein ...
Kurz: Ich bin mit Unity echt zufrieden und wenn man mit dem "Paket" Blender+Unity arbeitet, dann kann man wirklich alles machen, da gibt es eigentlich keine Grenzen mehr. :)
Man sollte vlt erklären, dass C++ eine Sprache ohne Garbage Collector ist. Mikroruckler haben hier einen anderen Grund.
Memory Leaks sind bei Sprachen mit GC nicht unmöglich, aber doch eher eine Seltenheit.
Das Problem mit zu viel im Speicher, was vom GC aufgeräumt wird, stimmt natürlich. Darauf muss man achten.
Danke für den wieder einmal sehr interessanten Aufschluss, Samb. 😲👍
"Hallo Hans, wie geht es dir?"
Mir geht't gut. Danke der Nachfrage :D
Also ich finde deine Chipflake Plüsch sehr gut
OOOOHHHH.... ein neues Samb-Video. Ich hatte schon Entzugserscheinungen.
Hatte auch das Problem mit Update und Fixed_Update. Jetzt kann ich darüber lächeln.
Dass es eine kostenfreie Version von Unity gibt, ist doch super!
Gerade damit man neue Entwickler züchten kann, ist so was wichtig.
Das Problem ist, wenn Steam den ganzen Rotz, der nichts ist, ohne zufragen auch in den Katalog aufnimmt.
Nettes viddel mal wieder, man schaltet immer wieder gern rein
Am Ende das Aufzählen der Namen klingt schon fast wie der Pokémon Rap von Staffel 1 ;)
Wieviel man letztlich rausholt liegt dann eben doch am Anwender und nicht am Programm. Ich kann es aber verstehen dass auch Anfänger ihre ersten Spiele direkt der breiten Masse zugänglich machen wollen. Es ist einfach der beste Weg um Feedback zu bekommen. Oft überwiegt ja auch der Stolz darüber etwas geschaffen zu haben, auch wenn es technisch nicht perfekt ist.
Ein sehr schönes Video was die Problematik gut veranschaulicht hat. Stark!
Jetzt ist nur noch die Frage zu klären warum es so unglaublich viel Shovelware für die Wii gab ;)
Super Video, Schade dass du nicht ein paar gute Beispiele für Unity Genannt hast. Ich liebe deine Videos und gucke die meisten mehrfach.
Gute "Unity" Spiele sind z.B die Ori Spiele.
Aber grundsätzlich sprichst du mir aus dem Herzen. Wurde auch schon öfters angefeindet, wenn ich Leute erzähle, dass ich mit Unity programmiere
Sehr schönes Video Mal wieder, ich bin gerade dabei mich das erste Mal tiefgreifender mit den ganzen Systemen von Unity zu beschäftigen, da ich in meiner Ausbildung ein Schulungsprojekt zu einer von mir ausgesuchten Software machen soll. Aus irgend einem von Selbsthass geprägten Grund kam ich auf die Idee Unity zu nehmen.....
Naja, jetzt versuche ich gerade den Unity Shadergraph so zu verstehen, dass ich in snderen, die keine Ahnung haben erklären kann. Immerhin habe ich schon Mal ein kleines Spiel gemacht und muss deshalb nicht bei Null anfangen. Trotzdem sehr lustig....
Was ich noch zu der Liste hinzufügen würde, was bei Unity echt schrecklich ist: Das Serialization-System. Auch davon bekommt man als Spieler am Ende nichts mehr mit, genau wie die anderen von dir aufgezählten Punkte... aber meine Güte. Wenn man sich in dem Editor selbst mit der Serialization auseinander setzt.. das ist eine pure willkürliche Hölle, die mehrere eigene Studiengänge füllen könnte >_>
Das mit dem Garbage Collector stimmt nicht so ganz. C# hat einen implementiert in der Sprache selbst, C++ nicht. Wenn man also in C++ programmiert, dann gibt es 3 Möglichkeiten mit dem Speicher umzugehen.
1. Einfach alles im Speicher lassen. Funktioniert aber nur so lange bis der Speicher voll ist, danach schmiert das Programm ab .
2. Den Speicher manuell leeren. Dass heißt, immer wenn ein Objekt nicht mehr gebraucht wird löscht man ihn durch das Ausführen eines Befehls. Das ist somit das Beste was man programmieren kann. Dort muss kein Algorithmus drüber laufen, der schaut ob etwas noch gebraucht wird. Macht man jedoch einen Fehler, dann kommt es zu Memory Leeks oder Systemabbrüchen und dass passiert schnell.
3. Einen Garbage Collector implementieren. Der funktioniert so, wie im Video beschrieben.
Sowohl Unity, als auch Unreal sind in C++ geschrieben und haben einen Garbage Collector implementiert. Und zugegeben es ist auch die beste Lösung, wenn man schnell und einfach Programmieren als Prämisse setzt. So gut wie jede Engine setzt auf dieses Prinzip. Natürlich kann man hier immer den Benutzer die schuld geben. Aber wenn eine Engine schlecht programmiert ist, dann bringt es auch nichts, wenn man der beste Programmierer der Welt ist. Produziert also eine interne Funktion viel Garbage, der nicht seien müsste, dann trägt die Engine zumindest eine Teilschuld.
What's that? A new challenger approaches! Darf ich vorstellen: Rust. Gehen wir zurück zu 2. aber nehmen das manuell weg. Diese Sprache wurde von Anfang an um dieses Problem designt. Sie ist noch sehr jung (2010 bzw. 2015 die erste stabile Version), macht aber schnell und viele Fortschritte. Dementsprechend gibt es noch nicht viele und ausgereifte Engines, sind jedoch auf dem Vormarsch. Eine die ich aktiv verfolge ist "Bevy" eine ECS-Engine ohne Garbage Collector dank Rust. Ich muss hier als Programmierer weniger wissen und mache dennoch weniger Fehler.
Stimmt, ich habe es in dem Fall auch sehr versimplet dargestellt.
Ich denke eben weil Unity und Unreal so verbreitet sind gibt es in dem Fall kaum interne Sachen, die viel Garbage erzeugen. Eher Funktionen von der Engine sollten beobachtet und die Dokumentation gut gelesen werden. Aber das meinte ich auch mit, dass es natürlich Optimierungen gibt.
Früher z.B. hat Camera.main immer GameObject.FindWithTag("MainCamera") aufgerufen, was langsam war und Garbage erzeugte. Heute cachet die Engine das Ergebnis, was man eigentlich als Programmierer selbst machen sollte.
Ich habe aber schon genug "professionellen" Code gesehen, der z.B. einen Typewriter Effect für Text erzeugte, in dem er via Substring immer einen neuen String erzeugt hatte, der einen Buchstaben mehr anzeigte.
Ist alles grundsätzlich ein Thema, das ein eigenes Video bekommen könnte :)
@@Samb Ich finde, dass Camera.main sehr gut zeigt, dass sehr wohl die Engine eine Teilschuld hat. Programmiert man professionell, dann hat man sich an gewisse Darstellungsregeln zu halten. (Im Falle von C#) Variablen werden in lower Camel Case geschrieben und sagen somit aus, dass diese keine Logik ausführen. Hier bricht Unity durchgängig die Regel, denn durch das Zusammenspiel mit C++ sind die Variablen eigentlich Getter und Setter Funktionen und müssten in upper Camel Case geschrieben werden. Diese sogenannten Property Fields sind eine Mischung aus Variable und Funktion und sollten auch so behandelt werden. Dass heißt keine komplizierte, bzw. aufwendige Logik ausführen. Im falle von Camera.main ist das Cachen das professionelle Verhalten, anders wäre es bei Camera.main() (Man beachte die Klammern!).
Damals als ich noch blutiger Anfänger war, habe ich auf die selbe Weise versucht den Typewriter Effect zu erzeugen. Zu der Zeit wusste ich noch nicht einmal, dass es einen Garbage Collector gibt. Und lange Zeit danach war ein String für mich ein Type wie Int und Float. Den Schreibeffekt durch Substrings zu erzeugen beherbergt aber auch noch ein anderes Problem und zwar das plötzliche springen des ersten Wortes der neuen Zeile. Dieses Problem habe ich damals versucht zu beheben und mein Gott war das damals schwer für mich. Ich weiß nicht ob sich in der Hinsicht mittlerweile etwas getan hat. Aber so wurde aus einem Effekt, der damals vielleicht 10 min Implementierungsdauer hatte, mehrere Tage.
@@Samb Ich stimme dir teilweise zu. Wenn man die Schwachstellen der Engine alle kennt, kann man sie ausbessern. Das macht einen guten Entwickler auch quasi aus. Als Anfänger war es für mich vor ein paar Jahren aber echt ein Pain diese Performance Issues alle überhaupt zu finden. Tutorials greifen meist ja nur den imperformanten Einsteiger-Weg auf, etwas zu tun und ohne meine erfahrenen Kollegen wäre ich hinter manches nie gekommen. Die Rider IDE erkennt jetzt ja immerhin viele der Bad-Practices und fixed diese für einen. Irgendwie frage ich mich aber trotzdem, wieso Unity da nicht selbst mehr tut oder zumindest mehr aufklärt. Sie wissen ja auch wo die Schwächen liegen. Deshalb hat quasi jeder offizielle Unity Talk Segmente wo es heißt "ja das haben wir selbst so und so gelöst, weil das in Unity nicht performant läuft".
Resourcenverwaltung mit RAII ist mMn in fast allen Fällen die beste Wahl. Das Schöne ist, es funktioniert nicht nur mit Speicherresourcen. Außerdem ist es viel einsehbarer als GC. Schade das es nicht so häufig wie GC ist.
Vielen Dank für dieses Video, bräuchte mehr Leute die solche Aufklärungsvideos machen.
Ich hab das Video noch nicht gesehen, aber ich hab mir gestern gedacht, dass ich gerne mal wieder ein Video auf diesem Kanal sehen möchte. Sind es bereits Entzugserscheinungen? :D
Wuhuuu! Endlich wieder ein Sambvideo!
Würde brennen für ein battlefield 2042 Video, nachdem ich vom Garbage Collector gehört hab.
Ich hab nun zum ersten mal vom garbage collector gehört. Danke
Infos die mich wieder ein Stück schlauer machen.
Danke❤
Und ich freue mich auf dein Essay über ubisoft/Activision.
Das Ding ist Spiele die mit Unity erstellt wurden schrecken mich ersten Moment auch immer ab aber dann erinnere ich mich das Gris auch mit Unity erstellt wurde und ich das Spiel absolut geliebt habe
Ich kenne haufenweise Unreal Spiele die ich echt lahm finde.
Die Engine allein zerbricht mir nie ein Spielkonzept,
sondern eher das Spiel selbst.
Ich dachte zuerst das Unity-Logo auf dem Thumbnail hängt an einem Faden, krasse optische Täuschung lol
Ich gebe auch nicht den Hammer die Schuld, wenn die vom Handwerker eingehämmerte Schraube einen Riss erzeugt hat
Reicht ja auch schon wenn der Handwerker das macht 😂
So jetzt mal wieder Spaß beiseite, ich finde es auch immer schade wenn leute unwissend etwas die Schuld geben ohne wirklich ahnung von der Materie zu haben.
Mit Unity gab es schon einige meisterwerke, aber die gründe wieso das so ist wurden ja im Video ausführlich genannt.
Ich wusste gar nicht, dass es Leute gibt die Vorurteile haben. Um ehrlich zu sein habe ich wenn dann immer von schlechten Unreal spielen gehört und weniger über schlechte Unity spiele.
Muss ich auch sagen. Unreal spiele waren oft nur grafik blender
Was denkst du über das Neue Unity logo um ehrlich zu sein finde ich das alte viel besser
In der EDV gibt es schon ewig eine Weisheit. „Das Problem sitzt vor dem Bildschirm“.
Meine Meinung woher das Problem stammt bevor ich das video sah: "es liegt an der großen Anzahl an Anfängertutorials in Kombination mit der großen Menge an kostenlosen oder leicht zu bekommenden Assets, die oft einfach nur kopiert werden ohne das man sich mit der Engine wirklich beschäftigt. Raus kommt ein zusammengeklauter/ kopierter Kram der dann schnell rausgehauen wird um wenigstens ein paar Käufer abzuzocken."
So bin mal gespannt worauf das Video hinausläuft und ob mein Vorurteil bestätigt wird ;).
Update: jope passt so, gutes Vorurteil :D
Ich bin anfänger und nutze unreal wird zwar schwer sich da durchzubeißen aber es wird sich lohnen :D
8:45 Ich habe das Vorurteil das Spiele, die mit der godot engine gemacht wurden eine ruckelige oder niedrige Performance haben.
Welche Programmier App lohnt sich am meisten? Welch empfehlen sie mir? Wo wurden die meisten beliebten Spiele Entwickelt?
Ich habe in meiner Ausbildung Unreal gelernt und liebe es. Für Artists ist es super, man kann so viel erreichen ohne zu Programmieren. Gerade lerne ich Unity und auch C# und hasse es bisher -.- Selbst ein Anfänger Code braucht ewig bis er mal funktioniert und trotz Internet als Hilfe bekomme ich vieles nicht gefixed, mein Dozent braucht oft auch mehr Zeit als ich gedacht hätte. Und ich rede hier von einem max. 15 Zeilen Code. Mal schauen wie es weiter geht.
Ähnlich ist es mit den Videobearbeitungsprogrammen unter Linux.. Man muss schon wissen, wie Videobearbetung geht um was gescheites rauszubekommen :D
Wenn man weiß, wie, kann man mit Unity schon einiges reißen. Vor wenigen Tagen hab ich "Praey for the Gods" innerhalb von von 2 Tagen auf der PS5 durch gesuchtet. Das Game wurde vom 3-Mann-Studio No Matter Studios mit eben dieser Engine entwickelt und sie holten so ziemlich alles aus Unity raus, was möglich war.
Hatte neulich mit einem Arbeitskollegen das Thema bei dem ich sagte das die Entwickler das Problem sind und nicht die Hardware.
Nach 15 Minuten habe ich aufgegeben da er ja schon etliche Videos gesehen hat in denen immer wieder gesagt wird wie schlecht doch diese und jene Konsole ist weil die Games nicht laufen. Optimierung ist das Zauberwort.
Hab ihm sogar noch versucht ihn dazu zu bewegen sich mal ein paar deiner Videos anzuschauen, er war so in seiner Meinung drin dass ichs wirklich aufgegeben habe.
Beim "Garbage Collector" kam bei mir ein wenig der Hass hoch, wegen meines Informatik-Unterrichts.
Ja, es ist dort alles Kinderkram, im Vergleich zu großen Spielen und Game Design technisch bin ich auch eher auf der künstlerischen Seite, auch wenn ich's studieren will, aber selbst ich blutiger Anfänger des Programmierens, dacht' mir nur "Was zur Hölle?"
Wir haben momentan objektorientierte Programmierung in Java, sollten also mit ausgefüllten Vierecken und Kreisen ein Auto basteln und es "fahren" lassen sobald wir auf einen Knopf drücken.
Nur wurde uns das so beigebracht, dass wir für jeden Frame 2 Autos generieren. Ein blaues, welches immer weiter nach rechts neu generiert wird und das gleiche nochmal, in weiß, so wie der Hintergrund, um das alte Auto zu überdecken. Also eine "programmierte Animation".
Für 15 Frames dann 30 Autos, das sehen die schwachen Schulcomputer bestimmt gern. Ich jedenfalls nicht...
Ist der Lehrer aus den 70ern? Normalerweise malt man alles in ein BufferImage, das zuvor (gefülltes Rechteck) alle Inhalte gelöscht bekommt. Und wenn man fertig mit der Szene ist übermalt man den Fenster-Canvas mit diesem Buffer. Dadurch wird Flackern (halb gemalte Grafik) verhindert. Der Aufwand jedes mal ein "Löschauto" zu mahlen ist um einiges höher als die GPU ein Rechteck ausmahlen zu lassen. Das hat man vielleicht Anfang der 80er noch so gemacht.
@@vast634 er ist recht alt, ja. Lehrer haben doch Fortbildungen, warum er es so beibrachte ist mir ein Rätsel.
Cool, dass du ein Video über die Unity Engine machst. Ich bin tatsächlich auch von diesem Vorurteil vorbelastet worden, da ich mir als Kind/Jugendlicher viele Spiele im Playstore runtergeladen habe mit der Hoffnung, ich würde ein gutes Spiel zocken. Aber nein, die meisten Spiele waren schlecht und wurden meistens mit Unity erstellt. Daher hab ich persönlich eher negative Erfahrungen durch das Branding bekommen.
Nichtsdestotrotz glaube ich dir, dass auch gute Spiele mit dieser Engine bereits erstellt wurden.
Unity ist halt ein Werkzeug, genau so, wie Stifte und ein Blatt Papier Werkzeuge sind. Es kann natürlich sein, dass das Werkzeug nicht besonders gut ist, allerdings ist das ein Aspekt, welcher der Konsument meist nicht mitbekommt.
Ich bin gerade im Anfang dabei, Unity richtig zu verstehen und daher kann ich deiner Aussage zustimmen: Unity Learn ist eine super Sache, wenn man ein Thema der Engine verstehen will, die Foren sind super aktiv und mit der Dokumentation hatte ich gute Erfahrungen.
Allerdings gibt es so vieles, was Unity übernehmen will/muss als Engine, dass du gerne mal auch Probleme hast mit sehr spezifischen Sachen, welche kaum ein Anderer nutzt. Einfach, weil es so unglaublich viele verschiedene Anwendungen im Bereich von Genres und eigenen Ideen gibt, dass einfach nicht alles abgedeckt werden kann.
Wie gesagt bin ich am Anfang und habe daher verschiedene Probleme bisher gehabt, welche ich zum Glück lösen konnte, einfach weil dies generelle Probleme waren wie das verstehen von Physik (wobei ich da immer noch nicht ganz den Dreh mit den verschiedenen Komponenten in dem Bereich raus habe), wie man Packages reinbekommt, wo man was findet usw. Allerdings bin ich da gespannt, wie es sein wird, wenn ich spezielle Anwendungsfälle habe, wo das bisherige System an seine Grenzen bringt. Das werde ich sehen.
Ich kann auf jeden Fall etwas vorwegnehmen an meiner spezifischen Erfahrung: Unity ist verhältnismässig Einsteigerfreundlich und simpel. Aber dadurch, kommst du schnell in Situationen, welche nicht per se konfigurierbar genug sind. Und es muss viel zum Editor hinzugefügt werden, damit man das Spiel so hinbekommen will, wie man es in der Vision vor sich hat.
Danke für das Video, welches noch einmal etwas mehr Klarheit gibt, welche Rolle Engines und auch andere Tools wie Videoschnittprogramme oder Bildbearbeitungsprogramme in der Erstellung der Produkte spielt: Keine zentrale.
Grüsse gehen nebenbei noch raus an Chipflake, dessen süssen Katzencharakter durfte ich mehrmals in diesem Video bewundern.
Bist du irgendwie mit Chipflacke in kontakt oder einfach nur ein fan. Ich find ihn auch ziemlich sympathisch mir fällt es nämlich immer wieder in den Videos auf.
Sehr spannendes Video wiedermal👌🏼😋
I will lediglich ein kleines Feedback abgeben weil es mir diesmal aufgefallen ist. Gleich am Anfang war eine große Bild-Ton-Schere für mich. Du hast von Digital Foundry geredet und hast ein Gameplay von Yooka-Lylee gezeigt. Ich bin mir unsicher ob der FPS-Test jetzt von Digital Foundry gemacht wurde oder nicht. Aber das passte in meinem Hirn nicht zusammen.
Ansonsten wieder mal ein sehr gutes Video gemacht. Freue mich immer ein Video von dir zu sehen.
Neues Video! Yay!🦆🦆🦆
Ich arbeite seit einigen Wochen mit ein paar Leuten an der Hochschule an einem Unity 2D Projekt, wobei ich mich auch zunächst in Unity einarbeiten muss. Mein Eindruck bisher ist, dass Unity für den Anfang verhältnismäßig intuitiv, aber bei tiefgreifenderen Aspekten sehr "fummelig" sein kann. Dabei hab ich allerdings bei weitem noch nicht Alles wirklich kapiert. So verwirrt mich teilweise noch immer sowas wie Layering, und ich habe noch nicht wirklich Ahnung davon, wie ich Skripte schreibe, sodass manche Objekte auf bestimmte Weise miteinander interagieren können. Aber das kommt wohl mit Zeit und Übung.
Abseits davon hat Unity denke ich das "Mario Maker"-Problem. Es ist äußerst zugänglich und bietet prinzipiell die Mittel, großartige Dinge zu erschaffen. Einige Perlen wurden damit bereits erstellt, hingegen gibt es auch viel, viel Müll, was aber eben dann eher die Schuld des Erstellers ist.
Hat die Unreal Engine wirklich auch einen Garbagekollektor? Ich habe gehört das Unreal auf C++ basiert und C++ hat meines wissens keinen.
Das Problem ist halt auch, dass die Defaults in Unity oft einfach komplett kaputt sind :D
Das Object Pooling hast du ja schon erwähnt, dass das normalerweise nicht dabei ist. Ein weiteres klassisches Problem ist, dass die Meshes nicht combined wurden und es kein Tool dafür in Unity gibt, um das per Laufzeit mal schnell zu machen. LODs zu erstellen ist auch ein Pain, wenn du nicht von Anfang an mit Nested Prefabs gearbeitet hast. Dann hast du zu viele Draw Calls und auch zu viele Triangles im Frame und die Objekte werden super teuer initialisiert.
Ich glaube, dass es deswegen schon gerechtfertigt ist, Unity die Schuld zu geben. Bessere Defaults könnte die Qualität von allen Spielen anheben.
Hab das Video noch nicht gesehen aber ich tippe mal. Unity steht jedem offen und wird deshalb gerne von einsteigern für erste Versuche genutzt.
Ich hatte lange das Vorurteil, dass Charaktere aus der Unreal Engine 3 immer wie Plastikfiguren aussahen, oder dass Metall nie wie Metall, sondern nach Psydo-Plastik-Metall aussah. Erst mit dem allgemeinen Look der UE4 konnte ich mich wieder anfreunden. Ich denke, man kann Engines nicht einen grundsätzlichen Look absprechen, es sei denn, er ist enorm modifiziert. Ich habe halt sehr viele Spiele gesehen, die einen ähnlichen Look wie Gears of War hatten, weil sie halt die UE3 verwendeten. Auch die GoldSource-Engine (Half-Life) hatte einen sehr einprägenden Look, sodass man immer sagen konnte: Jup, das ist diese Engine. Gleiches Ding auch bei der Source Engine. Aktuell verschwimmt das aber zum Glück. Ich würde vielleicht noch sowas noch zur CryEngine sagen, kann aber nicht sagen, warum ich das so fühle. Das ist halt einfach ein Gefühl, dass sich auch nur selten täuscht. Natürlich kriegt man so einen Look wegmodifiziert, aber ich sehe das recht selten.
Ich mochte Unity seit ich vor vielen Jahren Besiege geschenkt gekriegt habe.
Die vielen Physikobjeckte die Unity da schaukelt ist immer wieder beeindruckend. Wobei die Entwickler da entsprechend lange dran saßen das möglich zu machen.
Ich weiß dass "die Engine ist niemals Schuld" ein Grundsatz ist, der dir sehr wichtig ist und den du schon seit Ewigkeiten vertrittst. Auch wenn ich durchaus verstehe, was du damit aussagen möchtest und ich dir in vielen Punkten zustimme, muss ich trotzdem sagen, dass diese Sichtweise überhaupt nicht zu meiner eigenen Erfahrung als Entwickler passt und ich der festen Meinung bin, dass die Engine durchaus manchmal die Schuld trifft.
Mal ein hypothetisches Beispiel: Sagen wir Toyota hätte ein Auto auf den Markt gebracht, das jedes mal ein einstündiges Beschwörungsritual benötigen würde, um den Gurt anzulegen. Das würde dann schnell dazu führen, dass einfach extrem viele Leute ohne Gurt losfahren würden, was zu deutlich mehr tödlichen Unfällen führen würde. Klar, letzten Endes würde die Schuld dafür bei den Fahrern selbst liegen, denn trotz beschissenem Auto bliebe ihre Verantwortung, sich anzuschnallen, ja bestehen. Es wäre natürlich auch ihre eigene Schuld gewesen, überhaupt erst so ein dummes Auto zu kaufen. Trotzdem fände ich es kurzsichtig, hier zu sagen, dass das Auto und dessen Hersteller nicht zumindest eine Teilschuld trifft, weil Tatsache wäre, dass das ganze nicht so weit gekommen wäre, wenn es besser designed gewesen wäre.
Mit Game Engines sehe ich das genauso. Ich meine, alleine die Aussage "die Engine ist niemals Schuld, sondern der Entwickler" stellt für mich bereits ein Paradoxon dar, denn auch Engines werden ja nunmal von Entwicklern gemacht - und natürlich bauen auch die oftmals Scheiße. Genau wie die Endnutzer der Engine. Und die Scheiße, die die bauen, kann sehr oft und sehr leicht dazu führen, dass eine Engine gar nicht oder nur umständlich benutzt werden kann, ohne bestimmte Probleme zu verursachen. Du hast ja selbst sehr viele Beispiele dafür aufgezählt, worin Unity und UE abstinken und wie sehr man sich abfrusten muss, damit zu arbeiten. Meiner Meinung nach ist es da durchaus angemessen, zu sagen, dass die Engine ein Teil der Schuld trifft. Wenn ich erstmal die sieben Tore der Hölle durchqueren muss, nur damit ein bestimmtes Problem in einer bestimmten Engine nicht mehr auftritt, dann ist meiner Meinung nach da nicht allein der Entwickler dran Schuld, wenn er das nicht tut. Die Engine selbst müsste einfach smarter designed sein. Blöde Analogie dazu: Wenn ich eine tödliche Krankheit hätte, bei der ich jeden Tag drei Stunden Sport machen müsste, um nicht zu sterben, dann wäre letztendlich trotzdem die Krankheit Schuld an meinem Tod - und nicht die Tatsache, dass ich diese extremen Bedingungen einfach nicht umgesetzt habe, auch wenn ich ganz theoretisch drei Stunden Sport pro Tag machen könnte.
Aus diesen Gründen benutzen wir intern überhaupt keine Game Engines von Außenstehenden, sondern machen alles selbst in C++, obwohl es deutlich aufwändiger ist. Da haben wir aber die volle Kontrolle drüber und können dann eben auch leicht verhindern, eine Engine zu machen, die einen durch ihr mieses Design quasi dazu nötigt, schlechte Spiele zu machen. Wenn dann am Ende trotzdem schlechte Spiele bei rauskommen - ja dann kann man wirklich mit Fug und Recht und ohne Wenn und Aber behaupten, dass die Schuld dafür zu 100% bei uns liegt.
Übrigens noch zwei Kleingikeiten zum Thema Garbage Collector: "Den gibt's überall" stimmt ja so jetzt nicht ganz. Bin mir sicher, dass hast du nur zur Vereinfachung gesagt, um deinen Punkt zu verdeutlichen, aber zum Beispiel in C++ und ähnlichen Sprachen gibt es sowas von Haus aus überhaupt nicht. Da gibt es andere Methoden, Speicher zu verwalten, aber zumindest nativ keinen GC. Wir nutzen meist manuelle Speicherverwaltung mit fest vorgegebenen Größen. Das ist mehr Arbeit und weniger Bequemlichkeit, und es führt leichter zu Crashes, aber dafür ist auch alles durchlich planbarer und man merkt sofort, falls man irgendwo ein Budget überschreitet. Solche Ruckler durch Garbage Collection kann's natürlich auch nicht geben.
Die zweite Kleinigkeit, die ich zum GC anmerken will, ist dass ich mir recht sicher bin, dass der nicht die einzige Quelle von Mikrorucklern in Unity (und anderen Engines) ist. Da gibt es sicher viel mehr. Zum Beispiel Streaming von Assets, oder bestimmte Tasks, die nur auf dem Main Thread ausgeführt werden können. Klar kann man auch da meist Workarounds nutzen, dass diese Ruckler nicht mehr auftreten, aber auch da ist es erfahrungsgemäß oft so, dass die Engine einem oft keine (oder keine brauchbaren) Alternativen gibt und die somit ein Teil der Schuld trifft. Aktuell arbeite ich beispielsweise an einem Spiel, dass ganz gerne und oft einfach mal Assets im Main Thread lädt, und das führt natürlich regelmäßig zu Freezes. Das ist aber in der Engine vom Spiel einfach so umgesetzt, und das ließe sich auch nicht fixen, ohne die Engine an sich komplett umzuschreiben, was sicherlich viele Mannmonate (wenn nicht Mannjahre) kosten würde. Wo ich wieder beim Punkt bin "die Engine trifft durchaus ein Teil der Schuld".
Also... ja. Dem Grundsatz "die Engine ist niemals Schuld" kann ich allerhöchstens nur indirekt zustimmen, indem ich sage "sondern der Entwickler der Engine ist Schuld". Natürlich ist eine Engine am Ende des Tages nur ein Werkzeug, und natürlich ist man zu 100% selbst Schuld dran, wenn man ein Werkzeug falsch benutzt. Keine Frage. Wenn ich einen Hammer benutze, um damit ein Loch zu graben, dann ist es natürlich zu 100% meine eigene Schuld, wenn das besagte Loch scheiße wird, und nicht die des Hammers. Benutze ich hingegen einen Hammer, um einen Nagel in die Wand zu schlagen, und dabei zerbricht der Hammer und fliegt meinem Nachbarn ins Gesicht, dann ist da durchaus der Hammer Schuld dran, obwohl er nur ein Werkzeug ist. Dafür kann ich dann keine Verantwortung übernehmen, auch wenn ich ein anderes Werkzeug hätte nutzen können. Genau aus dem Grund kann ich auch nicht grundsätzlich die Ansicht teilen, dass immer der Entwickler einer Engine Schuld dran ist, wenn ein kaputtes Spiel bei rauskommt.
Wenn man mal drüber nachdenkt sind videogames einfach eine möglichkeit eine komplett eigene welt zu basteln in der man sich auch noch bewegen und aufhalten kann. Einfach unglaublich wenn man drüber nachdenkt 😄
6:51 ich dachte die Kamera bewegt man in LateUpdate 😅
Welche Spiele sind gute von der Unity?
Nein, dank dir nicht mehr.
Ich weiß und verstehe jetzt, dass die Entwickler Schuld sind, oder eben die Publisher, die den Entwicklern nicht genug Zeit gaben für Anzahl an Entwicklern... Man siehe das aktuelle GTA Drama.
Da wird es auch nicht Unreal Engine sein und ich glaube auch nicht, dass Grove Street Games die volle Schuld trifft. Sie waren einfach viel zu wenige, für solch ein großes Projekt.
Erklärt übrigens dein "Unity" Ausdruck aus dem einen Video, wo du so viele schlechte Spiele angesehen hast. Es war die gratis Version von Unity.
Ich habe jetzt vor kurzen mit Unity angefangen und vielleicht Wechsel ich irgendwann, wenn ich dann C++ gut kann zu Unreal Engine.
Mich erinnern die Aussagen und Vorurteile gegenüber Unity an die frühen 2000er, da gab es nämlich eine Engine der es genauso ging, der RPGMaker2000. Nur waren da sogar noch die Entwicker so frech zu sagen, ja die Engine kann gar nicht mehr, sie schränkt uns ja extrem ein. Nein, tut sie nicht, man kann damit alles skripten, wenn man will. Was sehr viele Projekte gezeigt haben. Die Schwämme an Müllspielen kam heraus, als ein deutsches Spielemagazin aus dem Bauerverlag mit Bravo Branding meinte, diese Spiele zu pushen und sogar Workshops zu den Programm anzubieten, wenn man sich alleine das Beispiel-Spiel von denen anschaut, stellen sich schon die Nackenhaare auf.
Dazu kam, dass der RPGMaker2000 lange Zeit gar nicht für den europäischen Markt gedacht war und nur in Japan zur Verfügung stand, ein russischer Entwickler hat das Ding dann ins Englische übersetzt und im Internet verbreitet, übrigens illegal und natürlich ohne Absprache des Entwicklers vom RPGMaker. Diese Version war jahrelang dann das Entwicklertool.
Wenn man Leute aus dieser Zeit fragt was sie von RPGMaker Spielen halten, wird man im großen Kontext hören, dass diese Trash sind. Leider wurde der Ruf dieser Spiele, gerade im deutschsprachigen Raum, dauerhaft zerstört.
Erst als mit "To The Moon" ein Spiel dieser Szene wirklich mal gezeigt hat, was im RPGMaker steckt, wenn auch schon ein Nachfolger vom RPGMaker2000, hat das Ganze zumindest ein bisschen geradegerückt.
@Walther Penne nanana, so pauschal zu sagen es geht nicht, gibts nicht. Viele Leute die damals behauptet haben x,y oder z geht mit den RPG-Maker nicht, war halt einfach nur Quatsch. Das Ding war damals in der 2000er Fassung schon ein extrem mächtiges Tool gewesen. Fähige Entwickler der deutschen RPG-Maker-Community haben komischerweise nie solche Sätze fallen lassen, eher Leute die nichtmal die grundlegenden Basics der Engine genutzt haben. Da du definitiv bei der Zeit gar nicht dabei warst, kannst du dich gar nicht dazu äußern wie sehr meine Aussage stimmt oder eben nicht. Pauschal zu sagen das meine Aussage nicht stimmt, ist einfach nur ein Armutszeugis und ziemlich dumm dazu.
Ich habe in meinen Leben in drei verschiedenen Firmen mit 3 verschiedenen Softwares gearbeitet (als Sachbearbeiter) und mir kam nie der Gedanke, dass das Entwicklungstool daran Schuld ist wie das System arbeitet (oder eben nicht), sondern diejenigen, welche die Kritik und Wünsche der Mitarbeiter einfach zur Seite schieben.
Dann Render Mal eine SciFi Film mit MS Paint ;)
@@Andy_S79 Ein Hammer bleibt ein Hammer und wird nicht zum Schraubenschlüssel, wenn man gerade eine Schraube nicht mehr lose bekommt. Und Paint war nie Schuld an unserer Kritik :P
@@pekedilly232 Völlig falsch.
@@Andy_S79 Unmöglich ist es ni ht, es würde nur eine Milliarden Euro Produktion werden
Hast du was mit Chipflake zu tun?
1:34 Der Kunst Vergleich hinkt gewaltig.
Sicher verbessert man seine "Maltechnik"
Aber ein - nicht digitales Bild - ist fertig wenn es fertig ist.
Code kann man optimieren, Texturen komprimieren etc...
Der Rest ist korrekt.
DF hat bei mir ohnehin schon ordentlich and Respekt verloren, weil die sich bald /nur/ noch auf technische Details verlassen.
Hard UND Software, muss im Einklang stehen.
Das Ying und Yang der Softwareentwickler.
Eine Frage zum Garbage Collector, soweit ich weiß und mein Verständnis von C++ richtig ist, sollte es dort gar keinen geben, sei denn Unreal hat etwas sehr merkwürdiges mit c++ gemacht. In C++ muss jedes mit new (oder malloc, falls das noch irgendwer benutzt, was ich nicht hoffe) erstelltes Object, dass somit im Heap gespeichert wird, mit delete gelöscht werden. Das hat zum einen den Nachteil, dass der Programmierer sich selbst darum kümmern muss, wann das Objekt gelöscht wird, hat aber auch den Vorteil, dass das dann gemacht wird, wenn es weniger weh tut. Zudem werden dann nicht alle Objekte gleichzeitig gescannt, was auch Ruckler vermeidet.
Wie heißt das Spiel mit dem Mädchen dass die Plüschfigur findet, von welchem häufig in diesem Video Footage verwendet wird?
@@recardo7 Danke! Wie heißt der Film? Wusste nicht, dass damit auch Filme gemacht werden.
Wenn es um Eigenheiten von Engines geht, muss ich immer an die Creation Engine denken. Die mir leider nach dutzenden Stunden Skyrim und Fallout immer die Savegames auffrisst. Zuerst dauert dann das Laden immer länger und irgendwann ist es dann vorbei und mein Spielstand ist tot. Dann fängt man an mit Savegameditoren rumzufummeln um die Objectlocations zurückzusetzen/löschen um doch noch irgendwie weiterspielen zu können. Wäre toll, wenn sie das bei Starfield mal abstellen würden.
Mal ne technische Frage:
Kenne c# bislang nicht, bzw kann es noch nicht. Aber hat nicht nur Java einen garbage collector? Unreal läuft doch zumeist über c++ wo destructor selbst erstellt werden müssen. Oder verstehe ich da was grundlegendes falsch?
Danke für das Video. Die Zusammenfassung der Tools in Unity die dich nerven fand ich am interessantesten. Ich habe auch bereits ein paar Projekte mit Unity gemacht und bevorzuge C# und die UI in ihrer Bedienbarkeit aber schaue auch neidisch zur Unreal Engine für ihren Umfang und Shader-power. Was sind die Gründe für dich bei Unity zu bleiben @sambzockt ?
wäre mal cool wenn du eine must have packages liste erstellen könntest, falls du das nicht schon gemacht hast. Ich blick so gar nicht durch was es da so alles gibt um nen projekt gut zu starten.
Ich finde ein Aspekt, den du noch gar nicht aufgebracht hattest ist der, den die meisten auch nutzen, um z.B. über Unity zu meckern: Voreinstellungen. Sei es die Sonnenposition/Stärke/Farbe, die Physik-Geschwindigkeit oder die Überblendzeit von Kameras in Cinemachine. Viele viele viele Spiele nutzen einfach die Presets und dadurch sehen unglaublich viele Spiele sehr gleich langweilig aus, weil die Engine (zumindest bei URP) zunächst so eingestellt ist, dass es einen möglichst neutralen Look gibt.
@Walther Penne Ich glaube du hast meinen Kommentar nicht ganz verstanden...
@Walther Penne ... Das ist literally mein Job... Überleg bitte, was deine Aussage ist, du sagst hier nämlich, dass die Performance einer Applikation massiv beeinträchtigt wird, wenn die Sonne statt von links von rechts kommt oder statt Gelb Orange scheint...
Diese ganzen einbledungen von Paragon als es um die unreal engine ging... Ich vermisse es...
Der Garbage Collector sollte in Unreal eigentlich eher weniger ein Problem darstellen, da C++ keine managed-language ist und man seinen Müll selbst aufräumen muss. Daher kann der Entwickler genau kontrollieren, wann was gelöscht wird. Dafür ist es auch leichter, Memory Leaks zu erzeugen. Ich möchte damit jetzt jedoch nicht sagen, dass Unreal in dem Punkt besser ist. Ich habe bisher lediglich ein paar Shader für Unity programmiert, kenne die Engine von innen daher zu wenig, um sie zu beurteilen.
Ich mein.. Unreal Engine hat einen Garbage Collector wie Unity und beide können entweder genutzt werden oder man deaktiviert sie und kümmert sich selbst darum. Man muss halt erst mal wissen, das solch Dinge existieren. Denke wäre der GC nicht immer automatisch an würden mehr Leute mitbekommen, dass ihr Code Humbug ist :)
Gutes Video :)
Endlich wieder neue Videos :D
Damals auf der PS3 lief Battlefield 4 nicht so toll. Da haben viele auch gesagt, es würde an der Frostbite Engine liegen. Zu dem Zeitpunkt war die Hardware der PS3 aber einfach veraltet.
2x Chipflake im Video, nice ^^