Überlegen Sie zweimal, bevor Sie Game Engines verwenden

Holivar über die Verwendung von Engines zum Erstellen von Spielen begann unmittelbar nach dem Erscheinen der ersten Game-Engines. Dieser Beitrag auf reddit ist kein ideales Beispiel für vernünftige Gegenargumente gegen den ständigen Einsatz von Motoren, aber ich glaube, dass der unwiderstehliche Wunsch, sie einzusetzen, ein wenig Fanatismus hervorruft.

Lassen Sie uns mit Bedacht argumentieren

Ich glaube, dass es keine fertige Antwort auf die Frage gibt, ob der Entwickler die Engine verwenden soll. Ein weiser Entwickler bewertet vor der Auswahl einer Technologie alle möglichen Optionen.

Fähigkeitsstufe

Haben Sie genug Fähigkeiten, um die ausgewählte Option effektiv zu nutzen? Wenn Sie keine Programmiererfahrung haben, müssen Sie viel lernen, bevor Sie bereit sind, ein Spiel aus einer Reihe unterschiedlicher Bibliotheken zu erstellen.

Wenn Sie weder technische Fähigkeiten noch Interesse daran haben, diese zu erlernen, gibt es wirklich keine Optionen - Sie müssen mit dem Motor arbeiten (oder jemanden davon überzeugen, den technischen Teil für Sie zu erledigen; viel Glück damit!).

Es gibt einen Zwischenzustand zwischen einem völligen Mangel an Fähigkeiten und einem professionellen Niveau. Es befindet sich hauptsächlich im Land der Skriptsprachen: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D usw. Alle sind für diejenigen gedacht, die ein bestimmtes technisches Wissen erwerben möchten, um schnell Ergebnisse zu erzielen.

Wenn Sie ein erfahrener / professioneller Programmierer sind, der in der Lage ist, Software von Drittanbietern sicher zu beherrschen, können Sie diese Fähigkeit nutzen und entscheiden, wie minimalistisch / maximalistisch Ihr Ansatz sein wird (ob es sich um eine extrem minimale SDL oder eine voll ausgestattete Unreal Engine handelt).

Entwicklungsziele

Was sind Ihre Ziele in diesem Projekt? Technologien sollten ihre Leistung maximieren:

• Dies ist ein Hobby für Sie und vor allem möchten Sie als Entwickler wachsen? Vielleicht sollten Sie sich von Unity und Unreal fernhalten und Spiele entwickeln, die auf Bibliotheken niedrigerer Ebenen basieren.
• Ist das ein Geschäft für Sie? Auf dieser Ebene werden die Dinge viel komplizierter. Optionen sollten anhand vieler Faktoren bewertet werden: Können Sie Mitarbeiter einstellen, die mit der Technologie vertraut sind? Wollen diese Leute Technologie nutzen? Passt es zu Ihrem Zeitrahmen? Haben Sie die Fähigkeiten, es effektiv einzusetzen? Mögen Ihre Künstler / Designer Technologie?

Interesse

Wenn Sie mehr mit Entwicklern zusammenarbeiten (oder planen) als allein, müssen Sie bewerten, wie andere Menschen an Technologie interessiert sind. Wenn Sie mit einer alten Engine / einem alten Framework arbeiten, die jeder hasst, wird es für Sie schwierig sein, motivierte Entwickler für Ihr Projekt zu finden.

Überlegen Sie auch, wie Künstler und Designer mit Technologie interagieren. Möchten Sie Tools erstellen, um die Unreal-Funktionalität nachzuholen? Sie werden unweigerlich die Fähigkeiten des Motors mit ihren eigenen vergleichen. Ich habe gehört, dass sogar AAA-Studios ein Problem mit Künstlern haben, die Unreal-Funktionen benötigen, die in der aktuellen Version von Unreal Studio noch nicht implementiert sind.

Wenn Sie alleine arbeiten, müssen Sie eine starke Leidenschaft für Projekte bewahren. Wenn Sie die Technologie hassen, mit der Sie arbeiten, geben Sie höchstwahrscheinlich die Arbeit auf. Wenn Sie aufgeben, werden alle Ihre Bemühungen zu Staub (mit Ausnahme der unschätzbaren Erfahrung).

Was geben sie dir wirklich?

Jonathan Blow hat ein erstaunlich weises Video darüber, was Game Engines tatsächlich geben . Sie lösen „einfache“ Probleme für Sie, aber dann stören sie, wenn sie versuchen, ein schwieriges Problem zu lösen, das aufregende Spiele ausmacht.

