STL für Spiele, ja oder nein? [geschlossen]

Jede Programmiersprache hat ihre Standardbibliothek mit Containern, Algorithmen und anderen nützlichen Dingen. Bei Sprachen wie C #, Java und Python ist es praktisch undenkbar, die Sprache ohne ihre Standardbibliothek zu verwenden.

Bei vielen C ++ - Spielen, an denen ich gearbeitet habe, haben wir entweder die STL überhaupt nicht verwendet, einen winzigen Bruchteil davon verwendet oder unsere eigene Implementierung verwendet. Es ist schwer zu sagen, ob dies eine fundierte Entscheidung für unsere Spiele war oder nur aus Unkenntnis der STL.

Also ... passt die STL gut oder nicht?

Als ich in der professionellen Spieleentwicklung arbeitete, war STL zu unreif und aufgebläht. Aber das war vor> 10 Jahren.

Jetzt arbeite ich in der Militärsimulation, die noch strengere Leistungsanforderungen hat (so wie die Framerate niemals unter einige FPS fallen kann). In der militärischen Simulation wird STL überall verwendet.

Einige der Leute, die Ihnen raten, STL nicht zu verwenden, argumentieren, dass es nicht immer die perfekte oder sogar beste Lösung für das Problem ist. Aber das ist keine Antwort auf die Frage. Die Frage sollte lauten: Stimmt etwas nicht mit der Verwendung von STL in Spielen? Ich würde nein sagen, STL ist die meiste Zeit eine bessere Implementierung als die, die sich ein Benutzer selbst einfallen lassen würde.

Stellen Sie einfach sicher, dass Sie wissen, wie die STL verwendet wird, und verwenden Sie sie in Ihrem Spiel. Lesen Sie einige Bücher und sehen Sie sich den Implementierungscode in der von Ihnen verwendeten STL an.

Ich würde sagen, dass es eine bessere Idee ist, die STL zu verwenden, wenn Sie nicht genau wissen , warum Sie sie nicht verwenden möchten.

Das ist das Besondere an der STL: Sie wird von Menschen entwickelt, die schlauer sind als Sie. Das soll nicht anstößig sein oder so, es ist nur so, dass die STL von Leuten entwickelt wird, deren Arbeit tatsächlich die STL erstellt. Es wird ungefähr so ​​schnell sein, wie es die Plattform zulässt, und es wird im Allgemeinen viel robuster sein als eine selbst erstellte Lösung (und dies sollte ebenso ein Problem sein, wenn Sie sich nicht mehr Gedanken über die Geschwindigkeit machen - weil Ihr Spiel dies erfordert Robustheit ist weitaus wichtiger als Geschwindigkeit, letztere ist ohne erstere bedeutungslos).

Die Beschwerden, dass die STL einen "engen Blick auf die Welt" erzwingt, kommen mir ein wenig albern vor. Das sind Container. Sie haben eine begrenzte Anzahl von Operationen, da Container eine begrenzte Anzahl von Operationen haben. Was machst du, das damit nicht einverstanden ist?

Ich habe sehr wenige Gründe gesehen, die STL nicht für Spiele zu verwenden.

Viele Leute wissen dies nicht, aber Sie können benutzerdefinierte Zuordnungen für Ihre STL-Containerklassen schreiben. Allokatoren sind im Grunde Richtlinienklassen, die Sie in Ihre Vorlagen übergeben, um zu bestimmen, wie Zuweisungen durchgeführt werden. Mit diesen können Sie normalerweise alle Speicherprobleme umgehen, die auf der Plattform Ihrer Wahl problematisch sind.

Wenn Sie die STL verwenden und dumme Dinge wie Zuordnungen von Zeichenfolgen zu großen Typen ohne Zeiger ausführen, haben Sie natürlich größere Probleme.

Die Standard-STL weist eine Reihe von Problemen auf, die die Verwendung mit Spielen erschweren, insbesondere im Hinblick auf die Speicherausrichtung.

Eine angepasste Variante wie die EA STL wurde speziell für Spiele entwickelt und verbessert die Speicherleistung und die Benutzerfreundlichkeit der Konsole erheblich. Es wurde 2016 unter einer BSD-3-Klausel mit einem Repository auf GitHub zu Open Source .

Hier ist, was Mike Acton (Engine Director bei Insomniac Games von Spyro the Dragon, Ratchet & Clank und Resistance Fame) dazu zu sagen hatte, als er hier gefragt wurde . Beachten Sie, dass er sowohl zu STL als auch zu Boost im Allgemeinen befragt wurde, was die Verwendung im Spiel betrifft.

