Metro Redux: A realidade de desenvolver jogos para PS4 e Xbox One

Penso que aquilo que conseguimos fazer com estas novas consolas foi um belo feito, tendo em conta o tempo que tivemos com os kits de desenvolvimento no estúdio - foram apenas quatro meses de experiência com a Xbox One e seis meses com a ps4 (acho que os problemas que tivemos em fazer chegar os kits de desenvolvimento a Kiev são do conhecimento geral).

Mas a verdade é que ainda não usamos todo o poder computacional que temos ao nosso dispor. Por exemplo ainda não usamos computação paralela em muitos contextos por falta de tempo e pelo facto de que o suporte para as consolas estar ainda numa fase "alfa". Isso significa que ainda ficou muita performance dentro da gaveta que podia significar melhorias visuais e de gameplay e que certamente irá ser usada assim que nos familiarizarmos mais com o hardware.

Bem, obviamente que elas não vêm com aquele hardware topo de gama que podem comprar para um PC (embora por quantidades exorbitantes de dinheiro) hoje em dia. Mas acho que são máquinas relativamente bem equilibradas em termos de hardware, hardware esse que é bastante superior ao que a maioria das pessoas tem nos seus PCs de momento, em termos de performance. E não nos esqueçamos que ao programar a um nível mais baixo, mais próximo do hardware, conseguimos o dobro da performance que aquela que teríamos ao programar num PC com especificações equivalentes. Contudo, na prática, chegar a esses níveis de performance requer algum tempo.

Mas respondendo à questão : elas poderiam durar tanto tempo como as suas antecessoras. Lembrem-se: quando a ps3 chegou às lojas, a Nvidia G80 foi lançada ao mesmo tempo, e era duas vezes mais rápida que a unidade de processamento gráfico da ps3....

Bem, uma arquitetura GPU semelhante em todas as plataformas é uma coisa muito, mesmo muito importante. A razão por detrás disso é que estes GPUs modernos são aparelhos muito complexos com picos de perda de perfomance que não são óbvios. Já não se pode dizer coisas do tipo: " Estamos limitados em termos de ULA (unidade de lógica e aritmética), ou em termos de ROP (unidade de output de renderização) ou já estamos limitados com endereçamentos de filtragem de texturas ou simplesmente limitados em termos de largura de banda". Já não há uma resposta simples para os problemas que vão surgindo. A resposta pode estar de algum modo relacionada com limitações na ULA, com o endereçamento das texturas e a falta de largura de banda, tudo ao mesmo tempo... E dominar tudo isto demora tempo.

Quanto ao CPU, já não é tão importante, desde que a performance chegue para dar conta do recado. Quanto à hierarquia de RAM e a sua performance, esta continua a variar de plataforma para plataforma.

Limitamo-nos a fazer port dos jogos e a correr montes e montes de testes!

Um exemplo que posso dar: Metro Last Light na consolas da geração passada tem tarefas altamente vetorizadas e tarefas de geração de texturas otimizadas "à mão". Uma dessas tarefas demora 0.8 milisegundos a cumprir num SPU da PS3 e 1.2 milisegundos numa única hyper-thread da Xbox 360. Quando fizemos o perfil desta tarefa já vectorizada na PS4 esta demorou mais de 2 milisegundos! Isto parece mal numa frame de 16 milisegundos. Mas lá está, esta tarefa foi criada propositadamente para não sobrecarregar os velhinhos GPUs das consolas da geração passada, algo que não se aplica às consolas da nova geração, logo é contra produtivo. Temos de arranjar uma nova maneira de programar.

Bem, acho que já respondeu à sua própria pergunta: a PS4 é um pouco mais poderosa. Esqueceu de mencionar as contagens da unidade ROP, que também é importante - e não nos esqueçamos que tanto a CPU como a GPU partilham a mesma largura de para comunicar com a DRAM (em ambas as consolas). Quando estava a estudar e a correr testes na Xbox One vi muitos casos onde a GPU não era o rápida o suficiente, mas sempre quando o processador não estava a "trabalhar". E também já vi o caso contrário, onde o CPU não dá uma resposta à altura quando a GPU não está a contribuir, mesmo quando é dado ao CPU prioridade no acesso à memória. Por isso é que acho que a decisão da Microsoft dar um pequeno overclock ao CPU antes do lançamento foi bem tomada.

