Quotes: Desenvolvendo para Jogos

Uma de minhas threads favoritas no reddit é uma que pede “descreva como é o desenvolver jogos para cada console“.

Abaixo, coloco algumas quotes (livre tradução) por console.

Atualização 21/05/15: Percebi que esta postagem está cheia de erros crassos de tradução (provavelmente devido ao horário que a fiz), então peço para que os desconsiderem. No entanto, a ideia geral se mantém.

PlayStation 1

Tudo é simples e direto. Com alguns anos de dedicação, uma pessoa pode entender todo o PS1 à nível de bit. Comparado com o que você podia fazer com os PCs naquele tempo, era incrível. Mas, a cada passo, você dizia: “Sério? Tenho que fazer assim? Merda. Tá bem, acho… Me dê algumas semanas.” Não havia debugger efetivamente. Você fazia sua versão e via o que acontecia.

Nintendo64

Tudo apenas funciona. Para a maioria das coisas, era rápido e flexível. Você nunca se sentia como se o utilizasse bem. Mas não havia nenhum problema porque seus esforços meia-boca normalmente aparentavam ser melhor que a maioria dos jogos de PS1. Cada megabyte no cartucho custava muito dinheiro. Havia um debugger, mas ele algumas vezes teria vários bugs aleatórios.

DreamCast

A CPU era estranha (Hitachi SH-4). A GPU era estranha (um predecessor aos chips PowerVR nos iPhones modernos). Havia algumas coisas que você não sabia como usar. A Microsoft meio que quase falou sobre configurá-lo como um PC com DirectX, mas não foi adiante, e não teria funcionado de qualquer forma. Parecia que seria legal. Mas, cara, o PS2 seria muito melhor!

PlayStation 2

Você recebe uma pilha de manuais com 25 centímetros de espessura escrita por engenheiros de hardware japoneses. A primeira vez que você lê a pilha, nada faz nenhum sentido. Na segunda vez, o terceiro livro faz um pouco mais de sentido devido ao que você aprendeu no oitavo livro. A máquina tem 10 processadores diferentes (IOP, SPU1&2, MDEC, R5900, VU0&1, GIF, VIF, GS) e 6 espaços de memória diferentes (IOP, SPU, CPU, GS, VU0&1) que trabalham de formas totalmente diferentes. Há tantas coisas incríveis que você pode fazer, mas tudo requer saltos mortais ao contrário em lâminas invisíveis de falhas de segmentação. Fazer com que o primeiro triângulo aparecesse na tela levou para algumas equipes mais que um mês porque envolvia rotear comandos pelo R5900 -> VIF -> VU1 -> GIF -> GS sem qualquer feedback sobre o que você estava fazendo errado até que cada passo dado estivesse correto. Se você estivesse disposto a modificar seu jogo para adequar à máquina, você teria resultados excelentes. Havia um debugger para a CPU principal (R5900). Funcionava até bem. Para o restante dos processadores, bastava escrever códigos sem bugs.

GameCube

Não trabalhei muito com o Gamecube. Parecia bem flexível. Como se você pudesse fazer tudo, mas nada ficaria extremamente bom ou ruim. A GPU não era muito rápida, mas seus poderes eram tragicamente subutilizados quando comparado ao Xbox. A CPU tinha uma RAM de latência bem baixa. Qualquer estrutura de dados complicada que você puder imaginar estaria tranquilo (em teoria). Apenas faça. Mas mais da metade da RAM estava dividida atrás de uma incrível barreira de alta latência. Então você tinha que manualmente organizar seus dados em ativos vs resto. Era um SIMD meia-boca que fazia 2 floats por vez ao invés de 1 ou 4.

PSP

Não fiz muito aqui também. Era anunciado como uma espécie de PS2, mas de dentro parecia mais um PS1. Eles tentaram diminuir algumas partes para fazer menos doloroso trabalhar com ele, mas estas partes pareciam tscas quando comparado ao design orginal. Tendo basicamente o rasterizador do PS2 completo para uma tela de resolução menor significava que você não precisava se preocupar com pixels blendados.

