{"id":474,"date":"2011-07-12T16:09:00","date_gmt":"2011-07-12T16:09:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/android-game-development-the-game-loop.html"},"modified":"2012-10-21T20:00:40","modified_gmt":"2012-10-21T20:00:40","slug":"android-game-development-game-loop","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/07\/android-game-development-game-loop.html","title":{"rendered":"Android Game Development – The Game Loop"},"content":{"rendered":"
The game loop is the heartbeat of every game. We used a very rudimentary one so far (you can find it here<\/a>) without any control over how fast or slow we update our game state and which frames to render.<\/p>\n

To recapitulate, the most rudimentary game loop is a while loop that keeps executing some instructions until we signal it to finish, usually by setting a variable called running<\/i> to false<\/i><\/p>\n

boolean running = true;\r\nwhile (!running)\r\n{\r\n   updateGameState();\r\n   displayGameState();\r\n}\r\n<\/pre>\n
The above code runs blindly without a care for timing and resources. If you have a fast device then it will run very fast and if you have a slow one it will run slower.<\/p>\n
The updateGameState()<\/i><\/strong> updates the state of every object in the game and the displayGameState()<\/i><\/strong> renders the objects into an image which is displayed onto the screen.<\/p>\n
There are two things we should consider here: FPS and UPS.<\/p>\n
FPS<\/strong> \u2013 Frames per Second<\/strong> \u2013 the number of times displayGameState()<\/i><\/strong> is being called per second.
\nUPS<\/strong> \u2013 Update per Second<\/strong> \u2013 the number of times updateGameState()<\/i><\/strong> is being called per second.<\/p>\n
Ideally the update<\/i> and render<\/i> methods will be called the same number of times per second (preferably not less than 20-25 times per second). 25 FPS is usually enough on a phone so us humans won\u2019t notice the animation being sluggish.<\/p>\n
For example if we target 25 FPS then it means we have to call the displayGameState()<\/i><\/strong> method every 40ms (1000 \/ 25 = 40ms, 1000ms = 1s). We need to bear in mind that updateGameState()<\/i><\/strong> is also called before the display method and for us to reach 25 FPS, we have to make sure that the update \u2013 display<\/i> sequence executes in exactly 40ms. If it takes less than 40ms, then we have a higher FPS. If it takes more than that, then we have a slower running game.<\/p>\n
Let\u2019s see some examples to understand the FPS better.<\/p>\n
The following diagram shows exactly 1 FPS. It takes the update<\/i> \u2013 render<\/i> cycle exactly one second to execute. This means that you will see the image on the screen change once every second.<\/p>\n\n\n\n\n
<\/a><\/td>\n<\/tr>\n
1 Frame per Second<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The following diagram shows 10FPS. An update<\/i> \u2013 render<\/i> cycle takes 100ms. This means every tenth of a second the image changes.<\/p>\n\n\n\n\n
<\/a><\/td>\n<\/tr>\n
10 FPS<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
But the above scenario means that the update<\/i>–render<\/i> cycle executes in 1\/10 of a second EVERY time. That is an assumption and we can\u2019t control the actual times on cycle executes, or can we? What happens if we have 200 enemies and every enemy is shooting at us? We need to update the state of each enemy and the states of their bullets and check for collisions in one single update. It\u2019s different when we have just 2 enemies. The times will clearly differ. The same applies to the render method. Rendering 200 firing droids will clearly take more time than rendering only 2.<\/p>\n
So what are the scenarios? We could have an update-render cycle that finishes in less than 100ms (1\/10 of a second), finishes in exactly 100ms or finishes in more than that. On a powerful hardware it will be faster than on a weaker one. Let\u2019s see the diagrams.<\/p>\n
The cycle finishes before the desired timeframe so we have a small amount of free time before running the next cycle.<\/p>\n\n\n\n\n
<\/a><\/td>\n<\/tr>\n
Frame with time to spare<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The following diagram shows a cycle which falls behind. That means that the time it takes for a update-render cycle to finish is greater than the desired one. If it takes 12ms that means we are 2ms behind (still considering the 10FPS). This can mount up and every cycle we loose time and the game will run slowly.
 
<\/div> <\/div><\/p>\n\n\n\n\n
<\/a><\/td>\n<\/tr>\n
Overdue Frame<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The first situation is the desired one. This gives us some free time to do something before we kick off the next cycle. We don\u2019t need to do anything so we just tell the game loop to go to sleep for the remaining time period and wake up when the next cycle is due. If we won\u2019t do this the game will run quicker than intended. By introducing the sleep time we achieved constant frame rate<\/strong>.<\/p>\n
The second situation (I skipped the ideal one as it almost never happens) when the loop is behind, requires a different approach.<\/p>\n
To achieve constant speed in a game we need to update the state of our objects when required. Imagine a droid approaching you at a constant speed. You know if it travelled half the screen in one second, so it will take another second to reach the other side of the screen. To calculate the position accurately we need to know either the time delta since the last postion, and the current speed of the droid, or we update the position (status) of the droid at constant intervals. I will choose the second one as playing with deltas in the game update can be tricky. To achieve a constant game speed<\/strong> we will have to skip<\/strong> displaying frames. Game speed is NOT FPS!<\/p>\n
Examine the following diagram. It is a scenario in which the update<\/i>–render<\/i> cycle takes longer than the desired time so we have to catch up. To do that we will skip the rendering of this frame and will do another update so the game speed won\u2019t be affected. We\u2019ll do a normal cycle in the next frame with even some time to give to the CPU to rest.<\/p>\n\n\n\n\n
<\/a><\/td>\n<\/tr>\n
Constant Game Speed with Variable FPS<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The above scenario has many variations. You can imagine the game update taking more than one full frame. In this case we can do nothing to keep the game speed constant and the game will run slower. We might have to skip multiple renderings to keep the speed constant but we have to make sure that we set the maximum number of frames allowed to be skipped because it can take quite a few updates to catch up and in case we skipped 15 frames that means we lost a lot from the game and it will just be unplayable.<\/p>\n
The MainThread.java<\/strong>\u2018s run()<\/i><\/strong> looks like this:<\/p>\n
\/\/ desired fps\r\nprivate final static int \tMAX_FPS = 50;\r\n\/\/ maximum number of frames to be skipped\r\nprivate final static int\tMAX_FRAME_SKIPS = 5;\r\n\/\/ the frame period\r\nprivate final static int\tFRAME_PERIOD = 1000 \/ MAX_FPS;\t\r\n\r\n@Override\r\npublic void run() {\r\n\tCanvas canvas;\r\n\tLog.d(TAG, \"Starting game loop\");\r\n\r\n\tlong beginTime;\t\t\/\/ the time when the cycle begun\r\n\tlong timeDiff;\t\t\/\/ the time it took for the cycle to execute\r\n\tint sleepTime;\t\t\/\/ ms to sleep (<0 if we're behind)\r\n\tint framesSkipped;\t\/\/ number of frames being skipped \r\n\r\n\tsleepTime = 0;\r\n\r\n\twhile (running) {\r\n\t\tcanvas = null;\r\n\t\t\/\/ try locking the canvas for exclusive pixel editing\r\n\t\t\/\/ in the surface\r\n\t\ttry {\r\n\t\t\tcanvas = this.surfaceHolder.lockCanvas();\r\n\t\t\tsynchronized (surfaceHolder) {\r\n\t\t\t\tbeginTime = System.currentTimeMillis();\r\n\t\t\t\tframesSkipped = 0;\t\/\/ resetting the frames skipped\r\n\t\t\t\t\/\/ update game state\r\n\t\t\t\tthis.gamePanel.update();\r\n\t\t\t\t\/\/ render state to the screen\r\n\t\t\t\t\/\/ draws the canvas on the panel\r\n\t\t\t\tthis.gamePanel.render(canvas);\r\n\t\t\t\t\/\/ calculate how long did the cycle take\r\n\t\t\t\ttimeDiff = System.currentTimeMillis() - beginTime;\r\n\t\t\t\t\/\/ calculate sleep time\r\n\t\t\t\tsleepTime = (int)(FRAME_PERIOD - timeDiff);\r\n\r\n\t\t\t\tif (sleepTime > 0) {\r\n\t\t\t\t\t\/\/ if sleepTime > 0 we're OK\r\n\t\t\t\t\ttry {\r\n\t\t\t\t\t\t\/\/ send the thread to sleep for a short period\r\n\t\t\t\t\t\t\/\/ very useful for battery saving\r\n\t\t\t\t\t\tThread.sleep(sleepTime);\r\n\t\t\t\t\t} catch (InterruptedException e) {}\r\n\t\t\t\t}\r\n\r\n\t\t\t\twhile (sleepTime < 0 && framesSkipped < MAX_FRAME_SKIPS) {\r\n\t\t\t\t\t\/\/ we need to catch up\r\n\t\t\t\t\t\/\/ update without rendering\r\n\t\t\t\t\tthis.gamePanel.update();\r\n\t\t\t\t\t\/\/ add frame period to check if in next frame\r\n\t\t\t\t\tsleepTime += FRAME_PERIOD;\r\n\t\t\t\t\tframesSkipped++;\r\n\t\t\t\t}\r\n\t\t\t}\r\n\t\t} finally {\r\n\t\t\t\/\/ in case of an exception the surface is not left in\r\n\t\t\t\/\/ an inconsistent state\r\n\t\t\tif (canvas != null) {\r\n\t\t\t\tsurfaceHolder.unlockCanvasAndPost(canvas);\r\n\t\t\t}\r\n\t\t}\t\/\/ end finally\r\n\t}\r\n}\r\n<\/pre>\n
Examine the above code very carefully as it implements the logic behind the diagram. You can find the full code in the downloadable project.<\/p>\n
There is another approach which I like. It is constant game speed with maximum number of frames per second. It uses interpolation to draw the state and it occurs on fast hardwares when there is time left for another rendering before the next game update. This can enhance the visuals of a game as it enables smoother animation but because we use mobile devices, giving the CPU some rest will save the battery quite a lot.<\/p>\n
There is an awesome article on game loops here<\/a>. I personally understood the game loops reading this article so I highly recommend it. The best I could find.<\/p>\n
Note that I also modified the default values in the Speed.java<\/strong> class. The speed is measured in units\/second. Because we are setting our desired FPS to 50 that means that the speed will increase by 50*speed.value every update. To have the speed of let\u2019s say 40 pixels\/second you will need to set the speed delta for every tick to 2 (40 \/ (1000 \/ 50) = 2). In other words you need the droid to advance 2 pixels every game update (when you have 50 game updates per second) to cover 40 pixels per second.<\/p>\n
Download the code here<\/a> and play with it.<\/p>\n
Examine it and you have a constant game speed with variable frame rate.<\/p>\n
Reference:<\/strong> The Game Loop<\/a> from our JCG<\/a> partner Tamas Jano from “Against The Grain<\/a>” blog.<\/p>\n
Do not forget to check out our new Android Game<\/i><\/strong> ArkDroid<\/a> (screenshots below)<\/span><\/span><\/i><\/strong>. You feedback will be more than helpful!<\/div>\n
<\/a><\/a><\/a><\/div>\n
Related Articles:<\/strong><\/div>\n