A hub and Spoke arrangement has advantages, as does a monolithic contract.
Hub and Spoke
- Simpler internal structure, possibly more readable
- Can accommodate a "rolling upgrade" path if that is desirable.
Monolithic
- It costs considerably less to initialize a few variables than to deploy a new contract for each game.
Working on a Hub and Spoke basis leads naturally to some generic concerns. As you mentioned, probably the Spokes need to update globals in the Hub, the Hub needs to limit access to certain functions so only a Spoke is authorized to do so, etc.
My explorations led me to create generalized contracts, roughly:
contract Hub is Deployer { ...
contract Spoke is Deployed { ...
Consider that Deployer keeps track of deployed Spokes and does things like:
modifier onlyDeployed { // only trust contracts made by this Hub
... and Deployed does things like remembering the Hub that spawned it.
If you want to be able to upgrade the game logic, then you can consider further separation of Hub data and Factory logic. That is, you want to be able to hold the global data in a contract that is not expected to change, while periodically replacing the contract that deploys new games.
The lowest gas cost and simplest approach is a monolithic contract with game data rolled up into structs and no possibility of an upgrade.
Hope it helps.