Vocês devem se lembrar da descrição de nossas investidas na programação de jogos, que culmina com a pergunta básica "okay, estamos no Linux, não tem uma IDE nem um engine que sirva, e agora?". Bom, a resposta está vindo e se chama Sloth SDL Engine. Vamos por partes.

O que é uma "engine"?

Engine, que em inglês significa "motor", é um termo comumente usado para designar uma biblioteca – i.e., um conjunto de funções e estruturas de dados – que tem o propósito de servir de arcabouço para aplicações. No caso, esta é uma engine de jogos, ou seja, é uma biblioteca que disponibiliza abstrações para criação de jogos facilitada.

E o que é SDL?

SDL é sigla para Simple DirectMedia Layer – tradução livre: "Camada Simples de DirectMedia" –, que é uma biblioteca multi-plataforma(e multi-linguagem) que provê estruturas para atuação em mídia. É quase um equivalente do DirectX da Microsoft, só que o directX é, basicamente, mais foda em termos de compatibilidade de drivers. O SDL ganha por ser independente de plataforma, ou seja, não é restrito a um sistema operacional ou a uma arquitetura definida.

Não é segredo que nerd que é nerd adora resolver problemas sem nenhuma utilidade aparente. Na maioria dos casos, quanto mais inútil e desligado de qualquer compromisso, mais tentador é o problema. Como dizia Carl Sagan, nem que se pagassem todo o dinheiro do mundo conseguiriam que Maxwell desenvolvesse suas equações em pesquisa controlada.

De fato, todo o processo de resolução de problemas, desde a formulação, passando pela modelagem e desenvolvimento do método, até finalmente obter os resultados e encontrar conclusões a respeito deles. Daí um dia eu me vi formulando um problema tão incrivelmente banal que provavelmente seria infinitamente fascinante de resolver: o Problema dos Dominós!

... hein?

O problema é o seguinte: você tem um conjunto de dominós com até n pontos(e.g., um jogo de dominó convencional é um 6-dominó). O problema consiste simplesmente de duas perguntas:

1. É possível enfileirar todas as peças de uma vez só, segundo as regra do jogo, i.e., uma peça com uma extremidade X se conecta com outra que tenha uma extremidade igual livre?
2. Se sim, de qual forma, i.e., enfileirando-as em que ordem?

Vamos direto ao ponto: programar sistemas é um troço complicado. Dentre várias coisas, é preciso tornar a interface o mais abstrata e "alto nível" o possível, e isso inclui, entre outros fatores, proteção. A hierarquia de usuários vai desde "Seu João", o usuário comum, até "O Root", o administrador, que tem poder absoluto.

É claro que, como programador do sistema, você é praticamente o "admin". Mas na prática existe outro "admin" por conta do sistema, e você, como encarregado do suporte, pode não ter esse privilégio todo. Mas, como programador, você se precaveu e existe uma maneira obscura de fazer esse acesso. E é aí que mora o perigo.

Dica de segurança do TP: Nunca, nunca deixe uma brecha para acesso irrestrito no seu sistema.

O problema é dobrado em sistemas de código aberto, mas também acontece com muita frequência em código proprietário também. Uma brecha obscura e bem escondida não é nada para o "Seu Zé", mas para um usuário com um pouco mais de experiência no ramo, pode ser um prato cheio. Sobretudo para o terror de todo adminsitrador de sistema e trabalhador da área de suporte: o hacker.

Muito bem, amigos, finalmente consegui retomar esta série com algo interessante. Visto que "Pong 4 Linux" não é nem de longe "interessante", e o nosso próximo projeto que já está "estourando a bolsa" – Sendo este o NABA –, é que eu comecei, de maneira independente, a criar uma engine para criação de qualquer tipo de jogo com menos passos do que normalmente necessário. O objetivo é criar um "Game-Maker-like" para Linux, visto que essa coisa não existe. Mesmo que sem interface...

Então eu comecei a pensar numa coisa... colisões.

Veja bem, todo jogo é baseado em colisões. Bom, nem todo. Alguns jogos podem ser abstraídos em função de outro tipo de coisa que não colisões. Mas esses são casos especiais. Em primeira instância, o que temos é um monte de objetos que interagem uns com os outros. E aí que mora o problema.

Dependendo de sua estrutura, um jogo "complexo" – em contraposição a jogos "simples" como Pong, Breakout e Tetris, que podem ser mais facilmente otimizados – é composto de muitos e muitos objetos. Pegue Super Mario Bros, por exemplo. Mario, cada inimigo, cada bloco quebrável, cada bola de fogo, é um objeto de jogo. E daí vê-se que existem algumas dezenas de objetos interagindo por fase. E agora é que entra a parte computacional do raciocínio.

Todo curso começa do básico, e uma introdução é necessária para aqueles que não entendem patavinas chegarem a algum lugar. Então, vamos nessa.

Introdução: Entendendo um Computador

Um computador nada mais é do que uma máquina que lê instruções e as executa em alguma ordem. Sua interface muda de modelo para modelo, mas a função e funcionamento são basicamente os mesmos. Além disso, um computador só faz aquilo que é mandado fazer. Por razões de segurança e previsibilidade, um computador não é dotado de inteligência própria e/ou imaginação, então ele não pode adivinhar o que você queria dizer com tal comando. Entretanto, ele também não vai de repente tomar consciência da sua existência patética e da superioridade de processamento dele em relação a você e tentar destruir a Terra. E todos somos muito gratos por isto. =)

Entendendo Programas

Um programa é um conjunto de dados e intruções que serão lidos e executados pelo computador em alguma ordem determinada. Imagine um programa como uma receita, exceto que ao invés de ingredientes e instruções, temos dados e... bem, instruções. O programa pode também capturar dados de alguma entrada e depois retornar alguma coisa para um saída.

Ainda estou pra descobrir quem foi o gênio original, mas praticamente qualquer bom professor de programação vai te dizer uma verdade universal: "só se aprende a programar, programando".

De forma análoga, só se aprende a programar IDEs programando IDEs, e só se aprende a programar engines de blogs, programando engines de blogs. Onde eu estou querendo chegar, com um título desses, é: só se aprende a programar jogos, programando jogos.

Foi daí que, algum dia, eu comecei a programar jogos. Ou tentar. Esta introdução é histórica, mas não vou entrar nos méritos usuais de "por que adoro jogos" ou "os primórdios primordiais de minha história na programação de jogos". Vou direto de onde comecei a fazer coisas que, bem, funcionavam.

A Era Windows: IDEs bacaninhas

Se vocês querem realmente saber, quando comecei a fazer programas que poderia ser considerados jogos "de verdade", eu usava IDEs da família Klik, mais especificamente "The Games Factory" e "Click & Create". Não vou negar, eram engines divertidas, mas deixavam a desejar na parte da programação. O negócio era quase totalmente gráfico, e embora fosse confortável, é mais ou menos como programar Java: uma hora você quer ter controle sobre tudo.