PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Warum entwickeln viele Spieleentwickler noch eigene Engines?


Railer
2021-05-07, 10:23:53
Hi zusammen,

mit fällt schon seit Jahren auf und jetzt wieder durch das neue Resident Evil 8 wieder, dass offenbar immer noch viele Spieleentwickler eigene Engines komplett neu entwickeln, anstatt UE, Unity oder CryEngine oder sonst was zu lizensieren. Ist es tatsächlich so viel billiger? Ich stelle mir eine Spiele-Engine zu entwickeln so vor, wie ein Rad neu zu erfinden - das kostet Zeit, Geld und benötigt extrem fähige Programmierer. Beim Lizensieren einer Engine würde man sich auf das Kerngeschäft konzentrieren können - nämlich Content erzeugen, also das Spiel selbst. Das ist so, als würden Reisebüros ihre eigenen Flugzeuge entwickeln.
Warum ist das in der Spieleindustrie so?

just4FunTA
2021-05-07, 10:31:42
Knowhow im eigenen Haus, Kosten und Unabhängigkeit würde mir dazu einfallen.

][immy
2021-05-07, 10:35:39
Hi zusammen,

mit fällt schon seit Jahren auf und jetzt wieder durch das neue Resident Evil 8 wieder, dass offenbar immer noch viele Spieleentwickler eigene Engines komplett neu entwickeln, anstatt UE, Unity oder CryEngine oder sonst was zu lizensieren. Ist es tatsächlich so viel billiger? Ich stelle mir eine Spiele-Engine zu entwickeln so vor, wie ein Rad neu zu erfinden - das kostet Zeit, Geld und benötigt extrem fähige Programmierer. Beim Lizensieren einer Engine würde man sich auf das Kerngeschäft konzentrieren können - nämlich Content erzeugen, also das Spiel selbst. Das ist so, als würden Reisebüros ihre eigenen Flugzeuge entwickeln.
Warum ist das in der Spieleindustrie so?
Auf der einen Seite, hat es sicherlich etwas damit zu tun, das man eine Herausforderung hat, aber auch das man eigene Vorstellungen etc. relativ Kompromisslos umsetzen kann.
Zudem ist es heutzutage nicht mehr so, das man wirklich alles selbst schreibt, sondern viel wird über Libraries etc abgefangen. Das "teuerste" sind dann wohl die Tools die man dann eventuell auch noch selbst entwickeln müsste, wenn man seine Software nicht so schreibt, das man bestehende nutzen kann.
Grundsätzlich hat es aber wohl eher etwas mit der Abhängigkeit zu tun. Nimmst du die Unreal oder sonstige Engine machst du dich halt ein stück weit Abhängig und Lizenzzahlungen gibt es dann ja auch noch, die sich heutzutage ja gern auch mal nach dem Erfolg eines Spiels bemessen und dann bei großen Titeln ruck zuck einiges an Lizenzzahlungen nach sich ziehen.

Abgesehen davon sind es ja meist keine puren Neuentwicklungen sondern Weiterentwicklungen von Engines die schon seit Jahren intern eingesetzt werden.

Dr.Doom
2021-05-07, 10:41:20
Vll ergibt sich auch eine Engine, die man ihrerseits weiterverlizensieren kann... so der Traum der Entscheider, die nicht zwingend in der Entwicklung tätig sein müssen.

Baalzamon
2021-05-07, 11:07:47
Moderne Spiele-Engines sind Eierlegende-Wollmilchsäue. Mit Unity kann man (zumindest theoretisch und ich denke das gilt zB auch für die UE) alles vom AAA FPS bis hin zum Indie 8-Bit-Style JRPG produzieren und das auch noch Plattformunabhägig für Mobile, Desktop etc.

Diese unglaubliche Flexibilität hat natürlich ihren Perfomancepreis. Wenn man also ein neues 'Doom' programmieren möchte, mit der entsprechenden Performance, ist es imho einfach nicht sinnvoll eine fertige Engine zu nehmen die alles kann, wovon man dann aber im Endeffekt nur die Hälfte braucht und der Rest einfach Overhead ist.

Zumal man, wie schon erwähnt, natürlich ab einer gewissen Größe Lizenzgebühren zahlen muss.

Mortalvision
2021-05-07, 11:27:28
Stichwort: Vertikale Integration“

Railer
2021-05-07, 12:12:34
Na ja, früher wurden zumindest ID-Engines auch lizensiert, aber inkl. Quellcode. Der Spiele-Entwickler konnte dann die Engine entsprechend seinen spezifischen Anforderungen anpassen, daraus sind einige bekannte Meisterwerke entstanden. Das ist aus meiner Sicht sinnvoller.
Klar hat eine UE oder Unity einen riesigen Overhead, aber eine lizenzierbare Engine sollte eben ausreichend customizbar sein - das ist sozusagen ihr Job. Nicht jedes Spiel erscheint auf allen Konsolen und mobilen Devices.

Man stelle sich vor die Film-Studios in Hollywood würden ihre eigenen CGI-Programme für ihre Filme entwickeln. Ein Spiele-Entwickler sollte ein Spiel entwickeln, nicht den Unterbau dafür - das sollten die darauf spezialisierten Unternehmen machen, die nichts anderes tun, als die Engines zu bauen und optimieren. Das ist im Allgemeinen abgesehen von der Spiele-Industrie eigentlich Gang und Gäbe. Dadurch könnten sich zum Einen Spiele-Studios entlasten, weil nicht erst Basics programmiert werden müssen. Zum Anderen wäre der Fortschritt deutlicher, weil eine ausgereifte Engine einfach eine bessere Grafik ermöglicht, als eine Eigenentwickelte (siehe was alles in UE/Unity möglich ist). Studios sollten eigentlich dadurch Zeit und Kosten sparen. Wenn die Entwicklung eines AAA-Titels 5 Jahre in Anspruch nimmt, wie viele davon geht für die Engine drauf? Content lässt sich zumindest stark parallelisieren, kann von "durchschnittsbegabten" erledigt werden und ist dadurch relativ günstig.

Selbst wenn eine Spiele-Engine nach Baukasten-Prinzip zusammengesetzt wird, ist es trotzdem ein sicher nicht triviales Vorhaben. Und ich denke nicht, dass das Lizensieren seiner eigenen, auf das eine Spiel zugeschnittenen Engine, als Geschäftsmodell in die Kalkulation einfließt - solche Engines sind kaum konkurrenzfähig im Vergleich zu einer UE/Unity.

Für mich ist es ein klares Zeichen dafür, dass in der Industrie etwas nicht optimal läuft, vermutlich wieder die Geldfrage - Lizenzkosten, die bei entsprechendem Erfolg ins unermässliche steigen.

Baalzamon
2021-05-07, 12:36:22
Na ja, früher wurden zumindest ID-Engines auch lizensiert, aber inkl. Quellcode. Der Spiele-Entwickler konnte dann die Engine entsprechend seinen spezifischen Anforderungen anpassen, daraus sind einige bekannte Meisterwerke entstanden. Das ist aus meiner Sicht sinnvoller.
Klar hat eine UE oder Unity einen riesigen Overhead, aber eine lizenzierbare Engine sollte eben ausreichend customizbar sein - das ist sozusagen ihr Job. Nicht jedes Spiel erscheint auf allen Konsolen und mobilen Devices.
Hmmm... Die id-Enignes sind, soweit ich weiss, stark auf FPS optimiert. Ich habe auch noch kein RTS oder TBS gesehen, welches mit einer id-Engine geschrieben wurde.

Wie sehr man sich in die Nesseln setzen kann, wenn man eine Engine wählt, die nicht zu Bedürfnissen des Spiels passen, kann man sich schon seit Jahren live bei Star Citizen angucken. ;)

