Warum sollte ein Spieleentwickler eine eigene Engine schreiben, anstatt vorhandene zu verwenden?

Ich habe beobachtet, dass viele große und bekannte Spieleentwickler oft ihre eigenen Engines entwickeln. Beispiele hierfür sind Valve, Crytek, Ubisoft, Epic Games und Square-Enix.

Könnte es einfach daran liegen, dass sie es können, oder ist es wahrscheinlich, dass vorhandene Motoren nicht genügend Anforderungen erfüllen, sodass wir unsere eigenen entwickeln würden? Ich kann mir kaum ein Spiel vorstellen, das eine bestimmte Engine erfordert. Unity oder Unreal sind einfach genug, um jede Art von Spiel zu machen. Selbst wenn nicht, haben sie Quellcode, der modifiziert werden kann, um auch einige außergewöhnliche Bedürfnisse zu befriedigen.

Warum sollte ein Spieleentwickler eine eigene Engine schreiben, anstatt vorhandene zu verwenden?

Es gibt mehrere Gründe, warum sich ein Studio dafür entscheidet, seine Technologie zu "bauen", anstatt sie zu "kaufen":

• Legacy-Technologie; Möglicherweise hat ein Studio damit begonnen, eine eigene Toolchain zu erstellen, bevor es eine funktionsfähige Middleware dafür gab.
• Spezifische Anforderungen; Ein Studio hat möglicherweise eine bestimmte Sammlung von Anforderungen, die für vorhandene Middleware oder nicht gut geeignet sind
• Budget Bedenken; Ein Studio ist möglicherweise nicht in der Lage, die Kosten oder vertraglichen Verpflichtungen für vorhandene Middleware zu übernehmen.
• "Nicht hier Syndrom gebaut;" Die technische Leitung des Studios ist möglicherweise vorsichtig (vernünftigerweise oder unvernünftigerweise) mit der Technologie, die sie nicht entwickelt haben, und versteht sie daher nicht vollständig.

Im Allgemeinen ist es sinnvoll, die Dinge zu besitzen und zu kontrollieren, die für den Erfolg Ihres Unternehmens entscheidend sind, und diejenigen, die dies nicht sind, auszulagern.

Für einige Studios ist das Design oder der Storytelling-Aspekt ihrer Spiele möglicherweise die entscheidende Ressource, von der sie erwarten, dass sie sie für den Erfolg nutzen. Für diese Studios ist es sinnvoll, einfach Technologie zu kaufen, mit der ihre Designer die entsprechende Vision verwirklichen können.

Für andere kann Technologie die Grundlage für den Erfolg sein. Studios, die beispielsweise MMOs erstellen, müssen diese Infrastruktur im Allgemeinen selbst erstellen, da dies für ihren Erfolg von entscheidender Bedeutung ist (und vorhandene Middleware ist im Allgemeinen nicht geeignet, zumindest für größere "AAA" -Titel).

Beachten Sie, dass einige der von Ihnen aufgelisteten Studios (insbesondere Crytek und Epic) aufgehört haben , direkt die dominierenden Kräfte auf dem Spielemarkt zu sein, und mit ziemlicher Sicherheit mehr als Middleware-Anbieter auftreten als als Spieleentwickler.

wie von Josh Petrie gesagt :

" Nicht hier Syndrom gebaut ;"

Ich schreibe auch meine eigene Engine, und ich nehme an, dass der Grund für jeden Entwickler anders sein wird, aber in der Tat - ich arbeite im Allgemeinen nicht gerne in Code anderer Leute. Ich bin zwanghaft in dem Sinne, dass es keinen Sinn macht, sich mit etwas anderem zu begnügen, wenn ich das Gefühl habe, es selbst bauen zu können .

Ich habe verschiedene Arten von Spiele-Engines, Rendering-APIs und dergleichen getestet, insbesondere Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre usw. Viele weitere ... Ich wollte mit dem Schreiben von Spielen beginnen und gut dokumentierter Einstiegspunkt ...

