Por Um Punhado De Bits: Motor De Arranque

Não é preciso ter conhecimentos de mecânica de automóveis para ser um exímio motorista mas ajuda a dominar o bólido se conhecer o básico. A expressão “motor de arranque” se refere a um pequeno motor elétrico que todo carro tem, cuja função é fazer o motor principal funcionar. Seria o equivalente a “pegar no tranco”, sem a necessidade de alguém empurrar o veículo numa descida ou daquela pessoa “manivelar” na frente do carro, como a gente vê nos filmes antigos.

Na programação de jogos, cedo ou tarde a gente se depara com a pergunta: por onde eu começo? Traduzindo, qual motor de arranque (engine) é a melhor para começar a produzir games? No tempo do bit lascado a pergunta era um pouco diferente: qual linguagem de programação era a melhor para começar?

Se acredita que em termos de engine o barato se resume a Unity ou Unreal, está perdendo um bonde e tanto, ainda que essas duas sejam de longe as mais famosas. Não sendo elas, existem centenas de opções, a depender apenas das suas habilidades, tipo de jogo a ser desenvolvido ou apenas preferência pessoal. Existem engines que atendem muito bem desde uma simples narrativa interativa até um massive online 3D multiplayer de mundo aberto. Escolher a ferramenta é, ao mesmo tempo um exercício de abstração e uma arte. Escolher errado pode comprometer não apenas o resultado final, quanto desperdiçar um tempo precioso que certamente fará falta mais adiante.

Mas qual é realmente a função do motor e qual seria o pré requisito para uma escolha acertada? Conhecimento. Conhecer o que cada motor faz ou seu desempenho é essencial e para isso você precisa conhecer um pouco de mecânica básica, para entender o que está procurando.

Aqui vai um pequeno exemplo do que estamos falando: você realmente sabe o que é necessário para colocar uma figurinha de um personagem fofo 2D, de digamos 150×200 pixels no centro da tela do seu monitor? Sabe o que acontece dentro do device (computador, celular ou console)? Vou tentar te explicar em poucos parágrafos.

Em primeiro lugar é preciso saber “onde” fica a memória de vídeo, lembrando que toda memória é linear, sequencial e mapeada por endereços. Essa tal memória de vídeo nada mais é do que uma espécie de “fotografia digital” do que o usuário está vendo no monitor e nela os pixels são representados pelas suas próprias cores. Saber “onde” não é suficiente. Também é necessário saber “como” colocar os pixels nos seus devidos lugares.

Esse “como” depende muito da profundidade de cor, usada no momento pelo device. Hoje em dia o mais comum é uma profundidade de 32 bits, ou seja, 4 bytes representando as cores primárias (Red, Green, Blue) e mais um byte que pode ser usado para vários propósitos. Em tempo: é mais fácil “trabalhar” com 32 bits, mesmo sobrando um byte do que com 24 bits, que seria o mais lógico.

De posse dessa informação, é preciso agora saber a posição exata, do centro da tela e aqui começam os verdadeiros problemas. Matematicamente falando é fácil: largura total da resolução do monitor, menos a largura da figurinha fofa, dividido por 2 e magicamente temos a coordenada X do canto superior esquerdo da imagem. Fazendo o mesmo para a altura, temos a coordenada Y.

Ficou claro que tudo vai depender da resolução usada por cada device? E literalmente cada caso é um caso, dada a diversidade de resoluções não apenas entre equipamentos mas num mesmo hardware.

Só falta agora transformar X,Y no endereço real na memória de vídeo, ou seja, largura total da tela do monitor multiplicado pela coordenada Y e somado à coordenada X, multiplicado ainda pela profundidade de cor – 4 (se for 32 bits) ou 3 (se for 24 bits). Se o device estiver com profundidade menor, isso implica no uso de paleta de cores, o que multiplica por 100 a dificuldade toda da programação.

Agora só falta transferir, pixel por pixel, a imagem fofa (que também estará em algum endereço linear da memória) para a memória de vídeo, levando em conta se o pixel é transparente ou não. Pixel por pixel, ainda que possa existir uma instrução no processador para “mover automagicamente” blocos de memória de um lugar para outro.

Lá em cima, nas camadas (ou motores) de alto nível, tudo isso pode se resumir a uma instrução tipo print x,y,imagem ou alguma coisa derivada disso. É algo como “o trabalho sujo a gente deixa pro motor fazer”, enquanto dedicamos nossos esforços para melhorar coisas como enredo, belezura das imagens, mecânicas alternativas, etc.

Entendeu onde entra esse lance de motor? Se você pretende fazer um mmo3D, então deve escolher mesmo um motor de caminhão (ou de navio) porque o trabalho sujo é gigantesco. Já se pretende escrever uma narrativa interativa simplificada ou mesmo um jogo 2D de plataforma, um motor de bicicleta elétrica já dá conta do recado. Sabe onde tem um motor desses grátis? No seu navegador preferido e ele se chama HTML. Não precisa mais do que isso. O Hipertexto, que deu origem ao HTML é basicamente isso: uma narrativa interativa.

Ah, mas pera lá…

Calma, essa conversa é longa e não pode ser feita aqui, em apenas uma coluna. Seriam necessárias dezenas delas para, pelo menos, entrarmos em sintonia sobre o que estamos falando, mas o objetivo hoje é mostrar que, se está no estágio “qual engine é melhor pra fazer o meu jogo”, então fica o aviso: tem muita coisa a ser considerada e a opinião pessoal de uns e outros pode não ser a melhor opção.

Pesquisar, conhecer e experimentar são bem mais efetivos, para uma boa escolha.

Então, se quiser criticar, elogiar, xingar, falar palavras de incentivo, mandar pix pra ajudar na aposentadoria, etc, o canal mais eficiente é o velho e surrado e-mail: renato@tilt.net. Sinta-se livre pra descer o sarrafo porque nesta altura do campeonato, meu amigo, eu já sofri todas as críticas positivas e negativas que um gamedev pode sofrer.

Imagem: Microsoft Image Creator