Contudo, contar o número de pixels no ecrã não é a melhor forma de medir as diferenças entre as duas consolas. Para além da resolução, há muitos mais factores ( e muito mais importantes) que afectam a qualidade de imagem. Conseguimos ter mais 40% de pixeis com a PS4 mas conseguimos ver com os nossos próprios olhos que isso não representa uma melhoria de 40% na imagem.

Na verdade, a dificuldade não é originada pela própria ESRAM mas pelo facto de que é muito pouca memória. Quanto à performance da ESRAM, é verdade que é suficiente para a GPU que temos da Xbox One. É verdade que na teoria a largura de banda máxima é comparada à da PS4, mas na prática é muito raro atingirmos esse valor (o que é normalmente feito com tarefas mistas de leitura e escrita simultânea FP16) e isso é um factor limitador.

Vamos por as coisas desta maneira: já vimos cenários onde um único núcleo do CPU estava ficava completamente atolado só pelo facto de pedirmos mais objectos no ecrã. Num cenário idêntico na PS4, era difícil de encontrar esses pedidos nos perfis gráficos quando estávamos a fazer a monitorização, porque eles demoravam pouco tempo por isso mal eram visíveis.

Não percebo porque é que escolheram o DX11 para ponto de partida numa consola. É uma consola! Porquê estarmos agora preocupados com um sistema antigo como o DX11? Na PS4, a maioria dos comandos para a GPU são umas variáveis de 32 bits , DWORD's, digamos que representam uns quantos ciclos de relógio no CPU. Na Xbox One este tipo de tarefas pode ser 1 milhão de vezes mais lento porque a aplicação de desenvolvimento usa mais variáveis com muito maior tamanho.

Mas a Microsoft não anda a dormir. Todos os kits de desenvolvimento que foram lançados antes e depois do lançamento da Xbox One estão com funções de pedido de objectos cada vez mais rápidas. Foram adicionadas montes de novas funcionalidades para tentar dar a volta ao modelo da aplicação do DX11. Até disponibilizaram uma aplicação para DX12/GNM do estilo "faça você mesmo". Contudo não a lançamos com o Redux porque não houve tempo.

Não é segredo nenhum. Apenas adaptamos o jogo para correr assim nas consolas em questão.

Se nestas novas consolas as ferramentas que usamos não lidam bem com interpoladores, mudamos um espaço tangente de vórtices para um espaço baseado em pixeis. Se as tarefas são demasiado rápidas para o processador, tentamos juntar todas essas tarefas. Se são tarefas demasiado lentas, usamos computação paralela. Se a GPU não gosta de um tipo de programação por causa dos números de contagens em cada ciclo, usamos velhos truques para dar a volta à situação. E por aí em diante.

Simplesmente usamos a arte da optimização, que aliás também beneficia a versão PC, principalmente em na parte do CPU, visto que é onde as consolas tem menos poder, logo é onde mais otimizações deste tipo fazemos.

Pelo simples facto de que conseguimos fazê-lo. Mas para o nosso próximo projecto, que ainda não foi anunciado, os designers querem o máximo de detalhe, efeitos, o máximo de tudo possível, por isso estamos a apontar para os 30fps.

Enviamos para as lojas um jogo com 60 fps constantes com uma qualidade visual equivalente àquilo que se vê no PC entre o alto e o muito alto. Em cada frame, temos um "custo" fixo de 30% desse tempo para pós processamento, o que nos deixa apenas 11ms para processar tudo aquilo que aparece no ecrã. Agora imaginem que tínhamos apenas 30fps, isso daria para termos visuais mais ricos, cerca de 2.5 vezes melhores.

Desde que o Metro Last Light foi para as prateleiras fomos colecionando sugestões dos nossos jogadores de forma a incluí-las em Metro Redux. O poder das novas consolas também nos permitiu melhorar o jogo em termos de gameplay, especialmente em termos de tiroteios e em envolvência geral - por exemplo o combate e as cinemáticas ficaram muito mais fluídos, e os controlos muito mais responsivos. Para além disso, a nova encarnação de Metro 2033 goza de muitas das melhorias introduzidas em Metro: Last Light: novas armas e as suas melhorias, um modo stealth mais viável e takedowns, AI melhorada com comportamento mais realista e todo o aspecto visual melhorado, entre outras coisas.

Estamos bastante contentes com o facto de que os jogos estão muito mais equilibrados: correm melhor, mais rápido e parecem jogos mais "frescos". E o facto de que conseguimos por todo o universo de Metro com todos os DLC, modos de jogo e definições de dificuldade num único e definitivo pacote.

