When it comes to globals, yes, there are many who will poopoo that. But really, sometimes you just need to get real work done (not more theoretical bookworm philosiphatin'!), so i'm not against globals entirely. But i would make a few suggestions:
1) If you use them, put them in a namespace. Globals are not a "class".
2) if you have globals, you have to set up ALL their values BEFORE those values get used by any other part of the code. Because they are just dangling out there, they are free to get used by any code at any time. that's bad. If you accidentally use an initialized global, you get weirdness and/or crashing. You can avoid that issue by passing the values to those that need it. YES it is annoying, BUT you can guarantee the value is initialized before you give it to other parts of the code.
BadFunction() { int foo = bar; // look at me, i'm just grabbing at globals! Who knows what they contain! }GoodFunction( int bar ) { int foo = bar; // hopefully the function caller knew what "bar" was in the first place. }GooderFunction( int bar ) { if ( InputIsYucky(bar) ) { /* do error handling stuph */ } int foo = bar; // ah, sanity! }
As for code splitting, basically you want to put each major thing in it's own file. If you are using OOP, each class or small group of classes make up a file. You would have Monster.h, Gun.h, Player.h, GameSpace.h, etc. And it's okay IMHO to have a globals.h or common.h. Most programs do. Eventually, as your program gets bigger, you will realize that some of the so-called globals aren't really so global and in fact inhabit certain domains. For instance, the screen size only means something to the drawing routines, not for the agents. graphics settings are for graphics routines, sound settings are for sound routines, and so on. You'll figure it out soon enough, so i won't grill you on it ;-)