STL / Boost, gehört es zu Gamedev? Wenn nur Teile davon, welche?

Du fragst hier nach zwei verschiedenen Dingen, oder? STL und Boost getrennt. Aber meine Antwort ist die gleiche: Es ist nichts Falsches an einer von beiden, aber ich rate von ihrer Verwendung ab. Die Verwendung von entweder ermutigt die Menschen zu passen , eine Lösung für ein Problem , anstatt die Suche nach einer Lösung für ein Problem. Die Lösung sollte immer für die vorliegenden Daten und die Einschränkungen der Hardware usw. geeignet sein. Sowohl STL als auch Boost haben eine extrem enge Sicht auf die "Welt" und ihre angemessene Verwendung ist begrenzt. Wirklich, ich entmutige sie, weil sie Programmierer auf Anhieb in die falsche Richtung führen. Ich sage oft, wenn Sie das Gefühl haben, eines von beiden zu brauchen, verstehen Sie das Problem, das Sie haben, wahrscheinlich nicht wirklich.

Mir ist auch aufgefallen, dass die meisten professionellen Spieleentwickler eher nach C streben als nach C ++.

Wenn Sie feststellen, dass Sie etwas, das bereits in der STL vorhanden ist, aus irgendeinem Grund umschreiben, hören Sie auf . Verwenden Sie die STL.

Die STL wurde über Jahre von Analyse und Zeit optimiert und es ist sicher, dass Sie wahrscheinlich nicht etwas schreiben werden, das effizienter ist. Das heißt nicht, dass Sie STL verwenden sollten, wenn eine einfachere Lösung möglich ist (dh wenn Sie ein Array verwenden, dessen Anzahl bekannt ist, nicht eine stl :: list), aber wenn Sie eine eigene Implementierung einer Map schreiben ( die grundlegende Datenstruktur, nicht eine Spielweltkarte), machst du es falsch.

Passt STL gut zu Spielen? Bestimmt. Spiele sind komplexe Softwarekomponenten. Die STL bietet Funktionen, mit denen die Komplexität verwaltet werden kann.

Passt es gut zu Ihrer Plattform? Nicht unbedingt. Wenn Sie für eine Konsole schreiben, müssen Sie sehr vorsichtig mit der Speicher- und Cache-Nutzung umgehen. Die STL macht dies nicht sehr einfach.

Ich denke, dass wir "Spiele" allzu oft mit "Hochleistungs-Echtzeitspielen, die auf eingebetteter oder maßgeschneiderter Hardware laufen" verwechseln, aber es ist wichtig, eine Unterscheidung zu treffen. Wenn Sie ein Windows-Spiel schreiben, das nicht versucht, im Vollbildmodus mit einer konstanten Geschwindigkeit von 60 fps zu laufen, gibt es keinen Grund, die Tools zu umgehen, die Ihnen die Standardbibliothek zur Verfügung stellt.

Ich weiß, dass es sehr spät für die Party ist, aber Zeitänderungen und Antworten bleiben bestehen. C ++ 11 hat ziemlich umfassende Änderungen, von denen viele die Leistung von C ++ und der Standardbibliothek verbessern sollen. Es sieht so aus, als ob diejenigen, die STL oder Boost nicht verwenden, dazu neigen, auch nicht mit den neuen Standards Schritt zu halten, so dass den selbst gesponnenen Lösungen wichtige Verbesserungen fehlen, was natürlich nicht immer der Fall ist.

Ich habe STL für jedes Projekt von Mitte der 90er bis heute verwendet, mit Ausnahme einer kurzen Zeit bei EA. Ich denke, die Anti-STL-Seite hatte ein paar leicht rationale Gründe, es nicht zu benutzen. Die sind größtenteils weg. Benutzerdefinierte Zuweiser sind eine Lösung, die Verwendung von Reserve ist eine andere, und die Nichtübergabe von Dingen nach Wert ist eine dritte, aber diese sind recht einfach, und jeder Programmierer sollte diese kennen. Wichtiger ist jedoch die Verwendung von Algorithmen. Compiler-Autoren wissen genau, was for_each () tut, und können den Code optimieren. Das kann bei einer selbstgerollten Schleife nicht auftreten. for_each () für ein const-Objekt ist noch besser. Microsoft optimiert for_each in vielerlei Hinsicht, einschließlich der Serialisierung. Sie haben auch die AMP-Bibliothek, die parallel_for_each () hat. Wenn Sie eine Chance bekommen, sprechen Sie mit den Compiler-Ingenieuren darüber. Konsolen-Compiler werden optimieren, was verwendet wird. Ein kleines Problem mit Hühnchen und Eiern. Microsoft ist sehr stark mit C ++ 11 und die nächste XBox wird nicht anders sein. Ich habe keine Ahnung von PS4, wir haben noch keine bekommen.

