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

41

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?

PaulD
quelle
1
Sie möchten keine Lizenzen für die Spiele-Engines anderer Unternehmen erwerben und diese bezahlen.
János Turánszki
Ich schätze, das ist es, was Sie tun, wenn mehr als
9.000
3
Es gibt mehrere Gegenbeispiele für große Studios, die AAA-Titel mit Motoren von Drittanbietern wie Unreal oder der CryEngine erstellen .
Philipp
3
Valve begann mit der Quake-Engine und schrieb schließlich ihre eigenen für spätere Spiele. Es ist oft eine Frage des Lernens, was verfügbar ist, und dann irgendwann etwas mehr als das zu erreichen, was die vorhandene Engine bietet. An diesem Punkt müssen Sie schwere Änderungen vornehmen oder Ihre eigenen rollen.
Nairou

Antworten:

53

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.

Josh
quelle
20
Ich würde hinzufügen, dass Technologien, die "hier gebaut" sind, manchmal Vorteile haben. Ein Beispiel ist, wie Unity3D ihre EULAs für jede Version ändert und seltsame Einschränkungen hinzufügt, z. B. keine "Glücksspiele". Wenn Sie eine Technologie lizenzieren, sind Sie dem Lizenzgeber ausgeliefert, die Lizenz nicht ohne besonderen Grund umzudrehen und zu widerrufen (dies geschieht mit den IP-Rechten für die Erstellung von lizenzierten Spielen) oder Sie zu beauftragen, ihre Fehler für sie zu beheben.
Skrylar
im Ernst, sagt Unity "keine Glücksspiele"? Sie hatten sogar eine spezielle Seite über Glücksspiele im Community-Bereich ihrer Website!
jhocking
Auf der Unity-Seite hier unter unity3d.com/industries/gambling können Sie eine "Unity Gambling-Lizenz" erwerben. Ich habe keinen Preis dafür gefunden, aber es hört sich so an, als ob Sie damit immer noch Glücksspiele machen können, vorausgesetzt, Sie zahlen für eine spezielle Lizenz.
Alex
1
Außerdem ist es einfacher, mit dem zu beginnen, was Sie bereits kennen, und am Ende einen Motor zu bauen, ohne zu wissen, was ein Motor ist. Ein Motor ist nichts anderes als eine Sammlung von Anwendungsfällen. Wenn Sie versuchen, die Redundanz zu reduzieren, schreiben Sie am Ende eine Engine, und wenn Sie versuchen, das Spiel nur zu erstellen, erhalten Sie ein monolithisches System. Es ist sehr, sehr schwierig, eine Spiel-Engine zu bekommen und zu lernen, wie man sie dazu bringt, ein Pixel anzuzeigen, und dann zu erkennen, dass es das nicht kann, weil es alles als Textur sieht. Damit müssen Sie sich nicht befassen, wenn Sie Ihre eigenen schreiben.
Dmitry
18

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.

Codie Morgan
quelle
13
Das liest sich viel mehr wie eine weitläufige persönliche Anekdote; Sie könnten dies wahrscheinlich bearbeiten, um es viel prägnanter zu gestalten und eine bessere Antwort zu erhalten.
Josh
2
Dies alles ist mit Sicherheit großartig zum Lernen und auch zum Entwickeln Ihres Spiels, wenn Sie die Zeit haben, alles zu tun. Wenn es in der Tat nur Sie sind. Aber was ist, wenn Sie jemals mit jemandem zusammenarbeiten möchten? Oder mit anderen Programmierern in einer Firma zusammenarbeiten? Wenn sich jemand Ihrem Projekt anschließen möchte, ist es nicht ein bisschen seltsam, dass er dann Ihren Code lesen soll - für ihn den Code anderer Leute ... genau das, was Sie HASSEN. Ich finde, dass das Lesen von Code auch eine sehr wichtige Fähigkeit ist. Keine Beleidigung, ich bin sicher, Sie haben viel gelernt und einen coolen Motor geschrieben - nur eine Notiz, dass es nicht alles ist, was dazu gehört.
Antont
Mir ist bewusst, dass jeder Job, bei dem ich Code in einer beliebigen Sprache eingesetzt habe, für mich immer solo war. D;
Codie Morgan
Ich muss sagen, ich weiß genau, aus welchen Gründen eine Person ihren eigenen Motor / Werkzeug / was auch immer ausrollt. Aber es hat einen Preis (wie alle Dinge) ... Ich habe das Gefühl, dass alle Chefs es einfach hassen , wenn Sie den schlechtesten Code da draußen nicht lesen / verstehen können. * Unzählige schlecht geschriebene, schlecht gewartete Codes ohne Dokumentation, machen Sie sich ein Bild davon (die "echte" Welt). Nichts für ungut.
Quonux
Das ist der Grund, warum wir Programmierer keine schönen Dinge haben können. Weil wir immer alles selbst machen wollen, anstatt arbeitende und vertrauenswürdige Methoden anzuwenden. Ich habe das zwingende Bedürfnis, alles selbst zu schreiben, aber ich lerne langsam, anderen zu vertrauen, und bis jetzt tut es mir mehr gut als schlecht :)
Maurycy
15

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.

