Is it a bad practice to use a large number of modules?

For a level-based project, certain objects have special functionality. I figured the cleanest way I could go about this would be to take an OOP approach by creating modules for each of these objects. (only the necessary ones. I integrate certain object behaviors in the main game handler that have less purpose or change)

Right now I have about 13 modules or so.

Just wondered, is this bad practice? Or would it be okay for scenarios like this? I literally couldn’t think of a better way to store/handle information for specific objects for cases where there could be a large number of that specific element on a level. I also took this into consideration for managing those specific objects, since there’s a decent number of game objects, so it’d be easier for me to go back and make code modifications for a specific game object.

Thanks :slight_smile:

4 Likes

The only bad thing about having too many modules is managing them and remember what each one does. Wherever you can, you should fuse two together if they share similar functionality. But performance wise, it really doesn’t matter how many modules you have. Plus, organization would be a perk from this (sorting code within different module scripts). It’s just managing them and memorizing their functionality.

2 Likes