Es ist daher imho schon sinnvoll verschieden Engines für unterschiedliche Einsatzbereiche zu haben und sich vorher zu überlegen, ob die lizensierbaren Engines überhaupt die Requirements abdecken können.

Für ein Triple-AAA Spiel mit Top-Notch Grafik und traumhafter Performance würde ich nicht Unity nehmen, imho ist sie dafür im Grunde nicht wirklich ausgelegt.

Man stelle sich vor die Film-Studios in Hollywood würden ihre eigenen CGI-Programme für ihre Filme entwickeln. Ein Spiele-Entwickler sollte ein Spiel entwickeln, nicht den Unterbau dafür - das sollten die darauf spezialisierten Unternehmen machen, die nichts anderes tun, als die Engines zu bauen und optimieren. Das ist im Allgemeinen abgesehen von der Spiele-Industrie eigentlich Gang und Gäbe. Dadurch könnten sich zum Einen Spiele-Studios entlasten, weil nicht erst Basics programmiert werden müssen. Zum Anderen wäre der Fortschritt deutlicher, weil eine ausgereifte Engine einfach eine bessere Grafik ermöglicht, als eine Eigenentwickelte (siehe was alles in UE/Unity möglich ist). Studios sollten eigentlich dadurch Zeit und Kosten sparen. Wenn die Entwicklung eines AAA-Titels 5 Jahre in Anspruch nimmt, wie viele davon geht für die Engine drauf? Content lässt sich zumindest stark parallelisieren, kann von "durchschnittsbegabten" erledigt werden und ist dadurch relativ günstig.


