Timeline for Need some advice on how to decide where to implement my enemy behaviours
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 30, 2016 at 16:15 | comment | added | James Moore | The enemy entity handler would recieve the message type PlayerKick, would cast the message payload to OnPlayerKick which has a collision object. The entity will then process the collision object to see if it applies to itself and then reacts accordingly. This means each enemy can use the same code to handle this and the ones it doesnt apply to can throw it away. This alongside something like a quad tree to only send it to objects within a certain quadrant of the scree etc. makes this a viable approach for the OP | |
| Jun 30, 2016 at 15:04 | comment | added | Nikaas | I mean if player kicks and each and every enemy is interested in being kicked but only 3 enemies fall into its kick? Each time different amount and instances of "enemy" are withing range. | |
| Jun 30, 2016 at 14:57 | comment | added | James Moore | @Nikaas I think you missed the part where I mentioned the event manager where entities register for the event types they are interested in. This covers option 2. Tight coupling is never a good thing. | |
| Jun 30, 2016 at 14:39 | comment | added | Nikaas | I'm new to coding and game-dev but I still think this approach is not the best when very small and variable number of all recipients will actually be interested in the event. I think that 1. "sender" should determine the "recipients" (tighter coupling) or 2 "recipients" on their own decide if they are interested in "listening" based on certain conditions (redundant checks). Actually thinking about it: events can work if receivers have a way to additionally check and determine if the just received event is truly intended for them. | |
| Jun 30, 2016 at 10:28 | comment | added | James Moore | Good question. I would have a thread safe method on the derived kick event class to set the event as a one-off i.e. the first entity to receive it uses it up. and after that any other entity who receives the event cannot do anything with it. Of course this could be extended further to ensure that for instance the entity who tries to process the event first is within hitting distance of the players kick etc. | |
| Jun 30, 2016 at 9:59 | comment | added | Patrick | I like this answer, But if for example, the kick can only affect a single enemy, you would run into problems, strictly out of an academic interest, how would you solve that using an event driven approach? you could argue that a kicked enemy can dispatch a "gotKicked" event with the kickID (to make sure it's not used again), but wouldn't that expose a race condition of sorts? | |
| Jun 30, 2016 at 7:50 | history | answered | James Moore | CC BY-SA 3.0 |