Mein Problem war jedoch zu dem Zeitpunkt, als ich keine Ahnung hatte, was unter dem Motor geschah. Ich wollte eine gute Kontrolle und einen Rahmen, den ich kenne wie meine Westentasche. Ich kam auf die Idee "Hey! Ich denke, der einzige Weg, wie ich lernen kann, wie das Ding funktioniert und wie ich es verstehe, besteht darin, meine eigene Engine komplett von Grund auf neu zu bauen. Der größte Teil meiner Programmiergeschichte war mit Web- und Verarbeitungslösungen - Das war ein ganz neues Ballspiel für mich.

Welches ist, was ich getan habe.

Deshalb habe ich XNA eingerichtet, da ich C # bereits kannte, und überlegt, wie oder wo ich anfangen soll. Ich brauchte eine Idee.

Ich entschied, dass ich, egal was passiert, direkt in 3D gehen würde .

Die Grundlagen zu verbessern war cool - das Sprite-Batch-Zeug, aber im weiteren Verlauf entdeckte ich neue Barrieren und Hindernisse - mein erstes echtes war das Batch-Limit . Mein Ziel war es, ein Spiel zu entwickeln, das zu jeder Zeit mindestens 10000 Entities im View-Frustum rendern kann.

Ich begann eine neue Reise der Implementierung von Shader Based Instancing (und lernte HLSL, als ich dabei war). Ich ließ die in XNA eingebauten Model- und Effect-Objekte fallen, um stattdessen meine eigenen Ersetzungen zu schreiben. Anfangs hatte ich Probleme, die VBO-Streams zu verstehen. Ich habe Dinge kaputt gemacht - ich bin online gegangen und habe Fragen zu den Instanzen gestellt und bin dabei geblieben, bis ich endlich verstanden habe, was die GPU tat. Es hat sich ausgezahlt; Nach ein paar Tagen Debugging meines VBO mit PIX (dxsdk) hatte ich nun über 20.000 Testobjekte in meinem Ansichtsfenster.

Jetzt hatte ich eine Vorstellung davon, wie das Rendern von Pipelines funktioniert, war aber noch nicht fertig - ich erstellte schließlich meinen eigenen Spielstatus, meine eigene Kamera, Post-Effekte und eigene Entity-Objekte und entfernte mich von der XNA-Content-Pipeline, indem ich meine eigene erstellte Loader (persönliche Abneigung gegen das XNB-Ding) erstellten eine komplizierte, tiefsortierte und im Mischzustand getrennte Geometriekette und hatten auch Sprites und Text instanziiert, die alle in die Spielszene projiziert wurden.

Ich habe fast ein ganzes Jahr lang kontinuierlich daran gearbeitet, es repariert, verändert und experimentiert. Am Ende kam es ziemlich gut heraus. Ich hatte jetzt ein Verständnis dafür, was unter der Haube vor sich geht, weil ich es geschaffen habe - mein Baby.

Jetzt war mein Motor größtenteils stabil und fast fertig. Es ist nicht perfekt: Das Scripting ist hupend und die GUI war überhaupt nicht großartig. Aber ich habe es trotzdem geliebt. Tausende Zeilen Code, Assets und Medien - eingebettet in ein privates 2-GB-Git-Repository, und all die Kopfschmerzen, die ich hatte, um eine Art von Entwicklung durchzuführen, die ich noch nie zuvor gemacht hatte. Jedes Hindernis, das ich überwunden habe, war eine Lektion gelernt - und eine Erleichterung.

Ich habe fast alles geschafft, was ich wollte.

Aber am Ende - ich entschied, dass es Zeit war, sie niederzulegen. So sehr ich mich auch selbst davon überzeugt habe, eine so große Engine mit Ratschlägen aus dem Netz und von anderen Spielefreunden zu schreiben, habe ich beschlossen, es noch einmal zu machen - und es noch besser zu machen -, denn diesmal weiß ich es meistens Was mache ich.

Das Projekt steckt immer noch in meinem GIT-Repo.

Mein zweiter Versuch, eine neue Engine zu schreiben (diesmal auf MonoGame), macht gute Fortschritte. Wenn etwas kaputt geht, ist es einfacher, es zu beheben. Weniger Chaos. Ich hoffe, dass ich mein Spiel in diesem Jahr irgendwann öffentlich präsentieren kann, da ich meinem Code ein bisschen zu sehr angehängt bin.

