Warum ist es so schlimm, zu früh zu optimieren?

Nachdem ich ein wenig über Optimierung nachgedacht habe, habe ich (buchstäblich überall) festgestellt, dass es eine allgemein anerkannte Sünde ist, ein Spiel zu früh zu optimieren.

Ich verstehe das wirklich nicht. Wäre es nicht unglaublich schwierig, einige der Kernstrukturen des Spiels am Ende zu ändern, anstatt sie das erste Mal mit Blick auf die Leistung zu entwickeln?

Das Warten bis das Spiel beendet ist, wird Ihnen sagen, ob Sie Optimierungen benötigen, aber sollten Sie es trotzdem nicht tun, könnte es die Vielfalt der Geräte erweitern, auf denen das Spiel laufen könnte, was die Anzahl der potenziellen Geräte erhöhen würde Spieler.

Könnte mir jemand erklären, warum es so eine schlechte Idee ist, zu früh zu optimieren?

Präambel:

In den Kommentaren wurden einige Einwände erhoben, und ich denke, sie beruhen größtenteils auf einem Missverständnis dessen, was wir unter "vorzeitiger Optimierung" verstehen - daher wollte ich dies etwas präzisieren.

"Nicht vorzeitig optimieren" bedeutet nicht "Code schreiben, von dem Sie wissen, dass er schlecht ist, weil Knuth sagt, dass Sie ihn nicht bis zum Ende bereinigen dürfen".

Es bedeutet: "Verlieren Sie keine Zeit und Lesbarkeit für die Optimierung, bis Sie wissen, welche Teile Ihres Programms tatsächlich Hilfe benötigen, um schneller zu sein." Da ein typisches Programm die meiste Zeit in ein paar Engpässen verbringt, führt die Investition in die Optimierung von "alles" möglicherweise nicht zu einer Geschwindigkeitssteigerung, die der Konzentration derselben Investition auf nur den Code mit Engpässen gleichkommt.

Dies bedeutet, dass wir im Zweifelsfall :

• Bevorzugen Sie Code, der einfach zu schreiben, klar zu verstehen und für den Anfang einfach zu ändern ist

• Überprüfen Sie, ob weitere Optimierungen erforderlich sind (in der Regel durch Erstellen eines Profils für das laufende Programm, obwohl ein Kommentar unter den Hinweisen eine mathematische Analyse enthält - das einzige Risiko besteht darin, dass Sie auch überprüfen müssen, ob Ihre Mathematik richtig ist).

Eine vorzeitige Optimierung ist nicht :

• Architekturentscheidungen zur bedarfsgerechten Strukturierung Ihres Codes - Auswahl geeigneter Module / Verantwortlichkeiten / Schnittstellen / Kommunikationssysteme mit Bedacht.

• Einfache Effizienz, die keine zusätzliche Zeit in Anspruch nimmt oder das Lesen Ihres Codes erschwert. Dinge wie das Verwenden von starker Eingabe können sowohl effizient sein als auch Ihre Absicht klarer machen. Ein weiteres Beispiel ist das Zwischenspeichern eines Verweises, anstatt wiederholt danach zu suchen (solange Ihr Fall keine komplexe Logik zur Ungültigmachung des Cache erfordert - vielleicht sollten Sie dies erst schreiben, wenn Sie das Profil auf einfache Weise erstellt haben).

• Den richtigen Algorithmus für den Job verwenden. Ein * ist optimaler und komplexer als eine erschöpfende Suche in einem Wegfindungsdiagramm. Es ist auch ein Industriestandard. Wenn Sie das Thema wiederholen und sich an bewährte Methoden wie diese halten, wird Ihr Code möglicherweise leichter verständlich, als wenn Sie etwas Einfaches tun, das den bekannten Best Practices widerspricht. Wenn Sie Erfahrung mit Engpässen bei der Implementierung von Spielefeature X in einem früheren Projekt haben, müssen Sie diesen Engpass bei diesem Projekt nicht erneut feststellen, um zu wissen, dass er real ist. Sie können und sollten Lösungen wiederverwenden, die in der Vergangenheit funktioniert haben Spiele.

All diese Optimierungsarten sind gut begründet und werden im Allgemeinen nicht als "vorzeitig" bezeichnet (es sei denn, Sie gehen in ein Kaninchenloch und implementieren die modernste Pfadfindung für Ihre 8x8-Schachbrettkarte ...).