Aus meiner Erfahrung ist es unglaublich aufwendig guten Content zu erzeugen. Ein 'Durchschnittsbegabter' erzeugt dir halt auch nur 'durchschnittliche' Assets. Für richtig guten Content braucht man imho auch richtig gute (und erfahrene) Mitarbeiter.

Content, bzw. Assets sind, soweit ich das weiss, heutzutage die Kostentreiber einer AAA-Spieleproduktion, nicht die Programmierarbeit selbst.

Losgelöst von jeglicher visueller Darstellung sind die meisten Probleme die es bei einem Spiel codeseitig zu lösen gilt nämlich oft genug trivial. Kompliziert wird es meist erst wenn Benutzerinteraktion und Animation ins Spiel kommen, das hat aber erst mal nichts mit der abstrakten Problemlösung zu tun.

Selbst wenn eine Spiele-Engine nach Baukasten-Prinzip zusammengesetzt wird, ist es trotzdem ein sicher nicht triviales Vorhaben. Und ich denke nicht, dass das Lizensieren seiner eigenen, auf das eine Spiel zugeschnittenen Engine, als Geschäftsmodell in die Kalkulation einfließt - solche Engines sind kaum konkurrenzfähig im Vergleich zu einer UE/Unity.

Für mich ist es ein klares Zeichen dafür, dass in der Industrie etwas nicht optimal läuft, vermutlich wieder die Geldfrage - Lizenzkosten, die bei entsprechendem Erfolg ins unermässliche steigen.

Mit Frosbite und den id-Engines hast du zumindest schon mal zwei Teilnehmer für die es sich ganz offensichtlich lohnt eigene Engines zu schreiben und warten.

Exxtreme
2021-05-07, 12:49:16
Man nennt es "not invented here-Syndrom". :) Bei Softwareentwicklern ist das leider sehr verbreitet. Wie andere Syndrome leider auch.

Es kann natürlich Sinn machen eine eigene Engine zu entwickeln wenn man besondere Ansprüche hat. Bei MMORPGs ist das öfter so, dass da was Eigenes kommt da die normalen Shooter-Engines keine zig Spieler auf einem Fleck verkraften.

Baalzamon
2021-05-07, 13:00:36
Man nennt es "not invented here-Syndrom". :) Bei Softwareentwicklern ist das leider sehr verbreitet. Wie andere Syndrome leider auch.

Es kann natürlich Sinn machen eine eigene Engine zu entwickeln wenn man besondere Ansprüche hat. Bei MMORPGs ist das öfter so, dass da was Eigenes kommt da die normalen Shooter-Engines keine zig Spieler auf einem Fleck verkraften.
Das stimmt wohl, nur etwas das man selber geschrieben hat versteht man auch vollständig (ab einem gewissen Komplexitätsgrad). ;)

Daneben gibt es ja auch noch andere Gründe keine Engine zu lizensieren, z.B. weil man sich von einem anderen Hersteller abhängig macht. Wenn ich mein Spiel mit Unity produziere und denen fällt plötzlich ein, ein System zu 'deprecaten' welches man braucht, dann kann man da erst mal nicht viel machen, ausser auf der alten Version zu bleiben.

Ich muss z.B. immer noch mit einer alten C# Sprachversion in Unity arbeiten, bzw. bei Unity 2018 bleiben, weil es andere Third-Party-Abhängigkeiten gibt, die einen Versionsprung verhindern.

Wäre alles eine Eigenentwicklung, wäre das 'kein Problem'. Dafür muss man halt das Rad ständig neu erfinden.

