Ponto V!

Home Arquitetura Dissecando os games Dissecando o Game: God of War
Bruno Crivelari Sanches
Dissecando o Game: God of WarImprimir
Escrito por Bruno Crivelari Sanches

Nesse artigo, pretendo abordar umas das minhas coisas favoritas: fuçar no funcionamento dos jogos, que consiste em tentar descobrir o máximo possível de como um jogo foi feito, em especial de como o motor funciona e como o jogo é programado. Tarefa essa, que há uns 10 anos atrás, quando mods eram bem populares, era muito mais simples, existiam muitas ferramentas e documentação disponíveis, isso tudo dava muitas pistas de como tudo funcionava.

Hoje em compensação temos muitos desenvolvedores de grandes franquias falando na GDC e disponibilizando muito material online de partes especificas do jogo, isso também ajuda muito, apesar de que em alguns casos, faltam diversos detalhes ou uma visão de como aquilo se encaixa no todo.

Não pretendo aqui discutir game design ou estilo do jogo, mas investigar como o game design foi feito em nível de programação e as tecnologias envolvidas. Como primeiro jogo dessa coluna selecionei o God of War.

God of War

Escolhi o jogo God of War pelo estilo e pela dinâmica do mesmo, não sou um grande fã do estilo, mas gosto muito do tema do jogo e sempre fico admirado com os cenários, apesar de não gostar muito de ficar jogando. Particularmente acho muito chato certas sequências que quase quebram o controle e tenho minhas críticas quanto a este estilo de “aperte rápido o botão tal durante uma animação”, por essas e outras, eu particularmente prefiro assistir alguém jogando a jogar.

O jogo acredito dispensa apresentações, mas resumindo: você é um guerreiro que foi invocado pelos deuses para acabar com um deus rebelde, o jogo se passa na Grécia antiga e traz toda mitologia grega no enredo. O estilo é de ação “destrua tudo no seu caminho” até não sobrar nada vivo e com bastante violência.

Desenvolvimento

O jogo foi desenvolvido pelo estúdio Santa Monica da Sony Computer Entertainment e levou em torno de três anos para ser criado. A equipe era relativamente pequena, mas formada praticamente apenas por veteranos da indústria, o que pesou em muito no desenvolvimento. O time todo era formado por:

  • 7 programadores
  • 10 designers
  • 22 artistas
  • 3 na parte de som
  • 4 produção

O motor utilizado era chamado de Kinetica, pois foi o motor usado no jogo Kinetica desenvolvido pela própria Sony e integrado com o Bluepoint engine, que segundo o site afirma que o jogo utilizava o asset pipeline e o renderizador.

O objetivo dos programadores era desde o inicio ter o jogo funcionando a 60fps constantes e evitar casos especiais e ter uma tecnologia / metodologia que evitasse desperdício de tempo e bugs e principalmente evitar que a equipe de programação fosse o gargalo do desenvolvimento, segundo um dos líderes do projeto: “a meta número um do projeto era de que no ultimo mês, a equipe de programação pudesse ficar na praia enquanto o resto do time finalizava o jogo" e a melhor maneira para se conseguir isso, segundo os desenvolvedores, era ter ferramentas totalmente data driven.

Quase toda criação de arte era baseada no Maya, dessa forma modelos, informações de colisão, câmeras, entidades (objetos do jogo) e etc. eram criados no Maya, aqui me parece que os desenvolvedores evitaram a construção de ferramentas ou editores e provavelmente focaram esses esforços na criação de plugins para o Maya que facilitasse esse processo. Segundo algumas fontes, todos desenvolvedores possuíam o Maya na sua maquina e o build atual do jogo, dessa forma qualquer um poderia criar novos itens para o jogo sem intervenção de programadores.

Para facilitar mais ainda o processo, um mecanismo de tuning existia no jogo, que permitia qualquer um ajustar diversos parâmetros do jogo, salvar as alterações no disco e incluir no próximo build, mas uma vez vemos aqui a importância do design data driven.

Nas ultimas duas semanas do projeto, existiam 500 bugs abertos, sendo que destes, apenas 25 eram relacionados a código, o time de programação não foi para a praia, mas não ficaram sobrecarregados no final do projeto como é comum em muitos projetos.

Tecnologias Interessantes