Nachdem dies geklärt ist, erfahren Sie , warum diese Richtlinie für Spiele besonders nützlich sein kann:

Vor allem in Gamedev ist die Iterationsgeschwindigkeit das Kostbarste. Wir werden oft viel mehr Ideen implementieren und erneut implementieren, als letztendlich mit dem fertigen Spiel geliefert werden, und versuchen, "den Spaß zu finden".

Wenn Sie einen Mechaniker auf einfache und vielleicht etwas naive Weise prototypisieren und ihn am nächsten Tag testen können, sind Sie in einer viel besseren Position, als wenn Sie eine Woche damit verbracht hätten, die optimalste Version zuerst zu erstellen. Vor allem, wenn sich herausstellt, dass Sie nichts zu suchen haben und diese Funktion am Ende nicht mehr verwenden. Wenn Sie dies auf einfache Weise tun, um frühzeitig zu testen, können Sie eine Menge verschwendeter Arbeit bei der Optimierung von Code sparen, den Sie nicht behalten.

Nicht optimierter Code ist im Allgemeinen auch einfacher zu modifizieren und verschiedene Varianten auszuprobieren als Code, der fein abgestimmt ist, um eine präzise Sache optimal zu machen. Dieser Code ist in der Regel spröde und schwieriger zu modifizieren, ohne ihn zu beschädigen, Fehler einzuführen oder ihn zu verlangsamen. Wenn der Code einfach und leicht zu ändern ist, ist dies während des größten Teils der Entwicklung oftmals eine geringe Ineffizienz der Laufzeit wert (wir entwickeln normalerweise auf Computern, die über der Zielspezifikation liegen, damit wir den Overhead auffangen und uns darauf konzentrieren können, zuerst die Zielerfahrung zu erzielen) Ich habe das gesperrt, was wir von der Funktion benötigen, und kann die Teile optimieren, von denen wir jetzt wissen, dass sie langsam sind.

Ja, es kann schwierig sein, Teile des Projekts spät in der Entwicklung umzugestalten, um die langsamen Stellen zu optimieren. Dies gilt jedoch auch für das wiederholte Umgestalten während der gesamten Entwicklung, da die Optimierungen, die Sie im letzten Monat vorgenommen haben, nicht mit der Richtung vereinbar sind, in die sich das Spiel seitdem entwickelt hat, oder etwas behoben haben, das sich als nicht der wahre Engpass herausstellte, sobald Sie mehr Features und Inhalte erhalten haben im.

Spiele sind seltsam und experimentell - es ist schwer vorherzusagen, wie sich ein Spielprojekt und seine technischen Anforderungen entwickeln und wo die Leistung am höchsten ist. In der Praxis machen wir uns oft Sorgen über die falschen Dinge - durchsuchen Sie die Fragen zur Leistung hier und Sie werden sehen, dass ein gemeinsames Thema entsteht, bei dem Entwickler von Dingen auf Papier abgelenkt werden, die wahrscheinlich überhaupt kein Problem darstellen.

Um ein dramatisches Beispiel zu nennen: Wenn Ihr Spiel an eine GPU gebunden ist (nicht ungewöhnlich), wird die gesamte Zeit, die Sie für die Optimierung und das Threading der CPU-Arbeit aufgewendet haben, möglicherweise keinen greifbaren Nutzen bringen. All diese Entwicklerstunden hätten dafür verwendet werden können, Gameplay-Funktionen zu implementieren und zu verbessern, um eine bessere Spielerfahrung zu erzielen.

Insgesamt wird die meiste Zeit, die Sie mit der Arbeit an einem Spiel verbringen, nicht für den Code aufgewendet, der letztendlich zum Engpass wird. Vor allem, wenn Sie an einer vorhandenen Engine arbeiten, können Sie die extrem teuren internen Regelkreise in den Rendering- und Physiksystemen nicht mehr verwenden. Zu diesem Zeitpunkt besteht Ihre Aufgabe in den Gameplay-Skripten darin, der Engine im Grunde genommen aus dem Weg zu gehen. Solange Sie dort keinen Schraubenschlüssel hineinwerfen, werden Sie bei einem ersten Build wahrscheinlich ganz gut abschneiden.