Letztendlich habe ich beim Schreiben meiner eigenen Engine gelernt, wie man das macht, während ich sagen konnte, dass ich genau weiß und verstehe, was jede Komponente tut und wie sie funktionieren soll. Eigentlich HASSE ich es, den Code anderer Leute zu lesen, besonders für große undokumentierte Projekte. Ich möchte, dass alles, was ich benutze, von mir gebaut wird.

Das bin nur ich. Ich bezweifle, dass ich jemals eine vorgefertigte Engine verwenden werde, wahrscheinlich, weil es mir einfach mehr Spaß macht, meine eigenen Frameworks zu schreiben, als mit dem Code eines anderen umzugehen - volle Kontrolle.

Der absolute Hauptgrund für das Schreiben einer eigenen Engine (und es überrascht mich, dass dies noch niemand angekündigt hat) ist das Debuggen .

Wenn Sie ein großes, kompliziertes Spiel geschrieben haben und es einen Absturzfehler gibt und Sie den Quellcode haben (und mit dem Quellcode durch das Schreiben bestens vertraut sind), können Sie einfach einen Debugger anhängen den Prozess und finden, was den Absturz verursacht. Getan.

Wenn Sie die im Handel erhältliche Engine eines anderen Benutzers verwenden und den Quellcode für diese Engine nicht haben (normalerweise nicht), können Sie auftretende Probleme selbst in Ihrem eigenen Code debuggen monumental schwieriger sein. Und wenn Sie auf einen Fehler im Motor selbst stoßen, können Sie ihn nicht selbst beheben. Wie wäre es, wenn Sie eine Woche vor Ihrem Veröffentlichungstermin einen Absturzfehler in der von Ihnen verwendeten Engine entdecken würden - einen Absturzfehler, den Sie nicht beheben können, da er sich in einer proprietären Engine befindet, für die Sie keinen Fehler haben haben den Quellcode? Ich habe gesehen, dass dies passiert ist - Sie haben keine andere Wahl, als einen dringenden Support-Anruf beim Anbieter zu tätigen und zu hoffen, dass er das Problem für Sie beheben kann (und daran interessiert ist), während Sie herumkrabbeln.

Die Spieleentwicklung ist schwierig, aber das Debuggen ist um Größenordnungen schwieriger. In meinem Buch ist alles, was die Spieleentwicklung erschwert, aber das Debuggen erleichtert, ein großer Nettogewinn.

Hier gibt es sehr gute Antworten, aber es fehlt ein wichtiger zusätzlicher Punkt.

Viele der heute lizensierbaren Motoren waren ursprünglich dedizierte Motoren .

Nehmen wir als Beispiel Unreal, weil es so allgegenwärtig ist.

Wenn Sie heute an Unreal denken, neigen Sie dazu, an eine Engine zu denken, die Sie lizenzieren und verwenden können, anstatt Ihre eigene zu erstellen, aber das war nicht immer der Fall, und es war einmal, als die Unreal-Engine nicht einmal existierte eine separate Einheit.

Es war einmal ein Spiel namens Unreal . Die Entwickler haben beschlossen, eine eigene Engine zu bauen, anstatt eine bestehende zu lizenzieren . Schneller Vorlauf durch mehrere Iterationen und diese Engine wird zur Unreal-Engine, die wir heute kennen.

Der Punkt ist, dass dies ein Henne-Ei-Problem ist. Jedes Stück Middleware, das Sie lizenzieren können, hat irgendwo begonnen, und es war oft gar keine Middleware (manchmal wurde es nicht einmal in der Absicht geschrieben , Middleware zu werden, und sein aktueller Status ist praktisch ein Zufall ). Die Leute schreiben ihre eigenen Engines, weil letztendlich jemand die Engine schreiben muss, und die heutige dedizierte Engine könnte morgen lizenzierbare Middleware werden.

Es gibt andere Gründe, warum sich ein Studio dafür entscheidet, seine Technologie zu "bauen", anstatt sie zu "kaufen":

