Pourquoi est-il si mauvais d'optimiser trop tôt?

Après avoir examiné un peu l'optimisation, j'ai découvert (littéralement partout) qu'il semble un péché universellement reconnu d'optimiser un jeu trop tôt.

Je ne comprends vraiment pas cela. Ne serait-il pas incroyablement difficile de modifier certaines des structures de base du jeu à la fin, plutôt que de les développer la première fois en tenant compte de la performance?

Je pense que attendre que le jeu soit terminé vous dira si vous avez besoin d'optimisations, mais si vous le faites quand même, après tout, cela pourrait élargir la variété des périphériques sur lesquels le jeu pourrait tourner, ce qui augmenterait le nombre de potentiels. joueurs.

Quelqu'un pourrait-il m'expliquer pourquoi l'optimisation trop tôt est une si mauvaise idée?

Préambule:

Quelques objections ont été soulevées dans les commentaires et je pense qu'elles découlent en grande partie d'une incompréhension de ce que nous entendons par «optimisation prématurée» - je voulais donc ajouter un peu de clarification à ce sujet.

"Ne pas optimiser prématurément" ne signifie pas "écrire du code que vous savez mauvais, parce que Knuth dit que vous n'êtes pas autorisé à le nettoyer jusqu'à la fin"

Cela signifie "ne sacrifiez pas le temps et la lisibilité pour l'optimisation avant de savoir quelles parties de votre programme ont réellement besoin d'aide pour être plus rapide". Dans la mesure où un programme typique passe le plus clair de son temps dans quelques goulots d'étranglement, investir dans l'optimisation de "tout" ne vous donnera peut-être pas le même gain de vitesse que de concentrer cet investissement sur le code goulot.

Cela signifie qu'en cas de doute , nous devrions:

• Préférez un code simple à écrire, clair à comprendre et facile à modifier pour les débutants

• Vérifiez si une optimisation supplémentaire est nécessaire (généralement en profilant le programme en cours, bien qu'un commentaire ci-dessous indique d'effectuer une analyse mathématique - le seul risque que vous rencontrez est également de vérifier que vos calculs sont corrects)

Une optimisation prématurée n'est pas :

• Décisions architecturales pour structurer votre code de manière à l'adapter à vos besoins - en choisissant les modules / responsabilités / interfaces / systèmes de communication appropriés de manière réfléchie.

• Des performances simples qui ne prennent pas trop de temps et ne rendent pas votre code plus difficile à lire. L'utilisation de dactylographes forts peut être efficace et clarifier votre intention. La mise en cache d'une référence au lieu de la rechercher de manière répétée est un autre exemple (tant que votre cas ne nécessite pas une logique complexe d'invalidation de cache - conservez peut-être l'écriture jusqu'à ce que vous ayez d'abord profilé de manière simple).

• Utiliser le bon algorithme pour le travail. A * est plus optimal et plus complexe que la recherche exhaustive d’un graphe de trajectoire. C'est aussi un standard de l'industrie. Répéter le thème en restant fidèle à des méthodes éprouvées comme celle-ci peut en réalité rendre votre code plus facile à comprendre que si vous faites quelque chose de simple mais qui va à l’encontre des meilleures pratiques connues. Si vous avez déjà rencontré des goulets d'étranglement lors de l'implémentation de la fonctionnalité de jeu X dans un projet précédent, vous n'avez pas besoin de répéter le même goulot d'étranglement pour savoir qu'il est réel. Vous pouvez et devez réutiliser des solutions qui fonctionnaient depuis longtemps. Jeux.

Tous ces types d'optimisations sont bien justifiés et ne seront généralement pas qualifiés de "prématurés" (à moins que vous ne perdiez de vue un lapin mettant en œuvre une orientation de pointe pour votre carte d'échiquier 8x8 ...)

C’est pourquoi , maintenant que tout est clair, pourquoi nous pourrions trouver cette politique utile dans les jeux en particulier:

Dans gamedev en particulier, la vitesse d'itération est la chose la plus précieuse. Nous allons souvent implémenter et ré-implémenter beaucoup plus d'idées que ce qui sera livré avec le jeu fini, en essayant de "trouver le plaisir".

