Personally, I'm always hungry for more general game architecture tutorials. Not "build your first crappy engine by following my first crappy engine design", but professional discussion on how the various parts of game engines fit together. What would a minimalistic but capable game engine actually look like? You can use pre-existing third party physics, sound, and rendering engines. What I struggle with is how does the physics and graphics and sound interact with each other, so, for example, a wooden box falling on a stone floor plays the appropriate wood-on-stone sound effect? How does the engine handle the player's footsteps making different sound in grass vs stone vs metal, without tight coupling?

There's a plethora of "how to use X library" or "how to make your own X library" (where X = rendering, collision, physics, or whatever). There's plenty of "what is, and how to use, component-entity-systems, object-oriented design, procedural design, etc..." tutorials. I can't find many tutorials about coding glue between the different subsystems. The game described could even be 2D, as long as the concepts discussed scale to larger games.

I'm coming from a C++ background, but it doesn't particularly matter what language the tutorial is in, as long as it explains the theory and shows concrete examples. It doesn't have to be a long tutorial either - just one or two articles even. It doesn't have to make a complete game (or even provide complete source-code), or show how to use whatever APIs it's using (it could even just use fictional function calls). As long as it shows and explains the interactions between subsystems to implement game features and logic, I'd be ecstatic.

Hey SOTL, I wrote yesterday an article of a good way of organizing the modules on a game engine (more detailed). That's the link if you want to take a look:

https://irlanengine.wordpress.com/2015/02/07/organization-of-game-engine-layers/

Hey SOTL, I wrote yesterday an article of a good way of organizing the modules on a game engine (more detailed). That's the link if you want to take a look:
https://irlanengine.wordpress.com/2015/02/07/organization-of-game-engine-layers/

Thanks, I just glanced over it. That article seems to be about project organization, and I'm actually really pleased with how my project is organized currently. What I'm looking for is code interaction between subsystems, for implementing the game logic. I can make them interact in my own code, but I feel like I would benefit alot from seeing how the professionals do it.

Isn't the way you hookup all the modules of an engine (physics, sound, collision, rendering, input) the secret sauce that make the engine different from other engines? It's not like there is a "right way" to do this.

Overall architectures definitely change from game to game, glue included. And if your engine is more OOP or more CES or more procedural, the glue will change alot. Even between two CES or two OOP architectures, the glue may take different forms if written by different people. I agree there's no "right way", I'm just looking for your personal "clean ways", or even less-than-clean but functional ways. Having actually worked in the industry (at least somewhat), and having alot more experience than I do, how do you make your subsystems talk to each other?

Coupled or not, what is your typical way of solving the problem of inter-system communication? Passing a SoundSystem reference to your PhysicsSystem, so on collision within your physics system, you can call soundSystem.MakeCollisionNoise(objectA.GetMaterial(), objectB.GetMaterial()) ? That's a valid way of doing that. Is that what you do? Or do you make SoundSystem global?

Or is it basically "global" by giving every major system a reference to the struct that contains all the systems and all the game data? That's what I currently do, and it works, but I want to know what others do.

Perhaps a series of code-review articles that digs into how popular open-source engines hook everything together?

Most opensource engines seem to be, "I made an engine! Let me opensource it and then see what I and others can build from it...", rather than, "I have experience making several games, here's the common knowledge I've acquired."

Opensource engines are the epitome of "make engines because it's cool!" with theoretical/idealistic architectures, where as I'm looking for real-life communication problems and real-world solutions. (Note: not all opensource engines are like this).

Also, opensource engines, and even closed-source commercial engines are usually more general-purpose trying to accommodate everything. I'm not worried about general-purpose or not. I'm equally fine with narrowly applicable "here's the solution I used for this one real actual situation".

I probably would benefit from looking through open source engines, and even more-so from commercial open-source games. Quake 2 and Doom 3 is opensource, so I should read through those. Halflife 2 would be another good one for me to check out, because these would be actual (but also messy) attempts to solve concrete problems.

I am in the "Make games, not engines" camp, so I tend to just make stuff that is tightly coupled and works, rather than trying to create an engine that can work for any situation.

I'm with you in that camp. When making specific games, trying to design the architecture of that game, I have difficulty writing the code to handle communication of events between subsystems. Basically, how does the Physics/Collision system tell the Sound system to play the correct sound? This isn't an actual problem I'm currently having (in my 2D game, it's easy enough for my Player class to query what tile he's walking on and what sound he should play or script to trigger), but is the best example I can think of to illustrate my general problem. Or not "problem", my general "area I think I can improve in, and wish to hear how more experienced developers handle it".

I'm not looking for "The One True Solution", but to just further my general collection of potential ways to solve architecture problems, if that makes sense. I'm always hungry for more architecture stuff, when it's explained simple enough that I can understand it.

If my explanations seem vague it's because my desire is vague - You: "What would you like me to teach you?", Me: "What can you teach? What have I yet to learn? What knowledge is out there that I don't even know exists? Teach me one of the things that I don't know exists and thus can't ask for."

I know I have alot more to learn in many areas, but I don't know what the specifics to learn are. I only know the general areas I am currently weak in, and one that I'm especially interested in is [general software engineering big-picture architecture how-it-all-fits-together-ness].

It's definitely a more niche article request, and obviously you're under no obligation to cater my suggestion, especially since more general-purpose articles would be more beneficial to a wider group of people. Speaking of that, thank you for even considering writing any articles. Whatever you right, in any subject, I'm sure I and others would find it very beneficial.