No QuickQuest desta semana, Gilliard Lopes continua a discussão sobre o processo de desenvolvimento de games AAA falando sobre a fase de Pós-Produção. Faça perguntas e sugira assuntos para os próximos QuickQuests pelo e-mail contato@thepodquest.com ou no Twitter @ThePodQuest.
Ouça diretamente no player abaixo:
Ou no link a seguir:
QuickQuest #06: Alfa, Beta, Gold!
(botão direito, depois "salvar como" para baixar)
Ou ainda, adicione o feed e tenha todos os episódios quando quiser!
http://feeds.feedburner.com/doublejump/podquest
No iTunes, vá em "Advanced - Subscribe to Podcast" e cole o endereço acima.
Ouça diretamente no player abaixo:
Ou no link a seguir:
QuickQuest #06: Alfa, Beta, Gold!
(botão direito, depois "salvar como" para baixar)
Ou ainda, adicione o feed e tenha todos os episódios quando quiser!
http://feeds.feedburner.com/doublejump/podquest
No iTunes, vá em "Advanced - Subscribe to Podcast" e cole o endereço acima.
8 comentários:
Quickquest mto bom!! Mta informação mas na medida certa!
O processo de produção de um game é realmente interessante, diferente do que se imagina quando se está por fora.
Parabéns mais uma vez.
Abraços!
Ps: Pra quem quer saber a música desse Quickquest é do Street of Rage 1, a primeira fase.
Pessoal,
Em primeiro lugar, parabéns pela escolha da trilha sonora. Acho que essa trilha ainda é o melhor trabalho do Yuzo Koshiro. Talvez o SOR 2 seja tão bom quanto.
Gilliard, obrigado pelas informações, sempre muito precisas e bem colocadas.
Muito sucesso pra vocês.
Um abraço,
Marcelo Martins
Olá.
Fiquei com uma dúvida.
O que acontece então com aqueles jogos que são conhecidos por seus bugs? Fallout New Vegas por exemplo que quando foi lançado teve suas notas de review reduzidas justamente por conter muitos bugs. Como esses bugs passaram por todas essas avaliações?
Grande abraço!
@Flavio
excelente pergunta. Gilliard pode vir a adicionar mais informação mas vou comentar o que eu sei.
Pelo que eu entendo,em geral, depende do escopo e objetivo do produto. Se o produto tem um escopo muito grande e pouco tempo para fazer os desenvolvedores podem tomar alguma decisão quanto aos bugs e tentar arrumar o que eles consideram o core do jogo, deixando de lado bugs em caminhos alternativos (como a maioria das side quests do Fallout).
Quando a bugs, todas as empresas focam em tirar os bugs do core do jogo, ou seja, tudo que o jogador tem contato constantemente precisa estar funcional. Por isso, se você tem um bug na sidequest numero 23 e que só abre depois de fazer X e Y, esse bug se torna menos prioritário e pode vir a passar.
Existem também testes que a Microsoft, Nintendo e a Sony (por exemplo) realizam que tem dois focos principais. Um para garantir que o produto tenha qualidade mínima para o mercado e outro que o produto respeite um conjunto de regras ,estabelecidos pela dona do console, sobre o comportamento do jogo em relação a eventos de sistema e de usuário. Por exemplo, duas coisas muito comuns e que todos vocês já podem ter vivenciado, você não pode continuar jogando o cartucho foi removido, por mais que seja possível e você não pode continuar jogando caso o controle seja desconectado. Isso já acontecia no NES, SNES.
Uma coisa que pode vir a acontecer também são um bugs em um caminho X do jogo que acaba sendo deixado de lado pela desenvolvedora. Pode ser por, por exemplo, que eh um caminho muito especifico e que , mas por alguma razão a maioria dos jogadores acaba escolhendo esse caminho, tornando ele um bug muito encontrado.
Espero que isso ajude a esclarecer.
Abraço.
Complementando a resposta muito boa do Secco para a pergunta excelente do Flavio: realmente faltou tempo pra entrar em mais detalhes sobre o processo de certificação das donas de plataforma. Tipicamente, os bug que elas procuram são aqueles que podem interromper a experiência do usuário de maneira abrupta, como crashes (o famoso "deu pau"), hangs (o jogo fica paralisado), e, principalmente, bugs que possam parecer ao usuário que o CONSOLE dele está com defeito.
Fora isso, a análise da dona da plataforma não é tão profunda assim no que diz respeito a bugs de jogo - eles não se importariam, por exemplo, se um jogador no FIFA tivesse uma velocidade absurdamente maior que os outros, o que é um bug óbvio de balanceamento, mas não parece um "defeito" da plataforma em si. Fica a cargo da própria produtora do jogo encontrar e corrigir esses defeitos, e quando eles "vazam" para o jogo final, a culpa geralmente é do desenvolvedor mesmo.
É triste mas é verdade: desenvolvedoras de games "shippam" bugs (ou seja, propositadamente deixam alguns bugs passar para o jogo final por falta de tempo). Idealmente você só faria isso em último caso, e com bugs raros ou em caminhos menos prováveis do jogador, como o Secco disse. Mas imagino que alguns projetos sejam obrigados a shippar mais bugs do que os produtores gostariam, por motivos de negócio. Essa é uma infeliz realidade, mas pelo menos me parece mais exceção do que regra.
Interessante esse episódio. :)
Quanto aos 3 dias de "espera por bugs": os programadores ficam "parados" literalmente aguardando uma luz acender e um aviso sonoro disparar para corrigir bugs? Ou nesse "tempo de espera" são feitas outras tarefas menores?
@felipowsky Geralmente ficam jogando o jogo (provavelmente ajudando a testar online no ambiente de produção) ou já trabalhando na base de código do ano seguinte (no caso do FIFA que tem todo ano né). É uma época boa pra fazer limpeza de código e protótipos de coisas que você acha interessante para o ano seguinte.
Eu particularmente fico jogando Career Mode ou online com o pessoal e tentando ter idéias para o próximo projeto.
@Felipe Augusto
então é engraçado pois é praticamente isso. Eu fiquei esperando por bugs e enquanto isso testava o Deus Ex. Na segunda semana resolvi ficar jogando até terminar hahaha, foi bacana, nunca havia sentado e jogado no ambiente de trabalho na hora do trabalho :). Depois começei a prototipar coisas, como o Gillard mencionou.
Mas se acender alguma luz, pára tudo, arruma o bug, (testa x 10) e volta fazer o que estava fazendo. É bem importante todo mundo estar relaxado mas continuar focado.
Essa etapa é interessante pois, em geral, os bugs mais fácils já foram resolvidos e se aparecer algo novo, o bug deve ser analisado e resolvido com muita calma para fazer o mínímo de mudanças no código.
É isso, abraço.
Postar um comentário