Apesar de ter dito no meu blog pessoal que eu estava interessado em C# e Flash (ainda estou), vira e mexe surge na minha mente que eu tenho de criar um jogo da memória em Java. Talvez pela linguagem ser melhor do que o Visual Basic e para treinar um pouco eu decidi tentar. Obviamente eu ainda não comecei, mas optei por ir postando o andamento da construção desse jogo aqui no GamedevBR, com artigos técnicos. Além disso, como vocês tem mais experiência do que eu, vocês podem até me ajudar com dicas que outros leitores podem aproveitar também!
Tá, e se você ainda não começou, pra quê este texto então? Simples: pra começar a citar os pré-requisitos para criar um game desse tipo. Um erro clássico de quem pensa em programar algo é que ninguém planeja e já sai criando. Sei que para um game de memória não é necessário ter um planejamento elaborado, mas para quem pensa em seguir na área de gamedev, ter pelo menos um rascunho é essencial pro desenvolvimento não se perder no meio do caminho.
Para este primeiro texto, vou comentar dos pré-requisitos iniciais da linguagem. Inicialmente, irei criar um game com 10 posições, totalizando 5 pares de 2 cartas cada. Imaginar o tabuleiro é fácil pra quem já jogou um game desse tipo antes: basta pensar em 10 imagens simulando cartas de baralho, sendo 5 numa fileira e 5 na fileira de baixo. Dependendo da lógica que for empregada, dá pro game aumentar o nível de dificuldade, para 10 pares, totalizando 20 cartas. Acima disso pode ser insano, até mesmo para quem tem memorização aprimorada. Mas é uma opção para o futuro.
Só isso já bastaria? Claro que não. Agora, o pulo do gato é fazer pelo menos as imagens aparecerem na tela. Isso é um pré-requisito básico.
Bom, você pode fazer usando vários métodos, já que isso vai depender da linguagem em si. O problema é que existem complicações operacionais. Primeiro: você tem de ter as imagens e isso pode ser um problema pra quem não manja de edição de imagens. É claro que o programador pode pedir pra algum amigo que manja de Photoshop criar as imagens: você não vai por exemplo tacar as imagens de qualquer jeito no jogo! Se fosse assim o jogo seria ruim e mesmo que você tenha orgulho da sua criação um possível empregador de gamedev pode achar o jogo graficamente ruim (quando for ver o seu portfólio).
Mas é um jogo da memória! Sim, mas se o jogo for bem feito, isso ajuda, não é? Com imagens decentes, bem editadas. Tudo faz parte do pacote. A área de desenvolvimento de games é, em parte, artística: você está criando games. Eles tem de estar pelo menos bonitos aos olhos do jogador. Não quer dizer que só os games de ponta hoje são bonitos por serem em 3D. Até mesmo computadores não tão potentes dá pra mostrar coisas mais definidas. Tem muito game simples que é artisticamente belíssimo e não demanda de tanto processamento gráfico e programação difícil. Games que divertem pra caramba. Mesmo pensando em criar algo usando a GUI básica da linguagem, eu quero pelo menos o jogo fique agradável aos olhos do jogador. Algo bem feito, que demore mais pra criar, é muito melhor do que ter algo criado correndo só pra fazer volume e passar pro próximo projeto.
OK, temos as imagens já editadas e vamos inserir elas no jogo. Pelo que eu já cheguei a mexer em Java, dá pra você fazer isso de 2 maneiras: chamar a imagem direto no HD ou inserir ela no executável de distribuição do jogo. Cada linguagem tem a sua particularidade nisso: em linguagens normais como o C++, Delphi e Visual basic, você gera um exe que acaba sendo for Windows. No C++ dá pra compilar pra Linux, mas pra isso você tem de recompilar o seu jogo pra deixar com o código nativo. Em Java temos o JAR, que serve muito bem para isso, além de ser um arquivo multi-plataforma: a máquina virtual que estará instalada no sistema operacional vai ler o arquivo e interpretar do mesmo jeito, abrindo o seu jogo. Obviamente que dependendo do código que você gerar pode haver complicações, já que se você usar uma função do Java 6, talvez máquinas virtuais antigas podem não ler certas funções do seu jogo e dar erro.
Então eu posso colocar um pré-requisito mínimo de máquina virtual, que será a que eu for usar. Mesmo que só use funções nativas do Java 5 (por exemplo), melhor colocar que o jogo rodará melhor no Java 6. Em parte isso é um serviço mediano, já que um desenvolvedor terá de testar a aplicação em diferentes máquinas virtuais pra saber se ele vai prestar ou não. Como estarei fazendo um estudo de desenvolvimento, quando for postar os primeiros builds aí sim que irei receber os primeiros feedbacks. E isso é uma desvantagem do desenvolvimento de games pra PC: você tem milhares de configurações diferentes dos jogadores e nem sempre um game vai rodar direito em TUDO. Num console a situação muda de figura: você estará desenvolvendo pra um hardware específico e com isso usará apenas as funções nativas próprias pro sistema-alvo. Não existem 2 consoles Xbox 360 diferentes tecnicamente (salvo o tamanho do HD, o processador e acessórios externos): é um console que tem um coração gráfico idêntico.
Bom, deixando de lado a parte de EXEs e JARs, temos novamente a questão das imagens. Você pode chamar elas no HD ou de dentro do seu build. No primeiro caso, temos uma vantagem e uma desvantagem. A vantagem é que o jogo pode ser expandido, bastando o jogador tacar a imagem direto numa pasta específica do jogo. Ou o próprio desenvolvedor pode fazer isso, usando algum instalador que jogará as imagens para esta pasta. A desvantagem é que se a imagem estiver numa pasta específica, algum jogador sacana pode apagar as imagens e abrir o jogo pra ver o que pode acontecer. Com certeza o jogo pode apresentar erros ou você pode evitar isso, conferindo se a pasta tem um número x de imagens. Se estiver correta, ainda tem a questão dos nomes das imagens e se todas estiverem com o mesmo tamanho em pixels de largura e altura. Se o jogador trocar a imagem, o jogo pode apresentar problemas. É, a vida é dura!
Outra questão da imagem no HD é o nome da imagem. O desenvolvedor pode colocar nomes próprios (algo como lara_croft.jpg ou mario.jpg) ou colocar nomes-estranhos, como imagem001.jpg, imagem002.jpg e assim por diante. Aí se o código do jogo tiver chamando o nome específico, vai dar um erro de “arquivo não encontrado”. Ou ele pode fazer um loop como for a=1 to numero_imagens { call carregue_imagem(“imagem_” + a) }. Aí se faltar uma imagem, o jogo pode dar problemas. No último caso dá pra pegar as imagens aleatórias e quanto mais imagens na pasta, mais variedade o tabuleiro poderá ter. Assim o jogador não irá cansar do jogo.
Pode achar paranoía se preocupar com o que o jogador poderá fazer nas pastas internas do jogo, mas para um programador, ele tem de pensar nisso. Tem de pensar em todas as possibilidades possíveis do jogador, desde ele apagar uma pasta específica até mesmo zoar com as imagens. É claro que a maioria nem vai se tocar desse negócio e vai apenas jogar, mas e os que sabem mais de informática? Muito desenvolvedor iniciante de games já deve ter tentado extrair um vídeo de uma pasta de um game que ele comprou. Ou ele deve ter comprado o GTA Vice City pra PC e deve ter colocado numa das pastas músicas de heavy-metal pra escutar enquanto ele está dirigindo um carro. Eu mesmo já fiz isso!
E tem a questão de chamar direto no build. Vantagem: as imagens sempre estarão lá. Desvantagem: o jogo pode não ser expandível, sendo que para ele ser expandível o desenvolvedor terá de trocar o EXE caso queira que o jogador tenha mais opções de cartas. É claro que se der pro próprio jogador a opção de expandir, explicando que ele pode inserir mais imagens na pasta do jogo, ele olhará o seu jogo com outros olhos. Ou você pode ser mais profissional e criar um módulo de geração de cartas, com um pequeno editor de imagens dentro do jogo. Algo similar ao editor de imagens do Orkut: você upa a imagem e dá pra pegar apenas uma parte dela, selecionando aquela parte e salvando a mesma. Dá mais trabalho, mas o trabalho será mais recompensador. Talvez o próprio desenvolvedor use o editor pra criar as imagens. Dizem que as fases do story-mode do LittleBigPlanet (criadas pela equipe da empresa) foram feitas usando o editor interno do jogo. Isso é algo a mais no jogo que pode fazer a diferença.
Bom, to vendo que o texto tá gigante e ainda nem pensei na parte de programação do jogo. Isso ficará pra depois, já que eu já escrevi demais 😀 Em breve a continuação da série de posts, com um planejamento melhor do que eu posso fazer e quem sabe algumas dicas de desenvolvimento. Mesmo que eu já tivesse o jogo pronto, a gente está sempre aprendendo coisas novas. Ter a mente aberta é algo que ando tentando ter, mesmo que eu seja um pouco fanboy do Java e do Playstation 3.