@C-Research I just realized from your post that I seem to have a bad Masochistic streak and tend to overcomplicate things.
These days I set the compiler to C++11 or 14, and still half of my code is C++99 since it is what I'm most comfortable with.

I'm happy that you dodged a bullet there and made this valuable experience.

C-Research said:

Question: What is standard practice for organizing game code modularity according to Game State:…

I noticed that some indie game developers are using several source files (main.cpp, game.cpp, menu.cpp, etc..)

Others are sticking all the cpp in a single main.cpp and with the single header file to wrap it all up. This seems fine for smaller games, but that does not seem to be massively scalable.

It is typical to bundle in terms of both systems and layers.

Various subsystems like audio, graphics, simulation, networking, input, serialization, and the rest can each do their own subsystems work with whatever state information they have and need.

SOLID principles help replace layers and items inside a subsystem. You can swap in smaller parts interchangeable with whatever the subsystems need for their work, composing large systems out of the small interchangeable cogs. Interchangeable game objects inside the simulation, interchangeable behaviors attached to those objects, interchangeable physics objects like cubes and spheres and capsules and meshes, interchangeable animation objects, interchangeable character controllers, interchangeable audio objects, interchangeable model and mesh resources, and so on.

Something in your game controls the main loops and coordinates how and when everything ticks. Exactly what it is depends on the game, usually it is engine work to figure it out.

And finally, communication within the systems is generally hierarchical. Shared mutable state causes many headaches. Communication down to subsystems and up to system controllers removes shared mutable state.

@frob I almost got shared mutable state (there's another term for this - slips my mind right now) to work one weekend with two objects as an experiment, one weekend. I kept getting an error which I could not resolve.

It was a mistake to try to tackle it from game loop - which I had to try, but since then I work with submodules. A lot of things about CPP seem too advanced for me at this time, so I keep it simple but organized by submodules and subdirectories. I have a couple classes in the game loop and that is it until I can learn a great way to script the game in Lua. Scripting in C++ is a real drag LOL

Now I am a HUGE fan of modules and submodules. It is easy for me to connect with CMake, just a few calls in the loop, configure in CMake, and make sure to get the header correct and I am good to go.

I really like the idea of a submodule for game state manager in the engine directory. What do you think of putting the API for it in the game directory near or inside the game script directory (an internal library, as it stands now)?

Keep in mind, I am trying to create Lua scripting of game assets and UIs without having to recompile nor restart the game while programming.

C-Research said:
I almost got shared mutable state (there's another term for this - slips my mind right now) to work one weekend with two objects as an experiment, one weekend.

Shared mutable state goes by many names. Global objects and singletons are both examples of it.

It is far better to have protection around systems enabling ownership and controlled access. There are many subtle bugs that crop up when anything, anywhere, at any time can potentially change the state of something. Access control provides some limits, such as limiting access during simulation updates.

Using hierarchical communications rather than shared states allows for individual systems to know and maintain them, rather than having globally-applicable states. Just because something happens to be used everywhere doesn't mean it is a good idea to make it global, because someday you might want another instance somewhere.

C-Research said:
What do you think of putting the API for it in the game directory

Always organize with directories. Organize them however it makes the most sense for your project, but always keep them organized.

It is common to keep game data separate from game code, to organize game data by types of objects like creatures and structures and environments, to organize into directories by game worlds and levels, audio, and whatever else. It is typical to organize engine code by subsystems like graphics, math, physics, networking, AI, and so on. It is typical to keep external plugins and external libraries in their own directories for isolation, versioning, and maintenance. It is common to keep intermediate assets and final binaries isolated in directories to more easily clean them and to prevent them accidentally getting submitted to version control.

I've never seen a simple “game directory” in anything but the smallest hobby games. If you're making Pong or a tiny Tetris you might have a single directory, but even that is unlikely as the game grows and you start adding more assets toward a complete game. Even with a hobby project you're going to have intermediate and final output files you don't want mixed together. You're going to get art and audio assets you'll not want mixed in with the source code. You'll quickly find that a single directory files get lost or mixed together in ways you don't like.

Guys, thank you very much for the help!

A mod may feel free to lock this thread at the appropriate time.

Have a nice day

We don't do that here. This is a discussion board first and foremost. Other people may contribute valuable insights or discussions.

@frob Cool! TY