Das diversas coisas do jogo, as que mais me chamaram a atenção foram: fluxo constante do jogo, sem loads entre fases, o único carregamento que vemos é quando começamos o jogo, após esse ponto o jogo flui naturalmente como se fosse um grande nível gigante, sem pausas para carregamento. Apesar de não ser exclusividade ou uma novidade, é algo que sempre me chamou a atenção nesses títulos, já desde o primeiro Prince of Persia (da nova geração, o Sands of Time), que é um dos primeiros jogos que me lembro a usar essa técnica.

Outro fato interessante, principalmente para um jogador de FPSs como eu é a câmera em terceira pessoa, que nesse jogo funciona maravilhosamente bem, na maioria dos títulos a câmera de terceira pessoa irrita mais que qualquer coisa, mas no God of War são raros os momentos que ela incomoda. Isso me despertou curiosidade, principalmente pelo fato de já ter implementado esse tipo de câmera algumas vezes e saber das dificuldades que é um trabalho desses.

Nos próximos tópicos, vamos ver em detalhes alguns pontos realmente interessantes desse jogo:

Assets

Toda a criação de assets do jogo era baseado no Maya (ou quase toda). Dessa forma, todo o processo de criação dos níveis era executado de dentro do Maya, desde modelagem da malha a colocar os volumes de som. Os artistas então com o uso de plugins feitos exclusivamente para o projeto montavam todo o nível, exportavam para um arquivo md (que acredito seja o formato nativo do Maya), que então era processado por scripts do motor para geração dos arquivos binários do jogo.

Esse processo resultava em diversos arquivos binários e um script com as dependências deles, isso permitia:

  • Que qualquer pessoa do time (afinal, todos tinham o Maya e todas as ferramentas) fizesse um build completo do jogo.
  • Os dados gerados ficavam em diversos arquivos, permitindo que diversos artistas trabalhassem em paralelo em um mesmo nível.

gow_files

Sistema de Entidades

O sistema de entidades é o coração do jogo, é onde todos os objetos que o jogador interage ganham vida e costuma ser uma das partes mais complexas no desenvolvimento de alguns jogos.

Nas informações que consegui encontrar nenhuma deixa claro que tipo de sistema foi usado, se é uma hierarquia de classes, sistema de componentes, etc. As informações que obtive deixam claro que essencialmente se trata de um sistema de eventos e gatilhos, fortemente atrelado ao sistema de animação, em alguns pontos fico com a impressão de ser um sistema de IO como do motor Source (que merece um artigo a parte, tanto o motor, quanto o sistema de IO).

O sistema permite que os designers conectem eventos a ações, como, por exemplo: “puxar alavanca” –> “abra a porta”, algo que já vimos em detalhes no artigo Programação de Gameplay 101. Aqui o sistema não parece ser muito diferente de outros jogos, mas parece ter uma integração um pouco mais forte com o sistema de animação, acredito que principalmente pelo fato que animação e efeitos cinematográficos são pontos fortes do jogo em si.

Alguns tipos de entidades:

  • Sensores: detectam entrada e saída de zonas, criam e destroem objetos.
  • Atuadores: tocam animações, controlam visibilidade.

Um fato interessante é que as entidades possuem atributos e estes podem conter “scripts inline”, como:

  • "Enabled: (GotShield && GotKey && ! DoorOpened)“.
  • "Execute: if (OnBeam) SetCamera ('OverheadCam')“.

Apesar da simplicidade, os valores acima realmente podem ser poderosos e aparentemente bem flexíveis. Em alguns jogos (como no Quake ou no Half-life), para se criar uma simples linha como “GotShield && GotKey !DoorOpened” iria exigir a iteração de vários objetos do jogo e a criação de varias entidades para uma lógica simples como essa.

Pelos comentários dos desenvolvedores no post-mortem parece que o sistema era bem ad hoc, com suporte a comandos simples como if/else, variáveis, mas sem loops.

Sistema de Câmera

O sistema de câmera foi algo que realmente me chamou atenção, principalmente pelo fato de eu já ter sentido na pele algumas vezes a dificuldade que é construir um sistema de câmera em terceira pessoa descente. Chamou-me mais atenção ainda quando consegui informações de como funciona: scripts! Sim, o sistema de câmeras é todo feito com scripts, os artistas durante a produção do nível definem todo comportamento da câmera e qual caminho ela vai seguir!