Si vous pouvez prototyper un mécanicien de manière simple et peut-être un peu naïve et le tester le lendemain, vous êtes dans une bien meilleure position que si vous passiez d'abord une semaine à en faire la version la plus optimale. Surtout s'il s'avère que c'est nul et que vous finissez par jeter cette fonctionnalité. Le faire de manière simple afin de pouvoir effectuer des tests plus tôt permet d’économiser une tonne de travail inutile en optimisant du code que vous ne gardez pas.

Le code non optimisé est également généralement plus facile à modifier et à essayer différentes variantes que le code conçu avec précision pour effectuer une tâche précise de manière optimale, qui a tendance à être fragile et plus difficile à modifier sans le casser, en introduisant des bugs ou en le ralentissant. Donc, garder le code simple et facile à modifier vaut souvent un peu d'inefficacité d'exécution pendant la majeure partie du développement (nous développons généralement sur des machines supérieures à la spécification cible, afin que nous puissions absorber les frais généraux et nous concentrer sur l'obtention de l'expérience cible en premier) jusqu'à ce que nous 'a verrouillé ce dont nous avons besoin de la fonctionnalité et peut optimiser les pièces que nous savons maintenant lentes.

Oui, il peut être difficile de restructurer certaines parties du projet à la fin du développement afin d'optimiser les points lents. Mais il en va de même pour le refactoring à plusieurs reprises tout au long du développement, car les optimisations que vous avez effectuées le mois dernier ne sont pas compatibles avec l'évolution du jeu depuis, ou corrigeaient quelque chose qui n'était pas le véritable goulot d'étranglement une fois que vous disposiez de plus de fonctionnalités et de contenu dans.

Les jeux sont étranges et expérimentaux - il est difficile de prédire comment un projet de jeu et ses besoins technologiques vont évoluer et où la performance sera la plus serrée. En pratique, nous finissons souvent par nous inquiéter des mauvaises choses - parcourez les questions de performances et vous verrez apparaître un thème commun: les développeurs se laisser distraire par des choses sur papier qui ne sont probablement pas un problème du tout.

Pour prendre un exemple dramatique: si votre jeu est lié au GPU (pas rare), alors tout ce temps passé à hyper-optimiser et à fileter le travail de la CPU pourrait ne produire aucun avantage tangible. Toutes ces heures de développement auraient pu être consacrées à la mise en œuvre et au perfectionnement des fonctionnalités de jeu, pour une meilleure expérience du joueur.

Globalement, la plupart du temps que vous passez à travailler sur un jeu ne sera pas consacré au code qui finit par être le goulot d'étranglement. Surtout lorsque vous travaillez sur un moteur existant, la boucle extrêmement coûteuse des systèmes de rendu et de physique est en grande partie hors de votre portée. À ce stade, votre travail dans les scripts de jeu consiste à rester fondamentalement à l'écart du moteur - tant que vous ne lancez pas une clé, vous obtiendrez probablement un résultat assez bon pour une première construction.

Donc, mis à part un peu d’hygiène de code et de budgétisation (par exemple, ne cherchez pas et ne construisez pas à répétition des choses si vous pouvez facilement les réutiliser, gardez vos requêtes de recherche de trajectoire / physique ou les relectures de GPU modestes, etc.), en prenant l’habitude de ne pas oublier -optimiser avant de savoir où sont les vrais problèmes s'avère bon pour la productivité - nous évite de perdre du temps à optimiser les mauvaises choses et rend notre code plus simple et plus facile à peaufiner.

note: cette réponse a commencé comme un commentaire sur la réponse de DMGregory, et ne duplique donc pas les très bons arguments qu'il avance.

"Ne serait-il pas incroyablement difficile de changer certaines des structures de base du jeu à la fin, plutôt que de les développer la première fois en tenant compte de la performance?"

Ceci, pour moi, est le noeud de la question.

Lors de la création de votre conception originale, vous devriez essayer de concevoir l' efficacité - au niveau supérieur. C’est moins une optimisation et plus une question de structure.