Benutzerdefinierte Zuweisungen sind eine Möglichkeit, das Speicherproblem zu lösen. Eine andere (oft übersehene) Option ist die Verwendung von class based new und delete. Auf diese Weise können enorme Leistungssteigerungen erzielt werden.

Die Vorstellung, dass Boost und STL einen engen Blick auf die Lösung von Problemen haben, ist purer Wahnsinn. Ich bin verblüfft, wie viele Dinge in STL und Boost durch Eigenschaften und Richtlinien anpassbar sind. Suchen Sie nach case independent string compare als Beispiel.

In Bezug auf lange Verbindungszeiten und Code Bloat sollte das neue externe Template dabei helfen. Generell stelle ich fest, dass lange Kompilierzeiten durch übermäßige Kopplung und Missbrauch von pch entstehen.

Der überzeugendste Grund für die Verwendung von STL über homespun ist, dass Millionen von Menschen Ihnen bei der STL helfen können. Wie immer nicht vorzeitig optimieren und testen, testen, testen.

Dies ist ein heißes Thema in der Spieleentwicklung. Ich persönlich empfehle es nicht, außer vielleicht für EASTL wie oben erwähnt. Ich habe zwei Hauptprobleme mit STL (technisch gesehen "The C ++ Standard Library", da STL nicht mehr der Name ist) in Spielen. 1) Dynamische Speicherzuweisung verschwendet oft viel Zeit in Spielen, wenn STL verwendet wird. 2) Die Verwendung von STL fördert einen Array-of-Structs-Ansatz für die Spielarchitektur, wohingegen ein Array-of-Structs-Ansatz wesentlich cachefreundlicher ist.

Es hängt davon ab, ob. Wie groß ist das Projekt, welche Plattform (en) und wie sieht der Zeitplan aus?

Wenn Sie an einem großen Projekt arbeiten, auf Plattformen mit begrenzten Ressourcen, einem beträchtlichen Zeitplan und einem beträchtlichen Budget, können Sie sich viel Ärger ersparen, indem Sie die unvermeidliche Hölle vermeiden, die eine halbe Million Zeilencodebasis erfordert Mit STL übersät, kann eine Framerate von über 30 nicht aufrechterhalten werden, es wird genug RAM verbraucht, um mehrere Assets aufzunehmen, und der Aufbau dauert 2 Stunden.

In anderen Situationen können STL und sogar Boost jedoch sehr nützlich sein, wenn sie richtig angewendet werden. Ich habe an Titeln mit einer Auswahl von STL / Boost gearbeitet, und es war ein absoluter Traum, sie zu codieren: Weniger Bugs / Leaks und einfach zu wartender Code bedeuten mehr Zeit für das Codieren neuer Funktionen! Gerade für Hobbyprojekte ist das ein Riesengewinn in der Motivationsabteilung.

Wissen, wann man Leistung gegen Bequemlichkeit eintauscht!

IMHO würde ich sagen, dass es gut passt, da STL bereits gut funktioniert und für die Aufgaben optimiert ist, für die es gemacht ist. Außerdem arbeitest du an einem Spiel, also benutze die Tools, die du zur Hand hast, um dein Leben zu erleichtern und deinen Code weniger anfällig für Fehler zu machen.

Warum sich die Mühe machen, das Rad neu zu erfinden, wenn Sie an etwas anderem wie der KI des Spiels, der Benutzererfahrung oder noch besser arbeiten können? Testen und Debuggen?

STL ist absolut in Ordnung für die Verwendung in Spielen, sofern Sie es gut verstehen. Unser Motor nutzt es ziemlich ausgiebig und es war noch nie ein Problem. Ich habe keine Erfahrung mit der Entwicklung von Konsolen, was eine völlig andere Geschichte sein mag, aber es wird auf allen PC-Plattformen (Windows / Mac / Linux) gut unterstützt.

Das Wichtigste ist, die Stärken und Schwächen der einzelnen Containertypen zu kennen und den richtigen Container für die von Ihnen ausgeführte Aufgabe auszuwählen.