Xbox

Cheirava como um PC. Havia alguns truques que você podia fazer para forçar a máquina. Mas, para a maior parte, era uma benção o suficiente ter uma especificação de computador simples e consistente para se desenvolver. E o debugger funcionava! Ele realmente funcionava! PIX foi feito por anjos!

Xbox360

Além da coisa do big-endian, ele realmente cheira como um PC –até que você para para analisá-lo. A GPU é ótima –exceto que a EDRAM limitada significa que você teria que desenhar sua cena duas vezes para obedecer o requerimento de anti-aliasing? WTF! Merda, há muitos registradores SIMD! 4 floats x 128 registradores x 6 bancos de registros = 12 mil registradores! Te dão o DirectX 9 e tudo funciona fora da caixa. Mas se você cava um pouco mais, você encontra maneiras melhores de fazer tudo. Cava mais e mais. Eventualmente, seu código não parece nada com o PC-DX9 e funciona muuuuito melhor do que antes! O debugger é excelente! PIX! PIX! Eu Te Amo!

C++, então é bem direto. Quase como programar para PC e Windows. Como é linkado ao Visual Studio 20XX, você pode debugá-lo direto em seu PC enquanto ele funciona ao seu lado. Quando alguém crasheia seu jogo na outra sala, eles podem te enviar o footprint da memória, stack de chamadas, etc e você pode carregá-lo para ver o que está acontecendo. Quando você precisa adicionar algo suportado pelo SDK (como networking), a documentação está “toda lá” mas nada faz sentido. Você terá listas e listas de nomes de parâmetros e valores de retorno sem qualquer ajuda de como usá-los. Esta é facilmente minha plataforma favorita porque é muito fácil de colocar o que você quer na tela.

Linda. Tão legal. DX9++, tinha a framework familiar do DirectX 9 com algumas novas capacidades como o tipo quad-primitivo. Gerenciar a EDRam com o Predicated Tiling pode ser ruim, mas apenas se você estiver fazendo um enorme alvo MSAA. O escalonador do hardware de 720p para 1080p é realmente bem bom também. Ah e PIX. Meu, oh meu deus, o PIX. Usei o PIX para Windows por um tempo e era ótimo, mas o PIX para Xbox? Meu deus. É fenomenal.

Wii

WTF RAM. Sério, era difícil fazer coisas que não estourassem a capacidade da memória, fiquei noites e noites fazendo blockfiles que não explodissem para cada nível mas que ainda tivesse o que os designers quiseram. Artistas e designers te odeiam quando você começa a ir ao trabalho deles e pede para comprimir tudo.

PlayStation 3

Uma caixa de 40 quilos aparece em sua mesa com um manual de 24 passos de como ligá-lo pela primeira vez. Todos tentam, a maioria falham. Eventualmente, uma pessoa consegue e faz para todo mundo. Há apenas uma CPU. Parece que ela pode ser capaz de fazer tudo, mas não pode. As SPUs parecem que são bem legais, mas não para algo que você ou qualquer outra pessoa esteja fazendo. O debugger da CPU funciona bem OK. Não há debugger pra SPU. Não havia nada como o PIX de início. Eventualmente, alguns desenvolvedores 1st-party da Sony se encheram e fizeram seu próprio debugger de GPU. A GPU é muito, muito desapontante… A maioria das pessoas tentam trabalhar apenas com a CPU, mas ela não consegue lidar com toda a carga de trabalho. Algumas pessoas cavam mais nas SPUs e, Deus, elas são rápidas! Infelizmente, eles percebem também que as SPUs devem se devotar quase o tempo inteiro para compensar as fraquezas da GPU.

