Executando verificação de segurança...
52

Curiosidades sobre o Street Fighter II e a placa de arcade CPS-1

As máquinas de arcade que rodavam Street Fighter II (1991) usavam uma placa de arcade da Capcom chamada de CPS-1 (CP System 1), que abandonou a restrição de sprites retangulares e tornou possível apenas manipular blocos de 16x16 pixels.

Poses em blocos do Ryu, Sagat, Ronda e Chun-li

Além de algumas operações básicas, como inversão horizontal e vertical, a placa CPS-1 não pode "alterar" blocos. Não possui recursos de rotação ou escala. O que fez ela se destacar foi o grande volume de blocos que conseguia manipular por quadro, estimado em cerca de 256.

Na época, os chips ROM eram caros, então os artistas e desenvolvedores precisavam de criatividade e trabalho para conseguir aproveitar o máximo de espaço de forma a permanecer dentro do orçamento e oferecer um jogo bem feito.

Antes da placa CPS-1, permanecer dentro do orçamento era uma simples questão de divisão: o número de sprites permitidos à equipe de arte era o tamanho de ROM dividido pelo tamanho retangular do sprite. Veja abaixo exemplos de sprites do Pokémon Red/Blue (fonte):

Sprites Pokémon Red/Blue

Com a placa CPS-1, a equipe trabalhava com planilhas de papel e tesoura, usando a planilha como se fosse um quebra-cabeça, preenchendo os espaços vazios.

Planilha em branco

Planilha do Dhalsim

A partir desse sistema, trago duas curiosidades.

Ryu e Ken

Muitas pessoas já sabem disso: o Ken é um patch nos blocos do Ryu. A paleta de cores do Ryu foi especialmente projetada para ser compatível com o tom de pele do Ken. Apenas as roupas e as cores do rosto diferem.

Cores do Ryu e do Ken

Planilhas do Ryu e Ken

O patch começa a ficar mais evidente quando você nota a pose de vitória do Ryu nos blocos 2x2 iniciando em 0x75 e os do Ken iniciando no bloco 0x70. O patch era feito assim:

Patch do Ken no Ryu

A pose de vitória do Ken começa com a pose de Ryu. A paleta é alterada e apenas blocos diferentes são usados (veja a quarta imagem). A cor branca dos dentes do Ryu vem de suas roupas, por isso eles ficam vermelhos quando muda para a paleta do Ken, já que seu kimono é vermelho. Então, os artistas tiveram que reaproveitar um pouco da cor da pele.

Animações sutis e precisas na barra de vida

Apesar da limitação dos blocos, o Street Fighter II tem animações bem precisas e sutis da barra de vida de um jogador, movendo-se pixel a pixel, como você pode ver abaixo:

Barra de vida diminuindo pixel a pixel

Sabendo que cada imagem tem 16 pixels, e que é posśivel realizar inversão horizontal de bloco, talvez a primeira forma de fazer uma barra de vida que alguém pensaria seria ter três blocos diferentes, um para as pontas (com a borda branca), outro com a vida cheia e outro com a vida vazia. A animação ficaria assim:

Animação de vida usando apenas 3 blocos diferentes

Mas isso limitaria bastante a mecânica do jogo, onde tudo daria múltiplos de 10% de dano, e a animação ficaria bem "engasgada". O que os desenvolvedores fizeram para conseguir uma animação mais fluida não foi nada mágico. Veja ficha de blocos abaixo:

Ficha de blocos

Assim como no GIF anterior, eu alterei a cor de fundo da imagem do blog para ficar mais fácil de enxergar os detalhes brancos.

Essa ficha revela que os desenvolvedores usaram 20 blocos para a barra de vida, o que permitiu representar a variação pixel a pixel:

Animação da vida usando 20 blocos diferentes

Mesmo com todas as limitações da época, vários jogos bons foram feitos e as pessoas envolvidas precisavam ser criativas e inteligentes, às vezes até programando em Assembly. Eu gosto bastante de curiosidades dessa época, por isso trouxe essas referências para cá. Para quem quer ler mais curiosidades de jogos, talvez se interesse por "Meu bug mais difícil de todos", um desafio no desenvolvimento do Crash Bandicoot 1.

Referências:

Carregando publicação patrocinada...
3
2

gamedev foi o que me fez me interessar por computação (e posteriormente segurança). Esse artigo me lembrou do meu início na área hehehe, embora é claro que nunca tive que lidar com limitação de hardware. Mas eu propositalmente me desafiava além do necessário, chegando a desenvolver jogos do zero, minha própria lib para gamedev, jogo de carros em Batch (shellscript do Windows que, confie em mim, foi mais difícil que fazer em assembly kkkk), engines de jogos etc.

Sempre achei legal tentar resolver problemas complexos, e nessa época desenvolver jogos era algo bem complexo. Claro que hoje em dia, com as game engines, qualquer um consegue desenvolver um jogo (mesmo que não saiba programar).

1