Mein früherer Arbeitgeber wechselte von einer Reihe robuster benutzerdefinierter Containerklassen zu STL. Die Build-Zeiten stiegen und die Fehlerbehebung ging zurück, beides ziemlich signifikant. Wenn wir von vorne angefangen hätten, hätte STL (vielleicht besser verwendet) wahrscheinlich Sinn ergeben, aber es war mir nie klar, dass wir durch den Umstieg auf STL irgendetwas erreicht haben, das es rechtfertigt, funktionierenden, schnellen und debuggbaren Code zu verwerfen.

Bei meinen persönlichen Projekten hängt es vom Projekt ab, ob STL passt oder nicht. Wenn ich eine datengesteuerte, speicher- und cachezugriffsoptimierte Arbeit im Stil von Mike Acton ausführen möchte, denke ich zumindest an das Rolling meiner eigenen benutzerdefinierten Datenstrukturen. Wenn ich einige Algorithmen oder das Gameplay als Prototyp entwickle und Leistung, Skalierbarkeit, Zielplattform usw. nicht wichtig sind, greife ich automatisch zu STL.

Meine 2 Cent dafür ist, dass die STL gut funktioniert. Ich habe eine 3D-Game-Engine (keine AAA-Qualität, aber fortgeschritten genug - skriptbasierte Entitätstypen, verzögerter Renderer, integrierte Bullet-Physik) für den PC entwickelt und muss noch feststellen, dass Container zum Hauptengpass werden. Falsche 3D-API-Nutzung und schlechte Algorithmen waren jedes Mal die besten Ziele (ermittelt durch Profilerstellung!), Wenn ich versucht habe, etwas mehr Leistung herauszufinden.

Ich habe Spiele mit STL erstellt und es gefällt mir, und es scheint eine gute Leistung zu bringen.

Gute Frage! Eine spezifischere Frage ist, welche allgemeinen Anforderungen ein Spiel haben würde, die mit STL und Boost nicht erfüllt werden können.

Aufgrund der engen Speicherbeschränkungen der Konsolenhardware ist meiner Erfahrung nach jede Art von Container mit dynamischer Größe eine schlechte Idee, unabhängig davon, wie clever Ihr benutzerdefinierter Allokator ist. Container, die keine absichtlichen Grenzen haben, ermutigen Programmierer, Code zu schreiben, der die Grenzen ihrer Datensätze nicht einschränkt. Abhängig von unzähligen Variablen, die schwer zu verfolgen sind, können Sie Ihre Speicherbeschränkungen überschreiten. Ich habe die Vermutung, dass dies eine der Hauptursachen für Instabilität in modernen Spielen ist.

Darüber hinaus kann die übermäßige Verwendung von Vorlagen zu sehr langen Kompilierzeiten in einer großen Codebasis führen und die Größe Ihrer ausführbaren Datei aufblähen, sodass sie nicht mehr in den Cache eines Hilfskerns auf einem ps3 passt.

Für die reine PC-Entwicklung finde ich STL und Boost jedoch sehr gut. Während allgemeine Lösungen nicht immer ideal sind, sind sie oft gut genug. Ihre erste Lösung für ein Problem ist so gut wie nie ideal, und Sie verbessern oder ersetzen die Unzulänglichkeiten, bis sie gut genug sind.

Die STL passt gut zu Ihrem Spiel, wenn die STL gut zu Ihrem Spiel passt.

Wie bei allen Technologieentscheidungen, die während der Entwicklung getroffen wurden, müssen Sie die Vor- und Nachteile abwägen. Kann ich durch das Rollen meiner eigenen Bibliothek mehr Speicherplatz, Leistung und Produktivität nutzen, als wenn ich nur die STL verwende? Möglicherweise; Es ist jedoch genauso einfach, eine vectorImplementierung zu erstellen , die mehr Speicher benötigt, langsamer ist und einen hohen Wartungsaufwand erfordert, um die Funktion im Vergleich zu den bereits vorhandenen Funktionen aufrechtzuerhalten.

Leute sollten es nicht vermeiden, die STL in ihren Spielen zu verwenden, weil andere Leute es vermeiden, die STL in Spielen zu verwenden; Sie sollten es vermeiden, wenn sie alle ihre Optionen abgewogen haben und aufrichtig glauben, dass eine andere Implementierung die Qualität ihres Produkts verbessern wird.