Exemple:
Vous devez créer un système pour traverser une rivière. Les conceptions évidentes sont un pont ou un ferry, alors que choisissez-vous?
La réponse dépend bien sûr de la taille du passage à niveau et du volume de la circulation. Il ne s’agit pas d’une optimisation, mais bien d’une conception adaptée à votre problème.

Lorsqu'on vous présente des choix de design, vous choisissez celui qui convient le mieux à ce que vous voulez faire.

Alors, disons que notre volume de trafic est assez faible, nous avons donc décidé de construire deux terminaux et d’acheter un ferry pour gérer le trafic. Une belle implémentation simple
Malheureusement, une fois que nous l’avons lancée, nous constatons qu’elle voit plus de trafic que prévu. Nous devons optimiser le ferry! (parce que ça marche, et construire un pont maintenant n'est pas un bon plan)

Les options:

• Acheter un deuxième ferry (traitement en parallèle)
• Ajouter un autre pont auto au traversier (compression du trafic)
• Améliorer le moteur du traversier pour le rendre plus rapide (algorithmes de traitement réécrits)

C’est là que vous devriez essayer de rendre votre conception originale aussi modulaire que possible.
Tout ce qui précède est une optimisation possible, et vous pouvez même faire les trois.
Mais comment faire ces changements sans grands changements structurels?

Si vous avez une conception modulaire avec des interfaces clairement définies, il devrait être simple d’implémenter ces modifications.
Si votre code n'est pas étroitement couplé, les modifications apportées aux modules n'affectent pas la structure environnante.

Jetons un coup d'oeil à l'ajout d'un ferry supplémentaire.
Un «mauvais» programme pourrait être construit autour de l’idée d’un seul ferry, et les états de quai et l’état et la position du ferry seraient regroupés et partagés. Cela sera difficile à modifier pour permettre l’ajout d’un traversier supplémentaire au système.
Une meilleure conception serait d’avoir les quais et le traversier comme entités séparées. Il n'y a pas de couplage étroit entre eux, mais ils ont une interface, où un ferry peut arriver, décharger des passagers, en prendre de nouveaux et partir. Le quai et le ferry partagent uniquement cette interface, ce qui facilite les modifications du système, dans ce cas en ajoutant un second ferry. Le quai ne se soucie pas de ce que sont réellement les ferries, tout ce qui le concerne est que quelque chose (n'importe quoi) utilise son interface.

tl; dr:

• Essayez de concevoir pour l'efficacité en premier lieu.
• Quand on vous présente deux choix, vous choisissez le plus efficace.
• Ecrivez votre code de manière aussi modulaire que possible avec des interfaces bien définies.

Vous pouvez ensuite modifier les mécanismes dans chaque module sans restructurer la base de code complète lorsque vous devez optimiser.

"Ne pas optimiser au début" ne signifie pas "choisir le pire moyen de faire les choses". Vous devez toujours prendre en compte les conséquences sur les performances (à moins que vous ne fassiez que du prototypage). Le but n'est pas de paralyser d'autres éléments plus importants à ce stade du développement - tels que la flexibilité, la fiabilité, etc. Choisissez des optimisations simples et sûres - choisissez les éléments que vous souhaitez limiter et ceux que vous gardez libres; garder une trace des coûts. Devez-vous utiliser le typage fort? La plupart des jeux ont fonctionné correctement. combien cela vous coûterait-il de supprimer cela si vous trouviez des utilisations intéressantes de la flexibilité pour gamemplay?

Il est beaucoup plus difficile de modifier le code optimisé, en particulier le code "intelligent". C’est toujours un choix qui améliore certaines choses et aggrave d’autres (par exemple, vous pouvez échanger du temps CPU pour utiliser de la mémoire). Lorsque vous faites ce choix, vous devez être conscient de toutes les implications - elles peuvent être désastreuses, mais elles peuvent aussi être utiles.