Ja, natürlich erhalten Sie einen großartigen Editor, Tools auf professioneller Ebene und eine Engine, die Tausenden von Entwicklern zur Verfügung steht, aber Sie bezahlen dafür mit vielen anderen Aspekten:

• Manchmal sind die darin verwendeten Lösungen zu verallgemeinert: Vielleicht wird die Schwerkraft in Ihrem Spiel auf völlig neue Weise angewendet, aber dann müssen Sie mit dem starr definierten unwirklichen Schwerkraftsystem kämpfen. Vielleicht erstellen Sie ein Projekt mit einem komplexen Netzwerkmodell, und dann müssen Sie die Unreal-Serverarchitektur vollständig entfernen.
• Manchmal sind Lösungen zu spezialisiert: Wenn Sie sich jemals mit den Eingeweiden von Unreal Engine befasst haben, haben Sie festgestellt, dass die gesamte Engine mit einem Ego-Shooter-Code durchsetzt ist. Wenn Sie ein Spiel dieses Genres erstellen, ist das in Ordnung. Wenn nicht, wird es nur verwirrend sein.
• Manchmal sind zu viele Dinge im Motor: Dies belastet sowohl das Gehirn als auch den Computer. Die Durchführung einer vollständigen Simulation der Festkörperphysik, einer 3D-Pipeline mit Skelettanimation und drei Frameworks ist eine absolute Pleite für ein 2D-Spiel. Sie müssen herausfinden, wie Sie all diese unwirklichen Funktionen deaktivieren können. Viel Glück damit. Persönlich finde ich, dass die Leistung von Unreal selbst in Testwelten mit wenigen Objekten enttäuschend ist.

Sie müssen die Frage stellen: "Was brauche ich wirklich?" Alles überflüssige loswerden. Jedes unnötige System verschwendet Ressourcen und Zeit.

Was wird für Ihr Projekt benötigt?

Technologie sollte von Ihrem Projekt verwaltet werden, es sei denn, es handelt sich um eine Technologiedemo. Wenn Sie ein Spiel erstellen, müssen Sie nur mit den Technologien arbeiten, die das Spiel beeinflussen - nur mit den notwendigsten, um Ihre Vision zu vermitteln. Wenn die Engine Ihnen den schnellsten Weg bietet, Ihr Spiel zu veröffentlichen, ist dies eine gute Wahl. Das wird aber nicht immer so sein!

Es gibt erfolgreiche Spiele, die dem schlechten Service einer der verfügbaren Engines dienen würden:

• Für Dreams wurde ein benutzerdefinierter Renderer geschrieben, der die intuitive Erstellung von 3D-Assets vereinfacht und beschleunigt.
• No Man's Sky verwendet aktiv völlig neue Methoden der prozeduralen Generierung. Wenn Sie solche Dinge in der Engine implementieren, müssten Sie sich ständig damit befassen.
• In Minecraft konnten nur einige der Funktionen von Standardmotoren verwendet werden.

Die Zukunft Ihrer (und unserer) Branche

Wenn Sie eine Technologie verwenden, sollten Sie über die Schließung nachdenken. Joel Spolsky hat eine Reihe von Artikeln über eine Geschäftsstrategie für die Softwareentwicklung, in denen er über die Schließung des Produkts nachdenkt. Kurz gesagt, seine Idee ist, dass Unternehmen daran interessiert sind, Sie für die Verwendung ihres Produkts zu halten, denn wenn Sie das Produkt nicht verwenden, verdienen sie kein Geld. Meister in der Erfassung ganzer Branchen sind Apple, Microsoft, Adobe und Autodesk. Sie vermitteln das Gefühl, dass es außer ihrer Software keine anderen Alternativen gibt.

Das Schließen betrifft sogar Hobby- / Solo-Entwickler. Ich habe einen Freund, der ständig mit Unity zu kämpfen hat (kompatibilitätsbrechende Updates, Prototyping-System, Adware, schlechte 2D-Unterstützung ...). Er möchte sich von Unity entfernen, ist jedoch stark an diese Engine gebunden, da der größte Teil seines Codes (und seiner Daten) auf der Unity-API basiert.

Warum kaufen Motoren?

