I agree with Greg purely because your approach seems to be discouraging the incredible power of modulation. The graphical interface and the inner workings of the game should not be intertwined too much (which is an EXTREMELY common mistake many of the helpers on this forum see with beginner programmers who are trying to make games).
At the very least, a well designed and organized game should be modularized to have:
1. A graphical library which provides all the basic graphical features for the game
2. A game engine library which contains all of the game's logic
3. A library which bridges the graphical and game engine libraries to make them work together
The game engine and logic of a game should NOT be dependent on a graphical interface existing (and vice verse). Many ignorant/beginner programmers try to do the graphics and game logic together, not only in the same libraries, but the same classes. All you get from that are massive source files which cannot be accurately tested, debugged, or modified, and game logic which is WAY too coupled with the GUI.
We see beginners come here and say stuff like: "item x won't move across the screen" and we look at their code and find they have coded the graphical stuff and the game logic together. Where do we even start to look for the problem? Is the graphical interface broken, or is the game logic broken? We would know if the programmer had designed it using modulation, because we would be able to test the graphical interface and the game logic independently.
Want them to be able to make a bunch of games with relative ease? Teach them to make a graphical interface library which they can plug into all of their games. Teach them to build game logic which does not depend on a working graphical interface - core game logic should be tested with unit testing long before you try to test it with a graphical interface. And teach them to take both libraries and make them work together.