Metrospective: 4A Games vs Digital Foundry
A mente por detrás de Metro 2033 explica a tecnologia.
O Unreal Engine definiu o padrão tecnológico dos shooters de consola de alta definição, mas Gears of War à parte, parece que cabe aos motores proprietários os exceder: Infinity Ward, Bungie e a Guerrilla Games produziram os títulos FPS mais aclamados pela crítica nas consolas, e todos eles usam a sua própria tecnologia interna.
Vindo dos arquitectos tecnológicos do GSC de S.T.A.L.K.E.R., o novo motor 4A que sustenta Metro 2033 da THQ parece ser outra base de código proprietária capaz de produzir alguns visuais espantosos. Até agora, a maior parte dos esforços de promoção da THQ concentraram-se na versão visualmente soberba de PC, apesar da Eurogamer ter jogado ambas as versões no mês passado. A Digital Foundry teve acesso extensivo a uma versão de antevisão Xbox 360, e o que vimos foi impressionante.
Para vos dar uma ideia do que nos cativou a atenção, aqui está um vídeo do jogo a correr na consola Microsoft, capturado e editado por nós com uma visão para mostrar o aspecto visual único desta nova tecnologia, e como se traduz em jogabilidade.
Nós queríamos saber mais, por isso arranjámos uma entrevista com o Responsável pelo Departamento Técnico da 4A Games, Oles Shishkovtsov. Tendo anteriormente trabalhado com o GSC como uma força instrumental impulsionadora por detrás do tecnologicamente impressionante S.T.A.L.K.E.R., tem havido controvérsia que o motor 4A é um derivado do GSC IP, mas Shishkovtsov não concorda, dizendo que a nova tecnologia começou como um projecto experimental nascido das frustrações no lidar com o seu velho motor.
"Os grandes obstáculos para o futuro do motor de S.T.A.L.K.E.R. foram a sua inerente incapacidade para ser multi-tópico, o fraco e dado a erros modelo de rede, e a simplesmente horrível gestão de recursos e memória que proibiu qualquer tipo de leitura contínua de dados ou simplesmente para manter o espaço de trabalho pequeno o suficiente para (na altura) as consolas de 'nova geração'," explica Shishkovtsov.
"Outra coisa que realmente me preocupava era a linguagem de extensão baseada em texto (S.T.A.L.K.E.R. tinha como linguagem de extensão puramente LUA)," continua. "Ao trabalhar em S.T.A.L.K.E.R. tornou-se claro que os designers/escritores de linguagem de extensão querem mais e mais controlo e quando o tem, ficam perdidos e precisam de pensar como programadores, mas eles não eram programadores! Isso contribuiu muito para os adiamentos originais com S.T.A.L.K.E.R."
Foram estes problemas e questões que fizeram com que Oles procurasse uma completa nova direcção para o novo motor.
"Eu comecei um projecto pessoal para estabelecer a futura arquitectura e para explorar as possibilidades do design," diz. "O projecto evolui muito nem e apesar de não ser funcional como um jogo (nem mesmo como uma demo: não tinha qualquer motor de renderização na altura, por exemplo) - providenciou-me uma clara visão do que fazer em seguida."
Shishkovstov e o seu colega Aleksandr Maksimchuk deixaram a GSC um ano antes de S.T.A.L.K.E.R. eventualmente ser enviado para as lojas, e o motor 4A, com o seu ênfase numa grandemente eficiente implementação de multi-tópicos boa para tanto PC como consola ganhou forma. Oles diz que o motor 4A não tem qualquer relação com a tecnologia X-Ray de S.T.A.L.K.E.R. porque uma adaptação seria "extremamente difícil".
"Uma adaptação directa não iria caber na memória mesmo sem todas as texturas, todos os sons e toda a geometria," reconhece. "E depois vai funcionar por volta dos 1-3 fotogramas por segundo. Mas isso não importa porque sem texturas e geometria, não consegues ver esses fotogramas! Essa é a minha opinião pessoal, mas provavelmente seria aconselhável a GSC esperar por outra geração de consolas."
Segundo Shishkovtsov, a filosofia de colocar em paralelo o código é diferente em muitos jogos, mas similar às técnicas empregues pela Criterion Games em Burnout Paradise: tarefas de processamento atribuídas a quaisquer processadores que estejam disponíveis no momento.
"Não temos linhas dedicadas para processar tarefas específicas no jogo com a excepção da linha PhysX," explica Shishkovtsov. Todas as nossas linhas são trabalhadoras básicas. Usámos o modelo de tarefa mas sem qualquer pré-condicionamento ou pré/pós-sincronização. Basicamente todas as tarefas podem executar em paralelo sem quaisquer bloqueios desde o ponto em que surgem. Não existem inter-dependências para as tarefas. Parece uma espécie de árvore de tarefas, que começa com as mais pesadas no início do fotograma (para tornar o sistema auto-equilibrado)...Da última vez que medi as estatísticas, estávamos a correr aproximadamente 3,000 tarefas por 30ms fotogramas na Xbox 360 nas cenas intensivas para o CPU com todas as linhas de equipamento carregadas a 100%."
Novamente, similar ao trabalho multi-linhas da Criterion, a 4A Games descobriu que uma implementação similar funciona na consola Sony também.
"A PS3 não é assim tão diferente...Usámos 'fibras' para 'emular' um CPU de seis-linhas, e então casa tarefa podem gerar um trabalho SPURS (SPU) e mudar para outra fibra," continua Oles. "Este é um tipo de descarregamento do PPU, que é transparente ao sistema. O resultado final deste lindo (à parte de ser um pouco restritivo) modelo é que temos escalamento perfeitamente linear aos limites de deficiência do equipamento."
Enquanto que o motor é descrito como um ambiente de desenvolvimento entre-plataformas completo, não vai haver versão PlayStation 3 de Metro 2033. O jogo vai ser lançado para PC e Xbox 360 apenas. No entanto, a consola Sony teve um grande papel no trabalho de desenvolvimento do núcleo da tecnologia.
"Desde o início elegemos a mais 'difícil' plataforma para correr. Muitas decisões foram feitas explicitamente sabendo dos limites e caprichos que vamos enfrentar no futuro," explica Shishkovtsov. "Para mim pessoalmente, o GPU da PS3 (eles gostam de lhe chamar RSX por alguma razão) foi a escolha segura porque eu estava envolvido nas fases iniciais de design do NV40 e é como uma casa: o RSX é um directo derivado dessa arquitectura. Ao ler os documentos da Sony foi tipo, 'Ha! Eles não percebem onde aqueles ciclos são perdidos! Eles codificaram caminho de código abaixo do recomendável em GCM para aquela coisa!' Todo esse tipo de coisas..."