Em um episódio do QuickQuest que promete causar polêmica, Gilliard Lopes está de volta pra argumentar sobre as diferenças entre games e software em geral, utilizando um exemplo prático baseado em um problema que precisou ser resolvido durante o desenvolvimento do FIFA 12. 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 #09: Game == Software?
(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 #09: Game == Software?
(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.
15 comentários:
Podquest mais uma vez muito interessante!
Constantemente entramos nesse tipo de discussão durante meu curso. O meu professor costuma chamar de "serviço porco" ou "roubado" esse tipo de coisa,rs.
Mas, no fim, o jogo é feito para se divertir, então aquele baú que fica de decoração no fim do mapa não precisa ser todo modelado em 3D, faz um cubo e bota textura! Da mesma forma os prédios, já pensou quantos processadores seriam necessários para fazer rodar uma cidade toda modelada em 3D? Cada janela, cada tijolo? Bota textura rs.
Eu acho que no exemplo do FIFA essa solução foi mto boa e completamente aceitável, pq sinceramente, whatever a substituição, o que o player quer é trocar o jogador e continuar a partida. As vezes ele vai até no banheiro na hora da troca e nem presta atenção em todo esse trabalho,hahaha
Concordo com o Gilliard, game não é software, nao tem que ser perfeito, tem que ser bom e divertido!
Abraço para todos
Pow, muito legal saber de detalhes da produção de um AAA, sempre que possível gostaria de saber mais problemas que vocês enfrentam.
Também acho que um código bem planejado, que possa ser sempre reutilizável é muito legal. Mais no mundo real e principalmente no mundo dos jogos que tudo tem que sincronizar perfeitamente para que o jogador não perca a crença no jogo, então nesse mundo bugs como esse podem não ter o tempo necessário para uma restruturação do código. Portanto a famosa "gambiarra" pode ser mesmo a melhor alternativa lógico quando bem documentada e comentada.
Acho que esse tipo de decisão normalmente nunca partiria de um programador que não tenha uma visão de game designer. Pois é função do designer planejar o que é ou não importante para experiência do usuário. Entretanto hoje em dia vejo que os programadores estão dando com esse tipo de decisão um passo mais orgânico a frente dos programdores mecânicos de software.
Lógico, é sempre válido lembrar que no primeiro momento onde seja possível a restruturação do código, esse problema deve ser planejado. No exemplo deste pod creio que ano que vem quando forem fazer o Fifa 13 poderiam dar uma saida melhor, ou n Gilliard?
Rafael P Padovani
Pessoal, obrigado novamente pelos comments.
@Silentkill É isso mesmo, por isso é tão importante para um projeto quando todo mundo se importa com o jogo e com a experiência do usuário. Mas quando falta isso, cabe aos game designers e produtores lembrar que o entretenimento é mais importante do que o software (ou a arte, ou qualquer outra parte que compõe o jogo).
O que você disse no final também é correto, aqui mantemos uma lista de "tech tasks" que os programadores podem executar durante a transição de um FIFA para o outro ou na pré-produção do próximo.
Abraços!
Gilliard,
Rapaz, que curioso esse bug! Muito obrigado por compartilhas essas informações com a gente.
Concordo 100% com você, o que importa é o que o jogador vai ver. Às vezes, mesmo com o código "bagunçado", se o custo/benefício for bom, certamente é a melhor opção.
É necessário ter uma visão holística do jogo. Se a solução certinha vai quebrar o jogo, é claro que é melhor nem arriscar fazê-la!
E isso não acontece só nos jogos não, viu? Você não tem ideia das artimanhas que a gente usa em produção de discos para eles poderem soar "grandes", "pomposos".
Tem uns truques realmente bizarros.
O mais simples deles: praticamente nenhum som de bateria que você num disco de rock é uma bateria real, sendo tocada de verdade. Aliás, hoje em dia, nem ao vivo!!
Mas, voltando ao FIFA 12
Eu imagino que esse frame com os jogadores com os braços abertos deve ter ficado bem bizarro! Se duvidar, é tão assustador quanto os discos de vinil que você girava ao contrário e gerava mensagens satânicas!! ;)
Aliás, demorou pra alguém lançar um jogo de futebol com zumbis...
Pô galera, mas e a longo prazo? Vocês realmente acreditam que esse tipo de workaround não abre brecha para efeitos colaterais sérios, tanto quanto se houve uma mudança um pouco mais complexa no código?
Correndo o risco de chover no molhado... acredito que o culpado por esse tipo de "solução" é dos caras que definem o prazo para o lançamento :D
Quando um problema desse tipo aparecesse o ideal seria adiar a data do lançamento até obter uma versão estável do sw.
Obs.: acho que os desenvolvedores do Diablo III estão em conformidade com essa linha de pensamento hehehe
Então stdio,
temos que lembrar que existem vários tipos de bugs e no caso do exemplo do Gilliard temos um bug de apresentação. Eles poderiam ter deixado passar mas algum jogador ou reviewer poderia ver e ficar chateado. Não era um bug de altíssimo risco que pode quebrar o jogo a qualquer hora.
Se fosse um crash por concorrência, aí não teria jeito, iria precisar de mais tempo.
O prazo é sagrado, mais tempo significa mais horas de trabalho. Nesse caso, a culpa não é de ninguém, exitem tempo no budged para arrumar bugs mas nesse tipo de problema é muito difícil de perceber (poderia muito bem ter sido lançado com esse bug e 99.999% das pessoas nunca iria ver).
O bug não fica lá para sempre, afinal, todo programador é vaidoso e não quer ver gambiarra no seu código. Vai ter um TODO/FIXME nessa linha explicando o problema para quando o time estiver se preparando para o próximo projeto, aplicar o fix correto.
Esse tipo de solução é uma questão de necessidade. Fixes desse tipo existem quando se tem um prazo para entregar. Quanto mais arriscada a mudança mais tempo de testes e mais risco a empresa corre.
Agora um caso que aconteceu comigo na EIDOS. Existia um crash e para arrumar o crash tivemos que refazer toda a base do sistemas de menus que havia sido herdado de um outro projeto. Esse bug só acontecia depois de 12 passos que precisavam ser exatos. Antes de qualquer coisa eu passei 3 dias analisando o código para ver o quanto isso iria afetar no jogo, quais eram as possíveis soluções e qual seria a menos custosa, i.e, tempo de desenvolvimento + tempo de testes + regressão da feature. Acabou que não tinha como fazer uma solução simples e levamos 2 semanas refazendo o sistema e testando em 3 plataformas 5 horas seguidas antes de fazer o checkin desse fix. Por sorte, não tivemos nem um outro problema relacionado, mas veja o trabalho e a quantidade de energia necessária para esse fix? O que eu mais queria naquele dia era um "if" e "return", mas não era possível.
E isso a 3 semanas da primeira submissão. É um risco muito grande que o time assume.
Aqui fora, prazo é sagrado e quem muda prazo coloca o produto todo em risco.
Nessa hora você tem que olhar no espelho e perguntar, estou fazendo software ou estou fazendo jogo? Se você não percebe a diferença provavelmente vai colocar o produto em risco.
No final o que importa é um jogo estável com uma experiência agradável.
Bem, é isso.
Abraço.
Pois é, stdioo, o Secco tem toda razão e foi mais rápido do que eu pra responder.
Isso tudo são lições que a gente aprendeu quando começou a trabalhar em projetos que tem uma responsabilidade muito grande para a empresa, pois vendem muito e significam muitas vezes os empregos de 300 pessoas dentro do estúdio. Quando tudo isso está em jogo, decisões como uma mudança de data do lançamento em prol de fixar um bug são tratadas de maneira muito diferente.
Um jogo como o FIFA, se atrasar dois meses, perde o hype do início da temporada de futebol, e pronto, lá se vão 5 milhões de cópias, por causa de 1 bug que 5 desses 5 milhões veriam uma vez na vida. Mais ainda, o marketing de antecipação que vai sendo feito pra criar expectativa, é jogado fora porque tem que fazer de novo para o novo lançamento. Aí vem o concorrente e lança antes, etc. etc. É a diferença entre muita gente ter emprego no ano que vem, ou não ter. Pense bem nisso.
O mesmo vale pro Deus Ex, que inclusive passou por um adiamento porque chegaram à conclusão, depois de muito estudo, que valia a pena em prol da qualidade como um todo. Atrasaram pra ganhar 20%, talvez 30% em qualidade, não pra consertar meia-dúzia de bugs. Se atrasasse de novo, fudeu, vai concorrer com Battlefield 3, Modern Warfare 3, Skyrim. Como fazer marketing de uma IP como o Deus Ex no meio desses gigantes, e querer que as pessoas prestem atenção?
Empresas como a Blizzard e a id Software podem se dar ao luxo de lançar seus projetos "quando estiverem prontos" porque trabalham de maneira muito diferente. A Blizzard tem dinheiro virtualmente infinito por causa do WoW; a id é relativamente pequena, muito focada, e tem grandes reservas de dinheiro dos projetos antigos. Palmas pra eles por poderem e quererem tocar seu business dessa forma, mas não é a realidade de praticamente nenhuma outra empresa da indústria.
Fernando e Gilliard, valeu pelas replies. É muito legal ter a chance de ver o mercado da perspectiva de quem está no meio dele.
Pois então, eu já acho que Game ~= Software e que na verdade a única coisa que muda é o objetivo de negócio. E nem muda tanto assim...
Qual é o objetivo de um game? O mais básico é agradar o jogador, não é (sim, podem haver outros)? E como se faz isso? Sendo um jogo divertido, lindo, interessante, diferente e/ou diversas outras características que importam para games e gamers.
E qual é o objetivo de um software? Não é agradar ao seu cliente (que não necessariamente é o usuário final)? E isso ele faz provendo a funcionalidade esperada, sendo fácil de usar, sendo estável e etc (epa, peraí, isso não são qualidades esperadas de games também? :) ).
Eu vejo a escolha de solução no caso do bug do Fifa sendo feita de maneira igual no caso de se tratar de um sistema bancário ou um editor de texto. Você pondera todos os fatores envolvidos, incluindo o objetivo de negócio mas não limitado a apenas ele: também conta tempo de desenvolvimento, prazos, manutenção futura, impactos. E escolhe uma das alternativas que melhor se enquadrem à situação corrente.
Se um problema equivalente tivesse ocorrido com um outro software qualquer e o prazo de entrega estivesse se esgotando, também se evitaria ao máximo reescrever todo um sistema! Fariam a correção mais rápida e segura que pudessem e colocariam o mesmo TODO/FIXME no código para ser (quem sabe) corrigido para o release seguinte.
PS sobre prazo: sim, prazo é importantíssimo mas como tudo nesse mundo, "depende". Em projetos com grande investimento externo, seja de um cliente externo ou de um investidor de risco, cumprir prazos é o que garante a sobrevivência de curto prazo da empresa. São partes/pessoas envolvidas com objetivos diferentes, cada uma defendendo o que importante para sí. Mas também há o caso de você trabalhar com investimento interno, gerado pela própria empresa, e aí a situação pode ser outra, mais tranqüila (que, agradeço todo dia, é o caso da CCP). :)
Bom, não acho que esse tipo de acontecimento seja exclusividade dos jogos, já trabalhei em diversos tipos de sistemas (incluindo jogos) e todos cedo ou tarde tinham algum bug semelhante.
Inclusive num dos projetos que trabalhei que envolvia controle de medicamentos, não existia essa questão de Software, o Software tinha que funcionar, custe o que custar e certo. Se surgisse um bug na ultima hora do release e a solução não fosse das mais elegantes, mas que garantisse que o Software não daria problema, ela seria adotada. Pois ninguém quer assumir na ultima hora o risco de grandes mudanças no Software e inserir bugs novos. A não ser é claro que não exista outra alternativa, nesse caso, dependendo do software e do problema, vai ter que atrasar.
@Chuim Acho que a diferença está justamente nos objetivos mais abstratos do game: você usou palavras como "divertido" e "interessante", e não vejo um equivalente desses objetivos no caso do software.
Os objetivos de um software devem ser passíveis de serem expressados como uma função que recebe input e produz o output esperado. De fato, uma linha de R&D gigantesca dentro da computação se dedica exatamente a garantir isso antes que qualquer linha de código seja escrita! A definição de "agradar ao cliente", nesse caso, se torna um documento de requisitos, um backlog, ou seja, algo concreto, enumerável. Mesmo em processos ágeis e iterativos se procura concretizar os objetivos, mesmo que eles mudem a cada sprint.
Já nos games, o "objetivo" é muito mais difícil de enumerar. Por isso nem gosto de chamar de objetivo, porque o próposito de um game é, no geral, subjetivo. Divertir, emocionar, ser interessante: não tem backlog que defina isso. Por isso existe a figura do game designer, ele é o oráculo que tenta responder à pergunta "este jogo, com essas features, atinge o objetivo"? Claro que nem ele sabe a resposta final e derradeira, mas a subjetividade do trabalho dele na busca constante por essa resposta é parte integral do desenvolvimento de um jogo, e não vejo isso existir no caso do software.
E é justamente na hora que o "bicho pega" que essa diferença fica mais exacerbada, na minha opinião. No exemplo que eu usei no podcast, tudo bem, pode ser que uma decisão parecida fosse tomada no caso de um software. Mas existem muitos outros casos onde uma solução inusitada, que contraria os preceitos do desenvolvimento de software com qualidade, é a solução desejada pelo game designer, não necessariamente por causa de um prazo apertado. No caso dos games, isso tem que ser aceito e praticado, na minha opinião.
Acho que a discussão acabou ficando muito focada na questão do prazo, mas meu argumento sobre porque games não são software nada tem a ver com isso. Espero que dê pra entender melhor o que eu quero dizer agora. E continuem concordando e discordando por favor!
Caraca..morri de rir quando você falou "solução...cachorra!"
Mas o engraçado é que nosso cérebro não é muito bom em lidar com mais uma coisa ao mesmo tempo, então esse é um tipo de erro bem natural.
Eu mesmo caio nele mais do que gostaria, principalmente quando subestimo as situações de concorrência. Ainda mais quando estou usando uma linguagem ou ambiente que me dá soluções fáceis ( ex: o synchronized do java ou aquelas filas de tarefas do Objective-C ).
Um ponto em que eu não esperava ver tanto isso é em CPU x GPU, especialmente em smartphones...
Pois é, Daniel, multi-processamento acaba tornando a execução do programa mais complicada, e programar pra esses tipos de plataforma, ainda mais com linguages que não te ajudam muito, se torna pouco intuitivo. Os piores bugs de todo ano no FIFA sempre estão relacionados a isso, e são os mais difíceis de consertar.
Muito bom os Quickquests estou começando a minha jornada no PodQuest com eles. Me divirto muito enquanto ouço informação de qualidade para ótimas reflexões.
Tem um termo que usamos no curso na VFS, ele é. "If you can't make it fake it."
E cai como uma luva nessa história. E é uma verdade como o Gilliard falou não iria fazer diferença para o usuário final, como o problema foi resolvido, mas sim, que não "há" problema algum.
Muito bom mesmo este Quickquest em particular, assim como todos que ouvi, em breve espero comentar mais. Vocês são de fato muito bons e carísmaticos parabéns.
hugs
Postar um comentário