Pergunta

Estou tentando criar um sistema central de envio de eventos usando uma espécie de padrão Observer para meu pequeno projeto de RPG e preciso de conselhos sobre a melhor forma de representar os dados do evento.

Terei um EventManager que registra classes de ouvintes para diferentes tipos de eventos definidos em uma enumeração estática, como Event_Input_KeyPressed ou Event_Game_ActorMoved.Ele armazenará eventos em uma fila e os enviará para os ouvintes correspondentes, cada um com um método handleEvent(Event e) ou algo assim.

Cada evento será um objeto do tipo Event, que contém dados como o tipo de evento.

A minha pergunta é: uma vez que a natureza dos dados do evento difere consideravelmente entre os tipos de eventos, como estes dados devem ser representados?Ainda não tenho certeza exatamente que tipos de eventos irei querer criar no futuro, então quero que isso seja o mais flexível possível.Por exemplo, um evento pode desencadear outros eventos se certas condições forem verdadeiras (ou seja,quando o jogador pressiona a tecla de ação, uma porta se abre se o jogador estiver em um determinado local e tiver uma chave).XML ou scripts são uma boa escolha?Outra maneira que consigo pensar é criar uma classe personalizada para cada evento geral, como ActorEvent ou MenuEvent, mas isso parece realmente ineficiente e inflexível.Além disso, como alguns objetos como Character só precisam saber eventos muito específicos, como quando a tecla "w" é pressionada, acho que eles não precisam ser notificados quando outras teclas como "h" são pressionadas.É viável criar tipos de eventos tão específicos ou existe uma maneira melhor?ou seja.Evento_Input_KeyPressed_W

Obrigado

Foi útil?

Solução

  1. Crie implementações concretas de seus eventos, estendendo-se desde o Event objeto básico.Primeiramente será mais fácil distribuir os objetos - ou seja, na sua fila, você só precisaria fazer um instanceof para determinar como lidar com o objeto.
  2. Seu código de ouvinte de evento se torna MUITO mais simples e controlado de forma mais rígida.Não há chance de um evento de mouse passar para um evento chave.Além disso, você não precisará testar e lançar o objeto de evento no nível do ouvinte
  3. Não vejo por que você não poderia criar um ouvinte de evento "filtrado" que desejasse apenas ser notificado sobre uma condição específica de um evento específico; na verdade, acho que é uma ideia interessante.
  4. Eu provavelmente criaria algum tipo de mecanismo de despacho conectável.Isso significa que ao adicionar um novo tipo de evento, você não precisará atualizar a fila, basta registrar um novo despachante.Dependendo do que você deseja alcançar, sua fila passaria o evento para o despachante (fornecendo alguns meios para o despachante obter uma lista de ouvintes).O despachante determinaria se sabe como lidar com o evento ou não.O despachante então despacharia o evento para os ouvintes necessários (e dependendo do que você deseja alcançar), retornaria um resultado dizendo se o evento foi despachado ou não.

Isso é MHO

Outras dicas

  • Como você diz que a estrutura de diferentes tipos de eventos é diferente, é melhor criar classes concretas para cada evento.Você não precisa criar uma classe para cada chave!Mas geralmente eventos de teclado
  • Você diz que os personagens devem ser notificados apenas de uma chaves específicas.Eu não sei qual é a sobrecarga de notificar o personagem e deixar esse objeto ignorar chaves não relacionadas, mas se este é um padrão comum entre as aulas, por exemplo, você tem 10 classes diferentes que podem reagir a um conjunto especial de chaves, seria bomPara não repetir códigos e implementar uma camada de despachante entre eventos e ouvintes.Um tipo de separador pode ser keyfilterdispatcher que recebe uma lista de chaves e filtros eventos com base nisso.Outro tipo de despachantes pode ser seqdispatcher que só perturba os ouvintes se vários eventos são considerados em uma ordem específica! Eu gosto da idéia do disfastável plugável, disse Madprorammer.Também você pode querer criar tubos de despachantes também!
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top