Por Um Punhado De Bits: Fundamentos Da Programação

Na idade do bit lascado, quando ainda não existiam as maravilhosas ferramentas de hoje, conhecidas como “engines”, o desenvolvedor de games tinha que escolher entre duas linguagens, para a criação de um jogo: o Basic ou o Assembly. Basic é uma linguagem de “conversação” em inglês, voltada para iniciantes e que equipava 10 em cada 10 dos computadores dos anos 80. Na verdade eles já vinham com ela de fábrica pois a única forma de usar o computador era escrevendo você mesmo um programa. Ou copiando-o de uma revista, livro, apostila e assim por diante.

Eu disse “conversação” porque era assim mesmo: você ia “conversando” com o computador e instruindo-o a fazer certas coisas. Linha após linha, numeradas para referência, e cada linha contendo uma determinada instrução com seus parâmetros. Por exemplo: como fazer uma variável numérica chamada “A” conter o valor 15? Simples: LET A=15 ou seja faça A ser igual a 15. Simples assim.

Já o Assembly (ou Assembler como a gente chamava nos tempos bíblicos da programação) era outro nível. Falando diretamente ao “cérebro” do computador (o processador), ela não exigia a interpretação do fonte digitado. O programador era instruído a usar mnemônicos, na sua grande maioria compuindecifráveis. Por exemplo, para fazer a mesma coisa que fizemos em Basic, bastava usar o seguinte: LD A,15 sendo que LD é uma forma abreviada de “LoaD” e A indica um registrador específico (o acumulador). Ou seja, carregue o Acumulador com o valor 15.

Só para ilustrar, programadores do baixo clero, que não dispunham de grandes equipamentos rodando compiladores assembler, tinham que digitar no computador não o mnemônico mas os códigos hexadecimais correspondentes à instrução desejada e seus parâmetros. Quer ver como? Preste atenção, nada nessa mão, nada na outra e… 3E 0F. A notação é em hexadecimal porque programador baixo nível pensa na base 16 e não na base 10, que é o normal. O código 3E é toda a parte LD A, do mnemônico e 0F é o valor 15 em hexa. Se você pensou que a gente “assemblava” de cabeça, pensou certo, dai chamarmos de linguagem Assembler, já que o compilador é o próprio programador.

Mesmo aparentando semelhanças nas instruções que descrevi acima, esses dois exemplos tem uma diferença fundamental entre eles: o Basic é interpretado e o Assembler é compilado (não tem a necessidade de interpretação, sendo executado imediatamente). E isso importa? Claro, isso reflete diretamente na velocidade de processamento do jogo e isso, mesmo que você tenha saído do coma recentemente, diz tudo sobre se o jogo é lento ou não. A briga por mais velocidade não é apenas uma competição entre hardwares e/ou latência da internet, mas também entre técnicas e linguagens de programação.

Enquanto no LD A,15 o processador já sabe o que é LD, onde está o A e quanto é 15, no LET A=15 o processador precisa descobrir que raios de instrução é essa LET, onde está e se já existe a variável A, se esse sinalzinho engraçado que vem depois indica uma atribuição ou é um teste de igualdade e se o 15 está dentro da faixa numérica aceitável para aquele caso. E ele vai fazer isso em todas as linhas de programação, tantas vezes quanto elas forem executadas dentro do fluxo principal de processamento do jogo. Repetitivo e desnecessário, mas é assim que a coisa funciona embora, nos dias atuais, a gigantesca velocidade de processamento dos computadores modernos meio que compensa essa perda de tempo.

Mas não se deixe iludir pela propaganda enganosa do último parágrafo. Se a sua engine do coração, cantada em verso e prosa pela maioria dos desenvolvedores de games, tiver algo como uma pseudo linguagem embutida, linguagem de script, ou coisa do gênero, pode ter certeza que pelo menos uma boa parte do jogo é interpretada e não compilada. Isso é bom ou ruim? Depende muito da qualidade e do conhecimento de quem fez a programação do referido jogo e principalmente dos propósitos e objetivos do dito cujo.

No final das contas, não existe muita diferença entre programar usando a linguagem A, B ou C porque tudo é mesmo uma questão de quão inteligente é o fluxo de processamento. Podemos, na melhor das hipóteses, argumentar que uma linguagem é mais produtiva que outra, de acordo com o programa que está sendo feito ou do tipo de computador usado ou mesmo se existe a transmissão via internet na jogada. Também podemos escolher por comodidade ou porque conhecemos mais e melhor certos procedimentos de cada uma delas.

É inegável que as engines modernas simplificaram muito a maioria das tarefas banais da programação, mas isso também tem um preço a ser pago, em termos de velocidade de processamento, tamanho e eficiência do código. Afinal, toda escolha tem consequências e a questão nem é saber qual é a melhor opção mas sim entender o preço que está pagando por ela.

Entenda, não estou pregando a volta do assembler na criação de jogos, muito pelo contrário. Só usei esse exemplo (e nem mesmo o Basic ainda é usado) para mostrar dois conceitos importantes da programação: a interpretação e a compilação. São faces de uma mesma moeda e conhecê-las pode ajudar muito nas escolhas futuras.

Ainda está achando que para fazer joguinho basta só ter uma ideia? Vai achando…

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: equipe Quebrando o Controle