Abgesehen von ein bisschen Code-Hygiene und Budgetierung (z. B. Suchen Sie nicht wiederholt nach Dingen / Konstruieren, wenn Sie sie leicht wiederverwenden können, halten Sie Ihre Pathfinding- / Physik-Abfragen oder GPU-Rücklesevorgänge bescheiden usw.) und machen Sie sich zur Gewohnheit, nicht vorbei zu sein - Die Optimierung, bevor wir wissen, wo die tatsächlichen Probleme auftreten, wirkt sich positiv auf die Produktivität aus. So sparen wir uns Zeit, die falschen Dinge zu optimieren, und halten unseren Code insgesamt einfacher und einfacher zu optimieren.

Anmerkung: Diese Antwort begann als Kommentar zu DMGregorys Antwort und dupliziert daher nicht die sehr guten Punkte, die er macht.

"Wäre es nicht unglaublich schwierig, einige der Kernstrukturen des Spiels am Ende zu ändern, anstatt sie beim ersten Mal mit Blick auf die Leistung zu entwickeln?"

Dies ist für mich der Kern der Frage.

Wenn Sie Ihr ursprüngliches Design erstellen, sollten Sie versuchen, auf höchstem Niveau effizient zu gestalten. Dies ist weniger eine Optimierung, und es geht mehr um Struktur.

Beispiel:
Sie müssen ein System erstellen, um einen Fluss zu überqueren. Die naheliegenden Entwürfe sind eine Brücke oder eine Fähre. Welche wählen Sie?
Die Antwort hängt natürlich von der Größe der Überfahrt und dem Verkehrsaufkommen ab. Dies ist keine Optimierung, sondern beginnt mit einem Design, das für Ihr Problem geeignet ist.

Wenn Sie eine Auswahl an Designs treffen, wählen Sie diejenige aus, die am besten zu Ihren Vorstellungen passt.

Nehmen wir also an, dass unser Verkehrsaufkommen relativ gering ist, und beschließen, zwei Terminals zu bauen und eine Fähre zu kaufen, um den Verkehr zu bewältigen. Eine nette einfache Implementierung
Leider stellen wir fest, dass nach dem Start mehr Verkehr als erwartet zu verzeichnen ist. Wir müssen die Fähre optimieren! (weil es funktioniert und der Bau einer Brücke jetzt kein guter Plan ist)

Optionen:

• Kaufen Sie eine zweite Fähre (Parallelverarbeitung)
• Hinzufügen eines weiteren Autodecks zur Fähre (Verdichtung des Verkehrs)
• Rüste den Motor der Fähre auf, um ihn schneller zu machen (überarbeitete Verarbeitungsalgorithmen)

Hier sollten Sie versuchen, Ihr ursprüngliches Design so modular wie möglich zu gestalten.
Alle oben genannten sind mögliche Optimierungen, und Sie könnten sogar alle drei tun.
Aber wie können Sie diese Änderungen ohne große strukturelle Änderungen vornehmen?

Wenn Sie modular aufgebaut sind und klar definierte Schnittstellen haben, sollten sich diese Änderungen leicht umsetzen lassen.
Wenn Ihr Code nicht eng gekoppelt ist, wirken sich Änderungen an Modulen nicht auf die umgebende Struktur aus.

Werfen wir einen Blick auf das Hinzufügen einer zusätzlichen Fähre.
Ein "schlechtes" Programm könnte auf der Idee einer einzelnen Fähre aufbauen und die Dockzustände und den Fährstatus und die Position zusammenfassen und den Status gemeinsam nutzen. Dies kann nur schwer geändert werden, damit dem System eine zusätzliche Fähre hinzugefügt werden kann.
Ein besseres Design wäre, die Docks und die Fähre als separate Einheiten zu haben. Es gibt keine enge Verbindung zwischen ihnen, aber sie haben eine Schnittstelle, an der eine Fähre ankommen, Passagiere entladen, neue übernehmen und abfahren kann. Das Dock und die Fähre teilen sich nur diese Schnittstelle, und dies macht es einfach, Änderungen am System vorzunehmen, in diesem Fall durch Hinzufügen einer zweiten Fähre. Das Dock kümmert sich nicht darum, welche Fähren es tatsächlich gibt, es geht nur darum, dass etwas (irgendetwas) seine Schnittstelle verwendet.

tl; dr:

• Versuchen Sie zunächst, auf Effizienz zu achten.
• Wenn Sie zwei Möglichkeiten haben, wählen Sie die effizientere.
• Schreiben Sie Ihren Code so modular wie möglich mit gut definierten Schnittstellen.

Sie können dann die Mechanismen in jedem Modul ändern, ohne die gesamte Codebasis neu zu strukturieren, wenn Sie eine Optimierung benötigen.

"Nicht zu früh optimieren" bedeutet nicht "die schlechteste Methode wählen, um Dinge zu tun". Sie müssen immer noch die Auswirkungen auf die Leistung berücksichtigen (es sei denn, Sie erstellen nur Prototypen). Es geht nicht darum, andere, wichtigere Dinge zu diesem Zeitpunkt in der Entwicklung zu lähmen - wie Flexibilität, Zuverlässigkeit usw. Wählen Sie einfache, sichere Optimierungen - wählen Sie die Dinge aus, die Sie einschränken und die Dinge, die Sie freihalten. Behalten Sie die Kosten im Auge. Solltest du stark tippen? Die meisten Spiele haben gut funktioniert. Wie viel würde es Sie kosten, das zu entfernen, wenn Sie interessante Anwendungen der Flexibilität für das Gamemplay finden würden?

Es ist viel schwieriger, optimierten Code zu ändern, insbesondere "intelligenten" Code. Es ist immer eine Entscheidung, die einige Dinge verbessert und andere verschlechtert (zum Beispiel, wenn Sie CPU-Zeit für die Speichernutzung eintauschen). Wenn Sie diese Wahl treffen, müssen Sie sich aller Auswirkungen bewusst sein - sie können katastrophal sein, aber sie können auch hilfreich sein.

Zum Beispiel wurden Commander Keen, Wolfenstein und Doom jeweils auf einer optimierten Rendering-Engine aufgebaut. Jeder hatte seinen "Trick", der es überhaupt erst ermöglichte, dass das Spiel existierte (jeder hatte im Laufe der Zeit weitere Optimierungen entwickelt, aber das ist hier nicht wichtig). Das ist in Ordnung . Es ist in Ordnung, den Kern des Spiels stark zu optimieren, das Denken, das das Spiel ermöglicht; Vor allem, wenn Sie Neuland erkunden, in dem diese optimierte Funktion es Ihnen ermöglicht, Spieldesigns zu berücksichtigen, die nicht viel erforscht wurden. Die durch die Optimierung eingeführten Einschränkungen können Ihnen auch ein interessantes Spielvergnügen bringen (z. B. haben die Begrenzungen der Einheitenzahl in RTS-Spielen möglicherweise begonnen, um die Leistung zu verbessern, sie haben jedoch auch einen Gameplay-Effekt).

Beachten Sie jedoch, dass in jedem dieser Beispiele das Spiel ohne die Optimierung nicht existieren könnte. Sie starteten nicht mit einem "voll optimierten" Motor - sie starteten mit dem Nötigsten und arbeiteten sich nach oben. Sie entwickelten neue Technologien und verwendeten sie, um lustige Spiele zu machen. Und die Engine-Tricks beschränkten sich auf einen möglichst kleinen Teil der Codebasis - die stärkeren Optimierungen wurden erst eingeführt, als das Gameplay größtenteils fertig war oder ein interessantes neues Feature auftauchte.

Nun überlegen Sie sich ein Spiel, das Sie vielleicht machen möchten. Gibt es wirklich ein technologisches Wunder, das dieses Spiel macht oder bricht? Vielleicht stellen Sie sich ein Open-World-Spiel in einer unendlichen Welt vor. Ist das wirklich das zentrale Stück des Spiels? Wäre das Spiel ohne nicht möglich? Vielleicht denkst du an ein Spiel, bei dem das Terrain unbegrenzt deformierbar ist, mit realistischer Geologie und so weiter. können Sie es mit einem kleineren Umfang arbeiten lassen? Würde es in 2D statt in 3D funktionieren? Holen Sie sich so schnell wie möglich etwas, das Spaß macht - auch wenn Sie bei Optimierungen möglicherweise einen großen Teil Ihres vorhandenen Codes überarbeiten müssen, kann es sich lohnen. und vielleicht merkt man sogar, dass das Spiel nicht wirklich besser wird, wenn man Dinge größer macht.