Wie bei den meisten Fragen lautet die Antwort niemals "ja oder nein", schwarz oder weiß. STL ist eine gute Lösung für einige Probleme. Es sollte in Ordnung sein, STL für diese Probleme zu verwenden. Es ist ein Fehler anzunehmen, dass es nutzlos ist, aber es ist auch ein Fehler anzunehmen, dass es in jeder Situation angebracht ist, es zu verwenden.

Das größte Problem bei der Verwendung von STL in der Spieleentwicklung ist die Speicherzuweisung. Die Standard-Allokatoren von STL passen anscheinend nicht gut zu den bevorzugten Allokationsstrategien für die Spieleentwicklung. Natürlich können benutzerdefinierte Zuweiser verwendet werden, aber dies macht die ganze Idee weniger ansprechend, wenn Sie überlegen, ob Sie eine STL zu einer Nicht-STL-Codebasis hinzufügen möchten.

Wenn es sich bei Ihrer Codebasis um eine Nicht-STL-Codebasis handelt, ist möglicherweise niemand mit STL- oder Vorlagenkonzepten vertraut, um die benutzerdefinierten Zuweiser korrekt zu implementieren.

Ich denke, diese Diskussion kann wie folgt zusammengefasst werden:

mittelmäßig geschriebener anwendungsspezifischer Code <gut geschriebener Universalcode <gut geschriebener anwendungsspezifischer Code

Jeder, dessen hausgemachte Lösung in die Kategorie 3 fallen würde, kennt mit Sicherheit die Antwort auf die ursprüngliche Frage für sein spezielles Problem. Die STL fällt in Kategorie 2. Für jemanden, der die Frage "Soll ich die STL verwenden" stellen muss, lautet die Antwort wahrscheinlich "Ja".

STL ist in Ordnung für die Verwendung auf einem PC, da sein fortschrittliches virtuelles Speichersystem die Notwendigkeit einer sorgfältigen Speicherzuweisung etwas weniger kritisch macht (obwohl man immer noch sehr vorsichtig sein muss). Auf einer Konsole mit begrenzten oder keinen virtuellen Speicherkapazitäten und exorbitanten Cache-Fehlerkosten sollten Sie keine benutzerdefinierten Datenstrukturen mit vorhersehbaren und / oder begrenzten Speicherzuordnungsmustern schreiben. (Und Sie werden mit Sicherheit nicht viel falsch machen, wenn Sie dasselbe bei einem PC-Spielprojekt tun.)

Ich denke, diese Frage ist wirklich eine größere, nicht gestellte Frage - sollte ich X in meinem Y verwenden ? Und die einzige Möglichkeit, dies wirklich zu beantworten, besteht darin, es selbst zu versuchen. Für jede Person, die sagt, dass X großartig funktioniert, gibt es jemanden, der sagt, dass es schrecklich ist. Und beide haben Recht - für ihr Projekt.

Das Tolle an Software ist, dass Sie im Gegensatz zu den meisten anderen Disziplinen die Dinge später immer wieder ändern können, wenn Sie feststellen, dass sie nicht so funktionieren, wie Sie es möchten. Finden Sie später heraus, dass STL in diesem Projekt nicht für Sie funktioniert? Reiß es raus, leg etwas anderes an seinen Platz. Gefällt es Ihnen nicht, wie Sie die Aufgaben auf Ihre Objekte aufgeteilt haben? Refactor. Gefällt es dir nicht, dass du Gegenstände benutzt hast? Ersetzen Sie sie durch gerade C-Methoden. Magst du es nicht, wenn alles in Strukturen und Methoden gespeichert ist, um sie zu manipulieren? Ersetzen Sie sie durch C ++ - Objekte.

Ich sage nein zur STL. Mein Grund ist ganz einfach:

1. Sie brauchen die STL nicht, um Spiele zu schreiben. Nicht einmal große.
2. STL erhöht die Kompilierzeit erheblich.
3. Eine lange Kompilierungszeit führt zu weniger Iterationen in Ihrer Entwicklung.

Ich halte die Anzahl der Iterationen für äußerst wichtig, daher halte ich mich von der STL und anderen Entwicklungstechniken fern, die die Iterationen verlangsamen (z. B. Architekturen oder zu kompilierende Skriptsprachen).

Kostspielige Iterationen führen dazu, dass riesige Entwicklerteams versuchen, Dinge zu erledigen, bei denen nur sehr wenig passiert. Ich habe es gesehen und gehört, und einer der Schuldigen scheint die Kompilierungszeit für Vorlagenbibliotheken zu sein.