   Organizing Game Code
  One problem I have run into for the last few games I made (I am a amateur game programmer), is organizing game code. People have always said to split up game code into game states. Also one thing I always did was have game logic inside the draw logic thread, which caused lag if a lot of things were being drawn. My next project is a more serious one that I hope to release to the public. It is a platformer/puzzle game for the Android.Now I am trying to plan ahead and organize the game code into states. Would something like this work?Loading Menu State (Load Menu Resources) -> Main Menu State -> New Game Menu State -> Loading State (Free Menu Resources, Load Gameplay Resources) -> Gameplay State -> QuickMenu/Pause State -> Loading State (Free Gameplay Resource, Load Menu Resource) -> Back to Main Menu StateAlso there will be two threads (well three if you include Android's UI thread), one for game logic and the other for drawing. Both will be synched to the same gamestate, and act accordingly. So if you are in the menu state, the gamethread will listen for input, and if a button is pressed, it acts accordingly. The drawthread will be in a loop, drawing every object  on that state.An example during gameplay: If a player presses the jump button, the gamethread increases the y velocity to some number, and then slowly increments (till it hits 0, and then decrements to the opposite direction), until a collision is detected. During this, the draw thread is constantly drawing the SAME player object, depending on what frame and position was set by the game thread.   
  At a cursory glance, that looks like it would work fine. Make sure that you have as little thread syncing between the update and draw threads, so you can restrict your update thread to 60Hz or something similar, and just let the draw thread run as quickly as possible.And just a note on the implementation of your game states, I don't know if the Android enforces asset bundling or anything like that, but hopefully you've got an easy list of the asset sets that you want to load at each time, ie.MenuAsset.list-StartButton.png-StartButtonHighlight.png-ExitButton.png-ExitButtonHighlight.png-MenuScript.scriptSomething like that. Ideally you'll want a single state machine for the game state, and then have a single loading state which will load one or more asset lists, and then just store the state you want to go to after the loading state. This is just so you don't have a MenuLoadState, GameLoadState, ScoreScreenLoadState, etc, etc.   ;  The purpose of separating game states is to avoid implementing two radically different logics in the same update method, most amateur developers (myself included in my early days) end up with an update method basically consisting in a very large switch calling functions for the different logics according to a state flag.I wrote a small article in the GameDev Wiki a while back in this subject, here is the link:http://wiki.gamedev.net/index.php/Managing_game_stateHere I explained as best as I could the problem, the solution aproach, and provided an example solution, there is a lot of room for improvement and there are other solutions as well, but it is simple, elegant and works.;  Thanks for the link, it seems like a simple approach to take.   