Trevor Powell
quelle
3
Dies ist ein großer Vorteil, den wir bei der Verwendung einer Open-Source-Engine (cocos2d-iphone) erfahren haben. Wir können es genauso debuggen wie den Code, den wir geschrieben haben. Ich bin der Meinung, dass Open Source in Ihrem Code liegt. Wenn es Fehler gibt, müssen wir diese wie in jedem anderen Teil unseres Codes beheben.
beheben
1
Dies kann von jeder Middleware gesagt werden . Das Debuggen von Code macht 80% der Arbeit eines Programmierers aus, und der Umgang mit Middleware ist ein häufiges Problem bei der Technologie, auf der wir heute mit mehr Middleware arbeiten, als wir zählen können. Zu lernen, das zu überwinden, ist nur ein Teil des Jobs. Wenn der Motor nicht kaputt geht, wird etwas anderes, über das Sie keine Kontrolle haben, funktionieren. Weniger bewegliche Teile sind eine gute Idee, aber wenn es kompliziert wird wie bei Game-Entwicklern, müssen Sie sich trotzdem mit vielen davon auseinandersetzen.
Tim
@Tim Ich bin absolut anderer Meinung - dass sich eine externe Sache auf eine schwer zu debuggende Weise schlecht verhält, bedeutet nicht , dass wir nur mit den Schultern zucken und uns damit abfinden sollten, dass sich alles auf eine schwer zu debuggende Weise schlecht verhält. Man muss natürlich die Dinge von Fall zu Fall prüfen, aber eine Engine ist ein großes System, in dem oft knifflige Fehler lauern. Warum sollten Sie das nicht unter Ihrer Kontrolle haben wollen, wenn Sie es sich möglicherweise leisten können, es selbst zu machen?
Trevor Powell
@TrevorPowell Es kommt natürlich auf die Komplexität des Projekts ab und wie Sie sagen, eine Fall-zu-Fall - Basis, sondern einfach ein Rad neu zu erfinden muss (vor allem , wenn es sich um ein großes Rad ist) ernsthaft in Bezug auf die durch gesparte Zeit in Betracht gezogen werden nicht tun es. Middleware macht es einfacher. Als Entwickler glauben wir, dass wir eine Lösung immer neu erfinden können, um sie zu verbessern, ohne zu überlegen, wie gut diese Lösung zusammengesetzt ist. Ein paar Beulen> Neuerfindung> Die völlig falsche Lösung
Tim
2
@Tim RE: "Middleware macht es einfacher", ich habe anscheinend ganz andere Erfahrungen als Sie gemacht.
Trevor Powell
9

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.

Maximus Minimus
quelle
2
Bemerkenswert ist, dass es damals, als die Spiele wie Unreal zum ersten Mal gebaut wurden, keine andere Wahl gab, als alles von Grund auf neu zu schreiben. Es ist nur die letzten paar Jahre, in denen wir eine Auswahl an N- Motoren haben ...
Joltmode
3

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.
Pedro Polonia
quelle
2

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.

