Na criação de jogos multiplayers é comum iniciar o trabalho "copiando" uma idéia de algum jogo conhecido. Não é que copiar seja ruim na sua essência, afinal ao copiar alguma coisa nós aprendemos também. Mas é preciso compreender o que se copia, para que a experiência seja válida e instrutiva. No lado oposto temos a geração expontânea de uma idéia; algo que simplesmente surge do nada: "ah, tive uma idéia...".

No mundo profissional e principalmente no mundo onde pretendemos ter algum resultado concreto, principalmente no campo da originalidade, a coisa não funciona muito bem assim. Não se deixa nada ao acaso. Pelo contrário: no mundo profissional usa-se o planejamento, traduzido na forma de projeto. Não se cria um jogo; projeta-se um jogo.

Para projetar um jogo é preciso compreender inicialmente (partindo dos propósitos do mesmo) a mecânica que será aplicada. Vamos trilhar o raciocínio inverso, para entender o conceito: no jogo Counter Strike o que está em evidência é a exploração daquele nosso instinto guerreiro, de matar o inimigo e proteger nossos aliados. Não estou discutindo aqui se isso é bom, ruim, certo, errado ou violento, mas apenas constatando o fato: a estrutura funcional do jogo foi moldada para expor essa nossa característica e pelo sucesso que o mesmo atingiu podemos concluir que acertaram na medida.

A questão é: como chegamos a isso, partindo do zero (e portanto dentro de um planejamento de produção de um jogo)? Primeiro precisamos decidir que elementos ou características vamos explorar: amizade, convivência, sociabilidade, cooperativismo, agressividade, rebeldia, etc. A partir daí montamos um modelo ou protótipo para entender os mecanismos e explorá-los na forma de um desafio.

Para ilustrar vou usar o cooperativismo (já que agressividade e rebeldia foram amplamente explorados comercialmente). Precisamos criar um jogo que reflita essa característica: pessoas cooperando para um resultado comum.

O melhor grupo de avaliação para isso pode ser montado numa rede local ou até mesmo em uma lan house, para que a dinâmica do experimento seja potencializada ao máximo. Agora só falta criar o modelo e o objetivo precisa ser simples e claro, para que dele possamos extrair lições. Daí nasceu a idéia do gado, solto em um pasto, tendo que ser reunido pelos peões. O propósito do modelo é descobrir quais os elementos que podem resultar em um jogo divertido, instigante e principalmente que agrade às pessoas.

Bem, o jogo eu ainda não fiz, mas o modelo experimental está aqui, operacional, e pode ser usado por qualquer um. Pode ser inclusive adaptado para refletir outras realidades ou testar outras características. Vamos a ele?

Usaremos apenas dois Forms, um TImage e um TBitmap, um TTimer e dois TNMUDP. O resto é firula. Com isso montamos a estrutura do modelo funcional de avaliação. O TImage (Tabul) e o TBitmap (Buf) serão usados para montar o tabuleiro do jogo, ou seja, o pasto. Nele, o gado, representado por um quadrado estará "pastando" livremente. Os vaqueiros, ou peões, são círculos que também estarão em movimento, embora numa velocidade maior que a do gado. O controle do jogador (teclas de setas) atua apenas na mudança de direção. As cores são usadas para identificar os vaqueiros e o gado que ele está (tentando) reunir.

Um controle adicional foi colocado na barra de espaço, o qual provoca o aparecimento de uma cerca na posição atual do vaqueiro e que serve como obstáculo para a livre movimentação do gado. O objetivo portanto é reunir a boiada, quer seja marcando-a toda com uma única cor, quer seja confinando-a em áreas cercadas. Mas isso (repito) não é o jogo e sim o experimento.

O que vamos estudar aqui é como as pessoas, ou um grupo de pessoas, reage a este desafio. Será que elas se unirão para facilitar o trabalho de reunir o gado? Ou será que acabarão competindo entre sí para ver quem "pega" mais bois? Qual das duas opções é a mais divertida? Você sabe?

Se sabe, parabéns: é um iluminado. Se não sabe, não perca tempo tentando adivinhar. Reúna os amigos, rode o modelo e estude as reações deles. Discuta, debata, troque "achismos", experimente criar limitações e extraia daí conceitos que possam ser aplicados em um jogo multiplayer que você pretende fazer em breve. Quem sabe não será exatamente este o diferencial que fará seu jogo se tornar um sucesso de público.

:: Como funciona o modelo

Clique aqui, baixe o zip com o executável e coloque uma cópia em cada máquina da rede. Um dos participantes será o servidor. Basta clicar no tabuleiro que o Form de comunicação será mostrado. Ligue o servidor e nas demais máquinas basta apenas entrar no pasto. Clique no tabuleiro para esconder a janela de comunicação e devolver o foco para o controle do peão.

O modelo usa as portas 17361 e 17362, para a troca de pacotes. Se a rede tiver proteção ou firewall, você precisará desbloqueá-las para que o modelo funcione ou então alterar o fonte e recomplilá-lo para usar uma porta livre (aberta).

:: A parte técnica

O sistema de controle fica concentrado no servidor, que faz os respectivos procedimentos e verificações e envia comandos aos clientes para que reproduzam a mesma cena em todas as máquinas. Um dos componentes UDP funciona como cliente e outro como servidor. Toda a comunicação e forma de interpretar os comandos já foi amplamente apresentada de debatida no club TILT, portando não há nada a acrescentar.

Clique aqui e baixe o zip com os fontes para Delphi. As partes mais importantes estão comentadas, para que você possa fazer alterações com segurança. No caso de dúvidas, não se acanhe em perguntar afinal, estamos aqui para isso mesmo.