Par exemple, les commandants Keen, Wolfenstein et Doom ont été construits sur un moteur de rendu optimisé. Chacun avait son "truc" qui permettait au jeu d’exister (des optimisations supplémentaires ont également été développées au fil du temps, mais ce n’est pas important ici). C'est bien . Il est normal d’optimiser fortement le cœur même du jeu, la pensée qui rend le jeu possible; surtout si vous explorez de nouveaux territoires où cette fonctionnalité optimisée vous permet de prendre en compte des conceptions de jeu peu explorées. Les limitations introduites par l'optimisation peuvent également vous donner un jeu intéressant (par exemple, les limites du nombre d'unités dans les jeux RTS ont peut-être été créées pour améliorer les performances, mais elles ont également un effet de gameplay).

Mais notez que dans chacun de ces exemples, le jeu ne pourrait exister sans l'optimisation. Ils n'ont pas commencé avec un moteur «entièrement optimisé» - ils ont commencé par la simple nécessité et ont progressé. Ils développaient de nouvelles technologies et les utilisaient pour créer des jeux amusants. Et les astuces moteur étaient limitées à une partie du code aussi petite que possible - les optimisations plus lourdes n’étaient introduites que lorsque le gameplay était essentiellement terminé ou qu’il permettait à une nouvelle fonctionnalité intéressante de se faire jour.

Maintenant, considérons un jeu que vous voudrez peut-être faire. Y at-il vraiment un miracle technologique qui fait ou défait ce jeu? Peut-être envisagez-vous un jeu en monde ouvert sur un monde infini. Est-ce vraiment la pièce centrale du jeu? Le jeu ne fonctionnerait-il tout simplement pas sans cela? Vous pensez peut-être à un jeu où le terrain est déformable sans limite, avec une géologie réaliste, etc. pouvez-vous le faire fonctionner avec une portée plus petite? Cela fonctionnerait-il en 2D au lieu de 3D? Obtenez quelque chose d'amusant dès que possible - même si les optimisations peuvent vous obliger à retravailler une énorme partie de votre code existant, cela peut en valoir la peine; et vous pourriez même vous rendre compte que rendre les choses plus grandes ne rend pas le jeu meilleur.

Comme exemple de jeu récent avec de nombreuses optimisations, je citerai Factorio. Les courroies sont un élément essentiel du jeu. Elles sont plusieurs milliers et transportent de nombreux morceaux de matériaux individuels tout autour de votre usine. Le jeu a-t-il commencé avec un moteur à courroie fortement optimisé? Non! En fait, la conception de la ceinture originale était presque impossible à optimiser - elle a en quelque sorte simulé physiquement les éléments de la ceinture, ce qui a créé des choses intéressantes que vous pouvez faire (c'est ainsi que vous obtenez un gameplay "émergent" - un gameplay qui surprend concepteur), mais cela signifiait que vous deviez simuler chaque élément de la ceinture. Avec des milliers de courroies, vous obtenez des dizaines de milliers d’éléments simulés physiquement. Même en les supprimant et en les laissant faire le travail, vous réduisez le temps de calcul associé de 95 à 99%. même sans considérer des choses comme la localité de la mémoire. Mais ce n’est utile que de le faire lorsque vous atteignez réellement ces limites.

Presque tout ce qui avait un rapport avec les courroies devait être refait pour permettre leur optimisation. Et les courroies devaient être optimisées, car il fallait beaucoup de courroies pour une grande usine, et les grandes usines sont l'une des attractions du jeu. Après tout, si vous ne pouvez pas avoir de grandes usines, pourquoi avoir un monde infini? C'est drôle, vous devriez demander - les premières versions ne le faisaient pas :) Le jeu a été retravaillé et remodelé de nombreuses fois pour arriver là où il est maintenant - y compris un remake à 100%, quand ils se sont rendus compte que Java n'était pas la solution idéale. jeu comme celui-ci et basculé en C ++. Et cela a bien fonctionné pour Factorio (bien que ce fût une bonne chose, il n’était pas optimisé dès le départ - en particulier s’il s’agissait d’un projet de loisir, qui aurait tout simplement échoué sinon par manque d’intérêt).

Mais la chose est, il y ade nombreuses choses que vous pouvez faire avec une usine à portée limitée - et de nombreux jeux l'ont montré. Les limites peuvent être encore plus stimulantes pour le plaisir que les libertés; Spacechem serait-il plus amusant si les "maps" étaient infinies? Si vous aviez commencé avec des "ceintures" fortement optimisées, vous seriez pratiquement obligé de suivre cette voie; et vous ne pouvez pas explorer d'autres directions de conception (comme voir ce que vous pouvez faire d'intéressant avec des bandes transporteuses simulées par la physique). Vous limitez votre potentiel de conception. Cela ne semble peut-être pas comme cela parce que vous ne voyez pas beaucoup de jeux inachevés, mais le plus difficile est de vous amuser correctement - pour chaque jeu amusant que vous voyez, il y en a probablement des centaines qui ne pouvaient tout simplement pas y arriver et ont été mis au rebut (ou pire, libéré sous forme de désordres horribles). Si l'optimisation vous aide à le faire, allez-y. Si ce n'est pas ... c'est probablement prématuré. Si vous pensez que certains mécanismes de jeu fonctionnent très bien, mais que des optimisations sont nécessaires pour vraiment briller, continuez. Si vous n'avez pas de mécanique intéressante,ne les optimise pas . Trouvez l’amus d’abord - vous constaterez que la plupart des optimisations n’aident pas, et sont souvent désastreuses.

Enfin, vous avez un grand jeu amusant. Est-il judicieux d'optimiser maintenant ? Ha! Ce n'est toujours pas aussi clair que vous pourriez le penser. Y a-t-il quelque chose d' amusantvous pouvez faire à la place? N'oubliez pas que votre temps est encore limité. Tout demande un effort et vous souhaitez concentrer vos efforts là où cela compte le plus. Oui, même si vous créez un "jeu gratuit" ou un jeu "open source". Regardez comment le jeu est joué; remarquez où la performance devient un goulot d'étranglement. Est-ce que l’optimisation de ces lieux rend plus amusant (comme la construction d’usines toujours plus grandes, toujours plus enchevêtrées)? Est-ce que cela vous permet d'attirer plus de joueurs (par exemple avec des ordinateurs plus faibles ou sur différentes plates-formes)? Vous devez toujours prioriser - recherchez l'effort pour obtenir un ratio. Vous trouverez probablement beaucoup de fruits faciles à jouer rien qu'en jouant à votre jeu et en regardant les autres jouer. Mais notez la partie importante - pour y arriver, vous avez besoin d'un jeu . Concentre-toi sur ça.

Cerise sur le gâteau, considérez que l'optimisation ne se termine jamais. Ce n'est pas une tâche avec une petite coche que vous terminez et passez à d'autres tâches. Il y a toujours "une optimisation de plus" que vous pouvez faire, et une grande partie de tout développement consiste à comprendre les priorités. Vous ne faites pas l'optimisation pour des raisons d'optimisation - vous le faites pour atteindre un objectif particulier (par exemple, "200 unités à la fois sur l'écran sur un Pentium à 333 MHz" est un excellent objectif). Ne perdez pas de vue l'objectif terminal simplement parce que vous vous concentrez trop sur les objectifs intermédiaires qui pourraient même ne plus être une condition préalable à l'objectif terminal.

Beaucoup de réponses semblent se focaliser beaucoup sur l'aspect performance de "l'optimisation", alors que moi-même j'aime bien regarder l'optimisation et toute l'épreuve de l'optimisation trop tôt à un niveau plus abstrait.

Humour moi comme je tente d'élaborer sur mon point de vue avec l'aide de polyominos.

Supposons que nous ayons des limites fixes définies par le framework ou le moteur avec lequel nous travaillons.

Nous procédons ensuite à la création de notre première couche / module du jeu comme suit.

À l'avenir, nous construisons notre deuxième couche / module.

À ce stade, vous remarquerez peut-être qu'il y a un peu d'espace disponible entre les deux modules et nous pourrions être tentés de l'optimiser pour tirer pleinement parti des limites qui nous ont été attribuées.

Parfait, maintenant l’application utilise pleinement les ressources dont nous disposons, l’application est meilleure, non?

Nous procédons à la construction de la troisième couche / module de notre application et nous réalisons soudainement (peut-être même que nous ne pouvions pas prévoir lors de la planification initiale) que la troisième couche / module ne fonctionne pas pour nous.

Nous recherchons une alternative, nous en trouvons une, et à la fin, cela nous oblige également à changer le 2ème module de notre application car il est incompatible avec notre 3ème module nouvellement sélectionné. (Heureusement, c'est un peu compatible avec notre 1er module, nous n'avons donc pas à tout réécrire à partir de zéro.)

Nous avons donc tout mis ensemble

Hmm, pouvez-vous voir ce qui s'est passé?

En optimisant trop tôt, nous avons en fait aggravé la situation en termes d’efficacité, car nous n’avons pas optimisé ce que nous avons finalement obtenu.

Et si nous avions voulu ajouter des modules supplémentaires ou des friandises supplémentaires par la suite, nous n’aurions peut-être plus la capacité de les faire à ce stade.

Et ajuster le niveau le plus bas de notre système n’est plus aussi faisable car il a été enterré sous toutes les autres couches.

Si, toutefois, nous avions choisi d'attendre avec notre envie de l'optimiser immédiatement, nous aurions abouti à quelque chose comme ceci:

Et maintenant, si nous procédons à l'optimisation à ce stade, nous obtenons quelque chose de satisfaisant à examiner.

J'espère qu'au moins certains d'entre vous se sont autant amusés à lire ceci qu'à moi :) et si vous sentez maintenant que vous avez une meilleure compréhension du sujet, tant mieux.

Argent.

Cela revient à cela. Argent. Puisque le temps, c'est de l'argent *, plus vous consacrez de temps à des activités pour lesquelles il n'est pas garanti que vous générerez plus d'argent (vous ne pouvez pas considérer ces activités comme des investissements ), plus vous risquez de perdre de l'argent et moins vous gagnerez d'argent. le jeu.

Voici quelques effets secondaires potentiels de l'optimisation trop tôt et les raisons pour lesquelles vous devriez l'éviter:

• Vos collègues vous détestent parce que vous jouez dans votre bac à sable avec vos jouets alors qu'ils travaillent dur pour obtenir des fonctionnalités.
• Les retards déplaisent aux échelons supérieurs et obligent l’équipe à rater les dates de livraison, ce qui entraîne la sortie du jeu au printemps au lieu d’avant les fêtes de fin d’année, ce qui fait que le jeu ne se vend pas assez. Et pour cette raison, le siège décide de fermer le studio, vous rendant effectivement sans emploi. Et pas de travail, pas d'argent. (Et comme personne ne vous aime parce que vous avez passé trop de temps à l'optimisation précoce, personne ne veut écrire une critique positive de votre travail pour vous sur LinkedIn, ce qui vous gardera sans argent plus longtemps.)

