Segunda-feira Jul 27, 2009

Tutorial Projeto Darkstar (parte VI)

Você deve ter percebido o botão de Chat no canto inferior esquerdo da tela de jogo. Você pode inclusive utilizá-lo, mas infelizmente os outros jogadores ainda não vêem o que você está escrevendo. Estabelecer essa comunicação é nosso objetivo no último post deste tutorial. Veja como é simples:

Tudo que precisamos fazer é implementar o método chatMessage(..) na classe SnowmanPlayerImpl:



É isso. Simples, não?

Teste agora os resultados. Rode o servidor, inicie uma partida entre dois clients e tente uma comunicação. Agora seu oponente já consegue ver o que você escreve:



Bom, o tutorial vai ficando por aqui. Espero que tenha sido útil para estabelecer um primeiro contato com o Projeto Darkstar. Sei que algumas dúvidas, principalmente sobre a implementação de alguns métodos, devem surgir. Lembre-se de que uma versão bem mais completa (em inglês) deste tutorial está disponível no site oficial do projeto (http://projectdarkstar.com), pois trata-se de um Hands On Lab realizado no último JavaOne. No site você encontra também toda a documentação necessária para aprofundar seus estudos.

Até mais! 

Tutorial Projeto Darkstar (parte V)

Até agora, nosso servidor aceita conexões de múltiplos clientes e os combina dois a dois para criar novas partidas. No entanto, ainda são poucas as mensagens enviadas pelo cliente que geram os efeitos esperados no status do jogo. Nesse post vamos tornar nosso servidor apto a interpretar duas dessas mensagens que são cruciais: MOVEME e ATTACK.

Começamos pela implementação do método protected moveMe(..) na classe SnowmanPlayerImpl. Nosso objetivo é fazer com que as mensagens MOVEME enviadas por um cliente sejam interpretadas e gerem modificações no status do jogo. O método deve ser algo como: 



Vamos agora ver o resultado desta implementação. Rode o servidor e conecte dois clients para que partida seja iniciada. Veja que, agora, a movimentação de um jogador pode ser observada na tela de seu oponente.


O próximo passo é implementar o método protected attack(..), para que as mensagens ATTACK enviadas por um cliente também tenham efeito no jogo:



Voilá! Teste novamente o jogo. Ele deve estar funcionando com movimentos e ataques ao adversário.

No próximo (e último) post, vamos implementar a ferramenta de chat entre os jogadores!

Tutorial Projeto Darkstar (parte IV)

Nesta parte do tutorial, vamos melhorar nosso servidor adicionando funcionalidades que permitirão manter status de jogos e coordenar o início dos mesmos. Isso permitirá que o servidor aceite a conexão de novos clients e inicie uma nova partida para cada dois novos jogadores conectados.

O primeiro passo será analisar o comportamento do Project Snowman do ponto de vista do servidor. Esse comportamento é coordenado por um conjunto de interfaces encontrado em Project Snowman Server -> Source Packages -> com.sun.darkstar.example.snowman.server.interfaces. Vamos analisar cada uma dessas interfaces separadamente:

DynamicEntity: É a interface que define a base de funcionalidades para objetos em movimento no jogo. Em nosso caso, tais objetos são jogadores e bandeiras.

SnowmanFlag: Como o nome já sugere, esta interface representa uma bandeira, que pode ser movida e carregada no campo de jogo.

SnowmanPlayer: Interface que representa um jogador. Cada cliente conectado é associado a um único SnowmanPlayer.

SnowmanGame: Representa uma partida que está sendo jogada entre múltiplos SnowmanPlayer's com múltiplas SnowmanFlag's.

EntityFactory: Interface utilizada para fabricar SnowmanPlayer's e SnowmanFlag's.

GameFactory: Interface utilizada para fabricar SnowmanGame's.

No post anterior, configuramos nosso servidor para que se fosse possível iniciar uma partida, ainda que com apenas um jogador e sem bandeiras. O que queremos agora é fazer com que cada vez que dois jogadores se conectem, uma nova partida seja iniciada. Para isso, o servidor deve adicionar a uma lista o jogador que se logou mas espera um companheiro para jogar. No momento em que o segundo jogador conectar-se, o protocolo de comunicação estabelecido (veja o post anterior) é usado para dar início a uma nova partida.


Agora, quando rodarmos nosso servidor, queremos que os seguintes dados sejam inicializados:

- Um EntityFactory para criar jogadores e bandeiras.
- Um GameFactory para criar SnowmanGame's cada vez que uma partida for iniciada.
- Uma List de objetos ManagedReference que representa SnowmanPlayer's esperando uma nova partida.
- Um int que funciona como contador de partidas iniciadas.

Adicionamos então as seguintes modificações à classe SnowmanServer.java:

Atributos:

     private EntityFactory entityFactory;
     private GameFactory gameFactory;
     private List<ManagedReference<SnowmanPlayer>> waitingPlayers;
     private int gameNumber;

Método initialize(..):

     public void initialize(Properties props) {
         this.entityFactory = new EntityFactoryImpl();
         this.gameFactory = new GameFactoryImpl();
         this.waitingPlayers = new ArrayList<ManagedReference<SnowmanPlayer>>(2);
         this.gameNumber = 0;
     }

Agora, para que uma partida seja iniciada sempre que dois jogadores se conectem, modificamos o método loggedIn(..):


Até o momento, nosso servidor só consegue interpretar mensagens do tipo READY vindas do cliente. Vamos agora aprimorar nossa classe SnowmanPlayerListener para que outros tipos de mensagem possam ser interpretados. O primeiro passo é modificar o método receivedMessage(..):



Implementando o método disconnected(..), tratamos o caso em que o cliente é desconectado:



Vamos agora implementar a classe que de fato coordena e mantém o status de todas as partidas. Acesse o arquivo SnowmanGameImpl.java em Project Snowman Server -> Source Packages -> com.sun.darkstar.example.snowman.server.impl e modifique seu construtor:



Devemos também implementar o método sendMapInfo(), que envia informações de coordenadas aos clientes:



Tente agora rodar o servidor (lembre-se de limpar o projeto primeiro!) e dois clientes. Se todos os passos acima foram seguidos sem problemas, você verá agora os dois jogadores logados na partida e suas respectivas bandeiras.

Porém, ainda temos uma série de limitações. Note que o movimento de um jogador não é refletido na tela do outro cliente, uma vez que  nosso servidor ainda ignora as mensagens MOVEME. Essa é uma tarefa para o próximo post!

About

Thiago Sá é estudante de graduação de Engenharia de Teleinformática na Universidade Federal do Ceará e atualmente exerce a função de Embaixador de Campus da Sun Microsystems em Fortaleza, CE.

Search

Archives
« Julho 2014
SegTerQuaQuiSexSábDom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
   
       
Today