Pourquoi reste-t-il des ressources supplémentaires dans le jeu final?

Je venais de lire ce qui a été découvert dans les fichiers de No Man's Sky, beaucoup de choses qui n'étaient pas utilisées ou pertinentes pour le jeu. J'ai également lu il y a peu de temps les paramètres E3 laissés dans les fichiers Watch Dogs. Pourquoi les développeurs de jeux laissent-ils des fichiers anciens et inutilisés dans le jeu final?

Cela prend sûrement de l'espace supplémentaire sur un disque et signifie que plus de données doivent être téléchargées si vous téléchargez le jeu?

De plus, les développeurs n'ont-ils pas peur de ce que les gens pourraient trouver?

Les jeux majeurs utilisent ce qu'on appelle un pipeline de construction. C'est comme un autre ensemble d'outils qui gère la construction du contenu du jeu pour toutes les différentes distributions. Les jeux multi-plateformes comme No Man's sky et Watch_Dogs utilisent très certainement des ressources différentes pour les différentes plateformes. Donc, selon moi, il y a deux réponses possibles à votre question.

1. Les développeurs ont oublié de retirer certains actifs du pipeline et ils ont été fournis avec le jeu réel.

2. Les développeurs ont intentionnellement laissé certains actifs "inutilisés" dans le jeu pour une utilisation ultérieure lors d'un patch ou d'une mise à jour, car ils n'ont pas pu respecter la date limite. Exemple Devil's Pit de The Witcher 3.

Il peut être plus difficile que vous ne le pensez de trouver tout le contenu référencé dans un grand jeu sur lequel plusieurs personnes ont travaillé. Même lorsqu'il existe des outils explicites en place pour aider (nous avons construit de tels outils à ArenaNet, toute personne qui utilise Unreal a accès à la version d'Unreal de ces outils, Bungie a des outils qui font la même chose et ont même parlé d'eux, et cetera)

Il existe plusieurs façons de référencer le contenu qui peuvent vaincre de tels systèmes, généralement simplement en référençant le contenu par quelque chose que le système ne peut pas suivre (comme la création d'une référence implicite ou codée en dur dans le code à un actif).

Même en supposant que vous ayez résolu le problème de trouver toutes les inter-références de contenu, vous avez le problème de ne pas être en mesure de dire si quelque chose est réellement utilisé . Peut-être qu'un élément est référencé quelque part dans un script, mais le volume de déclenchement de ce script est mal placé à l'intérieur d'un mur et le contenu ne peut donc jamais apparaître dans le jeu. Il est également assez difficile de tester cela de manière exhaustive.

Lorsque automatisé (ou automat capables ) méthodes de détection et de filtrage de contenu utilisé échouent, il vous reste la voie ancienne: intervention humaine. Les humains font des erreurs, de mauvaises hypothèses (ils peuvent penser qu'un fichier est toujours utilisé même si ce n'est pas parce que quelqu'un d' autre a fait un changement), et oui même parfois choisissent de laisser intentionnellement du contenu non pertinent dans le jeu comme des oeufs de Pâques. C'est juste la faillibilité humaine naturelle qui mène à cela.

Ce n'est généralement pas une quantité de contenu suffisante pour vraiment déplacer l'aiguille beaucoup pour les optimisations de charge ou de taille de fichier. Il existe également des outils pour signaler les actifs les plus importants ou les plus lents dans toute grande chaîne de construction ou moteur, mais l'objectif est de réduire l'impact des principaux contrevenants et de ne pas trouver et localiser chaque octet gaspillé. Habituellement.

Ce qui manque dans les autres réponses, c'est que cela n'a rien à voir avec les jeux. Cela affecte toutes les applications.

Il y a toujours des fichiers et du code qui ne seront pas utilisés dans un programme raisonnablement complexe. Cela se produit en raison des 2 choses suivantes:

• Les programmes évoluent avec le temps.
• Cela demande un effort pour déterminer si un morceau de code ou un fichier n'est plus utilisé.
  • Si vous supprimez des éléments sans dépenser cet effort, le comportement de l'application devient imprévisible

Ajoutant à / ehancing Uri Popov de réponse :

3. Les programmes peuvent installer des packages de mises à jour qui contiennent de nouvelles versions améliorées des fichiers d'actifs existants et une mise à jour du programme lui-même. Pour ma part, je n'écrase pas les versions précédentes des fichiers de ressources, car je veux permettre un retour à une version antérieure du programme (imaginez, par exemple, la panique d'avoir distribué une mise à jour totalement désastreuse :-)). La version originale du programme utilise peut-être texture_0.dds et la version mise à jour texture_1.dds (donc texture_0.dds n'est plus nécessaire). L'écrasement (en utilisant un seul nom) interdirait la suppression de la mise à jour du programme, c'est-à-dire le retour à la version d'origine, à moins qu'il n'y ait aussi la mécanique délicate d'écraser les fichiers d'actif plus récents avec les plus anciens. Et ce n'est pas quelque chose que quiconque veut soutenir.

Modifier:

Réagissant sur un commentaire à la question d'origine,

Personne n'a pensé à les supprimer

4. Je dirais que personne n'a osé les supprimer. Que se passe-t-il si le jeu ne dispose pas d'une capture d'erreur suffisante (par erreur, ignorance, erreur, personne clé a quitté l'entreprise, etc.) au point de chargement de ce fichier X (aujourd'hui manquant), et que le problème n'a pas été découvert malgré des tests intenses? Disons que le chargement ne se produit que "tous les 3 fois", uniquement au niveau 35 sur 36, que vous n'atteignez qu'en 4 semaines de jeu intense :-). La perte de réputation due à l'écrasement d'un logiciel est un phénomène brutal qui pourrait dans le pire des cas se retrouver dans une entreprise en faillite. Mieux vaut ne pas toucher ce fichier :-).