^{* D'autres réponses ont assez bien mis en évidence la partie "temps"}

En guise de remarque, en général , l’expérience permet de déterminer ce qui est optimisation prématurée et ce qui n’est pas prématuré et ce qui a une valeur pour l’entreprise et ce qui n’en a pas.

Par exemple, si vous avez travaillé sur le jeu A et si, à la fin du projet, vous vous rendez compte que la fonctionnalité XYZ était particulièrement lourde dans votre boucle de jeu, vous commencez à travailler sur le jeu B qui possède exactement la même fonctionnalité réécrire la fonctionnalité et l’optimiser dès le départ n’est pas vraiment une optimisation prématurée, car vous savez que ce sera un goulot d’étranglement si rien n’est fait.

L'optimisation est, par définition, le processus d'augmentation de l'efficacité d'une solution jusqu'au point où elle perd de son efficacité. Ce processus implique alors une réduction de l'espace de la solution.

À un stade précoce du développement logiciel, il peut toujours y avoir des "exigences cachées": si vous réduisez trop l’espace de votre solution, vous risquez de vous retrouver dans une situation dans laquelle vous ne pourrez pas satisfaire à une "exigence cachée" lorsqu’elle apparaîtra. à un stade ultérieur du développement, vous obligeant alors à modifier l’architecture en ajoutant de cette manière une instabilité et un tas de comportements indésirables.

L'idée est alors de faire fonctionner la solution entière et ensuite seulement, lorsque toutes les exigences sont définies et implémentées, resserrer le code. Vous verrez alors que de nombreuses optimisations que vous auriez légèrement mises en œuvre à la fois lors du codage, ne sont plus réalisables en raison de l’interaction avec les dernières exigences.

L'espace réel de la solution est toujours plus grand que celui auquel nous nous attendions au départ car nous ne pouvons pas avoir une connaissance parfaite d'un système très complexe.

Faites-le fonctionner en premier. Puis serrez les cordes.

En résumé, très souvent, l'optimisation précoce entraîne un gaspillage d'efforts si vous voulez changer les choses plus tard, puis il s'avère que vous avez optimisé les structures de code facilement modifiables en un niveau beaucoup plus bas, et vous devez maintenant le ramener à un niveau élevé. approche par niveau et d’optimiser à nouveau le résultat.

Il s'agit d'une erreur courante pour les développeurs débutants qui aiment se concentrer sur le plaisir "d'avoir fait un travail utile", comme l'optimisation, sans se demander si le moment est propice pour le faire. En acquérant de l'expérience en programmant de gros projets comme des jeux, vous saurez quand il sera nécessaire d'optimiser la base de code existante et quand il sera trop tôt. N'ayez pas peur de faire cette erreur, vous ne pourrez que tirer profit de son apprentissage.

En général, n'optimisez que si vous ne pouvez vraiment pas travailler avec la construction de développement dès maintenant. Par exemple, si vous créez et supprimez des millions d'objets 60 fois par seconde.

Donc, je dirais qu’il est bon, en termes d’apprentissage, d’optimiser au début quelques fois: p

L'optimisation vise à optimiser le fonctionnement de l'ordinateur sur le code, tandis que le développement nécessite que le programmeur fonctionne mieux sur le code.

L'optimisation ne fait pas ressortir les idées. Cela fait moins travailler l'ordinateur et le programmeur davantage.

Bien sûr, il existe différentes catégories, comme pour concevoir une voiture. Il n’ya rien de mal à optimiser un moteur avant de construire votre premier châssis, mais l’optimiser avant que vous ne connaissiez la forme du moteur risque de vous faire perdre du temps. La modularité et les spécifications peuvent permettre à un certain nombre d’endroits d’être optimisés avant même que le produit ne soit assemblé.

Je ne suis absolument pas d'accord avec toutes ces affirmations selon lesquelles le code ne devrait pas être optimisé au tout début. Cela dépend de votre stade. Si c'est MVP - prototype et que vous essayez simplement de regarder le jeu qui dure 1 à 2 semaines, vous êtes prêt à réécrire tout ce que vous avez déjà écrit. Oui, l'optimisation n'a pas d'importance. Mais si vous travaillez déjà sur un jeu dont vous savez qu'il sortira, le code devrait toujours être optimisé. Les histoires que les gens racontent sur les nouvelles fonctionnalités et les choses qui pourraient être ajoutées sont des idées fausses. C'est une architecture de code mal conçue plutôt qu'un code optimisé. Vous n'avez pas besoin de réécrire quoi que ce soit pour ajouter de nouveaux éléments si vous avez une bonne conception de code.

Par exemple, si vous avez un algorithme A * pathfinding, ne serait-il pas préférable de l'écrire de la manière la plus optimale possible? Plutôt que de changer plus tard la moitié du code que vous avez parce que vous avez dû apporter des modifications à l'algorithme, car il a maintenant besoin d'une autre méthode d'appels et de rappels? Et si vous avez déjà un code optimisé dès le départ, vous gagnerez beaucoup de temps. Parce que vous pouvez dessiner vous-même les relations entre les objets et leur interaction, au lieu de créer aveuglément des tonnes de nouveaux scripts et d'établir toutes les connexions immédiatement - cela conduit à un code de sphagetti peu clair.

La dernière chose que je veux ajouter est que plus tard, même si vous ne voulez plus créer le jeu, vous disposez de votre algorithme A * optimisé que vous pourrez utiliser pour vos prochains jeux. Réutilisabilité. Par exemple, de nombreux jeux ont un inventaire, une recherche de chemin, une génération de procédures, des interactions entre NPC, un système de combat, une IA, une interaction d’interface, une gestion des entrées. Maintenant, vous devriez vous demander: "Combien de fois ai-je réécrit ces éléments à partir de zéro?" Ils sont 70-80% du jeu. Avez-vous vraiment besoin de les réécrire tout le temps? Et si elles ne sont pas optimisées?