Als Beispiel für ein aktuelles Spiel mit vielen Optimierungen würde ich auf Factorio verweisen. Ein entscheidender Teil des Spiels sind die Gürtel - es gibt viele Tausende von ihnen und sie tragen viele einzelne Materialteile in Ihrer gesamten Fabrik. Hat das Spiel mit einer stark optimierten Riemenmaschine begonnen? Nein! Tatsächlich war es fast unmöglich, das ursprüngliche Gürteldesign zu optimieren - es wurde eine Art physikalische Simulation der Gegenstände auf dem Gürtel durchgeführt, die einige interessante Dinge hervorbrachte, die Sie tun konnten (auf diese Weise erhalten Sie ein "aufstrebendes" Gameplay - ein Gameplay, das überrascht der Designer), aber bedeutete, dass Sie jedes einzelne Element auf dem Gürtel simulieren mussten. Mit Tausenden von Bändern erhalten Sie Zehntausende von physisch simulierten Objekten - selbst wenn Sie diese entfernen und die Bänder die Arbeit erledigen lassen, können Sie die zugehörige CPU-Zeit um 95-99% verkürzen. auch ohne Berücksichtigung von Dingen wie der Speicherlokalität. Dies ist jedoch nur dann sinnvoll, wenn Sie tatsächlich an diese Grenzen stoßen.

Fast alles, was mit Riemen zu tun hatte, musste neu hergestellt werden, damit die Riemen optimiert werden konnten. Und die Bänder mussten optimiert werden, da für eine große Fabrik viele Bänder benötigt wurden und große Fabriken eine Attraktion des Spiels sind. Wenn Sie keine großen Fabriken haben können, warum dann eine unendliche Welt? Witzig, sollte man fragen - frühe Versionen haben das nicht getan :) Das Spiel wurde viele Male überarbeitet und umgestaltet, um zu sehen, wo es jetzt ist Spiel wie dieses und wechselte zu C ++. Und für Factorio hat es super geklappt (obwohl es immer noch gut war, dass es von Anfang an nicht optimiert wurde - zumal es sich um ein Hobbyprojekt handelte, das ansonsten aus Mangel an Interesse einfach gescheitert wäre).

Aber die Sache ist, es gibtViele Dinge, die Sie mit einer Fabrik mit begrenztem Umfang tun können - und viele Spiele haben genau das gezeigt. Grenzen können zum Spaß noch stärker sein als Freiheiten; würde Spacechem mehr Spaß machen, wenn die "Karten" unendlich wären? Wenn Sie mit stark optimierten "Gürteln" anfangen würden, wären Sie so ziemlich gezwungen, diesen Weg zu gehen. und man konnte keine anderen Konstruktionsrichtungen erkunden (wie zum Beispiel zu sehen, welche interessanten Dinge man mit physikalisch simulierten Förderbändern machen kann). Sie begrenzen Ihren potenziellen Gestaltungsspielraum. Es mag nicht so aussehen, weil Sie nicht viele unvollendete Spiele sehen, aber der schwierige Teil ist, den Spaß richtig zu machen - für jedes lustige Spiel, das Sie sehen, gibt es wahrscheinlich Hunderte, die einfach nicht dorthin gelangen konnten und verschrottet wurden (oder schlimmer, als schreckliches Durcheinander veröffentlicht). Wenn Ihnen die Optimierung dabei hilft, fahren Sie fort. Wenn es nicht ... Es ist wahrscheinlich verfrüht. Wenn Sie der Meinung sind, dass einige Gameplay-Mechaniken großartig funktionieren, aber Optimierungen benötigen, um wirklich zu glänzen, dann machen Sie weiter. Wenn Sie nicht interessante Mechanik haben,optimiere sie nicht . Finden Sie zuerst den Spaß - Sie werden feststellen, dass die meisten Optimierungen dabei nicht helfen und oft schädlich sind.

