Por que os ativos extras são deixados no jogo final?

Eu estava lendo sobre o que foi descoberto nos arquivos do No Man's Sky, muitas coisas que não foram usadas ou relevantes para o jogo. Também li há pouco sobre as configurações do E3 deixadas nos arquivos do Watch Dogs. Por que os desenvolvedores de jogos deixam arquivos antigos e não utilizados no jogo final?

Certamente isso ocupa apenas espaço extra em um disco e significa que mais dados devem ser baixados se você baixar o jogo?

Além disso, os desenvolvedores não têm medo do que as pessoas podem encontrar?

Jogos principais usam algo chamado pipeline de construção. É como outro conjunto de ferramentas que lida com a criação do conteúdo do jogo para todas as diferentes distribuições. Jogos multiplataforma, como o céu de No Man e o Watch_Dogs, definitivamente usam ativos diferentes para as diferentes plataformas. Então, do jeito que eu vejo, há duas respostas possíveis para sua pergunta.

1. Os desenvolvedores se esqueceram de remover certos ativos do pipeline e foram empacotados com o jogo real.

2. Os desenvolvedores deixaram intencionalmente alguns recursos "não utilizados" no jogo para uso posterior durante um patch ou atualização, porque não conseguiram cumprir o prazo. Exemplo do Poço do Diabo de The Witcher 3.

Pode ser mais difícil do que você pensa encontrar todo o conteúdo referenciado em um jogo grande que é trabalhado por várias pessoas. Mesmo quando existem ferramentas explícitas para ajudar (nós construímos essas ferramentas na ArenaNet, quem usa o Unreal tem acesso à versão dessas ferramentas da Unreal, a Bungie tem ferramentas que fazem a mesma coisa e até falou sobre elas etc.)

Existem várias maneiras pelas quais o conteúdo pode ser referenciado que pode derrotar esses sistemas, geralmente simplesmente referenciando o conteúdo por algo que o sistema não pode rastrear (como criar uma referência implícita ou codificada no código para algum ativo).

Mesmo assumindo que você resolveu o problema de encontrar todas as inter-referências de conteúdo, você tem o problema de não saber se algo está realmente sendo usado . Talvez algum recurso seja referenciado em um script em algum lugar, mas o volume do acionador desse script seja colocado incorretamente dentro de uma parede e, portanto, o conteúdo nunca poderá aparecer no jogo. Testar isso exaustivamente também é bastante difícil.

Quando automatizado (ou caixas automáticas capazes ) métodos para detectar e filtrar conteúdo não utilizado falhar, você é deixado com a maneira antiga: intervenção humana. Os seres humanos cometem erros, suposições ruins (eles podem pensar que um arquivo é usado ainda mesmo que ele não é porque alguém outra fez uma mudança), e sim mesmo, por vezes, optar por deixar intencionalmente conteúdo irrelevante no jogo como ovos de Páscoa. É apenas a falibilidade humana natural que leva a isso.

É normalmente não uma quantidade suficiente de conteúdo para realmente mover a agulha muito para otimizações do tamanho da carga ou de arquivo. Também existem ferramentas para relatar os ativos maiores ou mais lentos de qualquer grande cadeia ou mecanismo de construção, mas o foco é reduzir o impacto dos principais infratores e não encontrar e localizar todos os bytes desperdiçados. Geralmente.

O que falta nas outras respostas é que isso não tem nada a ver com jogos. Isso afeta todos os aplicativos.

Sempre existem arquivos e códigos que não serão usados ​​em nenhum programa razoavelmente complexo. Isso acontece devido às duas coisas a seguir:

• Os programas evoluem com o tempo.
• É necessário esforço para descobrir se algum pedaço de código ou arquivo não está mais sendo usado.
  • Se você remover coisas sem gastar o referido esforço, o comportamento do aplicativo se tornará imprevisível

Somando-se / ehancing Uri Popov 's resposta :

3. Os programas podem instalar pacotes de atualizações que contêm versões novas e aprimoradas dos arquivos de ativos existentes e uma atualização para o próprio programa. De minha parte, não sobrescrito versões anteriores dos arquivos de ativos, porque quero permitir um fallback para uma versão anterior do programa (imagine, por exemplo, o pânico de ter distribuído uma atualização totalmente desastrosa :-)). A versão original do programa pode estar usando texture_0.dds e a textura texture_1.dds atualizada (portanto, texture_0.dds não é mais necessário). A substituição (usando apenas um único nome) proibiria a remoção da atualização do programa, ou seja, o fallback da versão original, a menos que houvesse também a mecânica complicada de sobrescrever arquivos de ativos mais recentes por arquivos mais antigos. E isso não é algo que alguém queira apoiar.