Apache
quelle
1
Ich würde Havok nicht "stark modifiziert" nennen.
Josh
Ist Havok nicht nur eine Physik-Engine?
Philipp
Es ist, und GW2 hat nicht viel Beachtung geschenkt, woran ich mich erinnern kann.
Josh
Meinst du nicht (ie.: you want UE, not UDK only.)?
Keavon
#JoshPetrie: Tut mir leid, um ehrlich zu sein, ich habe keine Erfahrung in Havok / habe noch nie damit gespielt. Also bin ich auf GW2s LICENSE-Datei gestoßen und habe dann vor ein paar Tagen die Wiki-Seite besucht und Havok gesehen. Dann hatte ich eine alte Erinnerung daran, "Havok" zu Beginn eines Spiels gesehen zu haben, wo ich dachte, das IST die Engine. Aber damals habe ich auch nach Havok gesucht und wusste, dass es sich um eine Physik-Engine handelt. tl; dr: Ich habe die Sache mit Havok durcheinander gebracht. || #Philipp: Es ist ein bisschen mehr als das, aber in der Tat ist es keine Spiel-Engine, meine schlechte. || #Keavon: Richtig, behoben. Vielen Dank!
Apache
0

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 ...

0zkr PM
quelle
0

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.

Killer_B
quelle
0

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.

Peter
quelle
-2

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

thingybingytie
quelle
6
-1 Wenn Sie an einem Projekt mit angemessener Größe arbeiten, müssen Sie Funktionen / Klassen verwenden, die Sie nicht kennen und die Sie möglicherweise nicht selbst schreiben können, ohne die Anzahl der Bücher auf der Website zu studieren Thema. Ich spreche nicht über das, was jeder Programmierer wissen sollte, aber eine Spiel-Engine ist ein riesiges Projekt, und es wird erwartet, dass Programmierer X-Spezialthema X keine Kenntnisse in Thema Y hat und daher die Funktion verwenden muss, was ich auch nicht bin Dies bedeutet, dass Sie nicht wissen sollten, wie Sie die API verwenden sollen, aber möglicherweise nicht genug Wissen haben, um eine zu schreiben.
concept3d
2
Weiß Ihr Lehrer, wie man ein komplettes Auto von Grund auf aus chemischen Elementen zusammenbaut? Oder fährt er es, wenn es einfach funktioniert ;-)
Kromster sagt, dass er Monica
1
@ concept3d es gibt einen Unterschied zwischen der Arbeit an einem Projekt, in dem jemand anderes die von Ihnen verwendeten Funktionen / Klassen entwirft, da normalerweise, wenn Sie etwas nicht verstehen, leicht erklärt werden kann, dass ein Programmierer Codeklassen / Funktionen / Bibliotheken verwendet / Sie weiß nicht, dass es sich um eine dumme Person handelt. Sogar Klassen und APIs, die öffentlich erhältlich sind, enthalten Handbücher und Wikis, die erklären, was diese APIs oder Funktionen tun tiefes Wasser, ohne zu schwimmen, und wirklich unwissend und fehleranfällig
thingybingytie
@ hopjoppe5 Wenn Sie die akzeptierte Antwort überprüfen, sind dies die einzigen Gründe, warum Leute ihre eigene Technologie bauen. Viele der Bibliotheken / Codes sind in der realen Welt ausgelagert, und Sie müssen es verwenden. Das Lesen der Handbücher unterscheidet sich von der Kenntnis der Implementierung. Bei einigen Algorithmen wird sogar davon abgeraten, sie selbst zu implementieren. Sie sollten von Fachleuten in diesem Bereich implementiert werden, wenn Sie über Erfahrungen in der Praxis verfügen, werden Sie dies verstehen. Alles zu wissen ist unmöglich.
concept3d
Einer der Hauptgründe für die Abstraktion ist das Schreiben von Code, damit Benutzer, die nicht wissen, wie er funktioniert, ihn weiterhin verwenden können. Wenn Sie an einem Spiel arbeiten, das größer als Pong ist, kennen Sie wahrscheinlich nicht jeden Code. In den meisten Fällen ist dies eine gute Sache, da Sie sich auf das konzentrieren können, woran Sie gerade arbeiten, anstatt sich Gedanken darüber zu machen, wie das Eingabesystem mit Ihrer Anfrage nach einem "On Action Key Down" -Ereignis umgehen könnte.
Aidiakapi,