De longe o que acaba chamando mais atenção em todo esse sistema é a simplicidade e como ele é eficaz, isso nos mostra o quanto um trabalho artesanal pode agregar valor a uma produção se bem usado.

O sistema de câmeras não possui testes de colisão e nem checa se esta obstruído ou não, duas coisas bem comuns em câmeras de terceira pessoa. As câmeras são configuradas pelos artistas no Maya, onde seus parâmetros são ajustados, caminhos definidos e são integradas também com o sistema de entidades do jogo, permitindo que eventos do jogo afetem as câmeras.

Mas segundo algumas fontes o sistema não pré determina durante o build em que pontos a câmera vai estar, apenas em que região ela vai estar, assim ela tem certa liberdade de movimento em uma determinada área e chega-se a pensar que o jogo talvez gere algum PVS (Possible Visible Set, para mais informações, leia Estamos em 2011 e ainda meu preocupo com visibilidade) através de ferramentas e que depois é ajustado manualmente pelos artistas.

Mas o próprio desenvolvedor da câmera deixa claro que isso não ocorre e afirma que isso fica na mão dos artistas e que o motor não recebe esse tipo de informação, no final o que eles realmente tiram proveito é de, por exemplo, não precisar modelar uma sala inteira (apenas a parte visível) e conseguir ajustar exatamente o que pode ser carregado e descarregado em cada ponto, aparentemente um processo bem manual.

Jogador e Inimigos

O jogador e inimigos usam a mesma base de código, isso inclui inclusive portas, alavancas, etc. Essa simplicidade facilita em muito a criação de código e principalmente a depuração, e inibe casos especiais no código. Por exemplo, consertando-se um bug do jogador, automaticamente já se conserta bugs para os inimigos.

A interface para se mover o jogador ou um inimigo é baseado em um vetor, que determina a direção, velocidade do movimento e um número para indicar qual movimento de combate usar. Dessa forma, as entradas geradas pelo joystick são convertidas para um vetor e os botões em um determinado movimento, que alimenta o código do jogador, gerando o resultado desejado.

A mesma interface é usada com os inimigos, o vetor de movimento calculado pelo sistema de inteligência artificial e o movimento de combate a ser usado decidido por uma árvore de decisão extremamente simples: o inimigo sabe a distância que esta do jogador, o que ele esta fazendo, etc, o sistema pode então sortear um ataque para a distância atual e simplesmente atacar.

Para determinar onde os inimigos podem e não podem ir, os artistas criam waypoints usando uma ferramenta do Maya, que permite a estes “pintar” em uma grade sobreposta sobre o nível os pontos acessíveis e uma ferramenta gera os dados que o motor precisa para controlar a navegação dos inimigos.

Movimentação do Jogador

A movimentação do jogador e de outros objetos do jogo também compartilham o mesmo código. No caso do movimento dos atores, foi usada uma capsula e os testes de colisão são feitos com raios, técnica que na minha experiência é meio incomum, mas com certeza muito mais rápido do que calcular colisão de uma capsula inteira.

image

Na figura acima vemos a capsula usada pelo personagem e os raios usados nos testes de colisão. Os raios de cor ciano na parte de baixo procuram pelo chão, os verdes por paredes e os vermelhos por superfícieis que podem ser escaladas.

Animações Sincronizadas

Um dos pontos mais fortes do jogo é claro são as animações, desde as espetaculares lutas com chefões até as pequenas animações, como de acionar uma alavanca. Para fazer tudo isso funcionar, foi criado um sistema em que o jogador sincroniza-se com animações do ambiente, assim o controle dessas cenas cai todo nas mãos dos artistas e não dos programadores.

Quando uma animação é ativada, como quando o jogador puxa uma alavanca, o modelo do jogador é então preso a um handle, que é controlado pela animação e este pode mover-se para qualquer local, ao mesmo tempo em que é executada uma animação.

image

Observe nas imagens acima, como o modelo do jogador se desloca para fora do seu volume de colisão durante a execução da animação, isso traz grande flexibilidade para os artistas e ainda evita o problema de se programar casos especiais no código.