Editar:

Reagindo a um comentário da pergunta original,

Ninguém se lembrou de excluí-los

4. Eu diria que ninguém se atreveu a excluí-los. O que acontece se o jogo não apresentar interceptação de erro suficiente (por engano, ignorância, erro, pessoa-chave deixou a empresa etc.) no ponto de carregamento do arquivo X (agora ausente) e o problema não foi descoberto, apesar dos testes intensos? Digamos que o carregamento ocorra apenas "a cada 3 vezes", apenas no nível 35 de 36, que você alcança apenas em 4 semanas de jogos intensos :-). A reputação perdida ao travar um software é um fenômeno brutal e, na pior das hipóteses, pode acabar em uma empresa falida. Melhor não tocar nesse arquivo :-).

Por que os desenvolvedores de jogos deixam arquivos antigos e não utilizados no jogo final?

Certamente isso ocupa apenas espaço extra em um disco e significa que mais dados devem ser baixados se você baixar o jogo?

Além disso, os desenvolvedores não têm medo do que as pessoas podem encontrar?

Os desenvolvedores de jogos deixam arquivos não utilizados no jogo final, porque não desejam gastar o esforço para encontrar e remover todos os arquivos não utilizados. Afinal, todos os jogos funcionam muito bem com um pouco de material extra e tempo é dinheiro. A limpeza aumenta os custos (dependendo de como isso acontece automaticamente).

Embora exija espaço extra e signifique que mais dados devem ser baixados, esse geralmente não é o problema dos desenvolvedores e mesmo os clientes geralmente não se importam muito com tamanhos de download um pouco maiores.

Não tem certeza se os desenvolvedores precisam ter medo de algo que as pessoas possam encontrar? Por que eles deveriam? Contanto que não haja nada comprometedor nos arquivos extras (obras de arte muito ruins, piadas sobre seus chefes ou clientes, ...) eles provavelmente não se importam muito. Embora em alguns casos eles tenham medo do que os jogadores possam detectar nos ativos.

Isso foi sugerido, mas não foi totalmente abordado pelas outras respostas: tudo se resume ao custo, e alguns dos custos são mais complicados do que você imagina.

O custo mais óbvio é que alguém precisa excluí-los. Agora você pode simplesmente colocar um estagiário no caso e fazê-lo procurar nos arquivos e outros enfeites para remover os que não são necessários no jogo. Mas, ainda assim, você precisa pagar por isso e, mesmo que não o faça (porque você é um monstro que não paga estagiários), ainda assim o estagiário faria algo útil como pedir pizza para a equipe de desenvolvimento, então ainda lhe custa.

O custo menos óbvio é que o recurso que você está prestes a remover foi colocado por um motivo: você tem certeza absoluta de que o motivo está obsoleto? Claro, você escreveu este código para uma demonstração e não precisa mais dele, mas isso é totalmente verdade? Você escreveu uma função útil que esqueceu de migrar para as outras bibliotecas? Stacey fez um gráfico muito legal para a demo que acabou no jogo real? Um simulador interno ainda faz uso do nível antigo que você usou para testar?

Fazer jogos é um negócio. Mesmo que não seja um negócio lucrativo, ainda é um negócio com recursos limitados. Toda decisão requer uma análise de custo-benefício, mesmo se você não escrever casos de negócios para cada um. E o simples fato é que o custo de deixar esses ativos no jogo é um download um pouco maior e os benefícios são um risco significativamente reduzido de algo explodir logo antes do lançamento.

Todos esses pontos de interrogação no parágrafo "menos óbvio" representam incerteza. Você simplesmente não sabe. E quando você administra uma empresa, precisa trocar suas incógnitas por conhecidas. E o que se sabe é que o pacote que você construiu passou no teste, mesmo que tenha um pouco de inchaço.

Existem outros custos em potencial, como vazamento de informações em todo o processo de desenvolvimento que poderiam ser usados ​​para derivar hacks, mas você passou pelo processo de teste como está, não deveria se preocupar com isso.

tl; dr: ninguém notará um download 4% maior, mas eles perceberão se você interrompeu o jogo removendo os arquivos necessários.