• Neue Plattformen : neues mobiles Betriebssystem, Konsole oder Controller. Denken Sie an leapmotion, Google Glass usw. Die plattformübergreifende Unterstützung ist schwierig
• Neue Spielmechaniken und / oder In-Game-Editoren : Denken Sie an FEZ vor einigen Jahren (2D vs 3D)
• Mangel an guten kostenlosen Open-Source-Editoren . Mangel an guter Dokumentation über die vorhandene Quelle alter Spiele
• Weiterentwicklung der Tools in der Studio-Toolchain (oder Hinzufügen neuer Tools )
• Motorpreise und Lizenzkriege

Ich stimme auch bestimmten Anforderungen / Bedürfnissen zu und die Motorpreise und Lizenzkriege zwingen einige Studios, einige Motoren auf den Markt zu bringen.

Die guten Motive, andere Motoren zu "kaufen" oder "zu benutzen", sind:

• Wiederverwendung von Code : Eine Engine, die bereits in anderen Spielen verwendet wird, ist getesteter, stabiler und verfügt möglicherweise ab dem ersten Tag über die meisten erforderlichen Funktionen.
• Erweitern : Sie können einige Open Source-Engines erweitern.
• Kostenlos : oder fast kostenlos, da selbst kostenlose Open Source-Engines einige Entwicklerzeit zum Lernen benötigen.

Historischer Grund (meistens).
Welches hängt mit der Preisgestaltung zusammen.

Für jedes Spiel, das Sie in den letzten Jahren mit Unreal oder CryEngine gesehen haben, mussten Sie eine Menge Geld bezahlen. Vor allem, wenn Sie den Quellcode erhalten möchten (dh, Sie wollten UE, nicht nur UDK.)

Aber das hat sich geändert. Jetzt kann sich jeder noch größere Motoren leisten, als das Preisrennen begann.
Was das bedeutet...

• Sie werden viel mehr Spiele sehen, die sowohl UE4 als auch CryEngine verwenden.
  Es werden jedoch keine AAA-Spiele wie bisher sein.
• Benutzerdefinierte Anforderungen und Bedürfnisse für jedes Projekt werden nicht verschwinden.
  Sehen Sie den Warhammer40k / COH-Motor bei Relic oder den, den Generäle bei EA verwendeten.
  Selbst wenn sich jemand die größeren Motoren leisten kann, bietet er nicht unbedingt eine bessere Wahl.
• Es gibt andere auf dem Markt. Wie die Einheit.
  Die Leute lieben es, weil es benutzerfreundlich ist, eine schnelle Leistung erbringt und ein riesiger Warenbestand vorhanden ist.
  Natürlich kann Unity auf nahezu jeder Plattform bereitgestellt werden.

Also ja. Bedürfnisse, Preisgestaltung in der Vergangenheit und so weiter.

Was ist mit der Teamorganisation?

Hinter dem Debug-Zeug stecken die Dokumentation und der Support, nicht der Code, denn am Ende wollte ich nicht, dass meine Baugruppe den Code meiner eigenen Engine berührt. Das könnte ein Durcheinander sein.

Dazu brauche ich eine Selbsthilfegruppe. Aber das erhöht die Kosten: mehr Leute, mehr Orte, mehr Leitungstelefon, mehr Verwaltung ...

Eine Lösung hierfür könnte die Auslagerung sein ... an ein Middleware-Unternehmen, das Ressourcen für mein Geschäft mit der Herstellung von Spielen freigibt, dh für die kreative Gruppe und die Autoren.

Für ein Start-up-Unternehmen ist es keine schlechte Option, zu verwenden und nicht zu bauen. Und nachdem Sie eine kritische Masse an Einkommen erreicht haben, möchten Sie vielleicht, vielleicht, Ihren eigenen Motor bauen ...

Gut. Für die meisten Spiele, die ihre eigene Engine verwenden, die von ihren Entwicklern erstellt wurde. häufig. Mit Motoren von Drittanbietern können sie nichts anfangen. Also machen sie es sich selbst, um die Entwicklung ihres eigenen Spiels einfacher zu machen. oder zumindest möglich.