Unreal und Unity werden von den Marktanforderungen bestimmt. Ihre Kunden auf AAA-Ebene bestimmen mit Hilfe von mehreren Millionen Verträgen den Verlauf der Weiterentwicklung der Motoren. Wenn Sie an einem Spiel arbeiten, dessen Struktur nicht mit den Zielen dieser AAA-Spieler übereinstimmt, werden Ihnen die Entwickler der Engines nicht so treu dienen. Beispielsweise müssen zweidimensionale, prozedurale, experimentelle, Voxel-Spiele und Spiele mit großen Datenmengen fast immer nach etwas Eigenem suchen.

Je heller die Funktionen erscheinen, desto mehr versucht das Management von Unternehmen (meistens keine Technikfreaks), Motoren einzusetzen. Features wie die Unreal Engine Blueprints sind bei Künstlern und Designern sehr beliebt, stellen Programmierer jedoch vor große Probleme. (Dies ist typisch für jede Skriptsprache. Wenn Sie Personen, die nicht Programmieren studiert haben, das Programmieren erlauben, ist das Ergebnis schlecht, ähnlich wie die von Programmierern gezeichneten Grafiken schlecht sind.)

Erleichtern neue Funktionen wirklich die Fertigstellung Ihres Spiels? Fügen sie dem Endprodukt wirklich einen Mehrwert hinzu?

Zentralisierung bekämpfen

Jedes Mal, wenn eines der Studios von seiner eigenen Engine auf Unreal oder Unity umschaltet, gewinnen Epic- und Unity-Unternehmen in der Spielebranche noch mehr Macht. Auf den ersten Blick mag eine solche Zentralisierung rentabel erscheinen (immerhin arbeiten 500 Ingenieure am Motor, ausgezeichnet!), Aber in ein paar Jahrzehnten wird dies ein echtes Problem. Google kommt in den Sinn: Dieses Unternehmen hat die überwiegende Mehrheit der Funktionen erfasst, die Menschen im Internet nutzen, und es hat sie den Verlust eines großen Teils der Privatsphäre gekostet.

Selbst auf Hobbyebene schadet die Aufgabe der Forschung zugunsten von Unreal oder Unity zukünftigen Motorengenerationen. Dies kann sogar Unreal selbst schaden: Wenn jeder Unreal verwendet, kann Epic niemanden einstellen, der eine neue Generation der Engine erstellt, da niemand weiß, wie Game-Engines geschrieben sind!

Die Zukunft kann Open Source sein

Wenn wir als Branche wachsen und immer mehr qualitativ hochwertige Produkte schaffen wollen, müssen wir mehr und nicht weniger teilen, um Technologien zu teilen.

Ich denke, die Branche bewegt sich in diese Richtung, wenn auch extrem langsam. Dies gilt insbesondere für Gaming-Studios auf AAA-Ebene, die den Code ihrer Engines immer noch verbergen, um einen (imaginären?) Wettbewerbsvorteil zu erzielen.

• Microsoft hat große Schritte in diese Richtung unternommen . Wenn sich auch sie ändern, bin ich sicher, dass andere dies können.
• Die Unreal-Lizenzvereinbarung enthält eine Klausel, mit der Sie sich auf den Code verlassen können, wenn Sie an einer eigenen (proprietären oder kostenlosen) Engine arbeiten. Ich denke, das ist ein großer Fortschritt.
• Dank seiner völligen Offenheit und seines freien Zugangs gewinnt Godot an Popularität und ich hoffe, dass er, wenn ihm genügend Zeit und Unterstützung gegeben wird, ein Konkurrent von Unity (und schließlich Unreal) wird.
• id Software (zu Zeiten von John Carmack) veröffentlichte den vollständigen Quellcode von Doom to Doom 3 . Carmack hatte viele Gründe, eine solche Entscheidung voranzutreiben. Das überzeugendste davon für Unternehmen ist, dass es den Umsatz nicht beeinträchtigt. Das von Doom verwendete Shareware-Modell - der Entwickler gibt die Engine und verkauft Daten - kann heute eine effektive Strategie sein. Wenn Ihr Unternehmen befürchtet, dass Konkurrenten Ihre Technologie „stehlen“, können Sie Ihren Code veröffentlichen, nachdem ein neueres Spiel veröffentlicht wurde (wie bei id). Nach Carmacks Abreise scheint id das Interesse an der Veröffentlichung von Code verloren zu haben.

Softwarequalität

Jonathan Blow und Casey Muratori sind leidenschaftliche Kritiker moderner Software-Schreibpraktiken. Ihr Punkt ist, dass wir Add-Ons über Schichten von Abstraktionen so lange erstellen, dass wir riesige, zerbrechliche Schichten unnötigen Mülls erhalten, und dies erlaubt uns nicht, bessere Produkte zu schreiben.