davidzo
2021-05-07, 14:14:44
Eine Engine ist ja heutzutage weniger der Renderingpfad, als das ganze Toolset was drumherum angeboten wird um content zu erstellen bzw. assets einzubinden. Capcom hat halt in der Vergangenheit schon viel in custom Tools und Asset Generierung gesteckt, dass man wohl abgeschätzt hat dass die Portierung aufwändiger wäre als die Engine up to date zu halten. Zudem ist MT framework/RE engine schon seit wenigkeiten Multiplattform capable wenn man will.
Die meisten Engines am markt sind multiplayerfokussiert, was nochmal eine ganz andere Stufe an Komplexität hineinbringt. Wenn man das weglassen kann, ist der workflow wohl deutlich angenehmer und die resultierende performance ebenfalls.

BTW, viele "custom engines" haben im Renderpfad aber auch lizensierte Technologie anderer Engines.
Zum Beispiel soll Relics hauseigene "Essence Engine" ursprünglich auf unreal engine Code basieren. Alles was Essence aber ausmacht, "true sight" volumetrischer fog of war, terraforming und wettersystem hat Relic selbst entwickelt und vermutlich ist nach den vielen updates zum renderpfad, dx10, dx11 und die neue 64bit Variante nun nicht mehr viel vom ursprünglichen Code drin.

Zossel
2021-05-07, 14:30:15
[immy;12673365']Zudem ist es heutzutage nicht mehr so, das man wirklich alles selbst schreibt, sondern viel wird über Libraries etc abgefangen.

Fremde Libs werden spannend wenn die Bugs haben, und der Hersteller die Bugs mit "willnotfix" oder "upgrade to lastest Version" schließt oder mit dir "KeepTheCustomerbusy" spielt.

Man generiert mit fremden Libs Risiken für das eigene Geschäftsmodell.

=Floi=
2021-05-08, 04:13:04
Fremde Libs werden spannend wenn die Bugs haben, und der Hersteller die Bugs mit "willnotfix" oder "upgrade to lastest Version" schließt oder mit dir "KeepTheCustomerbusy" spielt.

Man generiert mit fremden Libs Risiken für das eigene Geschäftsmodell.

Ist stand der technik und es geht schlicht nicht mehr anders. Das thema könnte man ja komplett ausspinnen und ich entwickle ja auch nicht meine eigene glühbirne oder mein eigenes auto, nur weil manches nicht perfekt ist.


Ich denke es gibt auch noch so themen wie:
-spezielle anforderungen an die engine zB open world/gutes streaming/zerstörung in den level
-den technologievorteil, weil eine vorhandene engine an sich ja älter ist, als eine welche erst begonnen wird und man so gleich zB besser auf fortschritte reagieren kann. (Hier ist vor allem die COD engine ein negativbeispiel für uralte aufgeblähte engines) Sobald grenzen aufgemacht werden müssen, wird es meistens ineffizient oder nicht mehr sauber.
-der größte punkt dürften wohl die lizenzkosten sein.
-Die kosten dürften wohl auch mit das größte thema sein, weil man einfach keine laufenden kosten für lizenzen will. Ist das game fertig entwickelt, will man es noch abschreiben und dann keine verbindlichkeiten mehr haben.
Es dürfte für die großen auch dauerhaft günstiger sein.

Zossel
2021-05-08, 06:03:20
Ist stand der technik und es geht schlicht nicht mehr anders.

Es ist auch eine Frage des angestrebten Geschäftsmodells, will ich ein Produkt verkaufen welches a) besondere Merkmale gegenüber der Konkurrenz hat oder b) durch geringe Kosten günstig verkauft werden kann und genauso schlecht wie die Konkurrenzprodukte ist.

Viele Manager entscheiden sich aus Unfähigkeit, Bequemlichkeit und weniger Angriffsfläche für b), und "rechtfertigen" das auch mit den oben genannten Gründen.

Leonidas
2021-05-08, 11:06:43
Auffällig ist, dass die meisten Engine-Eigenentwicklungen von großen Studios oder gar Publishern kommen - wo diese Engine dann immer für eine Reihe an Spielen eingesetzt wird. Das dürfte den Kostenfaktor deutlich herunterdrücken.

Badesalz
2021-05-08, 11:08:53
Ist stand der technik und es geht schlicht nicht mehr anders. Das thema könnte man ja komplett ausspinnen und ich entwickle ja auch nicht meine eigene glühbirne oder mein eigenes auto, nur weil manches nicht perfekt ist.Das war nicht die Frage. Die Frage hier lautete, warum außer BMW, Mercedes und Toyota noch andere Hersteller Autos bauen und entwickeln.