Endlich hast du ein tolles, lustiges Spiel. Ist es sinnvoll, jetzt zu optimieren ? Ha! Es ist immer noch nicht so klar, wie Sie vielleicht denken. Gibt es etwas, das Spaß macht?können Sie stattdessen tun? Vergiss nicht, dass deine Zeit immer noch begrenzt ist. Alles ist anstrengend, und Sie möchten sich darauf konzentrieren, wo es am wichtigsten ist. Ja, auch wenn Sie ein "freies Spiel" oder ein "Open Source" -Spiel machen. Beobachten Sie, wie das Spiel gespielt wird. bemerken, wo die Leistung zu einem Engpass wird. Macht die Optimierung dieser Orte mehr Spaß (wie das Bauen immer größerer, immer verwickelterer Fabriken)? Ermöglicht es Ihnen, mehr Spieler anzuziehen (z. B. mit schwächeren Computern oder auf verschiedenen Plattformen)? Sie müssen immer Prioritäten setzen - achten Sie auf das Verhältnis von Aufwand zu Ertrag. Sie werden wahrscheinlich viele niedrig hängende Früchte finden, wenn Sie Ihr Spiel spielen und anderen beim Spielen zuschauen. Beachten Sie jedoch den wichtigen Teil - um dorthin zu gelangen, benötigen Sie ein Spiel . Konzentriere dich darauf.

Bedenken Sie als Krönung, dass die Optimierung niemals endet. Es ist keine Aufgabe mit einem kleinen Häkchen, die Sie abschließen und mit anderen Aufgaben fortfahren. Es gibt immer noch "eine weitere Optimierung", und ein großer Teil jeder Entwicklung besteht darin, die Prioritäten zu verstehen. Sie optimieren nicht um der Optimierung willen, sondern um ein bestimmtes Ziel zu erreichen (z. B. "200 Einheiten gleichzeitig auf dem Bildschirm auf einem 333-MHz-Pentium" ist ein großartiges Ziel). Verliere nicht den Überblick über das Endziel, nur weil du dich zu sehr auf die Zwischenziele konzentrierst, die möglicherweise nicht einmal mehr Voraussetzungen für das Endziel sind.

Viele der Antworten scheinen sich stark auf den Leistungsaspekt der "Optimierung" zu konzentrieren, während ich mich selbst gerne mit der Optimierung und der ganzen Qual der zu frühen Optimierung auf einer abstrakteren Ebene beschäftige.

Humor mich, wie ich versuche, meine Perspektive mit Hilfe von Polyominoes auszuarbeiten.

Angenommen, wir haben durch das Framework oder die Engine, mit denen wir arbeiten, einige feste Grenzen gesetzt.

Dann erstellen wir wie folgt unsere erste Ebene / unser erstes Modul des Spiels.

Im weiteren Verlauf bauen wir unsere zweite Ebene / Modul auf.

An diesem Punkt stellen wir möglicherweise fest, dass zwischen den beiden Modulen etwas Platz vorhanden ist, und wir sind möglicherweise versucht, ihn zu optimieren, um die uns zugewiesenen Grenzen voll auszunutzen.

Perfekt, jetzt nutzt die Anwendung die uns zur Verfügung stehenden Ressourcen voll aus. Die Anwendung ist besser, oder?

Wir bauen die dritte Schicht / das dritte Modul unserer Anwendung auf und stellen plötzlich fest (vielleicht sogar eine, die wir bei der anfänglichen Planung nicht vorausgesehen haben), dass die dritte Schicht / das dritte Modul für uns nicht funktioniert.

Wir suchen nach einer Alternative, wir finden eine, und letztendlich müssen wir auch das 2. Modul unserer Anwendung ändern, da es nicht mit unserem neu ausgewählten 3. Modul kompatibel ist. (Zum Glück ist es einigermaßen kompatibel mit unserem ersten Modul, sodass wir nicht alles von Grund auf neu schreiben müssen.)

Also fügten wir alles zusammen ...

Hmm, kannst du sehen, was passiert ist?

Durch eine zu frühe Optimierung haben wir die Effizienz jetzt tatsächlich verschlechtert, da wir uns nicht mehr für die Optimierung entschieden haben.

Und wenn wir später einige zusätzliche Module oder zusätzliche Leckerbissen hinzufügen wollten, sind wir möglicherweise nicht mehr in der Lage, diese zu tun.

Und die niedrigste Stufe unseres Systems einzustellen ist nicht mehr so ​​einfach, da es unter allen anderen Schichten verborgen ist.

Wenn wir uns jedoch entschlossen hätten, mit dem Drang zu warten, es sofort zu optimieren, wären wir zu so etwas gekommen:

Und jetzt, wenn wir die Optimierung an diesem Punkt durchführen, bekommen wir etwas Befriedigendes zum Anschauen.

