Falando micro a micro
Num dia calmo, Batman e Sobrinho conversavam
sobre como fazer jogos multiplayer...

Batman, qual é o truque para colocar dois micros em comunicação via internet? Queria fazer um jogo para rodar em modo multiplayer, mas não sei nem por onde começar.

Ora sobrinho, não tem truque, mas apenas conhecimento e programação. O começo, já falei isso, fica sempre no começo.

Mas antes de "falar com o mundo" você precisa definir claramente o que entende por multiplayer e o que você quer que seu programa faça exatamente. Muita gente pensa logo em fazer o máximo, mas se esquece do básico: traçar metas e objetivos claros.

Por exemplo: vamos bolar um jogo de combate entre navios. Algo derivado do velho batalha naval, mas para muitos jogadores. Cada jogador será um comandante de navio. Não teremos "chefe" nem líder, mas grupos. Que tal? Parece bem legal, dito desta maneira, não é mesmo?

A primeira coisa a decidir é quanto à comunicação e seu tempo. O jogo online pleno, ou seja, todo mundo jogando ao mesmo tempo, é o ponto alto da programação multiplayer, mas não o único. De fato, ele embute em seu mecanismo alguns aspectos que precisam estar bem claros. Por exemplo? Por exemplo a necessidade de todo mundo estar disponível no mesmo instante.

Multiplayer não quer dizer necessariamente todo mundo online, mas sim uma estrutura tal que muitos jogadores colaborem para a realização de um só jogo (ou partida). Digo jogo, porque é cada vez mais forte a tendência de transformar os jogos via internet não em jogos multiplayers, mas em um grande jogo online. Um jogão abrangente. E para isso podemos lançar mão de todos os mecanismos e meios à nossa disposição para fazer os computadores "se entenderem".

A base de toda essa comunicação é o protocolo TCP/IP, que já está instalado no seu equipamento (claro, senão você nem estava acessando esta página). Mas não vou aborrecê-lo com detalhes técnicos sobre o protocolo, como ele funciona, até onde é confiável e o que a gente pode de fato fazer com ele (e acredite, podemos fazer coisas do arco da velha). Vou considerar que estamos usando o nosso velho Delphi, cuja versão 5 possui entre outros coisas um conjunto de componentes chamados FastNet que são "da hora".

Do protocolo TCP/IP o que nos interessa mesmo é o IP. Se você ainda não sabe, o IP é um número, dividido em quatro campos (200.210.50.32) que identifica o nosso computador na rede. Ele é único, ou seja, a sua máquina recebe um IP ao se conectar na internet e não existe, em nenhum lugar do mundo, outra máquina com o mesmo número. Daí é fácil, conhecendo o IP do destinatário, colocar duas máquinas em um link de comunicação.

Santos protocolos Batman, até aí eu já tinha chegado. Isso tudo é teoria. Eu quero saber na prática. Ali, na hora da verdade, como eu faço?

Ora sobrinho, ligue os pontos e conecte-se: a teoria serve para isso mesmo. Não tem truque algum. Mas, já que você quer ver a coisa acontecer de verdade, vou dar-lhe um exemplo:

1)- vá no Delphi e crie um componente TNMUDP (UDP para os íntimos). A seção é FastNet e o componente é o do microfone;

2)- No Object Inspector você verá 6 propriedades, das quais nos interessam de imediato três delas:

LocalPort - porta local (no seu micro) usada para a comunicação;

RemotePort - porta remota (no micro do seu amigo), usada para a comunicação;

RemoteHost - "endereço" IP do micro do seu amigo.

O RemoteHost é óbvio, não é? Ele conterá o IP do computador com quem desejamos nos comunicar.

Mas, mas, mas Batman, não é uma boa ficar por aí dizendo qual é o nosso IP. Podem existir pessoas que queiram invadir nosso computador.

Ora sobrinho, deixe de histeria. Saber qual é o IP de quem está conectado é a coisa mais fácil do mundo. Além disso, seu problema maior nem é tornar seu IP público, mas ter-se conectado à internet sem um mínimo de cuidados. Mas, para não dizer que está todo mundo com medo do bicho papão errado e preservar o seu IP (e a sua neurose), use um redirecionador qualquer. Tem um monte deles na internet e geralmente são "di grátis".

Mas entenda bem: o redirecionador é uma mão na roda para não termos que ficar avisando nossos amigos toda vez que nosso IP muda (numa conexão discada, ele muda toda vez que você entra na rede). Ele não acrescentará, em termos de segurança, muita coisa ao seu computador.