Pourquoi les développeurs de jeux laissent-ils des fichiers anciens et inutilisés dans le jeu final?

Cela prend sûrement de l'espace supplémentaire sur un disque et signifie que plus de données doivent être téléchargées si vous téléchargez le jeu?

De plus, les développeurs n'ont-ils pas peur de ce que les gens pourraient trouver?

Les développeurs de jeux laissent des fichiers inutilisés dans le jeu final car ils ne veulent pas dépenser l'effort pour rechercher et supprimer tous les fichiers inutilisés. Après tout, les jeux se déroulent très bien avec un peu de matériel supplémentaire et le temps c'est de l'argent. Le nettoyage augmente les coûts (selon l'automatisation de cette opération).

Bien que cela prenne plus d'espace et signifie que plus de données doivent être téléchargées, ce n'est généralement pas le problème des développeurs et même les clients ne se soucient généralement pas des tailles de téléchargement légèrement plus grandes.

Vous ne savez pas si les développeurs doivent avoir peur de tout ce que les gens pourraient trouver? Pourquoi devraient-ils? Tant qu'il n'y a rien de compromettant dans les fichiers supplémentaires (vraiment de mauvaises illustrations, des blagues sur leurs patrons ou les clients, ...) ils ne s'en soucient probablement pas beaucoup. Bien que dans certains cas, ils ont réellement peur de ce que les joueurs pourraient détecter dans les actifs.

Il a été laissé entendre, mais il n'a pas été complètement abordé par les autres réponses: tout se résume au coût, et certains des coûts sont plus difficiles que vous ne le pensez.

Le coût le plus évident est que quelqu'un doit les supprimer. Maintenant, vous pouvez simplement mettre un stagiaire sur l'affaire et lui faire parcourir les fichiers et ainsi de suite pour supprimer ceux qui ne sont pas nécessaires dans le jeu réel. Mais tout de même, vous devez payer pour cela et, même si vous ne le faites pas (parce que vous êtes un monstre qui ne paie pas de stagiaires), vous auriez pu faire en sorte que ce stagiaire fasse quelque chose d'utile comme commander une pizza pour l'équipe de développement, donc cela vous coûte toujours.

Le coût le moins évident est que la ressource que vous êtes sur le point de supprimer a été mise pour une raison: êtes-vous absolument sûr que la raison est obsolète? Bien sûr, vous avez écrit ce code pour une démo et n'en avez plus besoin, mais est-ce tout à fait vrai? Avez-vous écrit une fonction utile que vous avez oublié de migrer vers les autres bibliothèques? Est-ce que Stacey a fait un graphique vraiment cool pour la démo qui s'est retrouvée dans le vrai jeu? Un simulateur interne utilise-t-il toujours l'ancien niveau que vous avez utilisé pour les tests?

Faire des jeux est une affaire. Même si ce n'est pas une entreprise lucrative, c'est toujours une entreprise avec des ressources limitées. Chaque décision nécessite une analyse coûts-avantages, même si vous ne rédigez pas d'analyses de rentabilisation pour chacune. Et le simple fait est que le coût de laisser ces actifs dans le jeu est un téléchargement légèrement plus important, et les avantages sont un risque considérablement réduit de quelque chose qui explose juste avant la sortie.

Tous ces points d'interrogation dans le paragraphe "moins évident" représentent une incertitude. Tu ne sais pas. Et lorsque vous dirigez une entreprise, vous devez échanger vos inconnus contre des connus. Et ce que l'on sait, c'est que le package que vous avez créé a réussi les tests, même s'il a un peu de ballonnement.

Il y a d'autres coûts potentiels tels que des fuites d'informations autour du processus de développement qui pourraient potentiellement être utilisés pour dériver des hacks, mais vous avez réussi le processus de test en l'état, vous ne devriez pas vraiment vous inquiéter à ce sujet.

tl; dr: Personne ne remarquera un téléchargement 4% plus important, mais ils remarqueront si vous avez interrompu le jeu en supprimant les fichiers nécessaires.