Big Picture

I suck at application architecture.

How do I do MVC for a video game? All explanations of MVC are completely tied to the web, where you have this nice clean cycle of [database -> page composition -> user submitted data]. A video game does not fucking work that way.

How do I refer internally to different parts of the game state? Let's say I have a top-level object called Game, which has an array of Players, and maybe a World class containing some Terrain and some Entities, some of which are PowerUps, etc. Now how do I find a PowerUp from within the Player source code?

Am I meant to go through the Game object, via game->world->entities->powerups? This is horrible because it creates a dependency chain; my Player source code is now dependent on all of those intermediate classes, even though it doesn't actually need to access them besides getting to the powerups. And how do I even access the Game object in the first place? They say don't use global variables. Does this mean I pass around a Game* to all methods in the entire app? Does this mean every single class in the app should store a reference to the Game*? There is a huge amount of overhead for this, not to mention lost optimization opportunities. Am I meant to make it a singleton? Because that's just a bullshit copout; that IS a global variable.

Is there a good book I can read that will explain all this bullshit?

>>1
As you have discovered MVC isn't directly applicable to most video games. Though most code can benefit from the modularization principles that MVC is based on(for instance you should try to separate your game logic from your rendering code). Every programming 'rule' or 'best-practice' has many exceptions.  For instance there are plenty of instances where global variables are reasonable.  Do what feels right.  For instance if you find yourself passing around a Game* everywhere when it would be much easier to just have it be a global variable, make it a global variable.  Then later on if you see the need to modularize the code more, just refactor.  There is no ONE-TRUE-WAY to program and therefor no one book will teach you how to write good code.  The best way is to write a fuck lot of code and learn by experience.

P.S. passing a pointer around has negligible performance impact