Daher verstehe ich die Frage auch nicht wirklich. Ich glaub das hier basiert eher am angedachten Eigennütz :tongue: Es wird angenommen, daß wenn alle nur die Top4 Engines nehmen, alles Top-Highend aussehen wird und es gibt dann nur noch mind. AA-Spiele die sehr wenig Bugs haben :wink: und richtig Spaß machen.

Ich bin mir sicher, daß diese Rechnung nicht aufgehen würde :rolleyes:

DrFreaK666
2021-05-08, 13:07:10
Hmmm... Die id-Enignes sind, soweit ich weiss, stark auf FPS optimiert. Ich habe auch noch kein RTS oder TBS gesehen, welches mit einer id-Engine geschrieben wurde.
....

Tadaaaaaaa
https://ufoai.org/wiki/About

Gouvernator
2021-05-08, 14:23:22
Ich stelle mir eine Spiele-Engine zu entwickeln so vor, wie ein Rad neu zu erfinden - das kostet Zeit, Geld und benötigt extrem fähige Programmierer. Beim Lizensieren einer Engine würde man sich auf das Kerngeschäft konzentrieren können - nämlich Content erzeugen, also das Spiel selbst. Das ist so, als würden Reisebüros ihre eigenen Flugzeuge entwickeln.
Warum ist das in der Spieleindustrie so?
Ich denke wenn man schon irgendwelche Pogrammierer bezahlt, dann sollen sie was in ihrer Zeit auch tun. Sprich ein Industrie-Betrieb wenn alles reibungslos läuft, kann seine Techniker dazu benutzen irgendwelche neue Maschinen zu erfinden. Und die Monteure schrauben es zusammen während sie nicht mit Reparatur und Wartung beschäftigt sind.
Eine Lizenz-Engine ist dann für den Fall das man eben keine größere technische Crew beschäftigen kann.

Baalzamon
2021-05-08, 14:51:24
Tadaaaaaaa
https://ufoai.org/wiki/About
Nice. Vielen Dank. :up:

=Floi=
2021-05-09, 00:49:25
Es ist auch eine Frage des angestrebten Geschäftsmodells, will ich ein Produkt verkaufen welches a) besondere Merkmale gegenüber der Konkurrenz hat oder b) durch geringe Kosten günstig verkauft werden kann und genauso schlecht wie die Konkurrenzprodukte ist.

Viele Manager entscheiden sich aus Unfähigkeit, Bequemlichkeit und weniger Angriffsfläche für b), und "rechtfertigen" das auch mit den oben genannten Gründen.

Du hast mit qualität keine chance mehr. Der markt ist minimalst. Es zählt nur noch der preis und die marge für den hersteller.

Wuge
2021-05-09, 13:49:45
Kann jemand abschätzen, wieviel Manpower (Entwickler-Tage) eine Engineentwicklung heztutage kostet?
Wenn ich mir z.B. DCS anschaue, die ja wohl alles selbst machen. Ist jetzt kein technisches Wunderwerk und bis heute kein multithreading. Trotzdem gibts immer mal neue features. Sitzen da 2 Entwickler oder sinds ehr 20 die sowas warten und weiterentwickeln?

Voodoo6000
2021-05-09, 14:28:48
Ich denke es hängt von der Engine ab. Es gibt auch sehr kleine Entwicklerstudios mit eigener Engine. Wie viele da an DCS arbeiten kann dir nur der Entwickler sagen. Ich glaube aber nicht, dass es mehr als 10 Leute sind.(kann mich aber auch täuschen)

DavChrFen
2021-05-13, 03:29:21
Ich glaube auch, dass die Komplexität eine nicht zu unterschätzende Rolle spielt: Wenn man nur einen Bruchteil dessen braucht, was die Engine bietet, weil man eine kleines Independentstudio ist, dann kann die Einarbeitungszeit in eine bestehende Engine größer sein als der Aufwand was eigenes zu entwickeln. Außerdem kann es immer sein, dass eine Engine ein bestimmtes Must-Have nicht hat. Und dann ist die Frage: Wie löst man das und was kostet es. Und es gibt das Risiko, dass man diese Must-Have erst recht spät erkennt.