Also die Aussprache von "Godot" müssen wir nochmal zusammen üben, aber was ein cooles Video! Man merkt, dass ihr euch in die Materie eingelesen habt, da macht es auch als "Industry Professional" Spaß zuzuschauen. Nicht vergessen, Godot ist nicht nur Open Source & kostenlos, but allen voran ein Community-Projekt, also kann jeder zur Engine selbst beitragen wenn er möchte - oder Plugins schreiben und sich die Arbeit bezahlen lassen, da habt ihr auch Recht gehabt.
Kleiner technischer Korrigierungskommentar: Assembly ist keine Engine, es ist eine Gruppe von Programmiersprachen. Eine Gruppe von Programmiersprachen und keine einzelne, weil jede CPU-"Architektur" (Ja, Fachsprache!) eine eigene hat. ARM (hauptsächlich bekannt aus Mobiltelefon-Chips wie den Snapdragons von Quallcomm, aber auch schon in Servern wie bei ¿Ampere?-Chips, die man auch bei Hetzner mieten kann (mit mehreren hundert Kernen oder irgendwie sowas krankem) oder den Graviton-CPUs von Amazon) hat z.B. mehrere Assembly-Sprachen, z.B. aarch64 oder THUMB. Bei Desktop-Computern hat man eigentlich nur x86_64, ganz entfernt verwandt mit dem Intel 8086 aus den 70ern; die werden von AMD und Intel hergestellt, aber auch VIA und somit Zhaoxin haben eine Lizenz. Da gibt es 8086-Assembly (ursprünglich glaube ich iAPX 86 oder so genannt), i386, i686, amd64 (auch bei Intel-CPUs heißt das amd64). OGRE ist übrigens keine Game Engine, der Name steht meiner Erinnerung zufolge für "Object-oriented Graphics Rendering Engine", demnach ist es eine Rendering Engine, also der Teil eines Spieles / einer Engine, der fürs fancy zeichnen zuständig ist. Die greifen dann wiederum auf Grafik-APIs (APIs sind Schnittstellen, Interaktionsmöglichkeiten zu, in diesem Fall dem Treiber) wie OpenGL, Vulkan, Direct3D (ein Teil von DirectX) oder Metal (bei macOS und iOS) zu. Cool übrigens, dass Ihr Godot erwähnt. Opensource ist meistens toll.
assembly is keine gruppe von programmiersprachen sondern eine einzelne sprache. sie hat nur je nach architektur unterschiedliche (wie nenn ich es am besten) "befehle und variablen". würde das so beschreiben. edit: instruction set heißt es glaube ich :D
@@MaxiKing913 Register mit Variablen zu vergleichen, ist keine gute Idee. Variablen können ebenso gut auf dem Heap oder Stack sein, statt in den Registern. Variablen gibt es in "Assembly" demnach nicht. Die Befehle sind anders, ja. Es gibt verschiedene Assembler für dieselbe Architektur, aber auch für verschiedene Architekturen. Die Unterschiede zwischen denen sind so groß, dass man von verschiedenen Sprachen reden kann. der GNU Assembler für SPARC wird komplett anders sein als der Netwide Assembler (NASM) für x86_64.
Hobby Unity VR Dev hier. Falls jemand Interesse an Game Development hat, hier sind ein paar Tips die ich auch gerne gelernt hätte als ich anfing. 1. Die Engine ist eig. vollkommen egal, fokussiere dich nicht zu lange (wie ich) auf die Entscheidung welche Engine du benutzt. Willst du möglichst reallistische Spiele nimm Unreal (obwohl sich da im Vergleich zu Unity HDRP auch nicht viel tut). Unreal ist für First/Thirdperson Spiele ausgelegt und optimiert. (man kann selbstverständlich auch was anderes entwickeln, aber dafür ist die Engine ursprünglich nunmal ausgelegt). Passt dein Spiel in diese Kategorie? Willst du viele versch. Spiele machen und alle Optionen haben? Mal 2D, 3D, VR oder AR und auch mal ein paar experimentelle Sachen: Unity Nur 2D? Godot, obwohl Gotdot-3D auf einem guten Weg ist sehe ich es noch nicht auf dem Level mit Unity und UE. Das schöne ist, das Wissen ist übertragbar. Kannst du Unreal, kannst du sehr einfach Unity lernen und andersherum. Deswegen lerne deine Engine und wenn eine Spiel-ldee es mal vorraussetzt habe keine Angst davor was neues auszuprobieren. Engines sollen dir helfen, nicht dich limitieren. 2. Deine ldee muss nicht geheim gehalten werden. lch sehe das oft, dass in Foren Devs ein absolutes Geheimnis drum machen, welche Konzepte sie verfolgen, was es schwer macht ihnen zu helfen. Niemand will deine Idee klauen. Deine Idee hatten wahrscheinlich schon 100 Leute vor dir, aber an der Umsetzung scheiterts dann immer. Das kannst du ändern, bleibe deiner ldee treu und mach das Projekt fertig. 3. GAME JAMS, GAME JAMS, GAME JAMS, GAME JAMS. Du lernst so unglaublich viel bei GameJams und bekommst super schnell Erfolgserlebnisse und lernst auch wie es ist ein Spiel fertig zu machen. 4. Du kannst natürlich gleich an deinem Herzensprojekt arbeiten. Aber sei dir im Klaren, du wirst jetzt nicht das nächste 100 Spieler Massive Multiplayer RPG programmieren können. Ich seh das leider viel zu oft, das neue Devs anfangen und sich an einem Maßstab messen, den nichtmal Studios mit hunderten Mitarbeitern und Millionen Budget erreichen. Dementsprechend ist man schnell demotiviert und viele hören dann einfach auf. Das wäre schade Es ist extrem viel Arbeit, es ist frustrierend, es frisst Tage, Nächte und ziemlich viel Schlaf. Aber es bringt unglaublich viel Spaß.
Ich habe nach ein paar kleineren Versuchen direkt ein simples jump and run Spiel entwickelt, dass sogar spaß macht. Viel mehr ist für Anfänger aber nach meiner rellativ geringen Erfahrung vermutlich wirklich nicht drin. Ih stecke auch gerade etwas fest. Jump and Run ist doch sehr viel simpler als andere genre. Habs nichtmal richtig geschafft Lebensenergie zu programmieren.
Das ist eine echt gute Zusammenfassung davon. Ich programmiere jetzt seit 4 Jahren Spiele (vor allem mit Unity) und würde dir in allem zustimmen. Vor allem: macht Game Jams!
Sehr gute Zusammenfassung. Und ich gebe dir 100% Recht. Ein Punkt, der noch Beachtung finden darf ist die Lizenzthematik. Ich selbst war für 2D Titel immer ein großer Fan von Game Maker bis es von Opera gekauft wurde und das reine Abomodell aufgedrückt bekam. Technisch super aber wer jetzt einsteigt, kann keine Permanentlizenz mehr kaufen. Das gleiche gilt für Unity. Aus dem Grund stehe ich selbst sehr hinter der Nutzung von Godot und Unreal weil bei diesen beiden die Aussichten gering sind, dass dich die Enginebereitsteller übers Ohr hauen. UE hat halt die Regelung, dass man pro Projekt, das über 1Mio$ jährlich einspielt, 5% abdrücken muss, sofern nicht anders verhandelt, aber 1 Mio um Jahr mit einem einzigen Projekt einspielen ist ein Punkt, den man erst mal erreichen muss. Wieso sind Abomodelle z.B. bei Unity und GM (unabhängig von den technicshen Qualitäten der Engine) schlecht? Du zahlst 10 Jahre brav dein Abo, erstellst eine vielzahl an Projekten und hörst irgendwann mal auf, dafür zahlen zu wollen (oder die Firma dahinter geht pleite oder fängt an zu spinnen) dann ist ggf. dein Zugriff auf alle bestehenden Projekte weg. Wenn die SW beim Starten sagt "wo ist deine Lizenz?" und sich wieder beendet (sh. Adobe und Autodesk Produkte) bist du deinen gesamten vergangenen Werken beraubt, weil dir der Enginehersteller den Zugriff blockieren kann. UE und (natürlich) Godot haben keine solchen Kontrollen, was sie in dieser Hinsicht zuverlässiger macht. Und: Ich bin bei dieser Sache nicht ganz auf dem aktuellen Stand aber wollte Unity nicht seit neuem neben dem Abomodell noch Zusätzlich was von den Einnahmen der Spiele bekommen (pro Titel eine Gebühr oder sowas)?
Also ich war bei "die engine ist nicht wichtig" raus - denn durchaus, eine engine ist das wichtigste, neben eigenem können, denn um so zukunftsweisender sie ist, desto besser wirst du in Zukunft mit ihr arbeiten können. Wenn du ein großprojekt hast, wirst du nicht in 3 Wochen fertig sein. Auf dem neusten Stand der Technologie zu sein, am besten noch vor allen anderen, ist ein extrem wichtiger Faktor. Und natürlich, keine geldgeilen wi**er wie unity als enginebesitzer zu haben. Kuss diggah.
Ich bin sehr beeindruckt wie ausgewogen ihr das Thema behandelt. Großen Respekt dafür, denn bisher gab es aus Nicht-Entwicklerkreisen keine wirklich gute Aufarbeitung des Themas Game Engines! Da merkt man sofort, dass ihr euch da auch schon selbst eingearbeitet habt 😄
godot ist halt einfach echt geil für indie/solo entwickler und ich find es supper das man mehr darüber redet, denn eigentlich hat es schon bewiesen was es kann, durch spiele wie: cruelty squad, endoparasitic, brotato, cassette beasts und dome keeper. - alles geile games noch dazu; mit dem 4.0 update ist die engine gerade für 3d games besser geworden.
Fuck yeah. Mehr Liebe für Godot. Es ist einfach so intuitiv und macht Spaß und eignet sich einfach perfekt für kleinere Spiele. Wobei mit der neuesten Version kann man auch deutlich mehr machen als nur kleine 2d Spiele :D
btw. Godot hat auf grund der Unity problematik sehr viel Geld bekommen uns sehr viel aufmerksamkeit. Der Schritt von 3.0 auf 4.0 war schon imens. Aber mit mehr Geld und mehr Aufmerksamkeit, wird godot warscheinlich recht schnell noch geiler. Godot for live.
Godot is gut aber es fehlen echte Projekte die auf sich aufmerksam machen und mal richtig zeigen wozu die Engine fähig ist. Bin selbst Unreal Entwickler aber derzeit find ich den Workflow in Godot in 3D einfach nur ungemütlich und umständlich deswegen bleib ich noch bei Unreal ^^
was mir bei Godot in erster Line fehlt ist C# to Web Export ... nur gdScript ist mir zu wenig / ich mag die Limitierungen nicht (gebt mir Fucking Exception Handling ... like wtf) Glaube aber nicht das ich als Hobby Dev jemals wen zu bekommen kann mein Spiel zu installieren. Auf ne Seite zu klicken und zu spielen das denke ich kann ich schon ...
@@klausklavikus3836 Ein Godot Projekt das ne Menge aufmerksamkeit bekommen hat ist Backpack Battles :D Gibt schon ne Überraschend große menge an auch guten Spielen die mit Godot gemacht werden ...
Als Spieleentwickler kann ich sagen das es egal ist was Ihr pickt, solange Ihr etwas pickt und auch immer wieder an eurem projekt weitermacht. Macht coolen sht da draußen. 👋🏻
Studiere gerade Games Programming und bin richtig froh das Leute außerhalb der Entwicklerbubble sich für solche Themen interessieren. Nicht jeder Fragt sich wie ein Spiel das man gerade Spielt Entwickelt wurde. Gerade weil so viel Halbwissen auf Social Media wie Twitter und Co. über diese Themen verbreitet wird, ist dieses Video einnfach mal erfrischend.
@@tgirlshark Wollte ich auch gerade schreiben, aber aktuell haben sie bei Resident Evil Revelations das Update mit dem Enigma Protector wieder zurückgezogen. Wahrscheinlich wird es wiederkommen, aber die Hoffnung stirbt zuletzt.
Ich lerne derzeit mit Godot 2D Spiele zu erstellen. Macht Spaß, ist relativ easy und leicht verständliche Tutorials gibts auch zu genüge. Kann ich eigentlich nur empfehlen, wenn man PC oder Mobile Games machen möchte.
Godot wird "Godoh" ausgesprochen! Der Name kommt von dem abstrakten Theaterstück "Warten auf Godot", was aus Frankreich kommt. Deshalb ist der letzte Buchstabe von "Godot" still zu lesen.
Wenn es dir nicht passt, dass ein Deutscher die Wörter nicht auf französische Art ausspricht, dann wander doch einfach nach Frankreich aus und fress den ganzen Tag Käse, Frösche und schlechten Wein.
Ich arbeite seit 6 Jahren mit der Unreal Engine auf täglicher Basis und 4:30 stimmt einfach nicht! Die Unreal Engine hat eine komplette Paper2D Klassensektion, mit der aktuellen Version (5.3) sind noch weitere 2D Features hinzugekommen z.B. Skeletal Editor mit dem man 2D Sprites einen Skeleton geben kann - das erlaubt es einen 2D Character technisch genau so zu behandeln wie einen 3D Character. Im Gegensatz zu Unity kann man bei Unreal standardmäßig mit Visual Scripting arbeiten (was man jedoch weitestgehend vermeiden sollte wenn es um Networking geht). Bei Unity geht das auch, aber viel eingeschränkter - man muss direkt mit C# programmieren. Es ist ein weitverbreiteter Irrtum, dass die Unreal Engine nicht für 2D Games geeignet ist und nur für ihre hochqualitative Renderfähigkeit populär und geeignet ist! Es ist durch und durch die stärkste Engine und es spielt keine Rolle ob man ein 2D Game, ein 3D Open World, eine App oder eine Website damit produziert. Der Unterschied (bezüglich 2D und Mobile) zwischen Unity und Unreal ist eigentlich nur: - Wenn Du ein Unity Projekt erstellst, ist es ein komplett leeres Gerüst, es sind keine Plugins standardmäßig aktiviert und man muss sämtliche Plugins die man im Projekt benötigt nachträglich aktivieren. Der Vorteil ist, dass das Projekt nicht zugemüllt ist mit Plugins die man nicht benötigt. Somit ist die Ausgangsbasis (z.B. für ein Mobile Game) viel einfacher. - Wenn Du ein Unreal Projekt erstellst, sind tausende Plugins (auch die 2D Plugins) bereits standardmäßig integriert und aktiviert. Wenn man hier ein Mobile Game builden wollte, müsste man sich erstmal durch die Plugin Listen durcharbeiten um so viel wie möglich zu deaktivieren (damit die Build Size am Ende so klein wie Möglich ist). Theoretisch könnte man sogar ganze Engine-Integrationen entfernen und die Engine komplett neu builden, da der Source Code der Unreal Engine öffentlich zugänglich ist - bei Unity ist der Source Code nicht öffentlich. Das Grundgerüst ist einfach nur anders aufgebaut. Aber im Prinzip können Unreal und Unity sehr ähnliche Leistungen vollbringen (auch was das Rendering betrifft). Unity kann auch Open World und heftiges Rendering. Unreal hat mit Nanite und Lumen (und World Partitioning) eben nur die besseren Voraussetzungen dafür geschaffen (z.B. mit Realtime Global Illumination). Ich würde die Unreal Engine auch nicht als die "schwerere" Engine für Einsteiger bezeichnen. Gerade durch Blueprints, die Masse an Tutorials auf YT und dem Epic Learning Portal (und den Foren) bekommt man perfekte Voraussetzungen um die Unreal Engine zu lernen. Bei Unity musst Du direkt C# programmieren lernen, bei Unreal wird es durch Visual Scripting vereinfacht und wenn man so weit ist, kann man sich an C++ annähern. Und kleiner Tipp an diejenigen die sich für Gameplay-Systeme in Unreal interessieren: Gameplay Ability System (GAS) wurde ursprünglich für Fortnite gebaut, steht aber allen zur Verfügung. Es ist ein unglaublich starkes System um Gameplay-Mechaniken aufzubauen (insbesondere in Multiplayer-Situationen). Es gibt ein paar wirklich gute GDC und Unreal Stream Talks darüber. Und zu 6:56 - Mit ner Ryzen 16 Core CPU öffnet sich Unreal genau so schnell wie Photoshop und kompiliert 100k Shader in unter 5 Minuten. Normaler Gaming PC reicht bei keiner Engine aus.
Ich persönlich spiele schon sein Jahren mit dem Gedanken selbst Spiele herzustellen, hab aber keine Ahnung vom programmieren. Seit paar Wochen schau ich mir Tutorials an zu Unreal und muss sagen, dass Unreal am einsteigerfreundlichsten aussieht. Etwas seltsam find ich dass Godot übertrieben gelobt wird in vielen Videos und Unreal eher stiefmütterlich erwähnt wird. PS, bei Unity gibts auch eine Visual Scripting Option (hab das auch erst letzte Woche erfahren) über die kaum Leute reden.
Yep. Entwickler machen die Spiele, die Engines sind nur Tools. Man kann mit jedem halbwegs stabilen Hammer einen Nagel in die Wand hauen, wenn man weiß wie man den Hammer benutzen muss. Und wenn man eine Schraube in der Wand drin haben will sollte man dann halt keinen Hammer sondern einen Akkuschrauber oder so verwenden. Und Bethesda hat bei Fallout 76 versucht einen Hammer mit einer Teewurst in den Boden zu bohren.
Godot, my GOAT! Extrem leicht zu lernen (trotz veralteter Tutorials) und geschmeidig zu benutzen. Außerdem die Engine auf der Cruelty Squad gebaut wurde.
Als Unity Entwickler hab ich mich auch mal, wegen dem ganz Debakel, in Godot eingelesen (öffnet ja auch in 2 sek., da kann man das mal schnell machen) und sie ist auf jeden fall simpler und intuitiver. Leider fehlen dort immer noch ein paar Features, die ich in Unity vermisse. Wie zum Beispiel das testen von eigenen Features. Das ist Unity so viel einfacher, weil man während der "play test" läuft Sachen verändern kann. Unreal hab ich tatsächlich noch nicht angefasst, obwohl das auch mal Zeit wird XD.
Im play mode gibts auf der linken seite in the scene hierarchy 2 tabs, "Remote" und "Local". Wenn man auf remote stellt, sieht man die objekte die sich im playmode befinden, und kann sogar die parameter ändern (achtung, paramter werden im game nur geupdated, wenn sie im inspector und nicht in der scene view angepasst werden. z.B. Transform) Oben drauf kann man wenn man im playmode ist, das kamera-icon oberhalb der scene view anklicken. Das sorgt dafür, das die game kamera sich mit der scene kamera synchronisiert. Somit wird die game kamera bewegt, wenn man die scene kamera im editor im playmode verändert
Ich habe im Mai 2023 mit Godot angefangen. Ich habe Tutorial von der Webseite Quiver gemacht, aber auch angefangen etwas Eigenes dort zu basteln. In Verbindung mit Blender habe ich festgestellt, dass man entweder Blendermodelle als .obj in Godot laden kann und dann in Godot mit einer Textur bestücken kann oder man macht ein Modell in Blender mit Textur und exportiert es als .glb/.gltf nach Godot. Es gibt aber auch ein Plugin für Godot wo man Terrain direkt in Godot machen kann mit einer Textur. Oder man erstellt einfach mesh-instanzen und lädt eine PBR-Texture mit dem eigenen Visual-Shader in Godot rein.
@@ReichAnFleischsie hatten versucht einzuführen, dass jeder Entwickler, pro Installation des entwickelten Spiels, dafür blechen muss. Bzw. wollten die die Distributionsplattformen verantwortlich machen. Diese hätten die Kosten am Ende aber eh weitergeleitet.
Ich hab rein hobbymäßig Unity, Unreal 4 und zuletzt Godot ausprobiert und muss sagen, dass mich Godot mit Abstand am meisten überzeugt hat. Es hat nahezu unendlich viele Möglichkeiten, die aber gleichzeitig alle sehr simpel und intuitiv gehalten sind. Ist mMn nach die zur Zeit beste Engine (ausgenommen für AAA-Games u.Ä. wo Unreal 5 einfach grafisch die Oberhand hält).
Als beruflicher Programmierer und hobbymäßig-ein-bisschen-was-in-Unity,-GameMaker-und-Blender-gemacht-Habender muss ich euch echt loben, soweit ich das beurteilen kann habt ihr das sehr gut zusammengefasst. Ein paar Punkte würde ich gerne noch hinzufügen. Wie in den Kommentaren schon angemerkt wurde, reiht Assembly sich hier eigentlich nicht mit ein, da es eine Gruppe hardwarenaher Programmiersprachen ist und keine Engine. Man kann theoretisch eine Engine in Assembly schreiben, aber die meisten Engines werden wohl in C oder C++ geschrieben, welche Programmiersprachen sind, die ähnlich wie Assembly-Sprachen direkt in Maschinencode (Nullen und Einsen) übersetzt werden, aber etwas einfacher zu nutzen sind. Man kann theoretisch in fast jeder Programmiersprache ein Computerspiel schreiben, und muss dabei auch nicht zwingend erst eine Engine entwickeln. Eine Engine ist eher eine Ausgliederung der hardwarenahen Features, die man in vielen Spielen benötigt. So erspart man sich die Arbeit, zB. Raytracing-Support noch komplett von Hand programmieren zu müssen, stattdessen kann man es über die Benutzeroberfläche der Engine umsetzen. Trotzdem bieten die meisten Engines auch die Möglichkeit, Teile des Spiels in Form von Skripts als Programmcode zu schreiben, im Fall von Unreal zum Beispiel ist das vorwiegend C++ und bei Unity C#. Beide haben dann nochmal Bibliotheken mit Programmierfunktionen für diese jeweiligen Programmiersprachen, die man nutzen kann, um sich das Leben einfacher zu machen. Godot hat zum Beispiel sogar seine eigene Skriptsprache, die man nutzen kann, unterstützt aber auch einige andere Sprachen wie C#. Ich hoffe das war halbwegs verständlich erklärt.
@@paluxyl.8682 ich bin immernoch Einsteiger, das coden ist dahingehend einsteigerfreundlich, da es eigene godot eigene Scriptsprache ist, die auf Phyton basiert. Hab selber super Probleme mit programmieren etc. Aber da kam ich doch ganz gut rein. Mir haben aufjedenfall sehr viele Tutorials geholfen.
Ich bin gerade dabei, mein eigenes 2D Game in Godot zu schreiben. Mir ging es auf den Sack, wie viel man in Godot händisch für Animationen machen muss. Hab ein Plugin geschrieben und es wurde mit Source Code im Godot Asset Store veröffentlicht. Muss sagen, es ist nice, wie einfach die Plugins geschrieben werden können und wie einfach es gemacht wird diese zu teilen. Note: Es gibt einen Review Prozess und die Bugs gehen direkt an mich.
Bei der Preisgestaltung der Engines habt ihr einen echt wichtigen Punkt vergessen. Bei der Unreal Engine muss man von der ersten eingenommenen Million gar nichts abgeben. Also wenn du 1.000.000$ einnimmst und 900.000$ Kosten für Koks und Nutten hattest, dann kannst du die ganzen restlichen 100.000$ auch noch für Koks und Nutten ausgeben. Speziell für Indie Entwickler ist es da auch egal ob Unity einen Prozent weniger kostet. Ich hab bis jetzt ja meine meiste Erfahrung in Unity gesammelt und nur ein klitze kleines bisschen in Unreal. Ich bin jetzt aber echt froh, dass ich bis jetzt eher an Konzepten geschrieben habe und eher ein paar VR Prototypen in Unity gemacht habe anstatt wirklich Zeit in ein Projekt zu investieren das ich auch veröffentlichen will. Da ist mir auch egal, dass die ganze Zeit die ich in Unity gesteckt habe mehr oder weniger umsonst war. Ich hab jetzt auch nicht wirklich Ambitionen 2D Spiele zu machen. Dafür machen die ganzen neuen Features von UE5 aber auch einfach absolut Sinn für die Konzepte an denen ich gearbeitet habe.
Stimmt, wichtiger Unterschied! Was auch nicht stimmte: Dass UE nicht open-source sei. Man muss zwar einer speziellen Lizenz zustimmen, sagt damit aber nur, dass man die Sources nicht klauen wird. Ansonsten kann man frei Dinge vorschlagen und mit entwickeln.
Hey, Leute ihr habt mich echt positiv überrascht wie euer Video präsentiert habt. Einige Aktionen haben mich irgendwie an Muppet Show erinnert. Sehr lustiges, unterhaltsames aber dennoch informatives Video.
Der Vorteil an Assembler ist halt das es so programmiert werden kann das es quasi auf jeder Hardware gut läuft. Der Nachteil ist aber das Assembler einfach auch der reinste Terror ist in Programmierung. Wenn man z.B. ein Spiel für eine Konsole Programmiert und es in Assembler Programmiert kann man z.B. auch weit aus mehr aus der Hardware rausholen als mit fertigen Engines die auf alles laufen oder ausgelegt sind dafür
Ahh die VRChat Tutorials, wie Rippe ich einen Charakter aus einem Spiel, mache die Boobies Bouncy 200x, und Importiere SIe als Avatar.... Bin ich jetzt SpieleEntwickler?
Ich arbeite selbst mit der Godot Engine und hätte eine Sache hier über die Engine noch gerne erwähnt gehabt: Die Engine unterstützt von sich aus bereits 2 Programmiersprachen, und per Plugin sogar noch 2 weitere. Eine von den 2 Hauptprogrammiersprachen ist GDScript, die völlig eigene Programmiersprache die sogar für Anfänger wie mich das Programmieren sehr angenehm macht.
der Erfolg von Blender basiert darauf, dass leute die damit geld verdienen freiwilig spenden, und dass sie sich coole programmierer ins boot holen, die sich durch das open source modell sehr gut damit auskennen. und dass man auch innerhalb eines programms eigentlich ein großteil der 3D Aufgaben (und auch 2D nebenbei bemerkt) erledigen kann. und die interne render engines sind auch nicht zu verachten. EEVEE und CyclesX
Die Engine kann so alt sein wie so will, das siehst du nur im Editor und an den begrenzten Möglichkeiten. Das sagt sehr oft, aber nichts an der Qualität der Modelle und Texturen. Wenn ich in der UE 5 Würfel mit Texturen und verbuggte Scripte für die Missionen schreiben, dabei vergesse das Probe light vorzubacken (Das Licht) wird es auch auf der UE 5 ein Gothic 3 geben.
1:21 Nicht um Bethesda in Schutz zu nehmen, aber hauseigene Engine werden natürlich intern immer weiter entwickelt und verbessern sich im laufe der Zeit. Es gibt nur keinen öffentlichen Release welche mit neuen Releaseversionen gekennzeichnet sind. Ist in etwa so als würde man sagen die Unreal Engine gibt es seit 1998. Ob der momentane Entwicklungsstand der Creation Engine auch zeitgemäßg ist, bleibt natürlich eine ganz andere Frage. ;)
Mir fällt auf das die meisten Spiele Engines von Shooter stammen. Sei es die Id Tech Engine, Source, Frostbite, Cry und sogar die Unreal Engine. Sie wurden alle speziell für Shooter entwickelt bzw. zu Anfang nur für Shooter entwickelt
Wer Interesse an einer 2D-RTS Engine im stil von C&C hat sollte sich mal OpenRA anschauen. Das Projekt ist Engine wie auch Spiel in einem, was vielleicht auf den ersten Blick verwirrend sein mag. Alles ist OpenSource es gibt und gab viele laufende Mod Projekte.
Bin seit 2014 ca Unreal Engine Entwickler. Es ist mehr arbeit als in den anderen Engine, dafür habt ihr aber auch mehr und professionellere Möglichkeiten. Nanite und Niagara sind da nur 2 der beeindruckenden neuen Technologien mit denen einiges Möglich ist. Wenn ihr euch selbst hasst... nehmt euch die Zeit und lernt die UE5 sie wird euch sehr glücklich machen ;)
Ey, die Creation Engine hat schon ein paar Vorteile.Zum beispiel merkt sich die Engine, wenn du einen Gegenstand aufsammelst und irgendwo anders hinschmeißt. Und das für einen ziemlich langen Zeitraum, was bei Rollenspielen ziemlich geil ist. Ansonsten kannst du ziemlich gut Random Generierte Welten erstellen und sie ist leicht Modbar und nicht allzu komplex. Falls ich Bullshit laber korrigiert mich bitte
Aaaahhhh seit Jahren springe ich hin und her und hin und her. Die meiste Erfahrung hab ich mit Unity, aber würde so gern auf Open Source entwickeln. Finde bei Godot aber dieses GDscript so super weird. Die Sprache ist an für sich super, aber quasi Python. Ich sehe absolut nicht den sinn ein quasi-Python zu bauen, wenn wir bereits Python haben. Also GDscript macht nichts besser, ist genauso schnell, ist genauso interpretiert, statt kompiliert und die Syntax ist auch quasi gleich. ABER man kann die vielen tausend Python-Bibliotheken, die es schon gibt nicht benutzen! Das ist ein extremer Nachteil und ich kann beim besten Willen nicht verstehen, warum man an dieser Stelle das Rad neu erfinden musste. Das gleiche mit der eingebauten IDE. Warum muss eine Engine eine integrierte IDE haben? Ich bin zufrieden mit meiner und denke die Energie ist besser in die eigentliche Engine investiert. Aber to be fair: von Haus aus werden noch C#, C und C++ unterstützt und durch die community quasi jede andere Sprache - auch Python. Wunderte mich nur warum solche Entscheidungen getroffen wurden.
Ich glaube ein Problem der Creation Engine ist, das Bethesda sich nicht richtig um ihre Engine kümmert. z.B. Valve hat extra die Entwicklung von Half-Life 3 und weiterer Spiele gestoppt um die Source Engine 2 fertig stellen zu können. Denn bei Half-Life 2 welches Parallel zu Original Source Engine entwickelt wurde, hatte sich die Entwicklung beider Projekte verzögert, da wegen Half-Life 2 weniger Mitarbeiter an der Engine arbeiten konnten und wegen der unfertig Source Engine auch die Tools für die Entwicklung von Half-Life 2 fehlten. Es hatte ja ein Grund gehabt wieso Epic Games vor Fortnite lange Zeit kein Spiel mehr entwickelt hat, da sie sich überwiegend um ihre Unreal Engine gekümmert haben
Creation Engine kommt eher das Gefühl auf das die Entwickler es gar nicht mehr schaffen Sie richtig zu optimieren. Da sind Bugs drin die 20 Jahre schon vorkommen. Die sind mit ihrer eigenen Engine überfordert und haben nicht das Know how es zu begradigen. Es gibt immer wieder Community Mods die alles fixen das Bethesda selber nicht schafft....jedes Spiel die selben, das ist etwas peinlich.
@@nikolah.8472 Das Alter einer Engine spielt meiner Meinung nach kaum eine Rolle. Die Unreal Engine existiert bereits seit 1998 und die RAGE Engine von Rockstar auf dem GTA und Red Dead Redemption laufen existieren auch schon seit 2007. Man sollte sich nur Zeit nehmen seine Engine gut zu optimieren. Epic hat vor Fortnite lange Zeit keine Spiele entwickelt (ich glaube 6 Jahre) und die Abstände zwichen den neuen Rockstar Spielen wird auch immer größer. Bethesda sollte sich mal die Zeit nehmen und ihre Engine erstmal optimieren lassen und dann erst ihr nächstes Projekt anfangen. Es kann auch sein das die Benutzeroberfläche der Creation Engine veraltet und verwirrend ist. Das hört sich komisch an, aber auch sowas muss für eine Engine entwickelt werden und es ist vor allem für neue Mitarbeiter und anderen Entwicklerteams schwierig sich an eine neue Benutzeroberfläche anzupassen, wenn sie für Neulinge zu kompliziert ist
@@gamefreack64 Das creation kit is eigentlich ziemlich OK zu benutzen. (also wenn Bethesda das auch so verwendet, dann sollte das eigtl kein Problem sein)
ich finde die Spiele in der SCHMERTTERLING Engine aus Polen echt schön. Die sind Performant und sehen trotzdem klasse aus. Sind zwar 3D aber nicht wirklich für Shooter gedacht.
Der Grund warum Bethesda so an der Creation Engine hängt, liegt eventuell in der Datenbank. Man kann in Spielen mit Creation Engine irgendwo etwas fallen lassen und weggehen und man findet es auch nach Stunden Spielzeit an der gleichen Stelle noch wieder. Das funktioniert mit hunderten Objekten in Echtzeit und das ohne das das Spiel komplett zusammen bricht. Dafür wird die Spielwelt, so weit ich weiß, in Teilbereiche unterteilt und die Items in diesen Bereichen in einer Datenbank abgespeichert. Sobald der Spieler den Bereich erneut betritt, werden die Objekte wieder aus der Datenbank geladen. Die einzige Engine, die mir bekannt ist die das auch kann, ist die Star Engine (von Star Citizen/Cloud Impirium Games).
Das ist wahrscheinlich der letzte Grund, warum jemand eine Engine benutzt. Desweiteren wurde in dem Video erklärt, warum Bethesda die Creation Engine benutzt, weil man nicht einfach mal eine Engine wechselt. Da sind Leute die jahrelange Erfahrung mit der Engine haben. Die Module der Engine werden ausgetauscht oder geupdated, wie das jede andere Engine auch macht.
Ihr sprecht immer davon, dass es viele Tutorials für Unity oder Blender gibt. ABER: Tutorial ist nicht gleich Tutorial. Das ist zu 98% so: Hier, wenn du die und die Knöpfe drückst machst du genau das nach was ich dir vorgebe. Ein richtiges Tutorial erklärt jeden Button, die Hintergründe oder auf alle Fälle genug Infos, dass man es auch checkt! Da gibt's dann sogar deutschsprachig den "DerUnrealEngineer", der erklärt mega! Hab ich bei Unity extrem selten bis teilweise je nachdem was ich suche halt garnicht...
Ich habe in allen drei Engines gearbeitet. Benutze Unity am meisten. Es stimmt sehr, dass die Engine dann am besten ist, wenn du sie für dein Spiel dir ausgesucht hast. Was indirekt hier ja gesagt wurde. Viele Entwickler haben aber vielleicht eine Engine um einiges mehr benutzt, als die andere. Was dafür sorgt, dass man vielleicht versucht ein 2d Spiel in Unreal zu machen.
Nicht alle können so viel Zeit aufbringen, um sich in 3 verschiedene Engines einzuarbeiten/einzulernen, um effektiv darin arbeiten zu können. Daher werden viele 2D Spiele auch in der Unreal Engine entwickelt, auch wenn sich diese Engine nicht wirklich für 2D Spiele anbietet, da es bessere Alternativen gibt. Der Hintergrund ist der, dass man dadurch die Umgebung lernt und dann später sehr einfach auf 3D Spiele wechseln kann, wo ja diese Engine wiederum ihre Stärken hat.
4:43 zu behaupten dass ein Tool/programm/App eine bessere usability hat nur weil es mir community driven tutorials dafür gibt ist ne wilde aussage. So wild, dass ich sagen würde dass sie unwahr ist.
Weiß nicht Jungs, aber der Channel hier wird mir diese Frage wohl kaum beantworten, was? Nächstes Mal bitte wieder ein vernünftiges Video, liebe Grüße.
Roller Coster Tycoon wurde in Assembly geschrieben weil jede Form von Abstraktion performance zieht, und in der aktuellen zeit die größe des spiels mit akzeptabler hardware zur zeit nicht erreichbar währe wenn man irgendwelche engines nutzen würde :)
ihr habt vergessen, dass es noch sehr viele frameworks gibt wie microsoft xna oder monogames , mit welchen spiele wie Stardew valley oder celeste gemacht wurden. kann ich nur empfehlen wenn man programmieren mag.
Auch wenn es für 99,9% aller Spiele unsichtbar bleiben wird: Godot und v.A. Unity für die Entwickler einen RIESEN Vorteil: Dass man die Prograammiersprache C# (c-sharp) und nicht C++ nutzen muss. Ist zwar in der Theorie etwas langsamer, dafür muss man sich keinen Kopf über das machen, was der PC "Hinter den Kulissen" macht. Was bedeutet, dass deswegen viele Spiele gebaut haben, die es sonst nicht gegeben hätte. Und auch für Modding ist es hilfreich.
Würde ich nicht unbedingt sagen, Anfänger können mit der Unreal Engine sehr einfach gutaussehende Spiele herstellen ohne sich besonders anzustrengen. Einfach das Terraintool benutzen um eine schöne Welt zu schaffen, dann eine guten Character sich runterladen oder kaufen. Ein paar Tutorial anschauen zu Locomotionsystem und eventuell paar anderen Sachen, fertig ist ein "Walking Simulator". In Godot bräuchte man Monate was man in Unreal in Tagen/Wochen schaft.
Scrap Mechanic läuft schon seit einer Weile nicht mehr auf Ogre, sondern auf einer eigenen Engine. Ogre-code ist kaum noch vorhanden. Ogre ist auch technisch gesehen keine Game-Engine, sondern ist nur für die Grafik (Rendering) verantwortlich.
GoDot ist im Prinzip ne gute Engine - es gibt jedoch für Studios ein ABER denn wenn ihr Hauptziel Konsolen sind (da steam z.b. zu overcrowded ist ;)). Das Problem ist das GoDot Konsole 1. immer noch nicht richtig kann und 2. wenn es was gibt oder jemanden bzw. ne Firma gibt dann kostet das mal eben richtig Geld wenn man sein GoDot spiel auf die Konsole bringen möchte. W4Games (mit den Mitbegründern von GoDot) war die Hoffnung dass sich das ändert aber die haben im Dezember dann ihr Bezahlmodel veröffentlicht und nun sind die wohl auch erstmal raus bis sich was neues ergibt. Es gibt aber noch andere Engines z.b. Defold und Game Maker. Und MonoGame dürfte man nicht vergessen (aber die sind halt eher ein Framework).
Ok paar anmerkungen als Jemand der zumindest Hobby mäßig Games macht: "Man kann eine Engine auch Updaten" EHHHH AHHHH Technically not wrong aber es gibt in der Software Industry sowas wie "technical Debt" also die Ansammlung von Alt Code und Workarounds und "sort of Kind of Fixes" die über die Jahre in der Code Basis (und dazu gehört auch eine Engine) halt ansammeln. So ein Wenig als würdest du immer das selbe Sofa nutzen und statt mal ein neues Gerüst zu bauen klebst du es einfach mit Duct-Tape zusammen wenn es kaputt geht. Nach 300 Jahren funktioniert es zwar noch und du könntest die Seitenarm Lehne jetzt austauschen und versuchen all das Duct-Tape abzubekommen aber es ist wirklich besser für alle wenn du dir ein neues Kaufst. Ähnlich ist das mit Code. Code wird von Personen geschrieben und nach einem Jahrzehnt hat sich die art wie wir Code schreiben extrem geändert ... Und Code der so alt ist zu durchschauen und zu verstehen ist schwierig. Geschweige denn da große Änderungen vor zu nehmen. Das führt dann schnell zu nicht vorhergesehenen Fehlern an einer anderen Stelle. Auf der anderen Seite ist alles Wegschmeißen und neu Machen auch nicht einfach. Das braucht neue Work-Flows, neue Frameworks und vor allem SHER SEHR viel Zeit. Faktisch heißt es starte wider bei 0. Ist also auch nicht wirklich eine Lösung. Kurz um Bethasda ist gerade F.ed egal was sie machen sie werden probleme haben. Weiter wie bisher und keiner wird die Spiele mögen weil zu alt backen. Alles neu machen und das nächste Spiel wird auch keiner mögen (weil ein Engine Wechsel ist immer schlechte Qualität. Siehe Mass Effect Andromeda (UE -> Frostpunk)) Plus es wird halt extrem teuer etwas das ein Unternehmen das Profit Orientiert agiert ja auch nicht will.. Klar wenn man jetzt z.B. auf Unity wechselt bekommt man auch leichter (und wohl auch günstiger) neue Leute weil das wird gelehrt. (übrigens ein Vorteil jeder nicht Proprietären Engine gilt also genauso für UE, Lumberjack, Godot usw) aber Unternehmen scheuen halt diese Extremen kosten. auch ne Sache die man bedenken sollte ist die Programm Sprache die mit dem ganzen einhergeht. --- Unity (Und optional auch Godot) ist C# die Sprache ist einfach und zu gleich Mächtig. Du musst dich halt 0 um Memory kümmern aber du schreibst für sie halt auch gänzlich anders als für C++ (was Unreal hat, und ebenso Godot). Die Performance im Vergleich zwischen den beiden ist sehr davon abhängig was du machst. Dann gibt es so Sachen wie gdScript (Godot) und O3DE (Lumberjack) was eigene Sprachen sind die Interpretiert werden müssen. Das ist der mit abstand am langsamsten in der Runtime aber am einfachsten und schnellsten lernbar drin zu entwisckelnde. Und dann gibt es Visiual Programming (BluePrints (UE), NodeGraph (Unity), O3DE (Lumberjack) diese sind noch mal einfacher können aber extrem effizient sein (da die vorher kompiliert werden). Mit denen kann selbst ein Kind anfangen zu Programmieren. Was auch wider in die kosten eines Engine Wechsels rein spielt. Denn auf eine neue Sprache umstellen ist teuer. Manche Plugins gehen bisweilen auch nicht in allen Sprachen oder sind schwierig von anderen her raus aufzurufen. Und dann gibt es die Frage wie einzelene Sprachen zusammen arbeiten. Godot als Beispiel unterstützt GdScript, C# und C++ ... Mehr als Funktionen vom einen in den anderen Aufzurufen geht jedoch nicht. Blueprint und NodeGraph (UE und Unity) hingegen können Nodes in C++ / C# definieren und diese dann im Graphen einbauen. Hier ist eine Recht weitgehende Interaction also möglich. Auch das sind Dinge die man bei der Engine Wahl beachten muss. -- Ebenso Zu beachten wie groß der Assetstore ist und was hier zu finden ist. Das Unreal so groß in Realistischen Spielen ist und Unity nicht liegt auch daran. Im Unity Asset Store hingegen gibt es das kaum. Godot wider rum hat (noch) kaum Assets... -- Blender hat übrigens auch ne Engine drin .. du kannst da theoretisch auch ein Spiel drin machen ...
Blender HATTE mal eine Game Engine - die ist seit dem 2.8 Release (soweit ich mich erinnere) rausgenommen worden, weil die einfach technisch veraltet ist. Es gibt aber einen Fork, heißt "UPBGE", wo die Entwickler EEVEE für die Game Engine nutzbar machen :)
Ich würd sagen Unreal ist für Anfänger gut geeignet, man bekommt nach paar Tagen recht hübsche kleine 3D Spiele hin. Und man muss nichtmal programmieren können, einfach "Blueprints" benutzten. Im Assettstore gibts dann noch eine Menge kostenloses Zeug für die ersten Projekte.
Als Entwickler würde ich den Aussagen dieses Videos erstmal zum Großteil nicht zustimmen aufgrund gefährlichen Halbwissens hier. Aber ich finde es gut, dass hier mal "open-source" als Schlüsselwort fällt und sogar Godot wie auch auch Blender in den Raum geworfen werden als positive Beispiele. Wäre natürlich noch geil, wenn ihr weiter in das "open-source Rabbithole" vordringen würdet. Vielleicht würden dann so Begriffe wie Anarcho-Kommunismus fallen oder man würde mal die Diskussion in den Raum stellen, wieso eigentlich die meisten Menschen nicht Linux auf ihrem Desktop nutzen. Wäre auf jeden Fall witzig!
Auch wenn's hier eher um Game-Engines geht, kann ich nur einmal den Sci-Fi Kurzfilm Solstice 5 von Paul Chadeisson empfehlen, dessen VFX ausschließlich mit Blender erstellt wurde. Nur um mal zu schauen, was ein kostenloses Tool so alles hergeben kann.
![[안방1열 직캠4K] 베이비몬스터 치키타 'DRIP' (BABYMONSTER CHIQUITA FanCam) @SBS Inkigayo 241110](http://i.ytimg.com/vi/tnlxo79cAqY/mqdefault.jpg)
Also die Aussprache von "Godot" müssen wir nochmal zusammen üben, aber was ein cooles Video! Man merkt, dass ihr euch in die Materie eingelesen habt, da macht es auch als "Industry Professional" Spaß zuzuschauen.
Nicht vergessen, Godot ist nicht nur Open Source & kostenlos, but allen voran ein Community-Projekt, also kann jeder zur Engine selbst beitragen wenn er möchte - oder Plugins schreiben und sich die Arbeit bezahlen lassen, da habt ihr auch Recht gehabt.
Cruelty Squad
godot kann deutsch
Haben Sie einen Übersetzer benutzt oder können Sie wirklich Deutsch?
Wie wird es denn richtig ausgesprochen?
@@jbdh6510gedoo wäre wahrscheinlich am nächsten. einfach nach einem englischen Video über Godot suchen
Kleiner technischer Korrigierungskommentar:
Assembly ist keine Engine, es ist eine Gruppe von Programmiersprachen. Eine Gruppe von Programmiersprachen und keine einzelne, weil jede CPU-"Architektur" (Ja, Fachsprache!) eine eigene hat.
ARM (hauptsächlich bekannt aus Mobiltelefon-Chips wie den Snapdragons von Quallcomm, aber auch schon in Servern wie bei ¿Ampere?-Chips, die man auch bei Hetzner mieten kann (mit mehreren hundert Kernen oder irgendwie sowas krankem) oder den Graviton-CPUs von Amazon) hat z.B. mehrere Assembly-Sprachen, z.B. aarch64 oder THUMB.
Bei Desktop-Computern hat man eigentlich nur x86_64, ganz entfernt verwandt mit dem Intel 8086 aus den 70ern; die werden von AMD und Intel hergestellt, aber auch VIA und somit Zhaoxin haben eine Lizenz. Da gibt es 8086-Assembly (ursprünglich glaube ich iAPX 86 oder so genannt), i386, i686, amd64 (auch bei Intel-CPUs heißt das amd64).
OGRE ist übrigens keine Game Engine, der Name steht meiner Erinnerung zufolge für "Object-oriented Graphics Rendering Engine", demnach ist es eine Rendering Engine, also der Teil eines Spieles / einer Engine, der fürs fancy zeichnen zuständig ist. Die greifen dann wiederum auf Grafik-APIs (APIs sind Schnittstellen, Interaktionsmöglichkeiten zu, in diesem Fall dem Treiber) wie OpenGL, Vulkan, Direct3D (ein Teil von DirectX) oder Metal (bei macOS und iOS) zu.
Cool übrigens, dass Ihr Godot erwähnt. Opensource ist meistens toll.
dieser Mann hat Recht
Danke das du das gesagt hast :) hätte mich sonst genötigt gefühlt, aber wäre nicht so ausführlich geworden wie deins :)
top
"ARM (hauptsächlich bekannt aus Mobiltelefon-Chips [...])" und Macs
assembly is keine gruppe von programmiersprachen sondern eine einzelne sprache. sie hat nur je nach architektur unterschiedliche (wie nenn ich es am besten) "befehle und variablen".
würde das so beschreiben.
edit: instruction set heißt es glaube ich :D
@@MaxiKing913 Register mit Variablen zu vergleichen, ist keine gute Idee. Variablen können ebenso gut auf dem Heap oder Stack sein, statt in den Registern. Variablen gibt es in "Assembly" demnach nicht. Die Befehle sind anders, ja. Es gibt verschiedene Assembler für dieselbe Architektur, aber auch für verschiedene Architekturen. Die Unterschiede zwischen denen sind so groß, dass man von verschiedenen Sprachen reden kann. der GNU Assembler für SPARC wird komplett anders sein als der Netwide Assembler (NASM) für x86_64.
Hobby Unity VR Dev hier.
Falls jemand Interesse an Game Development hat, hier sind ein paar Tips die ich auch gerne gelernt hätte als ich anfing.
1. Die Engine ist eig. vollkommen egal, fokussiere dich nicht zu lange (wie ich) auf die Entscheidung welche Engine du benutzt.
Willst du möglichst reallistische Spiele nimm Unreal (obwohl sich da im Vergleich zu Unity HDRP auch nicht viel tut). Unreal ist für First/Thirdperson Spiele ausgelegt und optimiert. (man kann selbstverständlich auch was anderes entwickeln, aber dafür ist die Engine ursprünglich nunmal ausgelegt). Passt dein Spiel in diese Kategorie? Willst du viele versch. Spiele machen und alle Optionen haben? Mal 2D, 3D, VR oder AR und auch mal ein paar experimentelle Sachen: Unity
Nur 2D? Godot, obwohl Gotdot-3D auf einem guten Weg ist sehe ich es noch nicht auf dem Level mit Unity und UE.
Das schöne ist, das Wissen ist übertragbar. Kannst du Unreal, kannst du sehr einfach Unity lernen und andersherum. Deswegen lerne deine Engine und wenn eine Spiel-ldee es mal vorraussetzt habe keine Angst davor was neues auszuprobieren. Engines sollen dir helfen, nicht dich limitieren.
2. Deine ldee muss nicht geheim gehalten werden. lch sehe das oft, dass in Foren Devs ein absolutes Geheimnis drum machen, welche Konzepte sie verfolgen, was es schwer macht ihnen zu helfen. Niemand will deine Idee klauen. Deine Idee hatten wahrscheinlich schon 100 Leute vor dir, aber an der Umsetzung scheiterts dann immer. Das kannst du ändern, bleibe deiner ldee treu und mach das Projekt fertig.
3. GAME JAMS, GAME JAMS, GAME JAMS, GAME JAMS. Du lernst so unglaublich viel bei GameJams und bekommst super schnell Erfolgserlebnisse und lernst auch wie es ist ein Spiel fertig zu machen.
4. Du kannst natürlich gleich an deinem Herzensprojekt arbeiten. Aber sei dir im Klaren, du wirst jetzt nicht das nächste 100 Spieler Massive Multiplayer RPG programmieren können. Ich seh das leider viel zu oft, das neue Devs anfangen und sich an einem Maßstab messen, den nichtmal Studios mit hunderten Mitarbeitern und Millionen Budget erreichen. Dementsprechend ist man schnell demotiviert und viele hören dann einfach auf. Das wäre schade
Es ist extrem viel Arbeit, es ist frustrierend, es frisst Tage, Nächte und ziemlich viel Schlaf. Aber es bringt unglaublich viel Spaß.
Ich habe nach ein paar kleineren Versuchen direkt ein simples jump and run Spiel entwickelt, dass sogar spaß macht. Viel mehr ist für Anfänger aber nach meiner rellativ geringen Erfahrung vermutlich wirklich nicht drin. Ih stecke auch gerade etwas fest. Jump and Run ist doch sehr viel simpler als andere genre. Habs nichtmal richtig geschafft Lebensenergie zu programmieren.
Das ist eine echt gute Zusammenfassung davon. Ich programmiere jetzt seit 4 Jahren Spiele (vor allem mit Unity) und würde dir in allem zustimmen. Vor allem: macht Game Jams!
Das mit dem klein anfangen und immer größer werden kann man allgemein auf Programmieren beziehen. So lernt man am meisten.
Sehr gute Zusammenfassung. Und ich gebe dir 100% Recht.
Ein Punkt, der noch Beachtung finden darf ist die Lizenzthematik.
Ich selbst war für 2D Titel immer ein großer Fan von Game Maker bis es von Opera gekauft wurde und das reine Abomodell aufgedrückt bekam. Technisch super aber wer jetzt einsteigt, kann keine Permanentlizenz mehr kaufen.
Das gleiche gilt für Unity.
Aus dem Grund stehe ich selbst sehr hinter der Nutzung von Godot und Unreal weil bei diesen beiden die Aussichten gering sind, dass dich die Enginebereitsteller übers Ohr hauen. UE hat halt die Regelung, dass man pro Projekt, das über 1Mio$ jährlich einspielt, 5% abdrücken muss, sofern nicht anders verhandelt, aber 1 Mio um Jahr mit einem einzigen Projekt einspielen ist ein Punkt, den man erst mal erreichen muss.
Wieso sind Abomodelle z.B. bei Unity und GM (unabhängig von den technicshen Qualitäten der Engine) schlecht? Du zahlst 10 Jahre brav dein Abo, erstellst eine vielzahl an Projekten und hörst irgendwann mal auf, dafür zahlen zu wollen (oder die Firma dahinter geht pleite oder fängt an zu spinnen) dann ist ggf. dein Zugriff auf alle bestehenden Projekte weg. Wenn die SW beim Starten sagt "wo ist deine Lizenz?" und sich wieder beendet (sh. Adobe und Autodesk Produkte) bist du deinen gesamten vergangenen Werken beraubt, weil dir der Enginehersteller den Zugriff blockieren kann. UE und (natürlich) Godot haben keine solchen Kontrollen, was sie in dieser Hinsicht zuverlässiger macht.
Und: Ich bin bei dieser Sache nicht ganz auf dem aktuellen Stand aber wollte Unity nicht seit neuem neben dem Abomodell noch Zusätzlich was von den Einnahmen der Spiele bekommen (pro Titel eine Gebühr oder sowas)?
Also ich war bei "die engine ist nicht wichtig" raus - denn durchaus, eine engine ist das wichtigste, neben eigenem können, denn um so zukunftsweisender sie ist, desto besser wirst du in Zukunft mit ihr arbeiten können. Wenn du ein großprojekt hast, wirst du nicht in 3 Wochen fertig sein. Auf dem neusten Stand der Technologie zu sein, am besten noch vor allen anderen, ist ein extrem wichtiger Faktor. Und natürlich, keine geldgeilen wi**er wie unity als enginebesitzer zu haben. Kuss diggah.
Ich bin sehr beeindruckt wie ausgewogen ihr das Thema behandelt. Großen Respekt dafür, denn bisher gab es aus Nicht-Entwicklerkreisen keine wirklich gute Aufarbeitung des Themas Game Engines! Da merkt man sofort, dass ihr euch da auch schon selbst eingearbeitet habt 😄
Rick hat auch schon selbst mit Unity gearbeitet
godot ist halt einfach echt geil für indie/solo entwickler und ich find es supper das man mehr darüber redet, denn eigentlich hat es schon bewiesen was es kann, durch spiele wie: cruelty squad, endoparasitic, brotato, cassette beasts und dome keeper. - alles geile games
noch dazu; mit dem 4.0 update ist die engine gerade für 3d games besser geworden.
Fuck yeah. Mehr Liebe für Godot.
Es ist einfach so intuitiv und macht Spaß und eignet sich einfach perfekt für kleinere Spiele. Wobei mit der neuesten Version kann man auch deutlich mehr machen als nur kleine 2d Spiele :D
💙
btw. Godot hat auf grund der Unity problematik sehr viel Geld bekommen uns sehr viel aufmerksamkeit. Der Schritt von 3.0 auf 4.0 war schon imens. Aber mit mehr Geld und mehr Aufmerksamkeit, wird godot warscheinlich recht schnell noch geiler. Godot for live.
Godot is gut aber es fehlen echte Projekte die auf sich aufmerksam machen und mal richtig zeigen wozu die Engine fähig ist.
Bin selbst Unreal Entwickler aber derzeit find ich den Workflow in Godot in 3D einfach nur ungemütlich und umständlich deswegen bleib ich noch bei Unreal ^^
Wir hoffen auch, dass Godot immer besser wird :)
was mir bei Godot in erster Line fehlt ist C# to Web Export ... nur gdScript ist mir zu wenig / ich mag die Limitierungen nicht (gebt mir Fucking Exception Handling ... like wtf)
Glaube aber nicht das ich als Hobby Dev jemals wen zu bekommen kann mein Spiel zu installieren. Auf ne Seite zu klicken und zu spielen das denke ich kann ich schon ...
@@klausklavikus3836 Ein Godot Projekt das ne Menge aufmerksamkeit bekommen hat ist Backpack Battles :D Gibt schon ne Überraschend große menge an auch guten Spielen die mit Godot gemacht werden ...
Als Spieleentwickler kann ich sagen das es egal ist was Ihr pickt, solange Ihr etwas pickt und auch immer wieder an eurem projekt weitermacht.
Macht coolen sht da draußen.
👋🏻
Studiere gerade Games Programming und bin richtig froh das Leute außerhalb der Entwicklerbubble sich für solche Themen interessieren. Nicht jeder Fragt sich wie ein Spiel das man gerade Spielt Entwickelt wurde. Gerade weil so viel Halbwissen auf Social Media wie Twitter und Co. über diese Themen verbreitet wird, ist dieses Video einnfach mal erfrischend.
Funnily Enough, das RE in RE Engine steht nicht für Resident evil, der volle Name der Engine lautet: Reach for the Moon Engine
shoutout für capcom die jetzt mods und modding in ihren RE Engine games verhindern wollen
@@tgirlshark Wollte ich auch gerade schreiben, aber aktuell haben sie bei Resident Evil Revelations das Update mit dem Enigma Protector wieder zurückgezogen. Wahrscheinlich wird es wiederkommen, aber die Hoffnung stirbt zuletzt.
@@tgirlshark Entschuldigung dafür... ich war derjenige mit der Chun Sache...
Ich lerne derzeit mit Godot 2D Spiele zu erstellen. Macht Spaß, ist relativ easy und leicht verständliche Tutorials gibts auch zu genüge. Kann ich eigentlich nur empfehlen, wenn man PC oder Mobile Games machen möchte.
Godot wird "Godoh" ausgesprochen! Der Name kommt von dem abstrakten Theaterstück "Warten auf Godot", was aus Frankreich kommt. Deshalb ist der letzte Buchstabe von "Godot" still zu lesen.
Godutt
Haben die Entwickler nicht selber gesagt das die das alle unterschiedlich aussprechen 😂
Ich spreche es halt auch immer wie Rick aus
@@craftatacke Ich als altes Theaterkind kann so eine falsche Aussprache nicht einfach stehen lassen!
Wenn es dir nicht passt, dass ein Deutscher die Wörter nicht auf französische Art ausspricht, dann wander doch einfach nach Frankreich aus und fress den ganzen Tag Käse, Frösche und schlechten Wein.
@@craftatackeIm Endeffekt ist es egal wie man es ausspricht, solange man es verwendet. Es gibt trotzdem die eine richtige Aussprache.
Ich arbeite seit 6 Jahren mit der Unreal Engine auf täglicher Basis und 4:30 stimmt einfach nicht! Die Unreal Engine hat eine komplette Paper2D Klassensektion, mit der aktuellen Version (5.3) sind noch weitere 2D Features hinzugekommen z.B. Skeletal Editor mit dem man 2D Sprites einen Skeleton geben kann - das erlaubt es einen 2D Character technisch genau so zu behandeln wie einen 3D Character. Im Gegensatz zu Unity kann man bei Unreal standardmäßig mit Visual Scripting arbeiten (was man jedoch weitestgehend vermeiden sollte wenn es um Networking geht). Bei Unity geht das auch, aber viel eingeschränkter - man muss direkt mit C# programmieren. Es ist ein weitverbreiteter Irrtum, dass die Unreal Engine nicht für 2D Games geeignet ist und nur für ihre hochqualitative Renderfähigkeit populär und geeignet ist! Es ist durch und durch die stärkste Engine und es spielt keine Rolle ob man ein 2D Game, ein 3D Open World, eine App oder eine Website damit produziert.
Der Unterschied (bezüglich 2D und Mobile) zwischen Unity und Unreal ist eigentlich nur:
- Wenn Du ein Unity Projekt erstellst, ist es ein komplett leeres Gerüst, es sind keine Plugins standardmäßig aktiviert und man muss sämtliche Plugins die man im Projekt benötigt nachträglich aktivieren. Der Vorteil ist, dass das Projekt nicht zugemüllt ist mit Plugins die man nicht benötigt. Somit ist die Ausgangsbasis (z.B. für ein Mobile Game) viel einfacher.
- Wenn Du ein Unreal Projekt erstellst, sind tausende Plugins (auch die 2D Plugins) bereits standardmäßig integriert und aktiviert. Wenn man hier ein Mobile Game builden wollte, müsste man sich erstmal durch die Plugin Listen durcharbeiten um so viel wie möglich zu deaktivieren (damit die Build Size am Ende so klein wie Möglich ist). Theoretisch könnte man sogar ganze Engine-Integrationen entfernen und die Engine komplett neu builden, da der Source Code der Unreal Engine öffentlich zugänglich ist - bei Unity ist der Source Code nicht öffentlich.
Das Grundgerüst ist einfach nur anders aufgebaut. Aber im Prinzip können Unreal und Unity sehr ähnliche Leistungen vollbringen (auch was das Rendering betrifft). Unity kann auch Open World und heftiges Rendering. Unreal hat mit Nanite und Lumen (und World Partitioning) eben nur die besseren Voraussetzungen dafür geschaffen (z.B. mit Realtime Global Illumination).
Ich würde die Unreal Engine auch nicht als die "schwerere" Engine für Einsteiger bezeichnen. Gerade durch Blueprints, die Masse an Tutorials auf YT und dem Epic Learning Portal (und den Foren) bekommt man perfekte Voraussetzungen um die Unreal Engine zu lernen. Bei Unity musst Du direkt C# programmieren lernen, bei Unreal wird es durch Visual Scripting vereinfacht und wenn man so weit ist, kann man sich an C++ annähern.
Und kleiner Tipp an diejenigen die sich für Gameplay-Systeme in Unreal interessieren: Gameplay Ability System (GAS) wurde ursprünglich für Fortnite gebaut, steht aber allen zur Verfügung. Es ist ein unglaublich starkes System um Gameplay-Mechaniken aufzubauen (insbesondere in Multiplayer-Situationen). Es gibt ein paar wirklich gute GDC und Unreal Stream Talks darüber.
Und zu 6:56 - Mit ner Ryzen 16 Core CPU öffnet sich Unreal genau so schnell wie Photoshop und kompiliert 100k Shader in unter 5 Minuten. Normaler Gaming PC reicht bei keiner Engine aus.
Ich persönlich spiele schon sein Jahren mit dem Gedanken selbst Spiele herzustellen, hab aber keine Ahnung vom programmieren.
Seit paar Wochen schau ich mir Tutorials an zu Unreal und muss sagen, dass Unreal am einsteigerfreundlichsten aussieht.
Etwas seltsam find ich dass Godot übertrieben gelobt wird in vielen Videos und Unreal eher stiefmütterlich erwähnt wird.
PS, bei Unity gibts auch eine Visual Scripting Option (hab das auch erst letzte Woche erfahren) über die kaum Leute reden.
Yep. Entwickler machen die Spiele, die Engines sind nur Tools. Man kann mit jedem halbwegs stabilen Hammer einen Nagel in die Wand hauen, wenn man weiß wie man den Hammer benutzen muss. Und wenn man eine Schraube in der Wand drin haben will sollte man dann halt keinen Hammer sondern einen Akkuschrauber oder so verwenden.
Und Bethesda hat bei Fallout 76 versucht einen Hammer mit einer Teewurst in den Boden zu bohren.
Godot, my GOAT!
Extrem leicht zu lernen (trotz veralteter Tutorials) und geschmeidig zu benutzen.
Außerdem die Engine auf der Cruelty Squad gebaut wurde.
Als Unity Entwickler hab ich mich auch mal, wegen dem ganz Debakel, in Godot eingelesen (öffnet ja auch in 2 sek., da kann man das mal schnell machen) und sie ist auf jeden fall simpler und intuitiver. Leider fehlen dort immer noch ein paar Features, die ich in Unity vermisse. Wie zum Beispiel das testen von eigenen Features. Das ist Unity so viel einfacher, weil man während der "play test" läuft Sachen verändern kann.
Unreal hab ich tatsächlich noch nicht angefasst, obwohl das auch mal Zeit wird XD.
kannst auch in Godot während es läuft Variablen ändern. Kannst sogar im laufenden Spiel den Code ändern, weil GDScript nicht kompiliert werden muss 😁
Im play mode gibts auf der linken seite in the scene hierarchy 2 tabs, "Remote" und "Local". Wenn man auf remote stellt, sieht man die objekte die sich im playmode befinden, und kann sogar die parameter ändern (achtung, paramter werden im game nur geupdated, wenn sie im inspector und nicht in der scene view angepasst werden. z.B. Transform)
Oben drauf kann man wenn man im playmode ist, das kamera-icon oberhalb der scene view anklicken. Das sorgt dafür, das die game kamera sich mit der scene kamera synchronisiert. Somit wird die game kamera bewegt, wenn man die scene kamera im editor im playmode verändert
Werde mal Godot für mein nächstes Projekt ausprobieren.
Auf jeden Fall ne gute Idee. Godot ist ziemlich nice!
Halt uns auf dem Laufenden!
Ich habe im Mai 2023 mit Godot angefangen. Ich habe Tutorial von der Webseite Quiver gemacht, aber auch angefangen etwas Eigenes dort zu basteln. In Verbindung mit Blender habe ich festgestellt, dass man entweder Blendermodelle als .obj in Godot laden kann und dann in Godot mit einer Textur bestücken kann oder man macht ein Modell in Blender mit Textur und exportiert es als .glb/.gltf nach Godot. Es gibt aber auch ein Plugin für Godot wo man Terrain direkt in Godot machen kann mit einer Textur. Oder man erstellt einfach mesh-instanzen und lädt eine PBR-Texture mit dem eigenen Visual-Shader in Godot rein.
Unity sieht ganz gut aus, nur die Firma dahinter ist Mist.
Von Unity sollte man sich als Entwickler spätestens seit dem letzten Skandal fern halten :D
Definiere?
@@bowser2lux welcher Skandal?
@@ReichAnFleisch den im Video kurz angesprochen "20 Cent pro Installation" Skandal
@@ReichAnFleischsie hatten versucht einzuführen, dass jeder Entwickler, pro Installation des entwickelten Spiels, dafür blechen muss. Bzw. wollten die die Distributionsplattformen verantwortlich machen. Diese hätten die Kosten am Ende aber eh weitergeleitet.
Ich hab rein hobbymäßig Unity, Unreal 4 und zuletzt Godot ausprobiert und muss sagen, dass mich Godot mit Abstand am meisten überzeugt hat. Es hat nahezu unendlich viele Möglichkeiten, die aber gleichzeitig alle sehr simpel und intuitiv gehalten sind. Ist mMn nach die zur Zeit beste Engine (ausgenommen für AAA-Games u.Ä. wo Unreal 5 einfach grafisch die Oberhand hält).
Als beruflicher Programmierer und hobbymäßig-ein-bisschen-was-in-Unity,-GameMaker-und-Blender-gemacht-Habender muss ich euch echt loben, soweit ich das beurteilen kann habt ihr das sehr gut zusammengefasst. Ein paar Punkte würde ich gerne noch hinzufügen.
Wie in den Kommentaren schon angemerkt wurde, reiht Assembly sich hier eigentlich nicht mit ein, da es eine Gruppe hardwarenaher Programmiersprachen ist und keine Engine. Man kann theoretisch eine Engine in Assembly schreiben, aber die meisten Engines werden wohl in C oder C++ geschrieben, welche Programmiersprachen sind, die ähnlich wie Assembly-Sprachen direkt in Maschinencode (Nullen und Einsen) übersetzt werden, aber etwas einfacher zu nutzen sind.
Man kann theoretisch in fast jeder Programmiersprache ein Computerspiel schreiben, und muss dabei auch nicht zwingend erst eine Engine entwickeln. Eine Engine ist eher eine Ausgliederung der hardwarenahen Features, die man in vielen Spielen benötigt. So erspart man sich die Arbeit, zB. Raytracing-Support noch komplett von Hand programmieren zu müssen, stattdessen kann man es über die Benutzeroberfläche der Engine umsetzen.
Trotzdem bieten die meisten Engines auch die Möglichkeit, Teile des Spiels in Form von Skripts als Programmcode zu schreiben, im Fall von Unreal zum Beispiel ist das vorwiegend C++ und bei Unity C#. Beide haben dann nochmal Bibliotheken mit Programmierfunktionen für diese jeweiligen Programmiersprachen, die man nutzen kann, um sich das Leben einfacher zu machen. Godot hat zum Beispiel sogar seine eigene Skriptsprache, die man nutzen kann, unterstützt aber auch einige andere Sprachen wie C#.
Ich hoffe das war halbwegs verständlich erklärt.
Godot einfach toll. Nutze ich in kombination mit Blender und es ist so herrlich.
Wie Einsteigerfreundlich ist Godot für jemanden der keine Programmiersprache kann ?
Gibts da auch so eine Art Blueprints wie bei Unreal ?
@@paluxyl.8682 ich bin immernoch Einsteiger, das coden ist dahingehend einsteigerfreundlich, da es eigene godot eigene Scriptsprache ist, die auf Phyton basiert.
Hab selber super Probleme mit programmieren etc. Aber da kam ich doch ganz gut rein. Mir haben aufjedenfall sehr viele Tutorials geholfen.
Ich bin gerade dabei, mein eigenes 2D Game in Godot zu schreiben. Mir ging es auf den Sack, wie viel man in Godot händisch für Animationen machen muss. Hab ein Plugin geschrieben und es wurde mit Source Code im Godot Asset Store veröffentlicht. Muss sagen, es ist nice, wie einfach die Plugins geschrieben werden können und wie einfach es gemacht wird diese zu teilen. Note: Es gibt einen Review Prozess und die Bugs gehen direkt an mich.
Bei der Preisgestaltung der Engines habt ihr einen echt wichtigen Punkt vergessen. Bei der Unreal Engine muss man von der ersten eingenommenen Million gar nichts abgeben. Also wenn du 1.000.000$ einnimmst und 900.000$ Kosten für Koks und Nutten hattest, dann kannst du die ganzen restlichen 100.000$ auch noch für Koks und Nutten ausgeben.
Speziell für Indie Entwickler ist es da auch egal ob Unity einen Prozent weniger kostet.
Ich hab bis jetzt ja meine meiste Erfahrung in Unity gesammelt und nur ein klitze kleines bisschen in Unreal. Ich bin jetzt aber echt froh, dass ich bis jetzt eher an Konzepten geschrieben habe und eher ein paar VR Prototypen in Unity gemacht habe anstatt wirklich Zeit in ein Projekt zu investieren das ich auch veröffentlichen will. Da ist mir auch egal, dass die ganze Zeit die ich in Unity gesteckt habe mehr oder weniger umsonst war. Ich hab jetzt auch nicht wirklich Ambitionen 2D Spiele zu machen. Dafür machen die ganzen neuen Features von UE5 aber auch einfach absolut Sinn für die Konzepte an denen ich gearbeitet habe.
Stimmt, wichtiger Unterschied!
Was auch nicht stimmte: Dass UE nicht open-source sei. Man muss zwar einer speziellen Lizenz zustimmen, sagt damit aber nur, dass man die Sources nicht klauen wird. Ansonsten kann man frei Dinge vorschlagen und mit entwickeln.
Age of Empires wurde auch in Assembler geschrieben und war daher in 800x600 noch flüssiger und ansehnlicher als C++ Games in 640x480.
Juhu! Godot und Wichtigkeit von Open-Source erwähnt!
Hey, Leute ihr habt mich echt positiv überrascht wie euer Video präsentiert habt. Einige Aktionen haben mich irgendwie an Muppet Show erinnert. Sehr lustiges, unterhaltsames aber dennoch informatives Video.
Ich kann wirklich nur empfehlen mal das "Was ist eine Engine" Video von Samb anzuschauen
Der Vorteil an Assembler ist halt das es so programmiert werden kann das es quasi auf jeder Hardware gut läuft.
Der Nachteil ist aber das Assembler einfach auch der reinste Terror ist in Programmierung.
Wenn man z.B. ein Spiel für eine Konsole Programmiert und es in Assembler Programmiert kann man z.B. auch weit aus mehr aus der Hardware rausholen als mit fertigen Engines die auf alles laufen oder ausgelegt sind dafür
Ahh die VRChat Tutorials, wie Rippe ich einen Charakter aus einem Spiel, mache die Boobies Bouncy 200x, und Importiere SIe als Avatar....
Bin ich jetzt SpieleEntwickler?
Ohne Video geschaut zu haben: Die mit der der Entwickler am besten umgehen kann
hehe wollte ich auch schreiben
Also die Engine im real Life ist ganz gut, nur hab ich irgendwie die Cheats noch nicht gefunden.
Hast den falschen Seed bekommen.
Die Unreal Engine braucht nur solange zum öffnen, weil er erst Epic Games Launcher öffnet und danach die Unreal Engine startet 😂
Ich arbeite selbst mit der Godot Engine und hätte eine Sache hier über die Engine noch gerne erwähnt gehabt:
Die Engine unterstützt von sich aus bereits 2 Programmiersprachen, und per Plugin sogar noch 2 weitere.
Eine von den 2 Hauptprogrammiersprachen ist GDScript, die völlig eigene Programmiersprache die sogar für Anfänger wie mich das Programmieren sehr angenehm macht.
Ich denk’ jedes Mal Rick trägt 'ne TNG Uniform, wenn er den Pulli anhat.
der Erfolg von Blender basiert darauf, dass leute die damit geld verdienen freiwilig spenden, und dass sie sich coole programmierer ins boot holen, die sich durch das open source modell sehr gut damit auskennen. und dass man auch innerhalb eines programms eigentlich ein großteil der 3D Aufgaben (und auch 2D nebenbei bemerkt) erledigen kann. und die interne render engines sind auch nicht zu verachten. EEVEE und CyclesX
Die Engine kann so alt sein wie so will, das siehst du nur im Editor und an den begrenzten Möglichkeiten. Das sagt sehr oft, aber nichts an der Qualität der Modelle und Texturen. Wenn ich in der UE 5 Würfel mit Texturen und verbuggte Scripte für die Missionen schreiben, dabei vergesse das Probe light vorzubacken (Das Licht) wird es auch auf der UE 5 ein Gothic 3 geben.
1:21 Nicht um Bethesda in Schutz zu nehmen, aber hauseigene Engine werden natürlich intern immer weiter entwickelt und verbessern sich im laufe der Zeit. Es gibt nur keinen öffentlichen Release welche mit neuen Releaseversionen gekennzeichnet sind. Ist in etwa so als würde man sagen die Unreal Engine gibt es seit 1998.
Ob der momentane Entwicklungsstand der Creation Engine auch zeitgemäßg ist, bleibt natürlich eine ganz andere Frage. ;)
Mir fällt auf das die meisten Spiele Engines von Shooter stammen.
Sei es die Id Tech Engine, Source, Frostbite, Cry und sogar die Unreal Engine.
Sie wurden alle speziell für Shooter entwickelt bzw. zu Anfang nur für Shooter entwickelt
Gut. Jetzt wo wir das geklärt haben: Welche Programmiersprache macht die besten Programme?
Lochpapier!
Der/die Entwickler von Roller Coaster Tycoon sind Legenden!
Wer Interesse an einer 2D-RTS Engine im stil von C&C hat sollte sich mal OpenRA anschauen. Das Projekt ist Engine wie auch Spiel in einem, was vielleicht auf den ersten Blick verwirrend sein mag. Alles ist OpenSource es gibt und gab viele laufende Mod Projekte.
Bin seit 2014 ca Unreal Engine Entwickler. Es ist mehr arbeit als in den anderen Engine, dafür habt ihr aber auch mehr und professionellere Möglichkeiten. Nanite und Niagara sind da nur 2 der beeindruckenden neuen Technologien mit denen einiges Möglich ist. Wenn ihr euch selbst hasst... nehmt euch die Zeit und lernt die UE5 sie wird euch sehr glücklich machen ;)
Cooles Video. Bei dem Assembly Vergleich musste ich laut lachen 🤣🤣
Die Enigne die wohl am meisten kann ist die Star Engine. bzw. die am meisten hin bekommt ohne in die knie zu gehen.
Ich trauere noch um die Fox Engine, welche nur für Metal Gear Solid V und für einige Pro Evolution Soccer Spiele eingesetzt wurde
Fun fact. RE Engine steht für "REach for the Moon" Engine. RE ist also von den ersten beiden Buchstaben von dem Wort reach
Ey, die Creation Engine hat schon ein paar Vorteile.Zum beispiel merkt sich die Engine, wenn du einen Gegenstand aufsammelst und irgendwo anders hinschmeißt. Und das für einen ziemlich langen Zeitraum, was bei Rollenspielen ziemlich geil ist. Ansonsten kannst du ziemlich gut Random Generierte Welten erstellen und sie ist leicht Modbar und nicht allzu komplex. Falls ich Bullshit laber korrigiert mich bitte
jedes unreal engine spiel sieht gleich aus. Alles wie Jump Force. Dieser Blurr effekt nach einem Treffer regt mich so auf
Aaaahhhh seit Jahren springe ich hin und her und hin und her. Die meiste Erfahrung hab ich mit Unity, aber würde so gern auf Open Source entwickeln. Finde bei Godot aber dieses GDscript so super weird. Die Sprache ist an für sich super, aber quasi Python. Ich sehe absolut nicht den sinn ein quasi-Python zu bauen, wenn wir bereits Python haben. Also GDscript macht nichts besser, ist genauso schnell, ist genauso interpretiert, statt kompiliert und die Syntax ist auch quasi gleich. ABER man kann die vielen tausend Python-Bibliotheken, die es schon gibt nicht benutzen! Das ist ein extremer Nachteil und ich kann beim besten Willen nicht verstehen, warum man an dieser Stelle das Rad neu erfinden musste. Das gleiche mit der eingebauten IDE. Warum muss eine Engine eine integrierte IDE haben? Ich bin zufrieden mit meiner und denke die Energie ist besser in die eigentliche Engine investiert.
Aber to be fair: von Haus aus werden noch C#, C und C++ unterstützt und durch die community quasi jede andere Sprache - auch Python. Wunderte mich nur warum solche Entscheidungen getroffen wurden.
Bei Unreal sind es 5% von jedem neuen € der über die 1 Millionen Marke dazu verdient wurde. Also ist die erste Million gebührenfrei.
Godot represent! Und ich lieb's immer wieder, wie unterschiedlich man den Namen aussprechen kann :P
Ich glaube ein Problem der Creation Engine ist, das Bethesda sich nicht richtig um ihre Engine kümmert. z.B. Valve hat extra die Entwicklung von Half-Life 3 und weiterer Spiele gestoppt um die Source Engine 2 fertig stellen zu können. Denn bei Half-Life 2 welches Parallel zu Original Source Engine entwickelt wurde, hatte sich die Entwicklung beider Projekte verzögert, da wegen Half-Life 2 weniger Mitarbeiter an der Engine arbeiten konnten und wegen der unfertig Source Engine auch die Tools für die Entwicklung von Half-Life 2 fehlten.
Es hatte ja ein Grund gehabt wieso Epic Games vor Fortnite lange Zeit kein Spiel mehr entwickelt hat, da sie sich überwiegend um ihre Unreal Engine gekümmert haben
Creation Engine kommt eher das Gefühl auf das die Entwickler es gar nicht mehr schaffen Sie richtig zu optimieren. Da sind Bugs drin die 20 Jahre schon vorkommen. Die sind mit ihrer eigenen Engine überfordert und haben nicht das Know how es zu begradigen. Es gibt immer wieder Community Mods die alles fixen das Bethesda selber nicht schafft....jedes Spiel die selben, das ist etwas peinlich.
@@nikolah.8472 Das Alter einer Engine spielt meiner Meinung nach kaum eine Rolle. Die Unreal Engine existiert bereits seit 1998 und die RAGE Engine von Rockstar auf dem GTA und Red Dead Redemption laufen existieren auch schon seit 2007.
Man sollte sich nur Zeit nehmen seine Engine gut zu optimieren. Epic hat vor Fortnite lange Zeit keine Spiele entwickelt (ich glaube 6 Jahre) und die Abstände zwichen den neuen Rockstar Spielen wird auch immer größer. Bethesda sollte sich mal die Zeit nehmen und ihre Engine erstmal optimieren lassen und dann erst ihr nächstes Projekt anfangen.
Es kann auch sein das die Benutzeroberfläche der Creation Engine veraltet und verwirrend ist.
Das hört sich komisch an, aber auch sowas muss für eine Engine entwickelt werden und es ist vor allem für neue Mitarbeiter und anderen Entwicklerteams schwierig sich an eine neue Benutzeroberfläche anzupassen, wenn sie für Neulinge zu kompliziert ist
@@gamefreack64 Das creation kit is eigentlich ziemlich OK zu benutzen. (also wenn Bethesda das auch so verwendet, dann sollte das eigtl kein Problem sein)
Woher weißt du das über Half Life 3? Leaked Information ;)
Brotato wurde mit Godot erstellt ... Also man kann ernsthafte Spiele damit machen
Northlight von Remedy, alle Spiele Klasse :D
ich finde die Spiele in der SCHMERTTERLING Engine aus Polen echt schön. Die sind Performant und sehen trotzdem klasse aus. Sind zwar 3D aber nicht wirklich für Shooter gedacht.
Ja Starfield fühlt sich 1:1 wie ein Space Skin für Fallout 4 an
Tap Strafing könnte auf dem gleichen weg wie damals in der CS Beta verhindern, es gehört einfach dazu
Blender hat so viele Tutorials, weil es so besch****n kompliziert ist
Der Grund warum Bethesda so an der Creation Engine hängt, liegt eventuell in der Datenbank. Man kann in Spielen mit Creation Engine irgendwo etwas fallen lassen und weggehen und man findet es auch nach Stunden Spielzeit an der gleichen Stelle noch wieder. Das funktioniert mit hunderten Objekten in Echtzeit und das ohne das das Spiel komplett zusammen bricht. Dafür wird die Spielwelt, so weit ich weiß, in Teilbereiche unterteilt und die Items in diesen Bereichen in einer Datenbank abgespeichert. Sobald der Spieler den Bereich erneut betritt, werden die Objekte wieder aus der Datenbank geladen. Die einzige Engine, die mir bekannt ist die das auch kann, ist die Star Engine (von Star Citizen/Cloud Impirium Games).
Das ist wahrscheinlich der letzte Grund, warum jemand eine Engine benutzt. Desweiteren wurde in dem Video erklärt, warum Bethesda die Creation Engine benutzt, weil man nicht einfach mal eine Engine wechselt. Da sind Leute die jahrelange Erfahrung mit der Engine haben. Die Module der Engine werden ausgetauscht oder geupdated, wie das jede andere Engine auch macht.
Ihr sprecht immer davon, dass es viele Tutorials für Unity oder Blender gibt.
ABER: Tutorial ist nicht gleich Tutorial. Das ist zu 98% so:
Hier, wenn du die und die Knöpfe drückst machst du genau das nach was ich dir vorgebe.
Ein richtiges Tutorial erklärt jeden Button, die Hintergründe oder auf alle Fälle genug Infos, dass man es auch checkt!
Da gibt's dann sogar deutschsprachig den "DerUnrealEngineer", der erklärt mega! Hab ich bei Unity extrem selten bis teilweise je nachdem was ich suche halt garnicht...
Ich habe in allen drei Engines gearbeitet. Benutze Unity am meisten. Es stimmt sehr, dass die Engine dann am besten ist, wenn du sie für dein Spiel dir ausgesucht hast. Was indirekt hier ja gesagt wurde. Viele Entwickler haben aber vielleicht eine Engine um einiges mehr benutzt, als die andere. Was dafür sorgt, dass man vielleicht versucht ein 2d Spiel in Unreal zu machen.
Nicht alle können so viel Zeit aufbringen, um sich in 3 verschiedene Engines einzuarbeiten/einzulernen, um effektiv darin arbeiten zu können. Daher werden viele 2D Spiele auch in der Unreal Engine entwickelt, auch wenn sich diese Engine nicht wirklich für 2D Spiele anbietet, da es bessere Alternativen gibt.
Der Hintergrund ist der, dass man dadurch die Umgebung lernt und dann später sehr einfach auf 3D Spiele wechseln kann, wo ja diese Engine wiederum ihre Stärken hat.
4:43 zu behaupten dass ein Tool/programm/App eine bessere usability hat nur weil es mir community driven tutorials dafür gibt ist ne wilde aussage. So wild, dass ich sagen würde dass sie unwahr ist.
Humor ist drin, gefällt mir.
Ich vermisse die Cryengine und den Editor von Crysis 1 damals. Das waren noch Zeiten.
Brauchst du nicht, einfach auf die Webseite gehen und die CryEngine runterladen
ok WAS ist Steves problem mit Octopath Traveller??? Das sieht so insane geil aus
Unity‘s %-Satz ist nicht 4%, sondern 2.5%.
Weiß nicht Jungs, aber der Channel hier wird mir diese Frage wohl kaum beantworten, was?
Nächstes Mal bitte wieder ein vernünftiges Video, liebe Grüße.
Roller Coster Tycoon wurde in Assembly geschrieben weil jede Form von Abstraktion performance zieht, und in der aktuellen zeit die größe des spiels mit akzeptabler hardware zur zeit nicht erreichbar währe wenn man irgendwelche engines nutzen würde :)
ihr habt vergessen, dass es noch sehr viele frameworks gibt wie microsoft xna oder monogames , mit welchen spiele wie Stardew valley oder celeste gemacht wurden. kann ich nur empfehlen wenn man programmieren mag.
Die beste Engine, mit der besten Community ist immer noch Minecraft.
Auch wenn es für 99,9% aller Spiele unsichtbar bleiben wird: Godot und v.A. Unity für die Entwickler einen RIESEN Vorteil: Dass man die Prograammiersprache C# (c-sharp) und nicht C++ nutzen muss. Ist zwar in der Theorie etwas langsamer, dafür muss man sich keinen Kopf über das machen, was der PC "Hinter den Kulissen" macht. Was bedeutet, dass deswegen viele Spiele gebaut haben, die es sonst nicht gegeben hätte. Und auch für Modding ist es hilfreich.
Tolles Video
habt ihr von Leuten aus den verschiedenen Bereichen (AAA, Indie) euch die Infos geholt, weil vieles war eher halbwissen ?:/
Als Entwickler würde ich sagen es kommt nicht auf die Engine an sondern auf den/die Entwickler
Trotzdem gutes Video
Würde ich nicht unbedingt sagen, Anfänger können mit der Unreal Engine sehr einfach gutaussehende Spiele herstellen ohne sich besonders anzustrengen.
Einfach das Terraintool benutzen um eine schöne Welt zu schaffen, dann eine guten Character sich runterladen oder kaufen. Ein paar Tutorial anschauen zu Locomotionsystem und eventuell paar anderen Sachen, fertig ist ein "Walking Simulator".
In Godot bräuchte man Monate was man in Unreal in Tagen/Wochen schaft.
Scrap Mechanic läuft schon seit einer Weile nicht mehr auf Ogre, sondern auf einer eigenen Engine. Ogre-code ist kaum noch vorhanden.
Ogre ist auch technisch gesehen keine Game-Engine, sondern ist nur für die Grafik (Rendering) verantwortlich.
Steven... hast du gesagt octopath sieht grauenvoll aus??
Ich finds süß☹️
der letzte Satz hat mich gekillt xD
Gamemaker ist wirklich toll, um in Spieleentwicklung einzusteigen.
GoDot ist im Prinzip ne gute Engine - es gibt jedoch für Studios ein ABER denn wenn ihr Hauptziel Konsolen sind (da steam z.b. zu overcrowded ist ;)).
Das Problem ist das GoDot Konsole 1. immer noch nicht richtig kann und 2. wenn es was gibt oder jemanden bzw. ne Firma gibt dann kostet das mal eben richtig Geld wenn man sein GoDot spiel auf die Konsole bringen möchte. W4Games (mit den Mitbegründern von GoDot) war die Hoffnung dass sich das ändert aber die haben im Dezember dann ihr Bezahlmodel veröffentlicht und nun sind die wohl auch erstmal raus bis sich was neues ergibt.
Es gibt aber noch andere Engines z.b. Defold und Game Maker. Und MonoGame dürfte man nicht vergessen (aber die sind halt eher ein Framework).
OMG. Wie Marhemantastisch
Unity sollte man auf keinen Fall mehr unterstützen, wer mehr darüber wissen will kann sich mal die Videos von dem TH-camr SambZockt anschauen
Samb wird bei diesem Video vor Freude weinen
4:28 Was soll der Octopath Traveler Hate? Die Grafik ist das schönste was ich je gesehen habe😭
da sieht man mal, dass kojima absoluter profi ist und auf die entwicklung der fox-engine für mgs5 bestand.
Ok paar anmerkungen als Jemand der zumindest Hobby mäßig Games macht:
"Man kann eine Engine auch Updaten" EHHHH AHHHH Technically not wrong aber es gibt in der Software Industry sowas wie "technical Debt" also die Ansammlung von Alt Code und Workarounds und "sort of Kind of Fixes" die über die Jahre in der Code Basis (und dazu gehört auch eine Engine) halt ansammeln. So ein Wenig als würdest du immer das selbe Sofa nutzen und statt mal ein neues Gerüst zu bauen klebst du es einfach mit Duct-Tape zusammen wenn es kaputt geht. Nach 300 Jahren funktioniert es zwar noch und du könntest die Seitenarm Lehne jetzt austauschen und versuchen all das Duct-Tape abzubekommen aber es ist wirklich besser für alle wenn du dir ein neues Kaufst.
Ähnlich ist das mit Code. Code wird von Personen geschrieben und nach einem Jahrzehnt hat sich die art wie wir Code schreiben extrem geändert ... Und Code der so alt ist zu durchschauen und zu verstehen ist schwierig. Geschweige denn da große Änderungen vor zu nehmen. Das führt dann schnell zu nicht vorhergesehenen Fehlern an einer anderen Stelle.
Auf der anderen Seite ist alles Wegschmeißen und neu Machen auch nicht einfach. Das braucht neue Work-Flows, neue Frameworks und vor allem SHER SEHR viel Zeit. Faktisch heißt es starte wider bei 0. Ist also auch nicht wirklich eine Lösung.
Kurz um Bethasda ist gerade F.ed egal was sie machen sie werden probleme haben. Weiter wie bisher und keiner wird die Spiele mögen weil zu alt backen. Alles neu machen und das nächste Spiel wird auch keiner mögen (weil ein Engine Wechsel ist immer schlechte Qualität. Siehe Mass Effect Andromeda (UE -> Frostpunk)) Plus es wird halt extrem teuer etwas das ein Unternehmen das Profit Orientiert agiert ja auch nicht will.. Klar wenn man jetzt z.B. auf Unity wechselt bekommt man auch leichter (und wohl auch günstiger) neue Leute weil das wird gelehrt. (übrigens ein Vorteil jeder nicht Proprietären Engine gilt also genauso für UE, Lumberjack, Godot usw) aber Unternehmen scheuen halt diese Extremen kosten.
auch ne Sache die man bedenken sollte ist die Programm Sprache die mit dem ganzen einhergeht.
---
Unity (Und optional auch Godot) ist C# die Sprache ist einfach und zu gleich Mächtig. Du musst dich halt 0 um Memory kümmern aber du schreibst für sie halt auch gänzlich anders als für C++ (was Unreal hat, und ebenso Godot). Die Performance im Vergleich zwischen den beiden ist sehr davon abhängig was du machst.
Dann gibt es so Sachen wie gdScript (Godot) und O3DE (Lumberjack) was eigene Sprachen sind die Interpretiert werden müssen. Das ist der mit abstand am langsamsten in der Runtime aber am einfachsten und schnellsten lernbar drin zu entwisckelnde.
Und dann gibt es Visiual Programming (BluePrints (UE), NodeGraph (Unity), O3DE (Lumberjack) diese sind noch mal einfacher können aber extrem effizient sein (da die vorher kompiliert werden). Mit denen kann selbst ein Kind anfangen zu Programmieren.
Was auch wider in die kosten eines Engine Wechsels rein spielt. Denn auf eine neue Sprache umstellen ist teuer. Manche Plugins gehen bisweilen auch nicht in allen Sprachen oder sind schwierig von anderen her raus aufzurufen.
Und dann gibt es die Frage wie einzelene Sprachen zusammen arbeiten. Godot als Beispiel unterstützt GdScript, C# und C++ ... Mehr als Funktionen vom einen in den anderen Aufzurufen geht jedoch nicht.
Blueprint und NodeGraph (UE und Unity) hingegen können Nodes in C++ / C# definieren und diese dann im Graphen einbauen. Hier ist eine Recht weitgehende Interaction also möglich. Auch das sind Dinge die man bei der Engine Wahl beachten muss.
--
Ebenso Zu beachten wie groß der Assetstore ist und was hier zu finden ist. Das Unreal so groß in Realistischen Spielen ist und Unity nicht liegt auch daran. Im Unity Asset Store hingegen gibt es das kaum. Godot wider rum hat (noch) kaum Assets...
--
Blender hat übrigens auch ne Engine drin .. du kannst da theoretisch auch ein Spiel drin machen ...
Blender HATTE mal eine Game Engine - die ist seit dem 2.8 Release (soweit ich mich erinnere) rausgenommen worden, weil die einfach technisch veraltet ist. Es gibt aber einen Fork, heißt "UPBGE", wo die Entwickler EEVEE für die Game Engine nutzbar machen :)
Rick und englische Aussprache: Vallah nix Gutes.
godot besonders für anfänger sehr intuitiv
Ich würd sagen Unreal ist für Anfänger gut geeignet, man bekommt nach paar Tagen recht hübsche kleine 3D Spiele hin. Und man muss nichtmal programmieren können, einfach "Blueprints" benutzten. Im Assettstore gibts dann noch eine Menge kostenloses Zeug für die ersten Projekte.
Ich benutz Godot schon seit einen Jahr :D kann es auch nur weiter empfehlen 🎉🎉🎉🎉
Bethesda machen alles mit der Creation Engine weil "It just works!" :D
?? :-D ich find den Stil von Octopath Traveller (und dem kommenden Dragon Quest III remake) eigentlich super
WTF?! Octopath Traveler is beautiful!
Uff ich sehe schon sämtliche Entwickler die Hände übern Kopf zusammen schlagen ....
7:38 du kannst mit blender auch nen ganzen Pixar Film machen wenn du die Zeit und das können hast. Ist mittlerweile ziemlich gleich capable wie Maya
Source 1 ist liebe
Als Entwickler würde ich den Aussagen dieses Videos erstmal zum Großteil nicht zustimmen aufgrund gefährlichen Halbwissens hier. Aber ich finde es gut, dass hier mal "open-source" als Schlüsselwort fällt und sogar Godot wie auch auch Blender in den Raum geworfen werden als positive Beispiele.
Wäre natürlich noch geil, wenn ihr weiter in das "open-source Rabbithole" vordringen würdet. Vielleicht würden dann so Begriffe wie Anarcho-Kommunismus fallen oder man würde mal die Diskussion in den Raum stellen, wieso eigentlich die meisten Menschen nicht Linux auf ihrem Desktop nutzen. Wäre auf jeden Fall witzig!
Ich stehe Mal hier und halte die Flagge für Bevy hoch 😊
Auch wenn's hier eher um Game-Engines geht, kann ich nur einmal den Sci-Fi Kurzfilm Solstice 5 von Paul Chadeisson empfehlen, dessen VFX ausschließlich mit Blender erstellt wurde. Nur um mal zu schauen, was ein kostenloses Tool so alles hergeben kann.
Dem kann ich nur zustimmen. Einfach göttlich, was der da gemacht hat.
Unreal ist besser, da muss man nicht "irgendwann" pro download zahlen und man kann spiele in VR spielen..
Die Entwickler machen die Spiele xD