Sign in to follow this  

Information exchange among Components

Recommended Posts

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 : )

 

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

if a number of modules / systems / "compnents" use Lua, then you need a low level Lua module they can all reference and use. its not an "is a" relation, its not a "has a" relation, its a "uses a" relation - IE it uses a library or some specific api calls from some sort of library module.

 

so from lowest toi highest you have Lua itself, then your Lua API, then your modules that use the Lua API, such as levels and windows.

Share this post


Link to post
Share on other sites

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.

Edited by Angelic Ice

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Is there any common strategy for this? Any known design-pattern?

 

this is an issue of controlling the scope of, and access to variables.   IE the "golbals" issue.

 

the possible approaches fall at various points on the "stupid programmer proof" scale.

 

at the least "safe" end of the scale you have globals, which you don't have to pass around, because they're already in scope.  but then you have to rely on coder discipline to only use them in a non-global manner. IE gloabl for read-only operations, but treated as a special variable for write operations. So you have to be careful where you change the global values.  you have to inspect the code line by line to see what globals its dependent on. this reduces portability.

 

a little more safe, you split things into code modules, with a module containing one or more classes that implement some "subsystem".  then include the modules in other modules that use them.  the included modules are still global to modules that use them, but not to the entire program.   you only have to look at the include files to determine what module a given module is dependent on.  so its more portable. easier to hook up to code in another program.

 

on the safest side, everything again is in modules, but they are declared at the lowest scope possible, and passed down from there.  now each method's definition explicitly states exactly what that routine is dependent on, for maximum ease of portability, and the ability to share code at the method / class level vs the module level between projects.  although shared code would likey end up in its own module. the downside is having to pass everything.

 

whats best for you depends on your circumstances. a solo dev can get away with globals and good coder discipline. few others can.  globals in a code base with many devs, some of which are new to the code base often leads to a lack of coder discipline and thus bugs in the code. this is why globals are generally frowned upon. you have to make sure you dot every t and cross every i when using globals. <g>.

Edited by Norman Barrows

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this