und viele Spiele, die nur allgemein ihre eigene Engine verwenden. arbeite besser. weil sie individueller sind und zu 100% zu ihrer Aufgabe passen. und das Spiel selbst fühlt sich anders an. Es ist wirklich einfach, ein Spiel zu spielen und das zu sagen, was von gemacht wurde. unwirklicher Motor oder was auch immer. mehr benutzerdefinierte Engine im Allgemeinen und sollte zu einem Spiel führen, das sich einzigartig anfühlt. Sieht einzigartig aus und funktioniert einzigartig und sollte eine bessere Leistung bringen als ein Spiel, das mit einer vorgefertigten Engine erstellt wurde.

Meine Antwort unterscheidet sich von den vorhandenen, daher füge ich sie hinzu, obwohl es spät ist:

Wenn Sie das Ventilbeispiel aus der Frage oder der Hexer-Reihe nehmen, war der Prozess:

• Motor lizensieren
• Passen Sie den Motor an Ihren Zweck an
• Spiel freigeben und Geld generieren
• Erstelle eine eigene Engine für das nächste Spiel

Der gleiche Ansatz wird von fast allen finanziell vernünftigen Entwicklern verfolgt, die ihre eigene Engine entwickeln. Durch Modifizieren einer Engine bauen sie Kenntnisse über die Funktionsweise einer Engine auf und stoßen auf Konstruktionsbeschränkungen, die sich aus einer lizenzierten Engine ergeben. Am Ende haben sie das firmeninterne Wissen, um einen Motor zu entwickeln, das Geld, um die Entwicklung eines Motors zu finanzieren, und ein Projekt, das von einem speziellen Motor profitiert. An diesem Punkt lautet der Grund für den Bau eines Motors: Weil es klug ist, etwas zu tun.

Mein Programmierlehrer sagte uns, wir sollten nur APIs / Methoden / Klassen / Funktionen verwenden, die Sie erstellen können

denn wenn Sie nicht wissen, wie man es baut und die Arbeit anderer nutzt, wissen Sie wahrscheinlich nicht, wie es funktioniert, und wenn Sie nicht wissen, wie etwas funktioniert, sind Sie viel anfälliger für Fehler und Probleme und stoßen an die Wände der Verwirrung

Das Erlernen einfacher Dinge kann zusammengenommen zu seltsamen Problemen führen, ganz zu schweigen von einer komplexen Game-Engine, insbesondere wenn Sie diese Game-Engine zum Ausführen Ihres Spiels verwenden sollen, was zu vielen unerwarteten Ergebnissen und Problemen führen kann

und die Spiel-Engine folgt nicht dem logischen Code oder einer anderen Logik, wenn sie erstellt wird. Sicher gibt es einige Dinge, die erwartet werden können, aber in Wirklichkeit wird alles basierend auf dem Verständnis und den Kenntnissen einer Programmiersprache oder der Funktionsweise eines Systems erstellt

Wenn ich mich zum Beispiel für das Schreiben einer mathematischen Gleichung entscheide, kann ich sie auf so viele Arten schreiben, dass ich sie mit Polynomen, Differentialrechnung, Grundgeometrie oder Algebra darstellen kann. Manchmal würde ich aber auch in einer bestimmten Form / einem bestimmten Format schreiben, weil ich es möchte um in der lage zu sein zu manipulieren, was leicht verfügbar ist, wie zum beispiel, wenn ich vorhabe, eine menge von vertex-manipulationen durchzuführen, schreibe ich dieses mathematische modell unter verwendung der grundgeometrie, aber wenn ich die kurve mit gradienten verändern möchte, konzentriere ich mich möglicherweise auf die differenzielle berechnung, um dies zu können Um die Farbverläufe usw. leicht zu manipulieren, und das Gleiche gilt für alles, was ich leichter erreichen möchte

und manchmal gibt mir die aktuelle Spiel-Engine möglicherweise nicht die Flexibilität dessen, was ich vorhabe, oder vielleicht gibt sie dir diese Option, aber es ist sehr schwierig, weil sich die Spiel-Engine auf physikalische Kräfte als Hauptquelle für Bewegung und Manipulation von konzentriert Objekte im Spiel

Trotzdem hoffe ich, dass ich deutlich gemacht habe, worauf ich hinweisen wollte