Multiple objects listening for the same key press

Question

I want to learn the best way to implement this:

I have a hero and an enemy on the screen. Say the hero presses "k" to get out a knife, I want the enemy to react in a certain way.

Now, if in my game loop I have a listener for the key press event and I identify a "k" was pressed, the quick and easy way would be to do:

// If K pressed
// hero.getOoutKnife()
// enemy.getAngry()

But what is commonly done in more complex games, where say I have 10 types of character on screen and they all need to react in a unique way when the letter "k" is pressed?

I can think of a bunch of hacky ways to do this, but would love to know how it should be done properly.

I am using C++, but I'm not looking for a code implementation, just some ideas on how it should be done the right way.

Answer 1

Well, if you're talking about much, much more advanced games, rather than having an enemy react to the press of the button, you'd have the enemy's AI react to "seeing" the player armed with a knife, and "seeing" it would require that the player was in line of sight, and the enemy "inspected" the character, in terms of health/equipment/etc, and then based on the final determination, "angry" was what the enemy AI decided on.

ie: on each update-cycle (or every several, to save CPU), have each enemy that's in-range, check to see that they've still got sight of the hero and run a basic AI routine to choose their strategy, based on what they inspect.

If your question is more about what to do about an event which several things need to know about, in general...

Suppose ESC is to toggle "pause"/"main-menu" if you're in-game, but it's also used to back out of sub-menus, if you're in a sub-menu, setting options, or to close your character's stat/inventory screen in real-time, during gameplay.

So now you've got all of these things which need to know when ESC is being pressed.

Instead of tying them all together in one gigantic function with a boatload of conditional statements to work through what should happen...
...you should look into a pattern where various menus can subscribe (or "register" or "listen") to the keypress event, and fire their own methods when notified about the event in question.

I'm most used to JavaScript now, so it almost feels like cheating, with how easily you can pass methods back and forth.

But with a little bit of planning, you can use the Mediator pattern to create one "emitter" per type of thing that you want to listen to:

Say you have an Input mediator, which listens for keyboard presses and mouse clicks, and deals with all of the hard stuff like timestamps and working out screen-coordinates and the rest.

Then, using a "subscribe" or "listen" method of input, each object interested in being notified will subscribe to something:

//[pseudo]
input.subscribe("input/keypress/ESC", thisObj);
input.subscribe("input/keypress/SPACE", otherObj);
input.subscribe("input/keypress/ESC", anotherObj);

Then, when Input hears about a keypress and works it out to be the proper key, it will publish or notify (or whatever), all of the objects which have subscribed (and support the proper interface).

//[pseudo]
input.notify("input/keypress/ESC", data_to_send_to_each_subscriber);

So now, if you're in-game, the game window can subscribe to ESC to pause, and unsubscribe to ESC once it IS paused (and subscribe again when it resumes). Other menus can subscribe to ESC as soon as they're initialized, or "opened", or whatever (depending on if you want to create new instances every time, or use the same one), and unsubscribe when they're being closed.

Now your menus don't need to know about one another, and they don't all need to be a part of the same function/switch/whatever... ...they just need to know when to listen, and when to clean up after themselves.

Answer 2

Well your enemies shouldn't be reacting to a key press, since they're not controlled by the player.

One way to do this would be to implement a system where enemies know what's in their vicinity. When your player is in a certain radius of enemies, the enemies could react in different ways (get suspicious/get angry when he gets out his knife/etc).

The way I would handle this would be to have a certain area around enemies that is considered "in range", when the player performs an action, you could raise an event for all enemies that have the player in range and the logic of how they react would be executed by the enemy objects themselves.

I guess my point is, having enemies react to key presses directly isn't terribly good design.

Answer 3

Your problem can be solved through applying the Observer Pattern.

You have Subjects like the keyboard key handlers, and you have Observers like the player character which need to react on events.

Every Observer can "subscribe" to one or more Subjects. This causes the Subject to add the Observer to an internal list. When something happens in the Subject, it calls a method on every Observer which subscribed to it. The Observer can then react on the event as it sees fit.

But as the others pointed out: Entities like enemies shouldn't react on user input directly - they should react on the behavior of the entity which is controlled by the player. The Observer pattern can also be used in that context, but there are also other patterns to consider (like using a Controller or just have each enemy check the state of the player in the game logic update loop).