Hoffentlich hatten zumindest einige von Ihnen so viel Spaß beim Lesen wie ich beim Erstellen :) und wenn Sie jetzt das Gefühl haben, dass Sie das Thema besser verstehen - umso besser.

Geld.

Darauf kommt es an. Geld. Da Zeit Geld ist *, desto mehr Zeit verbringen Sie mit Aktivitäten, bei denen nicht garantiert ist, dass sie mehr Geld generieren (dh Sie können diese Aktivitäten nicht als Investitionen betrachten ), desto mehr Geld riskieren Sie zu verschwenden und desto weniger Geld verdienen Sie das Spiel.

Hier sind einige weitere mögliche Nebenwirkungen einer zu frühen Optimierung und Gründe, warum Sie diese vermeiden sollten:

• Ihre Kollegen hassen Sie, weil Sie mit Ihren Spielsachen in Ihrer Sandkiste spielen, während sie hart daran arbeiten, neue Funktionen zu entwickeln.
• Die Verzögerungen stören das höhere Management und führen dazu, dass das Team Liefertermine verpasst, was dazu führt, dass das Spiel im Frühjahr anstatt vor der Ferienzeit veröffentlicht wird, was wiederum dazu führt, dass das Spiel nicht genug verkauft wird. Aus diesem Grund beschließt die Zentrale, das Studio zu schließen, wodurch Sie praktisch arbeitslos werden. Und kein Job bedeutet kein Geld. (Und da Sie niemand mag, weil Sie zu viel Zeit für die frühe Optimierung aufgewendet haben, möchte niemand auf LinkedIn eine positive Bewertung Ihrer Arbeit für Sie verfassen, die Sie für längere Zeit vom Geld abhält.)

^{* Andere Antworten haben den 'Zeit'-Teil gut genug hervorgehoben}

Als Randnotiz hilft im Allgemeinen die Erfahrung dabei, festzustellen, was eine vorzeitige Optimierung ist und was nicht und was für das Unternehmen von Wert ist und was nicht.

Wenn Sie beispielsweise an Spiel A gearbeitet haben und am Ende des Projekts festgestellt haben, dass die Funktion XYZ Ihre Spielrunde besonders stark belastet, beginnen Sie schließlich mit der Arbeit an Spiel B, das genau die gleiche Funktion hat Das Feature neu zu schreiben und es von Anfang an zu optimieren ist keine vorzeitige Optimierung, da Sie wissen , dass es ein Engpass sein wird, wenn nichts unternommen wird.

Optimierung ist per definitionem der Prozess der Steigerung der Effizienz einer Lösung bis zu dem Punkt, an dem sie ihre Wirksamkeit verliert. Dieser Vorgang impliziert dann eine Verringerung des Raums der Lösung.

In einem frühen Stadium der Softwareentwicklung kann es immer noch zu "versteckten Anforderungen" kommen: Wenn Sie den Speicherplatz Ihrer Lösung zu stark reduzieren, können Sie möglicherweise in eine Situation geraten, in der Sie eine "versteckte Anforderung" beim Auftauchen nicht erfüllen können In einem späteren Stadium der Entwicklung müssen Sie dann die Architektur ändern und auf diese Weise Instabilität und möglicherweise eine Reihe von unerwünschten Verhaltensweisen hinzufügen.

Die Idee ist dann, die gesamte Lösung zum Laufen zu bringen und erst dann, wenn alle Anforderungen festgelegt und implementiert sind, den Code zu verschärfen. Sie werden dann feststellen, dass viele Optimierungen, die Sie beim Codieren mit Leichtigkeit auf einmal vorgenommen hätten, aufgrund der Interaktion mit späten Anforderungen nicht mehr möglich sind.

Der reale Raum der Lösung ist immer größer als derjenige, den wir zu Beginn erwarten, weil wir keine perfekte Kenntnis eines sehr komplexen Systems haben können.

Lass es zuerst funktionieren. Dann die Seile festziehen.

Kurz gesagt, wenn Sie später Änderungen vornehmen möchten, wird das frühzeitige Optimieren häufig zu einem Aufwand, und dann haben Sie die leicht zu ändernden Codestrukturen auf eine viel niedrigere Ebene optimiert, und Sie müssen sie jetzt wieder auf eine hohe Ebene zurücksetzen Level-Ansatz, und optimieren Sie das Ergebnis noch einmal.