Quase exatamente igual ao 360, você pode programar no Visual Studio, mas quando você roda seu código, ele vai por uma pipeline proprietária e roda em seu próprio debugger (que tem quase 90% das funcionalidades do VS). Todos reclamam sobre a documentação mas para a maioria dos casos você teria que ir no site dos desenvolvedores e pesquisar nos fóruns ou nos tickets de suporte pelas respostas que você precisa. Debugar pode ser interessante porque havia mais coisas para quebrar na leitura/escrita de memória que o Visual Studio. Nunca desenvolvi um jogo que era exclusivo ao PS3 ou 360, tudo era desenvolvido ao mesmo tempo em 4 projetos que estive para ambas as plataformas. O SDK é bem legal, você não fica preso com tantas coisas para fazer que você normalmente ficaria com o 360.

Peça de hardware extremamente complicada, e o plugin da IDE era meio que uma coisa estranha de se entender e rodar apesar que, em sua defesa, era meu primeiro trabalho com ele e era bem difícil fazer qualquer coisa. Apesar que o PSMove era uma ótima peça de hardware e bem responsivo. Comentário obrigatório sobre as SPUs e PPUs: conceito excelente, mas muito complicado para qualquer coisa que queríamos fazer em nosso escopo limitado.

Gameboy Color

Geralmente um horror. Você tinha que ser bem meticuloso com a localização dos dados gráficos e como renderizá-los na tela. Algo como fazer duas caixas de colidirem (um jogador atingindouma bola de fogo, um jogador pegando um powerup, etc) significava cálculos horrosos em assembly. Você está bem em um hardware com interrupções, algo que você nunca pensaria quando programando coisas para a geração atual.

Gameboy Advance

Muito mais fácil que o GBC. C era a linguagem. Como ele suporte vários fundos nativamente, você pode ajeitar gráficos rapidamente, etc. Ainda lidando com interrupções para a entrada (pelo menos com a configurações que tínhamos). Geralmente divertido, eu não gostaria de fazer um jogo inteiro nele.

Leento… mas memória rápida embutida no chip. Fácil de entender. ARM7TDMI é provavelmente minha arquitetura favorita

GP2X

A documentação não foi enviada com o portátil, então tive que caçá-la. Como esperado, tudo está escrito em japonês-ingrês. Enquanto que cada parte era bem documentada, estava além de minhas habilidades da época saber como tudo interagia. Acho que a GP2X usa GPIO para os joysticks. Uma porta JTAG existia mas estava morta na chegada. Pessoas que bricavam seus GP2X reportavam nos fóruns que conseguiram restaurar o bootloader com a JTAG uma vez sob uma lua cheia após o sacrifício de duas virgens. O console tinha suporte a hardware para blits 2D e cópias rápidas e tinha duas CPUs: uma ARM 920TDMI e uma ARM940TDMI. Nenhuma tinha FPUs, suporte para SIMD ou divisão. A primeira tinha uma MMU enquanto que a 940 estava configurada com um banco registrador. Por exemplo, você podia colocar o banco de registro para o endereço físico 0x06000000 e a ARM940 veria aquele endereço como zero. Ele botaria seus vetores de exceção ali. Então usar ambas as CPUs era chato mas possível. Fiz raízes e divisões na 940 também, assim como áudio em meus projetos de brincadeira.

Nintendo DS

“Para que serve a outra tela?”
Não era tão divertido… o hardware 3D mais louco já visto em um console (parecia mais uma engine de sprites melhoradas do que hardware 3D de verdade). Sempre desejei que estivéssemos fazendo um bom jogo 2D para ele ao invés de um jogo 3D não tão bom…

“É tão poderoso! Ah, pera. Tente ter bons gráficos enquanto suporta o 3d!”

Publicado por

Daniel Araújo

Redator-chefe do próprio blog. Escreve bem sobre absolutamente nada, tem opinião sobre absolutamente tudo. Ninguém se importa mesmo assim.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.