Hello,

I am currently trying to solve an issue and I'd like some direction on the best way to handle it.

In essence, my game has a few states (intro, loading, menu, game, pause, etc), each state is a unique class defined in a unique file, and they all inherit from a common interface GameState.

Right now, I am compiling each class into its own module, which creates the problem that I can't access classes from other modules and I need to do things like that, for example, the loading script would get the handle to the game script object, and would change some values in that state object for game initialization.

How should I handle this? Move all classes to a single module so they can access each other mutually? Should I use a messaging system instead? Is there any other recommended way?

Also, in case of maintaining a single module for all my classes, besides avoiding name collisions, should I have any other concerns? Is there a problem if I add later other classes into this module, whenever there is the need?

Thanks

There is a class in AngelScript addons, called CScriptBuilder. It allows you to create modules from several files (or memory). Besides that, it allows you to use C-style includes in your scripts.

Yes, I wasn't asking exactly how to do it, but rather how it should be done :)

There are benefits to both ways. By building everything into a single module you will have an easier task of inter-communication between objects, but by keeping the objects in different modules you will be able to treat each individually (for example, exposing different engine interfaces, load on demand, hot-loading, serializing, etc).

To solve inter-communication between classes in different modules, you can use shared types and imported functions, or you can build a messaging system like you said.

Thanks Andreas :)

Those features you mention do sound promising, I think I am convinced, each state will sit in a independent module.

First, the dynamic nature of my state system would be impractical. I'd have to specify all game states source at init time, or it would be a total mess with classes referencing other classes that aren't compiled yet, generating a ugly dependency.

Also, I will definitely create a Messaging system as a clear interface to communicate between states. This is really the best way as I can create premade states for multiple things and re-use them quite easily. For example, I create a pause state and document it so everyone knows it is expecting a "UI_Source_File" at initialization. Then, I can re-use the same pause game code for many games, only changing its looks by those properties. Sounds like the cleanest approach to me.