Dies ist ein häufiger Fehler für Anfänger, die sich darauf konzentrieren möchten, Freude an "nützlicher Arbeit" zu haben, z. B. Optimierung, und nicht darüber nachdenken, ob es der richtige Zeitpunkt ist, dies zu tun. Wenn Sie Erfahrung mit dem Programmieren von großen Projekten wie Spielen sammeln, erfahren Sie, wann eine Optimierung der vorhandenen Codebasis erforderlich ist und wann es zu früh ist. Haben Sie keine Angst, diesen Fehler zu begehen, Sie werden nur davon profitieren, wenn Sie daraus lernen.

Optimieren Sie im Allgemeinen nur, wenn Sie in diesem Moment wirklich nicht mit dem Entwicklungsbuild arbeiten können. Zum Beispiel, wenn Sie 60 Mal pro Sekunde Millionen von Objekten erstellen und löschen.

Daher würde ich sagen, dass es in Bezug auf die Lernerfahrung gut ist, einige Male frühzeitig zu optimieren: p

Die Optimierung konzentriert sich darauf, dass der Computer am besten mit dem Code funktioniert, während die Entwicklung erfordert, dass der Programmierer am besten mit dem Code arbeitet.

Optimierung bringt keine Erkenntnisse. Dadurch arbeitet der Computer weniger und der Programmierer mehr.

Natürlich gibt es verschiedene Kategorien, wie beim Entwerfen eines Autos. An der Optimierung eines Motors vor dem Bau Ihres ersten Chassis ist nichts auszusetzen. Die Optimierung des Chassis, bevor Sie die Form des Motors nicht kennen, kann jedoch zu Zeitverschwendung führen. Durch Modularität und Spezifikationen können zahlreiche Stellen für Optimierungsarbeiten bereitgestellt werden, noch bevor das gesamte Produkt zusammengebaut wird.

Ich bin mit all diesen Aussagen nicht einverstanden, dass Code in einem frühen Stadium nicht optimiert werden sollte. Es kommt darauf an, auf welcher Bühne du bist. Wenn dies ein MVP - Prototyp ist und Sie nur versuchen, sich das Spiel anzusehen, das 1 bis 2 Wochen dauert, dann sind Sie bereit, alles, was Sie bereits geschrieben haben, neu zu schreiben. Ja, Optimierung spielt keine Rolle. Wenn Sie jedoch bereits an einem Spiel arbeiten, von dem Sie wissen, dass es veröffentlicht wird, sollte es die ganze Zeit über optimierten Code enthalten. Die Geschichten, die die Leute über neue Funktionen und Dinge sagen, die hinzugefügt werden könnten, sind Missverständnisse. Es ist eher eine schlecht gestaltete Codearchitektur als optimierter Code. Sie müssen nichts umschreiben, um neue Elemente hinzuzufügen, wenn Sie ein gutes Code-Design haben.

Wenn Sie zum Beispiel einen A * -Pfadfindungsalgorithmus haben, wäre es nicht besser, ihn so optimal wie möglich zu schreiben? Anstatt später die Hälfte des Codes zu ändern, mussten Sie einige Änderungen am Algorithmus vornehmen, da jetzt andere Methodenaufrufe und Rückrufe erforderlich sind. Und wenn Sie bereits von Anfang an über einen optimierten Code verfügen, sparen Sie viel Zeit. Weil Sie sich Beziehungen zwischen Objekten und deren Interaktion zeichnen können, anstatt blinde Unmengen neuer Skripte zu erstellen und alle Verbindungen sofort herzustellen - dies führt zu unklarem Sphagetti-Code.

Das Letzte, was ich hinzufügen möchte, ist, dass Sie später, auch wenn Sie das Spiel nicht mehr machen möchten, über Ihren optimierten A * -Algorithmus verfügen, den Sie für Ihre nächsten Spiele verwenden können. Wiederverwendbarkeit. Beispielsweise verfügen viele Spiele über Inventar, Pfadfindung, Prozedurgenerierung, Interaktionen zwischen NPC, Kampfsystem, KI, Schnittstelleninteraktion und Eingabeverwaltung. Jetzt sollten Sie sich fragen: "Wie oft habe ich diese Elemente von Grund auf neu geschrieben?" Sie sind 70-80% des Spiels. Müssen Sie sie wirklich die ganze Zeit neu schreiben? Und wenn sie nicht optimiert sind?