Vielleicht ist ihre Philosophie dem Idealismus näher als dem Pragmatismus (was normalerweise zu einer Verzögerung bei der Veröffentlichung von Spielen führt), aber wenn sie Ihnen nahe steht, sollten Sie sie nicht ignorieren.

Sind Ihnen Geschwindigkeit, Qualität und Eleganz Ihrer Technologie wichtig? Viele Menschen sind mit der negativen Antwort sehr zufrieden, aber einige möchten Programme „sauberer“ erstellen.

Was sind die Alternativen?

Anstatt die Engine zu verwenden, schreiben Sie nur ein Spiel.

Anfänger denken oft, dass sie eine Engine benötigen, um ein Spiel zu erstellen. Mit hoher Wahrscheinlichkeit sollten sie diesen Standpunkt ablehnen. Anfänger werden Zeit damit verschwenden, nutzlose Engine-Funktionen zu implementieren, anstatt das Spiel selbst entscheiden zu lassen, was es unbedingt benötigt. Nur das Spiel sollte steuern, was von der Engine benötigt wird (natürlich kann Unity als Gegenbeispiel als Beispiel für den Ansatz „Engine First“ herangezogen werden; Unreal Engine 4 verfügt über Paragon, Fortnite und Unreal Tournament, um dieses Konzept zu unterstützen, ganz zu schweigen davon Dutzende Jahre Erfahrung in der Veröffentlichung einer unendlichen Anzahl von Spielen in früheren Versionen von Engines.

Bibliotheken verwenden

Von vorne anfangen ist nur dann sinnvoll, wenn Sie über die Fähigkeiten und den Plan verfügen, Innovationen für eine bestimmte Komponente zu erstellen (oder Einschränkungen haben). In allen anderen Fällen gibt es viele Bibliotheken für die Integration. Dies ist besonders gut, wenn Sie wissen, dass beispielsweise ein Standard-Physiksystem vollständig für die Anforderungen Ihres Projekts geeignet ist (dies ist besonders wichtig, da Sie für die Implementierung Ihrer eigenen Physik viel Wissen in diesem Bereich benötigen).

Hier sind einige Bibliotheken, die die Lücke zwischen der Arbeit von Grund auf und der Verwendung einer vollständig fertigen Engine schließen können:

• Grafik: SDL, SFML, Ogre
• Physik: Bullet, PhysX (das kürzlich Open Source wurde - ein großer Sieg!)
• Sound: SDL, SFML

Dies ist nur ein sehr kleiner Teil der vorhandenen Bibliotheken.

Ein großes Plus bei der Verwendung von Bibliotheken ist, dass Sie die größte Flexibilität unter allen Optionen erhalten. Wenn Sie den gesamten Code in eine Engine schreiben, müssen Sie große Anstrengungen unternehmen, um ihn zu portieren. Wenn Sie ein Spiel als Sammlung von Bibliotheken schreiben, haben Sie eine große Mobilität und können ganze Subsysteme ersetzen. Wenn die Bibliothek Ihren Anforderungen nicht entspricht, können Sie eine andere ausprobieren oder sogar einen eigenen Ersatz schreiben.

Darüber hinaus unterstützen sowohl Unreal als auch Unity den Import dynamisch verknüpfter Bibliotheken. Dies bedeutet, dass Sie mit Bibliotheken arbeiten und dann zu Unreal wechseln können, ohne den gesamten Basiscode des Spiels neu schreiben zu müssen, da er sich in der Bibliothek befindet. Damit der Code für solch große Änderungen flexibel genug ist, ist ernsthafte Nachdenklichkeit erforderlich, aber ich denke, dass es sich für ein durchschnittliches oder langfristiges Projekt lohnt.

Abschließend

Ich habe verschiedene Gesichtspunkte vorgestellt, unter denen Technologien bei ihrer Auswahl berücksichtigt werden können. Verbringen Sie ein paar Wochen mit einer detaillierten Studie, und dies kann Ihnen in Zukunft mehrere Monate Portierungsarbeit oder sogar jahrelange Unannehmlichkeiten ersparen.

Am Ende besteht Ihre Hauptaufgabe darin, das Projekt abzuschließen. Sie sollten alle Anstrengungen unternehmen, um den kürzesten Weg zur Lösung dieses Problems zu finden. Es kann für Sie ziemlich unerwartet sein!