Tópicos de O.O. - Design Fest - Grupo M-2

Tarefa: MultiBatt - The Outer Space Battle Game

Componentes do grupo M-2:

Nome	Numero USP	Email
Alex Minoru Kusano	3286179	alexmk@linux.ime.usp.br
Daniel de Angelis Cordeiro	3286158	danielc@linux.ime.usp.br	Moderator
Flavia Rainone	3286141	fla@linux.ime.usp.br
Marcos Roberto Yukio Koga	3312021
Rafael de Andrade Jardim	3286162	varas@linux.ime.usp.br	Recorder
Rodrigo Moreira Barbosa		barbosa@linux.ime.usp.br
Stefan Neusatz Guilhen		sngim@linux.ime.usp.br
Tiago Tagliari Martinez	2253604 -- Pos	tiagotm@directtalk.com.br

O que tiramos de bom do Design Fest

Diagramas e Padrões

Algumas considerações e problemas levantados pelo grupo :

Problemas:

Usar MVC, e atualizar as paginas por padrão Observer?
    -Manter um estado central no servidor e usar MVC, atualizando os clientes através do padrão Observer?
   - Ou manter vários estados, um em cada cliente, sendo que cada estado é atualizado pelo servidor e também atualiza o estado central?

Controle das naves :
    _Como o controle das naves deverá ser feito? No cliente ou no servidor? Em outras palavras, o cliente só envia as teclas apertadas e o servidor atualiza a situação da nave, ou o cliente trata o pressionamento de teclas alterando ele a situação da nave no servidor.

Problema de sincronia nos clientes.
   _Como manter todos os clientes sincronizados?

Tipo de informações que deveriam ser passadas aos clientes:
   _ O que a nave fez?
   _ Estado geral da nave?
   _ Ou os dois?

Manter os torpedos no modelo do jogo ou no Servidor?
   _ Esta duvida foi levantada porque a trajetória do torpedo é facilmente determinada.

Asteróides: Lugar fixo ou aparecer aleatoriamente em qualquer lugar?

Explosões:
   _ Quando ocorrem? Devem ser consideradas como mais uma classe que herde de Elemento ou apenas um estado de cada objeto que possa explodir? E quando morrem devem receber todas as pontuações?

Pontuação:
   _ Qual pontuação o cliente deve ver em sua tela durante o jogo? A de todos os jogadores ou apenas a sua?

Chat como implementar:
   _ Mensagens com Id e o cliente decide quais ele já mostrou e quais não mostrou, para então mostrar ?
   _ O servidor decide quais e quantas mensagens serão colocadas na tela?

Tipos de jogos:
   _ Como seria feita a entrada dos jogadores em uma sessão de jogo? Teria-se um tempo limite para a entrada apos a sessão ser criada, ou se poderia entrar a qualquer hora.
   _ E a contagem dos pontos de cada jogador?
   _ Foi levantada a hipótese de extensão do jogo para um modo de times, como um policia e ladrão, assim o jogo acaba quando um time é morto por completo.

Tecnologia de comunicação:
   _ Qual tecnologia será usada na comunicação cliente - servidor ?
   _ O desacoplamento do sistema deve ser total, como uma nova classe na UML que represente a “camada rede”?
   _ Ou devemos explicitar quais objetos serão disponibilizados remotamente, como em JAVA-RMI ou CORBA?

Decisões:

    •  Todo processo ocorre no servidor e o cliente tem apenas as camadas view e controler. Seria mais fácil controlar a interação entre as naves, e seria passado ao cliente, a cada intervalo controlado pelo servidor, não só o estado da nave, mas tanbém uma foto geral da situação, com o estado de cada nave e dos elementos, tais como torpedo, asteróides, etc...Este tipo de atualização foi escolhido porque o jogo é pequeno e muito dinâmico. Essa solução seria mais viável em redes locais, porque no caso da Internet haveria sobrecarga e maior incidência de perda de pacotes.
    •  Os asteróides serão controlados por um módulo do sistema a fim de permitir facilmente a mudança de algoritmo que controla sua aparição: onde e em que quantidade.
    •  As explosões acontecerão entre quaisquer dois tipos de elementos do sistema: nave com nave, nave com asteróide, torpedo com torpedo, etc... Essas explosões serão tratadas de forma padrão como um estado de cada elemento, estado esse que antecipa sua morte. A explosão não é tratada como elemento do estado.
    •  O servidor então irá receber os sinais das teclas pressionadas, repassadas pelos clientes, para todo tipo de comando: mudança na direção, velocidade ou disparo de torpedos. Então o servidor devolve um objeto mapa para que o cliente o interprete e desenhe na tela o estado do jogo. Esse envio de atualização é realizado para todos os clientes indiscriminadamente.
    •  O servidor também terá a lista de clientes conectados a ele, esta lista será usada para atualizar mensagens aos clientes como as pontuações e também para que o servidor de partidas possa controlar qual jogador está em qual sessão e por conseqüência atualizar tais jogos.
    •  A pontuação de cada jogador é constantemente enviada ao seu dono durante o jogo todo. Só esta pontuação lhe será enviada, pois as n maiores pontuações da sessão só estarão disponíveis assim que o jogador morrer.
    •  Sobre a jogabilidade, decidiu-se por deixar a sessão aberta enquanto houver alguém lá dentro e todos poderiam entrar e sair quando quisessem, assim os pontos do jogo seriam computados levando-se em consideração o tempo de permanência e número de mortos por cada jogador.
    •  Sobre o chat decidiu-se que o servidor manterá uma fila de mensagens e as enviará aos clientes. Além disso, haverá um numero nmax de mensagens a serem enviadas ao cliente por vez.
    •  A tecnologia da comunicação cliente servidor será a de JAVA - RMI.

Divisão do Jogo:

Partes: Sessão de jogo, estado do jogo, algoritmo de inteligência.

Sessão de jogo: poderá haver uma ou mais “salas” de jogos no servidor, ao entrar no jogo o cliente terá uma tela de capa onde ele poderá optar por criar uma nova sala ou entrar em uma existente e que não tenha estourado o limite máximo de jogadores.
Estado do jogo: guarda constantemente o estado de todos os elementos do jogo, sendo atualizados pelo algoritmo de inteligência. De tempos em tempos, tira-se uma foto deste estado e envia-se ao cliente.
Lógica do jogo(algoritmo de inteligência): usa uma classe só (um módulo) bem organiza da em métodos ou funcionalidades.