Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualDareDeveloper

Posted 06 July 2013 - 07:06 AM

Sounds like a complex game. Have you considered using a more generic event system with an event bus?

 

The IO module could listen to the key events and store them in one keySequence object with a sequence map which is ordered and with the key identifier and the current state of the key (or a ring buffer of 5 key / key state pairs).

Now you'd have two options:

- fire a generic keySequenceChangeEvent on the event bus and let a complex eventListener react to the event

- let the IO module analyze the keySequence (create unique hash keys and lookup an event constant in a map), fire a specific userActionEvent and write several specialized (and more simple) eventListeners for those events

 

Guess in both cases that architecture would allow you to couple the modules more loosely and be more flexible later on. Several modules could react to a keyEvent without putting it all in the one "do something" block. They just need to have access to the event bus.


#5DareDeveloper

Posted 06 July 2013 - 07:05 AM

Sounds like a complex game. Have you considered using a more generic event system with an event bus?

 

The IO module could listen to the key events and store them in one keySequence object with a sequence map which is ordered and with the key identifier and the current state of the key (or a ring buffer of 5 key / key state pairs).

Now you'd have two options:

- fire a generic keySequenceChangeEvent on the event bus and let a complex eventListener react to the event

- let the IO module analyze the keySequence (create unique hash keys and lookup an event constant in a map), firing a specific userActionEvent and writing several specialized (and more simple) eventListeners for those events

 

Guess in both cases that architecture would allow you to couple the modules more loosely and be more flexible later on. Several modules could react to a keyEvent without putting it all in the one "do something" block. They just need to have access to the event bus.


#4DareDeveloper

Posted 06 July 2013 - 03:48 AM

Sounds like a complex game. Have you considered using a more generic event system with an event bus?

 

The IO module could listen to the key events and store them in one object with a sequence map which is ordered and with the key identifier and the current state of the key (might be important: released or pressed ... what about the state: user is still holding the forward key and has released the jump key?).

Now you'd have two options:

- fire a generic keyEvent / sequenceChangeEvent on the event bus and let a complex eventListener react to the event

- letting the IO module analyze the input sequence (create a unique hash and lookup an event constant in a map), firing a specific userActionEvent and writing several specialized (and more simple) eventListeners for those events

 

Guess in both cases that architecture would allow you to couple the modules more loosely and be more flexible later on. Several modules could react to a keyEvent without putting it all in the one "do something" block. They just need to have access to the event bus.


#3DareDeveloper

Posted 06 July 2013 - 01:42 AM

Sounds like a complex game. Have you considered using a more generic event system with an event bus?

 

The IO module could listen to the key events and store them in one object with a sequence map which is ordered and with the key identifier and the current state of the key (might be important: released or pressed ... what about the state: user is still holding the forward key and has released the jump key?).

Now you'd have two options:

- fire a generic keyEvent on the event bus and let a complex eventListener react to the event

- letting the IO module analyze the input sequence (create a unique hash and lookup an event constant in a map), firing a specific userActionEvent and writing several specialized (and more simple) eventListeners for those events

 

Guess in both cases that architecture would allow you to couple the modules more loosely and be more flexible later on. Several modules could react to a keyEvent without putting it all in the one "do something" block. They just need to have access to the event bus.


#2DareDeveloper

Posted 06 July 2013 - 01:41 AM

Sounds like a complex game. Have you considered using a more generic event system with an event bus?

 

The IO module could listen to the key events and store them in one object with a sequence map which is ordered and with and the current state of the key (might be important: released or pressed ... what about the state: user is still holding the forward key and has released the jump key?).

Now you'd have two options:

- fire a generic keyEvent on the event bus and let a complex eventListener react to the event

- letting the IO module analyze the input sequence (create a unique hash and lookup an event constant in a map), firing a specific userActionEvent and writing several specialized (and more simple) eventListeners for those events

 

Guess in both cases that architecture would allow you to couple the modules more loosely and be more flexible later on. Several modules could react to a keyEvent without putting it all in the one "do something" block. They just need to have access to the event bus.


#1DareDeveloper

Posted 06 July 2013 - 01:40 AM

Sounds like a complex game. Have you considered using a more generic event system with an event bus?

 

The IO module could listen to the key events and store them in one object: sequence maps, ordered and with and the current state of the key (might be important: released or pressed ... what about the state: user is still holding the forward key and has released the jump key?).

Now you'd have two options:

- fire a generic keyEvent on the event bus and let a complex eventListener react to the event

- letting the IO module analyze the input sequence (create a unique hash and lookup an event constant in a map), firing a specific userActionEvent and writing several specialized (and more simple) eventListeners for those events

 

Guess in both cases that architecture would allow you to couple the modules more loosely and be more flexible later on. Several modules could react to a keyEvent without putting it all in the one "do something" block. They just need to have access to the event bus.


PARTNERS