Hello forum : )

I was wondering if I should use my event-listener for an information exchange.

Let's look at the level-module, having the level information, and the Lua-module, having Lua loaded.

How should communication be?

A few ideas of mine:

Do not use the event listener: Composition

This would mean that the Level-module owns a Lua-class that it can use.

I dislike this because there will be multiple modules needing a Lua-class.

So instead of having many Lua-instances, one could do them all well.

Use it: Intensive Event-Triggering

My Level-module triggers a load-game-event to which the Lua-module listens.

Upon triggering, the Lua-modules triggers a loaded-game-information on which the

Level-module would trigger.

Feels awkward to make this communication like this, but maybe it is normal?

Now, what is your suggestion?

Thanks for reading : )

If these components are so tightly coupled, why are they separate components?

If you have a family of components that really do need to be separate parts, interchangeable, and also tightly coupled, why don't they have their own little hub where they can communicate quietly with each other and not the rest of the world?

Oh, well my Lua-component is just an interface which loaded Lua and handles it.

At the moment it sits inside the Level-component, but then again, what do I do if my window-component wants to use Lua as well?

It was like: Okay, this needs Lua and that too.. so.. where do I place my Lua-component?

Well, the ugly part is just that whenever I want to extend this, it becomes more code at several constructors at once, as they have to pass around those references.

This is might describe the way of obtaining modules, but it is actually just exponential amount of update-work whenever something new is being implemented.

Module-Hub is within the core of my engine, the core runs the game.

Every game-state can be instantiated by another state: The main-menu-state can introduce the gameplay-state.

But the main-menu-state won't need a module that the gameplay-state won't need.

Additionally, while the game keeps being developed, new needed modules might be required, as a result the list of passed module references will increase.

Which costs a lot of annoying implementation work.

I thought about passing around the core itself, as it owns those modules, every state/sub-component of a state can freely get references to needed things.

Also thought about bundling the modules into a module-store with private modules and public ones.

Is there any common strategy for this? Any known design-pattern?

I have my Event-Listener, but that is really not what it should be used for, I assume.

You might want to reevaluate your components if several components have a very tight dependency, they need to be together. Other wise you'll wind up with a huge mess in your code base.

If you can fire and forget with no consequence of order in which you do so... Message passing would be best.

Technically you're sending data. Information is only a property of the data.