Outro detalhe do sistema de animação é que animações “especiais” ou específicas ficam atreladas a quem origina elas, por exemplo, se na luta com um chefão o jogador precisa executar animações exclusivas para aquele chefe, estas animações ficam atreladas ao modelo do chefe, isso evita que uma animação usada apenas em certo ponto fique carregada o tempo todo na memória, economizando uma memória considerável, principalmente em um console como o Playstation 2.

Cenários sem Loads

Como desenvolvedor de motores, curioso, pesquisador e chato, foi algo que mais me chamou a atenção: como organizaram isso no motor? A primeira grande dificuldade de algo assim é o consumo de memória, depois o gameplay, pois se o usuário pode ir e vir no cenário temos que manter o estado de todo o jogo salvo em algum lugar. Isso é um grande desafio para um Playstation 2, onde não temos HD e o memory card possui sérias limitações e restrições, assim, temos que nos virar com a memória.

Para controlar os níveis, o jogo mantinha dois níveis carregados simultaneamente: o atual e o anterior ou o atual e o próximo. O level designer então coloca triggers (gatilhos) que ao serem acionados pelo jogador disparam a carga de um nível. Na figura abaixo vemos um exemplo:

level_gow

Na figura acima, o jogador começando no nível A, ao cruzar o gatilho “Load Level B” faz com que o motor inicie a carga do nível B, observe que o designer foi cuidadoso em incluir um corredor ou uma área de transição, a ideia é que durante o tempo que o jogador estiver cruzando a região de transição, o motor tenha tempo suficiente para carregar o próximo nível, dessa forma ao sair do corredor, o jogador já estará no novo nível e não vai ter percebido o carregamento.

Observe que existem outros gatilhos, no caso do jogador vindo do nível B, ele vai primeiramente disparar o gatilho “carregue nível A”, assim o jogador pode se movimentar entre ambos os níveis sem problemas.

É interessante ver que também foi usado um artifício técnico para evitar problemas caso o carregamento do nível demore mais que o esperado, podemos ver isso com os gatilhos “Block Level A” e “Block Level B”, esses gatilhos pausam o jogo caso o jogador chegue neles antes do nível ter sido carregado. Os desenvolvedores comentam que, mesmo se tratando de um console, onde os tempos são bem estáveis, pode acontecer algum atraso, como por exemplo, um leitor de CDs sujo demorando mais que o normal para ler dados, então por segurança são colocadas essas travas para evitar que o jogador chegue a um nível não carregado.

Em alguns casos não era possível fazer os níveis de forma continua, dessa forma os designers procuravam formas de ocultar o efeito de “warp”, que não era nada além de um teletransporte que leva o jogador para outra região. Em uma das cenas, por exemplo, a câmera se movimenta de forma a passar bem na frente de uma bandeira, que bloqueia a visão do jogador enquanto é feito o teletransporte, ficando assim a impressão de um fluxo sempre continuo.

Outro artifício usado foi trocar os níveis, por exemplo, se o jogador não tivesse resolvido um determinado puzzle, ao ir de um nível ao outro era carregado uma determinada versão de um nível, se já tivesse resolvido o puzzle, outra versão era usada, isso gera duplicação de arte, mas resolve muitos problemas, como manter diferentes estados do jogo entre níveis.

Por fim, para os artistas determinarem o tamanho da área de transição, foi usada uma regra simples e bem especifica para o jogo: para cada mega de dados a carregar, incluir um segundo de caminhada para o jogador, assim os artistas calculavam facilmente o tamanho da transição.

Considerações Finais

O jogo God of War sempre me chamou a atenção pelos seus cenários e de como tudo fluía bem durante o jogo, mas estudando as técnicas usadas e principalmente o post-mortem que foi apresentado na GDC fica claro que foi algo muito bem pensado e feito de forma não muito convencionais.

Este artigo esta longe de cobrir todos os detalhes técnicos do jogo, aqui estou resumindo apenas as partes que eu achei mais interessantes e dignas de nota, mas existe muito mais por trás, principalmente nas ultimas versões do jogo.

Nas referências abaixo quem quiser se aprofundar pode ver os artigos originais e apresentações que usei como base, estes oferecem mais detalhes sobre vários itens, em especial ao sistema de câmera (que no fundo não é tão simples assim) e gerenciamento do projeto, além de algumas questões bem especificas para consoles, como gerenciamento de memória.

