1
\$\begingroup\$

I'll be soon implementing for the first time a Command pattern to catch general events about the world of the game I'm developing

Since I haven't found much info about this particular issue, I'm asking if it makes more sense to have a single 'catch-all' class which will eventually process any type of event or to offload events to different types of Queue

e.g. player related Commands will be offloaded to the Player class, enemies related commands will be offloaded to the Enemies class, and world/terrain related commands (such as chunk creation) will be handled by WorldGen

Normally, this would break the idea of having a 'receiver' object as a constructor parameter of an instance of a Command, but does having just a single 'catch-all' class more maintainable than partitioning the command handlers?

Is it maintainable in a convoluted game to have just a single catch-all class to execute every type of Command? Wouldn't it be easier to optimize the usage of more threads by having different command handlers?

\$\endgroup\$
3
\$\begingroup\$

A single handler would have a lot of dependencies, where as multiple handlers can be better compartmentalized.

Personally, I take it one step further, and make the handlers non-exclusive: events may have zero, one or multiple handlers listening for it.

If you make a system where handlers can subscribe to messages, then a single event (e.g. a hand-grenade going off) can generate responses from different parts of the game.

  • The sound system may catch that event, and play a loud boom.

  • A damage system may catch it and look for damaged players.

  • A particle system may catch it and generate a flash and smoke.

  • The leaderboard/achievement system may catch it, and unlock the achievement "Grenade"

  • etc.

Set it up so that the event-generator does not need to know about any subscribers. The event is just generated. How many listeners there are, if any, is of no concern to the code that generated the event.

This creates nice code with few dependencies, because the code where a grenade is made to explode, does not have to depend on particle-system code, sound-code, or any other code that gets triggered via one or more handlers.

Because subscriptions are optional, it also means that if, for instance in debug runs, a system is not brought up, everything still keeps working. There are just fewer handlers listening to the event. You can run without the leaderboard-achievement system, or without the sound system, and nothing would break when a grenade explodes.

\$\endgroup\$
  • \$\begingroup\$ Does this implies a general handler catching every type of events forward them to every event handler which decided to listen to these messages? Doesn't it impact performance if many event handlers have to discard many commands not related to them? \$\endgroup\$ – Row Rebel Oct 16 '17 at 20:45
  • 1
    \$\begingroup\$ Personally, I use a subscription method where each handler is registered with the framework. And yes, dispatching a message to the correct handlers is O(N) and costs performance. But then again: how many events do you expect in a single 1/60s frame? Surely, optimization is not important for these higher level constructs? \$\endgroup\$ – Bram Oct 17 '17 at 0:06
  • \$\begingroup\$ I'm sure it was not going to be the bottleneck anyway, I just asked to see if I correctly understood the answer. Thanks for your time, all is clear now \$\endgroup\$ – Row Rebel Oct 17 '17 at 1:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.