Entendi Batman, mas como eu faço para trocar por exemplo o IP por um "nome internético", do tipo www.meumicro.cbj.net? Não tem que consultar um lugar, para fazer a identificação? Como funciona isso?

Aí é que está toda a beleza de usar pacotes como o Delphi: esse "servicinho" básico ele faz para a gente. Na verdade, na propriedade RemoteHost tanto faz colocar o IP como o domínio do destinatário: o componente "encontra" o destinatário sozinho (ele sabe como fazer isso e isso é tudo o que nos interessa por enquanto).

Santas conexões Batman. E quanto às portas? Essa eu não entendí direito.

Um computador pode usar o seu IP para conectar-se a um sem número de outros computadores. Mas precisamos de algo para manter a ordem nesta comunicação, senão o seu programa recebe uma mensagem que era para ir para o navegador, por exemplo.

Daí que existem 65.536 "portas" de comunicação, pelas quais podemos nos ligar a outros micros. Escolhemos uma de comum acordo e fim de papo.

Qualquer uma?

A rigor sim, mas evite as portas "baixas", ou portas declaradas. Por exemplo: a porta 80 é usada para acesso à web; a porta 110 é para e-mail (se não me falhe a memória). Se escolher um valor acima de mil, só por muito azar irá escolher uma que já esteja em uso.

Legal, e como "troco" informações com o outro computador?

Usando um método para mandar e um evento para receber. Por exemplo, coloque isso em uma procedure (a procedure será usada para mandar mensagens para o computador amigo).

procedure Enviar(msg: string);
var
  MyStream: TMemoryStream;
Begin
  Form1.UDP1.RemoteHost:= '200.210.30.25';
  Form1.UDP1.RemotePort:= 7000;
  Form1.UDP1.LocalPort:= 7000;
  MyStream:= TMemoryStream.Create;

  try
    MyStream.Write(Msg[1], Length(Msg));
    Form1.UDP1.ReportLevel:= Status_Basic;
    Form1.UDP1.SendStream(MyStream);

  finally
    MyStream.Free;
  end;
end;

Bico, não é? SendStream manda a nossa mensagem para o endereço IP desejado. Uma espécie de "mala direta": o correio não informa se entregou mesmo a mensagem, se ela não se perdeu no caminho, se chegou intacta ou se chegou na ordem certa. O UDP, que é um subset do TCP/IP não é nada confiável, mas é rápido como um tiro laser. Dificilmente se perde e as vezes que isso acontece, bem, vale a pena o risco. Digamos que para o nosso jogo, foi um tiro que deu "água", na sorte.

Para receber a mensagem, você precisa de um evento: OnDataReceived, ou seja, quando a mensagem chega no computador destino ele "apita":

procedure TForm1.UDP1DataReceived(Sender: TComponent; NumberBytes:   Integer; FromIP: String; Port: Integer);
var
  MyStream: TMemoryStream;
  Msg: String;

begin
  MyStream:= TMemoryStream.Create;
  try
    UDP1.ReadStream(MyStream);
    SetLength(Msg,NumberBytes);
    MyStream.Read(Msg[1],NumberBytes);

  finally
    MyStream.Free;
  end;
  //... Aqui a variável Msg já contém a mensagem
  //recebida - o que fazer com ela
  //fica por conta de cada programador.

end;

Pronto, está aí seu "comunicador" universal, para falar via internet com todas as pessoas do planeta cibernético.

Legal Batman, já vou testar e fazer o meu jogo multiplayer. Só tem um problema: reunir a galera para fazer e testar a comunicação. Além de encontrar todo mundo, vai ficar caro né? Digo, a conta do telefone.

Calma sobrinho. Para tudo nessa vida tem um remédio. Você não precisa "gastar" telefone para escrever e testar seus programas multiplayers, mas usar um pequeno truque (tá, reconheço: tinha um truquezinho escondido na manga).

Lembre-se que estamos nos comunicando por IP, logo, a sua máquina tem um IP. Se enviar a mensagem para o seu próprio IP, ela chega. O mecanismo é o mesmo.

Mesmo se eu não estiver conectado?

Não precisa nem estar conectado sobrinho. Reservou-se um IP só para isso: 127.0.0.1, ou seja, esse IP é chamado de IP local - a sua própria máquina. Mande uma mensagem para ele e você estará falando consigo mesmo. Assim você escreve suas rotinas e vai testando-as sem gastar telefone. Se estiver conectado em uma rede local, melhor ainda: cada computador tem um IP dentro da rede. Você "fala" com o vizinho e já vai corrigindo os bugs do programa.

 
online