Ohh... Now i get it

So this morning at 4:30 am it finally dawned on me how developing video games really should be thought of as "creating simulations".  (I guess it's just me and my crazy reliance on metaphors that finally makes me see the light).  Having spent years developing "business logic" and Java (J2EE) applications, moving into game development has been a large paradigm shift.  Anyways, trying to make heads and tails over all of these new things (APIs, etc.) required me to take some source code examples from android game projects, and decompose them/modify them/rewrite them/rebuild them (You can't get that kinda experience just reading about developing, you gotta get your hands dirty and grind out some code).

Anyways, one of the things I've had drilled into my psychi over the years is not to mix business logic with presentation logic, and the first thing I do is start tearing into some code where its (frankly) just a hodgepodge.
You got one class that does all of these things:

• main game loop
• handle input events from user
• maintain graphics (draw itself every frame)
• run game rules (i.e business logic)
• handle state change (it's stateful)

 I started modifying things (in this "uber" class) just to see if I could add functionality, and (as expected) things started to crack very early on.  In one regard it was easy for me to turn around simple changes because (almost) all of the code was just a few lines away.  However you start fiddling a little here and there and the code is just as ugly as hell and hard to keep straight (and buggy).

Really, I think the problem here is that when developing a video game, the first thing you want to do is figure out how you can get something rendered and viewable on the screen.  So you hack something together and slam it into a prototype that will show some sprite or animation show up... then from there you try to figure out how this thing is going to move around and exist in this game world.  Moving further into development with this paradigm causes all of the logic to be placed on how these simulated objects will appear in the simulated world.  We should really think of it like this "The Simulated World should be simulated whether it's viewable or not is a different concern"... so in that regard, the should be "runnable" without any view.

So I took the original code and I would try to refactor it in a way that made things a little more manageable.
After a few passes the following things (abstractions) started to emerge:
1) State - "GameObjects" - the state of anything that is being simulated in the game root object is WorldState, contains the states of other objects (MapState, MarbleState,...)
2) Loop - Metaphor (Time) a Simulation that occurs over time and has/contains rules/constraints that are enforced WorldLoop
3) Rule(s) - What happens for each iteration of the gameLoop (Collision Detection, AI, and other simulated world when things "happen"
4) Input - Entity that can handle the users input to the simulation

5) *Feedback - view, sound, vibration and other game feedback should be under this umbrella contains  *Renderer(s) - given a "GameObject" render it's contents for each simulated object that has a visual representation we have a *Renderer (i.e. TileRenderer, MarbleRenderer, etc.)

At minimum, you should be able to run the simulation with the State, the Loop and the Rules... (assuming the simulation doesnt require user input) this makes it much easier to port the game to multiple platforms (because they all have rules for rendering that are heavily console specific)

I think it was when I started to see that the UI thread (I'm using a SurfaceView) was relatively decoupled from the GameLoop that I realized that the "simulation" metaphor made so much sense... Lemme elaborate:

Lets say you were given a "simple" physics problem  the usual car A leaves Boston travelling at 40 mph and car B leaves New York travelling at 60 mph (where will their paths cross?)
You can "solve" this problem using a simulation with the following gamestate
GameStateObject
name : Car A
location : Boston
location Lat /Long:

42

21

71

5

12:00 noon

speed: 40Mph

GameStateObject
name: Car B
location: New York
location Lat/Long:

40

47

73

58

12:00 noon

speed:  60mph

Then you have a GameLoop that basically simulates elapsed time and asks the GameRules to update the GameObjects (A and B) location based on their speed and the time that has elapsed since the last update (the GameRules also determines when to "stop" given the latitude and longitude of both cars (Car A and Car B).

Anyways doing this in practice requires a great deal of discipline, (and much more code) but adds a ton of flexibility... the renders can render things completely differently if they are decoupled from the state of something (3rd person, first person, etc.)  But in a generic sense, time passes and things happen in this simulated world how the user manipulates and perceives this is becomes a different issue.