Estamos a fazer as duas coisas. Temos estado a trabalhar num jogo novo e também em Redux. Tínhamos recursos livres para tratar de Redux enquanto o nosso novo projecto ainda estava numa fase de pré-produção e agora já precisamos de toda a equipa de Redux no novo projecto que já está a todo o vapor! Mas como viram, Redux não é um mero port, é uma experiência completamente nova, especialmente a parte de 2033!

Sem dúvida.

Para os jogos em que estamos a trabalhar, os nossos designers estão a pensar mais numa experiência do tipo sandbox - menos linear mas ainda muito focada num grande enredo. Não vou entrar em detalhes, mas também vai exigir muito dos nossos programadores. Também estamos a melhorar os gráficos em muitos aspectos, por exemplo recentemente desenvolvemos uma nova técnica de oclusão ambiente global baseada em física (ao invés de oclusão global, como SSAO). Não vou ainda falar do nosso motor de renderização baseado em física porque os nossos artistas ainda se estão a adaptar ao mesmo.

Para que serve essa técnica e para que é que a usamos? Primeiro significa que não temos de ajustar tanto os conteúdos para que eles fiquem "bonitos". Como resultado, os artistas que tratam da luz adoram esta técnica, mas os artistas que tratam das texturas odeiam-na. Tecnicamente é uma técnica que visa preservar a imagem espelhada em cada pixel. Na verdade, Redux vem com uma técnica que visa preservar a energia desta imagem espelhada, que é um pequeno mas importante aspecto neste tipo de técnicas, mas deixamos todos esse tipos de ajustes para os artistas. De qualquer das maneiras, estamos a pensar em adoptar essa técnica para o nosso próximo título para não depender tanto dos artistas, pelo menos por agora.

À parte do facto de que estas aplicações nos permitem programar a um nível mais baixo, muito mais perto do hardware, essas aplicações representam uma mudança de paradigma naquilo que toca ao seu próprio design. O DX11 dava conta do recado por nós enquanto que o DX12 volta a meter a responsabilidade toda nas nossas mãos, o que nos permite programar numa abordagem de muito mais baixo-nível. Quanto ao Mantle, na minha modesta opinião, acho que é uma aplicação temporária.

É importante. Todos trabalho de tracking de dependências requer uma fatia enorme do poder do CPU. E quando estamos a falar do buffer de comandos com múltiplas threads que tínhamos com o DX11, estamos a falar de um autêntico flop, enquanto que o da DX12 já é a escolha acertada.

O problema é mais complicado que isso. Não do género : "Tomem lá mais 10% de performance que vos roubamos", às vezes podemos usar 1.5%, outras vezes 7% e por aí fora. Podíamos ter apontado para uma resolução mais alta, mas apontamos antes para uma estabilidade 100%, com o frame e v-sync fixos. Isso não quer dizer que pudéssemos ter feito mais com mais tempo, e o kit de desenvolvimento continua a ser melhorado todos os meses.

Bem, a performance dos processadores neste momento estagnou devido a vários factores - sendo o económico um deles. Eu diria que os produtores de jogos para PC se deve de focar na performance dos CPUs que estão nas consolas.

É difícil de responder a essa sem provocar guerras entre os fãs. Comprem sempre os componentes mais poderosos que a vossa carteira consegue suportar, com um particular ênfase na placa gráfica.

O problema com memória unificada é a coerência. Mesmo nas consolas, onde vemos componentes altamente integrados, temos a opção de mapear a memória ora para o CPU, ora para o GPU ou então "completamente coerente". E ser completamente coerente não é útil porque significa que vamos perder performance. Quanto ao PC tradicional? Ter que recorrer a algum tipo de bus externo só para recolher as caches, vai ser muito lento.

Sim, o Metro Last Light em Linux era baseado em OpenGL 3.2 - é estável mas não suporta nenhuma das funcionalidades "topo de gama". Para o Redux estamos a replicar a versão DX11, com quase todas as funcionalidades. O problema disso é que a vossa placa gráfica terá de suportar OpenGL 4.

Definitivamente. K1 é uma autêntica estrela brilhante no mundo das plataformas móveis. Quem me dera que o céu estivesse cheio de estrelas como a K1 para que fosse economicamente viável para nós produzir para essas plataformas!