O mais interessante de tudo, é que nas poucas informações que consegui sobre o God of War III, o processo continua o mesmo: artesanal, mas de forma inteligente e prática.

Referências

God of War: http://en.wikipedia.org/wiki/God_of_War_(video_game)

Designing and Implementing a Dynamic Camera System: http://www.pontov.com.br/files/arquitetura/dissecando/gow/DesiningAndImplementingADynamicCameraSystem.pdf

God of War: How the left and right brain learned to love one another: http://www.pontov.com.br/files/arquitetura/dissecando/gow/S2409i1.ppt

God of War: postmortem: http://msinilo.pl/blog/?p=149

The Making of God of War III: http://www.eurogamer.net/articles/the-making-of-god-of-war-iii


Comentários (22)
  • Elinaldo Jr  - Sugestão de novo post
    avatar

    Olá Bruno, parabéns por mais esse post, muito legal mesmo. Eu sei que é um jogo bem antigo, mas eu sempre quis que alguém fizesse algo parecido com o International SuperStar Soccer do SNES, quem sabe o próximo post não pode ser desse jogo. :whistle:
    Parabéns mais uma vez.

  • Bruno Crivelari Sanches
    avatar

    O duro que futebol é uma das coisas que mais desprezo nessa vida e isso inclui jogos de futebol :).

    Fazer algo assim sobre jogo do Snes seria interessante, o duro é conseguir informações, quem sabe um do mega drive? Esse eu sei onde encontrar informações, acho que vou colocar o sonic na lista :).

    Por enquanto o que tenho planejado aqui (não necessariamente nessa ordem): Duke Nukem 3d (o original, não o lixo do forever), Quake, Half Life (ainda não decidi o 1 ou 2), Unreal.

    T+

  • Paulo Vinicius Wolski Radtke  - Jogos com carregamento por streaming
    avatar

    Bruno, complementando uma informação, um dos primeiros jogos a ter carregamento inteiro por streaming em videogame foi o Crazy Taxi do Dreamcast, seguido pelo Dead or Alive 2 (ele "engana" carregando os dados nos cinemáticos em tempo real). No PS2, essa honra ficou, se não me engano, com o Jak and Daxter (que até hoje usa isso nos Uncharted no PS3). No XBox foi o Halo, que fazia o mesmo e até melhor, porque usava o HD do videogame para cache, então se você continuasse a partida anterior, ele nem load fazia do DVD, pegava os dados do snapshot no HD e ia embora.

  • Bruno Crivelari Sanches
    avatar

    Aha! Eu como não sou muito cara dos consoles (fui até o megadrive) então não sei detalhes.

    No PC, o primeiro jogo a fazer isso que me lembro era o Messiah, mas era uma forma meio primitiva, quando você abria uma porta, a porta ficava fechada e ele fazia o load (sem parar o jogo) e quando o load terminava ele abria a porta.

    Eu particularmente acho fantástico essas técnicas de streaming, fica muito bacana nesse tipo de jogo.

    T+

  • fungos
    avatar

    "se o jogador não tivesse resolvido um determinado puzzle, ao ir de um nível ao outro era carregado uma determinada versão de um nível, se já tivesse resolvido o puzzle, outra versão era usada, isso gera duplicação de arte"

    Tecnicas Jessy aplicadas no GoW.

  • Bruno Crivelari Sanches
    avatar

    Jessy foi pioneira em muita coisa :P

  • Mateus Pires Leite  - Faça do Sonic!
    avatar

    Embora Mario seja mais famoso que o Sonic eu acho o jogo do Sonic muito mais complexo em termos técnicos que o Mario. Se você for realmente fazer sobre ele, por favor, fale sobre os loopings! Eu sei é tudo ali é um grande trabalho de vetores mas quando você tenta replicar algo mínimo tentando usar aquela ideia percebe a complexidade do trabalho.

  • Bruno Crivelari Sanches
    avatar

    Ta na lista! :) Assim que der tempo faço.

  • Johnny Camargo  - Ajuda
    avatar

    Ola http://forum.ragezone.com gostaria de perguntar se voce teria alguma interesse em nos ajudar com essas server files que seguem nesse link:http://forum.ragezone.com/f111/new-godswar-server-files-working-7 37064/ falta decopilar algumas coisas e como eu pude ver voce entende muito de C++ para voce seria molesa alguns sistema do jogo nao estao funcionando como por exemplo sistem de upgrade de itens Forge Sytem e Após algum tempo ligado o gameserver recebe algum erro e para de funcionar

  • Bruno Crivelari Sanches
    avatar

    Não entendi nada e os links estão quebrados. Descompilar jogos é crime.

  • Renato Bittencourt
    avatar

    Muito interessante a matéria. Adorei a parte do "futebol ser uma das coisas que mais desprezo na vida", rs... Isso me cabe tb. Bem, sou responsável pela DEMO do remake do jogo "Shining Force 2" para Nintendo DS. Ficaria lisonjeado se desse uma olhada no meu trabalho e comentasse: http://forums.shiningforcecentral.com/viewtopic.php?f=5&t=12564&start= 460#p605782.
    Agradecido.

  • Bruno Crivelari Sanches
    avatar

    :)

    Faz parte, nada contra se alguém quiser falar de jogos de futebol aqui, só não esperem que eu o faça :).

    Poxa, não tenho nintendo DS, fiquei curioso, tem vídeo?

    T+

  • Anônimo
    avatar

    Digo a mesma coisa. Então, nesse link aí tem o emulador e tudo mais que precisa pra ver o game. Dá uma olhada e comenta algo lá se for o caso. Desculpa se fui inoportuno com o post aqui, mas não iria perder a oportunidade de ter meu simples trabalho apreciado por ti. T+.

  • Bruno Crivelari Sanches
    avatar

    VErdade! Agora consegui rodar! Poxa, ficou muito chique! Obrigado pela honra. Desenvolvido em que?

  • Maycon Carlete  - ideias proxima analise.
    avatar

    Rock n' Roll racing é uma boa pedida, o jogo rodava tanto no snes quanto no mega-drive :woohoo: hehehe

  • Bruno Crivelari Sanches
    avatar

    O duro que jogos de console são difíceis de se conseguir informação, são belas caixa pretas. Se eu conseguir algo, faço no futuro sim.

  • Rafael
    avatar

    Algumas dúvidas: Bruno, quando o motor faz o load do cenário ele deleta da memória o outro que estava carregado? Esse processo não fragmenta a memória e o jogo perde desempenho ?

    Um exemplo é o GTA, que faz spawn constante de NPC's, veículos e o próprio cenário gigante.

  • Anônimo
    avatar

    Sim, fragmenta. Dai vem a questão: como evitar isso?

    Muitas vezes nem é feito "delete" da memória, pois muitos jogos trabalham com arrays fixas para cada tipo de objeto, então eles só reciclam elementos do array, como um pool de objetos.

    Existem casos, comuns em consoles, onde no CD gravam quase como se fosse um "dump" de memória, então o jogo lê aquele bloco inteiro, coloca em um endereço de memória (em alguns consoles, usam endereços físico direto, mas não sei se nos novos como ps3 ou xbox360 rola ainda isso), então se tem controle total de memória.

    A fragmentação até prejudica o desempenho, mas prejudica mas no sentido que determinados objetos ficam "espalhados" pela memória e isso ferra com a vida do cache, principalmente em estruturas encadeadas, mas esse problema se resolve com arrays em muitos casos.

    O maior problema da fragmentação mesmo (principalmente em consoles) é você acabar com a memória, ela fica toda "esburacada" e no final, você não consegue alocações grandes por falta de um bloco de memória grande o bastante.

  • Luigi
    avatar

    Faz do Chronos Trigger

  • Anônimo
    avatar

    Se eu conseguir achar informações boas sobre o desenvolvimento dele, faço sim.

  • jhonata henrique machado  - franquia do jogo
    avatar

    vc tem uma base de quantos foi a franquia de jogo ???

  • Anônimo
    avatar

    Não faço ideia, me interesso apenas pela parte técnica.

Escrever um comentário
Your Contact Details:
Gravatar enabled
Comentário:
[b] [i] [u] [url] [quote] [code] [img]   
:angry::0:confused::cheer:B):evil::silly::dry::lol::kiss::D:pinch::(:shock:
:X:side::):P:unsure::woohoo::huh::whistle:;):S:!::?::idea::arrow:
Security
Por favor coloque o código anti-spam que você lê na imagem.
LAST_UPDATED2  

Busca

Linguagens

Twitter