Como instalar o MingW com o Allegro no Windows ?

O propósito deste texto é descrever detalhadamente a instalação do MinGW (http://www.mingw.org/) conjuntamente com a biblioteca para desenvolvimento de jogos Allegro (http://www.talula.demon.co.uk/allegro/ ou http://alleg.sourceforge.net/).

O MinGW é, grosseiramente, uma versão do compilador C da GNU (GCC – http://gcc.gnu.org/) para Windows, permitindo então compilar programas C/C++ neste ambiente de forma muito eficiente.

O Allegro é uma biblioteca multiplataforma que inclui muitas funções úteis no desenvolvimento de jogos, como funções gráficas (2D e 3D), áudio, controle de teclado/mouse/joystick e timer. Funciona de forma muito simples e permite a geração de códigos praticamente idênticos em todas as plataformas em que está disponível, dentre as quais Windows, Linux e DOS.

Conjuntamente com um editor de textos (nossa preferência pessoal é pelo XEmacs – http://www.xemacs.org/ pois tem uma funcionalidade única para escrever o código, mas outra forte indicação é o Dev-C++ – http://www.bloodshed.net/ que é um ambiente integrado que funciona com o MinGW; mas qualquer outro editor de sua preferência serve) temos um ambiente de desenvolvimento de jogos básico completo.

Parte I – O que devo pegar?

Para instalar o MinGW e o Allegro, você deverá baixar os seguintes pacotes:

i) A distribuição completa do MinGW, atualmente em um único arquivo de instalação, que se encontrava na época deste texto em http://prdownloads.sourceforge.net/mingw/MinGW-1.1.tar.gz

ii) Os seguintes utilitários adicionais portados para MinGW:

  • fileutils: consiste em utilitários para lidar com arquivos muito úteis, principalmente na linha de comando ou makefiles. Pegue a versão disponível em ftp://ftp.franken.de/pub/win32/develop/gnuwin32/mingw32/porters/Mikey/fileutils316-ming.tar.bz2
  • sed: é necessário pra compilar o Allegro. Pegue em ftp://agnes.dida.physik.uni-essen.de/home/janjaap/mingw32/binaries/sed-2.05.zip
  • bzip2: você vai precisar pra abrir o fileutils acima. Pegue em http://prdownloads.sourceforge.net/mingwrep/bzip2-1.0.1-20011028.zip

iii) O Allegro propriamente dito com o arquivo para fazer interface com o DirectX no Windows. Vá à página de download da última versão estável do Allegro (4.2) – http://alleg.sourceforge.net/wip.html – e baixe os seguintes arquivos com source para windows:

  • all400.zip (http://prdownloads.sourceforge.net/alleg/all420.zip?download)

E APENAS UM dos arquivos abaixo, dependendo da versão do DirectX que você deseja dar suporte:

  • dx70_mgw.zip (não confunda com dx70_min.zip!) – http://alleg.sourceforge.net/files/dx70_mgw.zip
  • dx80_mgw.zip – http://alleg.sourceforge.net/files/dx80_mgw.zip

Parte II – Configurando o MingW e preparando para instalar o Allegro

Comece pela instalação do pacote do MinGW, descompactando o arquivo no diretório que deseja que ele fique instalado. O usual é algo como c:mingw32 (pessoalmente prefiro c:mingw pois mingw32 é um nome ultrapassado do projeto). Este arquivo pode ser descompactado com o Winzip. De agora em diante, vamos assumir que a instalação foi feita em c:mingw.

O diretório c:mingwbin deve ser incluído no início do seu path (caso você use DJGPP também: antes da inclusão do diretório dele!), sendo que isso pode ser feito de várias formas, sendo as mais comuns:

  • Windows 9x: editando seu arquivo c:autoexec.bat alterando a linha do path ou simplesmente incluindo no final deste arquivo a linha “path c:mingwbin;%PATH%”
  • Windows NT (inclui 2000,XP e Me): abra o Painel de Controle, vá em “Sistema” e então na aba “Avançado” e finalmente no botão “Ambiente”. Selecione PATH= e adicione “c:mingwbin”.
  • Da mesma forma, a seguinte linha deve ser inserida no c:autoexec.bat : “set MINGDIR=c:mingw”. (Caso você utilize Windows XP ou NT, no mesmo menu descrito no ítem anterior, crie uma variavel denominada MINGDIR e atribua a ela o valor c:mingw. Não utilize autoexec.bat).

Após estas alterações nos arquivos de inicialização será necessário que você reinicie o computador. Vá então em uma janela DOS/CONSOLE e digite a seguinte linha para testar a instalação: “gcc -v”. O resultado deve ser algo como:”Reading specs from C:MINGWBIN..libgcc-libi386-mingw32msvc2.95.3specs gcc version 2.95.3 20010726 (release)”.

Instale agora o pacote sed e bzip2, descompactando-os para o diretório do MinGW (aponte o winzip para c:mingw portanto). Em seguida, na janela DOS, vá ao diretório onde está o arquivo do fileutils e rode o comando “bunzip2 fileutils316-ming.tar.bz2” (este comando deverá funcionar se você descompactou direito o arquivo bzip2 e incluiu c:mingw no seu PATH adequadamente e irá descompactar o arquivo fileutils316-ming.tar.bz2 para fileutils316-ming.tar o qual o Winzip pode lidar). Então descompacte com o Winzip o arquivo fileutils316-ming.tar gerado por este último comando para o diretório do MinGW como acima.

Descompacte da mesma forma os arquivos do Allegro para o diretório do MinGW (c:mingw), e quando for descompactar o arquivo dx70_mgw.zip (ou o dx80_mgw.zip – depende de qual arquivo você pegou) e sobrescreva todos os arquivos existentes.

Pronto! Basta agora configurar o Allegro e então compilá-lo!

Parte III – Compilando o Allegro

Se você chegou até aqui, não deverá ter mais problemas (estamos considerando apenas a instalação padrão. Se você quer algo mais sofisticado, certamente sabe do que está falando e não precisa deste tutorial!).

Os comandos a seguir devem ser executados em uma janela DOS/CONSOLE. Para compilar o Allegro devemos preparar os arquivos de configuração para avisar de que a compilação será com o MinGW e então mandar compilar o mesmo. Para isso, basta seguir os seguintes passos, digitando os comandos entre aspas na linha de comando:

1. Vá ao diretório do Allegro: “cd c:mingwallegro”
2. Rode o arquivo de configuração do allegro: “fix.bat mingw32”
3. Finalmente vamos compilar o Allegro: “make”
4. Tome um café…(dependendo da sua máquina, considere jogar uma partida de xadrez)
5. Basta então mandar instalar a biblioteca: “make install”

Pronto! O Allegro está instalado! Você poderá ver vários exemplos no diretório c:mingwallegroexamples e uma demo muito interessante em c:mingwallegrodemo . A documentação básica do Allegro está no diretório c:mingwallegrodocs e é muito indicado que você veja o link de tutoriais na página da biblioteca, principalmente o Vivace se você for iniciante.

Caso você deseje informações mais detalhadas, este texto foi feito com base no processo que usei para instalar no meu computador, mas foi fortemente influenciado pela documentação nos sites citados e na documentação da configuração e instalação do Allegro,constantes do diretório de documentação que acompanha a biblioteca.

Bom código!

Dicas para se fazer um jogo de computador

ANTES DE COMEÇAR…

Lembre-se de que jogos de computador são o conjunto de várias artes diferentes formando uma só. A idéia de arte é altamente subjetiva, por isso você nunca irá agradar a todos. Entretanto tenha em mente de que se a sua intenção for criar um jogo por remuneração, e não prazer, seu trabalho terá que ter um público alvo e satisfazê-lo. Defina seu objetivo e seu público alvo antes de começar.

Preocupe-se em descobrir suas limitações antes de começar a criar seu jogo. Se você não sabe fazer algo necessário ao seu projeto, você tem que aprender a fazer ou aliar-se imediatamente a quem saiba. O seu trabalho ficará muito mais difícil se você tiver que aprender algo ou procurar por algum talento durante a fase de produção. Meu projeto levou três meses para ser concluído, mas acredito que poderia ser feito em menos da metade do tempo caso eu já tivesse os elementos que faltavam antes do início da produção: conhecimento sobre efeitos sonoros e música.

Comece um projeto com a certeza de que você pode terminá-lo. É melhor um Jogo da Velha completo do que um Doom IV em seus sonhos. Você precisa de uma boa estrutura de produção e de boas idéias. Entretanto tenha em mente que você pode compensar a falta de idéias com uma ótima estrutura de produção (é o que acontece com praticamente todas as empresas de softwares profissionais criando clones dos mesmos jogos de sempre só que com mais tecnologia), ou a falta de estrutura de produção com ótimas idéias (Tetris). Se você não tiver nem idéias, nem estrutura de produção, o máximo que você conseguirá é um jogo com gráficos e sons fracos e sem nenhuma jogabilidade. Não tente fazer sem dinheiro, sem conhecimento técnico e sem tempo, um trabalho igual ao de uma empresa com recursos, meses disponíveis e profissionais especializados.

Um jogo de computador é composto de ENTRADA / PROCESSAMENTO e SAÍDA, assim como qualquer coisa em informática. Você deve saber receber os dados via teclado, mouse e/ou joystick (entrada), atualizar os dados do jogo em função da entrada recebida (processamento) e por último mostrar as imagem e o som (saída). Contudo, estes devem ser vistos apenas como os conhecimentos básicos. Tenha em mente que é fácil fazer um efeito de vídeo, ou tocar um som, ou receber a entrada de dados do joystick, etc. O que é realmente difícil é sincronizar todas as rotinas de maneira perfeita, impedindo uma entrada de dados errada (não captar o movimento do jogador, por exemplo), um processamento errado (ativar algo fora da hora, não detectar uma colisão, etc.), ou uma saída errada (imagens fora do lugar, som fora de hora, etc).

Um jogo inicializa seus dados, carrega o que precisa, vai para a tela de título e de lá ou começa o jogo ou volta para o sistema operacional. Ao acabar o jogo, voltará para a tela de título. Isto é o básico da lógicade programação de jogos. Se você pretende incluir mais coisas (menu de opções, galeria de imagens, recordes, etc.), é melhor imaginar o fluxograma antes de começar. Mas isso não é tudo, lembre-se de que o bloco principal do jogo é a parte mais complexa de toda a estrutura.

Planeje sempre, escrevendo tudo o que puder antes de começar a trabalhar. Você pode remendar seu código para implementar uma característica nova no jogo depois, mas tenha em mente que remendar dá muito mais trabalho do que escrever algo que já estava em seus planos. Ex.: meu jogo teria modo de dois jogadores, que não foi implementado porque ao me lembrar disso, o programa estava em um estado de montagem que teria que ser praticamente reconstruído para suportá-lo.

Ao colocar uma estrutura FOR, IF, WHILE, REPEAT, etc., automaticamente feche o final da sua estrutura e depois comece a escrever sua parte interna, tudo devidamente indentado. Tive diversos problemas ao esquecer de fechar uma estrutura, e depois procurar atentamente por toda a listagem do programa até descobrir onde estava o erro. Afinal, devo ter até umas cinco estruturas uma dentro da outra em algumas partes do meu jogo.

Grave seu trabalho em mais de um diretório, em mais de um meio de armazenamento, e se possível, em mais de um lugar (em casa e no trabalho). Grave cada dia de alteração de seu fonte em um arquivo diferente (e diretório, preferencialmente). Assim, você não perderá muito trabalho no caso de uma alteração em seu código comprometer seu funcionamento.

Faça o seu programa o mais modular possível. É mais fácil corrigir ou melhorar algo que apareça freqüentemente em seu programa se estiver em uma função separada.

Opções de jogo (dificuldade, volume de som e música, etc.) devem obrigatoriamente ser variáveis globais. Assim, estarão disponíveis para alteração a cada momento com facilidade, e servirão bem para a construção de um menu de opções no seu jogo.

Ao incluir a entrada de dados em seu jogo, não se esqueça de incluir teclas para avançar de fase automaticamente, conceder imunidade, vidas, etc. Isso vai poupar muito na hora de depurar os erros (i.e.: você não perderá tempo até chegar em uma fase para checar se ela está como você quer). Se quiser, faça estas teclas atreladas a uma variável global no início do programa, para que você possa ativar ou desativar os macetes rapidamente na hora de compilar uma versão final do software.

Seu jogo pode ficar muito mais divertido com apenas um simples ajuste nos valores das variáveis (dificuldade, velocidade dos inimigos, número de vidas, etc.).

Ao incluir um novo elemento de jogo, trace uma “teia mental” de quais outros elementos podem ser afetados por sua inclusão. Você deverá imediatamente checar toda esta teia. Muitas vezes uma pequena alteração praticamente invalidou outras partes do jogo.

Você não deverá ser o único beta-tester de seu jogo. Outras pessoas irão inspecionar seu jogo melhor do que você (para o pai, o filho vai ser sempre o mais bonito), e irão jogar de maneira diferente de você. Não tenha dúvidas de que irão achar erros que você não acharia.

Gaste parte do seu tempo desenvolvendo ferramentas para seu programa. É proveitoso gastar um dia inteiro trabalhando para resolver o trabalho de uma hora, se você faz o trabalho de uma hora várias vezes.

Quando algum colega vê o seu software, existem vários tipos de reação possível a ele… “interessante”, “maneirinho”, e “c******! Tem até o …”. O “interessante” significa fraco. O “maneirinho” quer dizer regular. E se alguém diz “C****** ! Tem até o detalhezinho da mosquinha pousando em cima da mesa!” ou frase parecida, significa que seu jogo está realmente ficando bom.

Quanto aos gráficos e som: assistindo ao jogo, as pessoas analisam detalhes. Jogando, elas vêem o jogo como um todo. Tenha em mente que gráficos e sons detalhados chamam a atenção do jogador antes de começar, e o ajudam a manter imerso no jogo após começar. Gráficos são particularmente importantes para jogos comerciais: ninguém compra um jogo com imagens feias na embalagem. Ou seja, os gráficos não são tão importantes quanto uma boa jogabilidade, mas com certeza eles vendem o jogo.

Gaste mais tempo concentrando-se na jogabilidade do que na tecnologia. Aquele jogo com altíssima tecnologia em 3D em tempo real, som surround, atores de Hollywood e controles que não respondem direito jamais vai ser tão divertido quanto um jogo de Atari.

Se você quer fazer um jogo para se divertir, faça-o do jeito que você gosta. Se você quer fazer um jogo para ser vendido, faça-o do jeito que os outros gostam.

Todo mundo gosta de jogos de computador. Aquela pessoa que diz que odeia jogos de computador muito provavelmente não conhece o jogo que gosta.

Seja original no seu jogo. Ninguém joga aquilo que já enjoou. Há alguns anos atrás, li em uma matéria na antiga revista CPU MSX uma frase que guardo até hoje: “Não digo que você não possa fazer o seu próprio PacMan. Faça-o, mas de uma maneira diferente do que todos nós já conhecemos”. Lembre-se de que os jogos no mesmo estilo de sempre podem até vender, mas os jogos recordistas eram diferentes do conhecido: Tetris, Wolfenstein 3D, Asteroids, Space Invaders, Grand Theft Auto, etc.

No seu jogo, nunca mostre todos os elementos disponíveis de cara. Vá gradualmente introduzindo novas características… Este é o melhor caminho para manter o jogador preso. No momento em que as novidades acabarem, o jogo acaba para o jogador.

No caso de um jogo em que o usuário assume um personagem, é fundamental ter um bom personagem e um bom cenário. Ninguém irá querer personificar alguém sem graça, e nem tampouco entrar em um mundo sem nada de interessante.

– Este texto é de autoria de Leandro Correia, escrito em dezembro de 2003. Este texto pode ser distribuído livremente em qualquer meio, comercial ou não, desde que exibido sem alterações.

É preciso desenvolver um engine para o seu jogo?

UMA ABORDAGEM PELA PROGRAMAÇÃO ORIENTADA A OBJETOS VERSUS PROGRAMAÇÃO ESTRUTURADA

Quando se tem em mente o desenvolvimento de um software, deve-se passar necessariamente pela fase de projeto, onde as idéias a respeito do que se quer fazer são confrontadas com as possibilidades técnicas do grupo de desenvolvimento e uma síntese entre intenção e realidade irá nortear o processo de construção do código. Em se tratando de jogos, a coisa pode se tornar ainda mais complicada, pois geralmente esperamos muito mais de nossos programas do que aquilo que somos realmente capazes de realizar em curto prazo.

Essa fase de projeto de software pode ser traduzida em um detalhamento mais fino das atividades, entradas e saídas que o sistema irá comportar. Isso passa necessariamente por uma escolha primordial: programação estruturada ou programação orientada a objetos. A programação estruturada é aquela que nos permite detalhar o funcionamento de um programa através das funções e procedimentos que o compõem. A programação orientada a objetos nos permite uma outra hierarquia, mais rica e mais complexa, de estruturação, com classes que comportam métodos que podem herdar características de outras classes e assim consecutivamente. A ênfase que se dá ao projeto em programação estrutura é em relação à ação que uma determinada função ou procedimento irá executar, já na programação orientada a objetos a ênfase na fase de projeto se dá ao tipo de dados que se deseja obter e a forma como esses dados serão tratados pelo programa. São dois enfoques bem diferentes e que têm implicações de projeto que resultam em conceitos diferentes para um mesmo software.

Bem, deixemos momentaneamente a questão da programação estruturada e da orientação a objeto de lado para colocar em questão o que se entende por engine e qual deve ser o seu papel.

A palavra engine pode ser traduzida como “motor” ou “máquina”. Um engine pode ser entendido, de tal forma, como uma coletânea de código orientada à ação (execução de ações por parte dos elementos do sistema) que visa ser genérica o suficiente para que possa ser reaproveitada na construção de outros sistemas, enfim, de outros jogos que executem ações semelhantes. Veja que quando falamos de ação, não estamos apenas nos referindo a jogos de ação, mas sim a como um programa toma decisões em tempo de execução com base numa interação por parte do usuário. Essa definição difere consideravelmente do que podemos considerar uma biblioteca de software propriamente dito: uma lib é orientada ao suporte de tarefas de mais baixo nível que dão muito trabalho se forem reescritas a cada novo sistema desenvolvido, ou seja, não tem essa preocupação se ser orientada à ação.

Tomemos como exemplo jogos de RPG e pensemos no papel que um engine pode ter. Essencialmente, a estrutura de programação desses jogos é a mesma, mudando apenas o conjunto de regras que irá nortear o comportamento dos usuários e a forma como os mesmos irão interagir com o sistema. Se tivermos um código genérico o suficiente para passarmos como parâmetro as regras do jogo e as formas de interação, teremos um construído um engine que, de forma geral, pode nos auxiliar em todo o desenvolvimento de jogos desse tipo.

Visto isso, voltemos agora aos conceitos de programação estruturada e orienta a objetos.

A orientação a objetos surgiu como um novo paradigma em programação visando justamente resolver o problema de reaproveitamento de código e da manutenção desse código por pessoas diferentes. Como dissemos acima, a própria ênfase da orientação a objetos se dá nos dados que uma classe deve tratar, ou seja, nos dados que devem ser recebidos como parâmetros e aqueles que devem retornar de um método encapsulado por uma classe, o que torna a tentativa de generalizar o código muito mais eficiente do que na orientação estruturada.

É evidente que tal forma de programação exige disciplina e experiência, já que sempre iniciamos nosso estudo em programação pela forma estruturada e levamos certo tempo até compreender a forma como as classes podem ser estruturadas e vantagem que isso traz ao código final. Também é evidente que para desenvolvermos pequenos jogos, a forma estruturada é mais simples e, diria mais, até mais útil. Mas, a questão que fica, é que se pretendermos desenvolver um trabalho a longo prazo, visando produtividade de construção de código, parâmetros de qualidade na fase de análise do projeto, teste e manutenção, devemos sim nos preocupar em construir engines que sejam orientados a objeto e possam ser constantemente revisados para trazer o nível de generalidade que pretendemos alcançar. Logo, a resposta ao título do texto é: depende do porte e do desenvolvimento a longo prazo do projeto que se pretende criar.