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.

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.

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