Todo mundo alguma vez já jogou uma versão do clássico jogo Snake!

Snake foi uma febre em especial nos anos 90 e aparecia em diversos modelos de celulares e nos famosos minigames.

Assim como muitos outros jogadores, eu também fiz parte dos jogadores dessa época de minigames monocromáticos e meu jogo favorito era Snake.

Por isso, quando resolvi iniciar o projeto Assembly Classics, Snake foi o primeiro jogo da minha lista se desenvolvido.

Sobre o jogo

The Snake Game é uma recriação do clássico Snake; o famoso jogo da cobrinha. O objetivo dele é bem simples, aumentar o tamanho da cobrinha sem colidir com as paredes do jogo e consigo mesmo.

Minha proposta era construir um jogo o mais próximo possível do original, mas com alguns recursos modernos, como o suporte ao controle do XBOX.

Na versão final, esse foi o visual definido para o game:

Por que Assembly?

Hoje em dia o desenvolvimento de jogos conta com muitas ferramentas que podem auxiliar no desenvolvimento de jogos.

Engines como a Unity , que contém sistemas prontos de física e colisão além de uma variedade de ferramentas que facilitam o desenvolvimento, são muito populares e ajudam imensamente na construção de jogos, então porque não utilizar essa ferramenta?

Se você espera por um motivo técnico do porque eu utilizei Assembly ao invés da Unity, talvez isso irá te desapontar, mas essa escolha não foi técnica, foi passional.

Escolhi assembly pois é uma linguagem de programação pela qual eu tenho uma verdadeira fascinação; sempre me interessei muito, mas nunca tive a oportunidade de estudar pra valer até recentemente, e não me arrependi.

Apesar de não ter tido um motivo técnico para a escolha, existem muitas vantagens em se trabalhar com assembly e a principal delas é entender mais a fundo não apenas como seu jogo funciona, mas também como Sistemas Operacionais e linguagens de programação de um modo geral funcionam.

Microsoft Macro Assembler - MASM

Uma das primeiras coisas que aprendi quando comecei a estudar a Assembly é que diferente de linguagens como C, C# e JavaScript, o Assembly não é uma linguagem única; existem diversas versões de assembly que variam por arquitetura e fabricante.

Dentro do universo X86_64, que é a arquitetura padrão de computadores, nós temos MASM, NASM e FASM, por exemplo, além de muitas outras variações.

Essas linguagens possuem o mesmo conjunto básico de instruções, mas sua sintaxe e recursos podem diferir.

Veja abaixo a diferença de uma procedure escrita em MASM vs NASM:

MASM - Microsoft Macro Assembler

.data
PUBLIC GetFoodCount

.code
GetFoodCount PROC
    mov rax, FoodCount
    ret
GetFoodCount ENDP 

NASM - Netwide Assembler

global GetFoodCount

section .text

GetFoodCount:
    mov rax, FoodCount
    ret

Como falamos, ambas possuem as mesmas instruções 'mov', 'ret', mas a sintaxe é ligeiramente diferente.

Para o The Snake Game eu optei por utilizar o MASM, da Microsoft e dessa vez o motivo foi técnico. Minha intenção no início desse projeto era criar jogos nativos para Windows, utilizando Win32, então fazia sentido manter todo ecossistema dentro da Microsoft.

O Desenvolvimento

Com o Assembler definido, chegou a hora de iniciar o desenvolvimento e com isso veio o primeiro desafio: 32-bit vs 64-bit.

Eu já havia utilizado MASM antes do desenvolvimento de Snake na construção da uma UI para uma aplicação de desenho, entretanto, essa aplicação era 32bit.

Para o Snake eu optei por utilizar assembly 64bit pois se trata de uma arquitetura mais moderna, hoje em dia praticamente já não existem processadores puramente 32bit.

Se por um lado a familiaridade com o MASM 32bit me ajudou a avançar rapidamente no projeto, a escolha pelo uso do MASM 64bit trouxe novos desafios, começando pelo que chamamos de ABI.

Application Binary Interface - ABI

A ABI é um conjunto de regras que define como softwares devem se comunicar em nível binário.

Como programadores, muitos de nós já trabalhamos com APIs, que essencialmente possui um conjunto de regras que permite que softwares até mesmo de linguagens diferentes possam se comunicar.

A ABI é a mesma coisa, mas ao invés de comunicação entre códigos, ela se foca na comunicação do binário com outros binários, bibliotecas, sistema operacional e indiretamente o hardware.

Dentre todas as regras da ABI uma das mais visíveis no código é a convenção de chamada, ou seja, como funções chamadas recebem parâmetros

No Windows, por exemplo, a ABI utilizada é a Microsoft x64, que tem a seguinte convenção de chamada:

RCX -> 1º Parâmetro
RDX -> 2º Parâmetro

R8 -> 3º Parâmetro
R9 -> 4º Parâmetro
Stack -> 5º Parametro em diante

Considere por exemplo a função fictícia SetError(int code, string message);

No MASM ela seria chamada assim:

mov RCX, code
mov RDX, mensagem
call SetError

Veja que o primeiro parâmetro (code), foi colocado em RCX e o segundo parâmetro (message) foi colocado em RDX.

Isso é importante pois o Windows 64bit vai buscar os parâmetros nesses registradores quando detectar a chamada de SetError; A convenção de chamada serve para que o binário possa se comunicar da forma que o sistema espera.

Concluindo

Isso é tudo para o nosso primeiro post!

Com a ABI fora do caminho o desenvolvimento começou a andar e o jogo começou a ganhar forma e o primeiro avanço visível foi a criação da janela utilizando o Win32.

No nosso próximo encontro veremos como essa janela foi criada além das dificuldades encontradas no processo, mas se você está curioso sobre o código ou quer baixar o game, basta conferir nosso site oficial.