In that case, 'scene' is just a module containing functions relevant to scenes.

I'm sorry for being misleading. Obviously, I'm very rubbish at this stuff, but trying to improve.

In my code, functions are put into modules. Any 'objects' are actually just tables with values, not functions.

I thought it's your scene that is in charge of updating everything :o: 'in charge' is a very strange notion, since a scene is just a table holding some data like a C struct. I actually update all my game objects outside of the scene (I maintain a table of objects and if they have an active flag set...

Thanks. For clarity, I never suggested that changing my architecture was out of the question... only that it lead to unusual restructuring of the code (passing in modules of functions is the worst of these imo). Other options have design implications. If I set a flag, and let the scene handle its ow...

I do think it's worth thinking of a way to not have mutually recursive modules in the long run, though. This has been repeated as mantra, but never explained. How would I do that in this situation? I appreciate your post, but I've failed to understand what the solution is in terms of architectural ...

I understand that it's just a reference, but it seems so *weird* to me.

Maybe this is a case where globals are the answer, despite everything telling me 'no!' Keeping all modules in the global scope might be alright.

That's definitely an option, but it seems a bit weird to pass in an entire module like that... I usually reserve table values for actual properties of that table, as though it were a struct, except in the case of tables acting as modules... in which case they simply store functions.

Hi, again. It seems many moons ago I started a thread about problems I was having with circular requires. Well, they've struck again and I still don't have a good solution that doesn't require strange contortions of my architecture. Let me explain the situation I keep running into. I am trying to ke...

not a bad idea.

i think maybe i just won't raise events within the events handlers... then the issue resolves itself!

ah, I understand now. I'll think about doing it that way but I try to avoid globals as much as I can. if you are going to require "dispatcher" in every file then there is no reason not to use globals. globals aren't always a bad thing (just like OOP isn't necessarily bad), of course they ...

ah, I understand now. I'll think about doing it that way but I try to avoid globals as much as I can.