# Is a separate thread for game loop compulsory for simple games?

I am new to game development. In order to learn I am recreating this game on android platform. You can observe the game-play video at the above link. It is a simple game.

I have read a lot of articles on getting started with game development.Almost all of them recommended using a game loop on separate thread, which makes sense for other games. However, for this particular game do I need to start a separate thread ?

• – Anko Mar 23 '14 at 8:06
• Not sure this is a duplicate, as this is about Android. There are some other considerations about threading in a Java-based platform that are different than that question. – Sean Middleditch Apr 6 '14 at 23:52

A game loop is generally recommended because it is simple. Almost any game can be properly developed and ran by utilizing a loop, and most games would require one to properly function.

For example, most physics engines require reliable constant updates for a proper simulation. Animations and other dynamic content and graphics need to be updated every change, etc... Aka something you get practically free by using a loop.

Now do be aware that your loop doesn't have to run on a separate thread. In fact most games will run the loop on the main thread for simplicity. Even my Android projects follow this principle.

Now the real question here is what alternative do you propose? If you have another idea for how to reliably get input, do updates, and draw frames that works for you then go ahead! Otherwise a game loop might be the easiest way to get going.

• The alternative I am thinking is to update screen using main thread itself since all actions are in series - player swipes across same color balls, then all touched balls disappear, remaining balls fall under gravity along with replacement balls. – jin Mar 14 '14 at 14:33
• So you are not asking if a loop is required? Your main concern is if it has to be on a separate thread, correct? – AturSams Mar 14 '14 at 14:36
• correct. my question is about thread not the loop. for such simple game (although i will be lucky to be able to make such a game) do i need to spawn a new thread or everything can be done on main thread ? – jin Mar 14 '14 at 14:39
• No, it's not necessary. As long you have a loop, then there's no need to create a second loop. – user39686 Mar 14 '14 at 14:45
• @jin you should really change the title and how you write your question then. – Vallentin Mar 14 '14 at 14:45

No, a separate thread is not required. If you're not doing anything too intense (which doesn't look like that's the case in the game you've shown us), everything can be done on the main thread.

A second thread is required if you're doing a lot of processing or otherwise experiencing issues with the UI/input becoming unresponsive. For example, in more complex games, you don't want the UI/input to become unresponsive when the AI is calculating its next move. Since your game appears to be primarily responding to user input and updating visuals, a second thread is not required.

Answering the "Is a loop required" original question.

No, but the alternatives are more complicated, harder to implement and rarely used.

Games are by definition interactive. At the minimum, that's waiting on input and updating output. The simplest way to do that is a with a loop. It's not required to spawn a new thread for that.

Even though the game you've mentioned appears simple, it has interactive visuals and sounds and it constantly updates those based off user input.

There's not a lot of alternatives to a game loop either. Some kind of interrupt based system could be possible. However, such systems increase the complexity and reduce other factors like determinism. There's a reason game loops are so common, they're easy to implement, easy to understand, flexible and do a great job.

• The only time I encountered lower level interrupts was when a certain HW task was done and the CPU / OS needed to be notified so they could properly process it (reading data from disk into memory and then being notified that it's ready so we could be returning control to the application and allowing it to process it) so I don't know what you mean and simply misinterpreted it. – AturSams Mar 14 '14 at 14:57

Answer to actual question (Does a game loop need to be in a separate thread):

The reason people often recommend using a separate thread is because they don't want heavy processing to interfere with UI interactivity. You are the only one who can tell if a separate thread is needed for your game. It entirely depends on the engine and framework if the main game loop in your present design may interfere with the UI's response time. Thought you generally assume it won't (in small projects) unless you have a reason to think otherwise.

Another reason to keep code in seperate threads is to keep code modular and simple. Having two unrelated pieces of code mixed together can often cause code to become less readable and maintainable in the long run.

Does a game loop need to run on it's own separate thread? Possibly. If there is a problem with response time or code and you need multiple UI items to respond regardless of heavy processing or you simply wish to break the code into specific tasks that occur simultaneously for design reasons then go with it. However, it is considered an advanced programming practice.

A simple but perhaps not a great example to illustrate is a two player game. You may want to run two instances of a class that handles user input and converts to state changes in player character instance.

Some frameworks encourage/require you to utilize and event/interrupt based system like ActionScript3.0 does. In those case the loop code will normally go to the OnEnterFrame event or something similar that occurs 20 - 60 or 120 times per second.

Answer to original question (Do I need a main loop):

It all boils down to the program counter. If you are making a game that will run more than a predetermined amount of time and will not generate code as it goes then you will need to kindly request your user's pc to repeat some instructions that it has already processed and what will possibly change in the meantime is the state (the values stored in the game's objects and globals).

Since you know you will need to repeat instructions, there are several ways to complete this task and continually process the same instructions. All these methods involve moving the program counter back to the currently relevant instruction. The most common control flow statements that cause code to be repeated are called loops, another is the goto statement which is rarely used in modern code and has a similar effect in this case (completely not relevant to you).

So to answer your previous question, do you need a loop? Yes, you do.

• As far as I know, event based frameworks, like AS3, still has a game loop running underneath. I'm talking about lower level interrupts, not a framework that implements an event system. – MichaelHouse Mar 14 '14 at 14:43
• Hmm.. I don't think people oft use lower level interrupts in games. AFAIK they are mainly used by the CPU to monitor IO operations. I was thinking of a higher level abstraction as a design practice where you respond to user input or hardware activity (without polling) rather than run several instructions every frame and then tell the HW to render the result. – AturSams Mar 14 '14 at 14:52
• Yes, people don't often use those, anymore. Like I said, they're harder to use and we have much better ways of doing things now. I understand what you're saying, and it's certainly a different way to think of things, but it's only on the surface that it appears different, underneath it's the same type of loop. – MichaelHouse Mar 14 '14 at 14:58
• I agree with @Byte56 it boils down to a loop, unless we are talking about a kernel level events which use IO interrupts. – concept3d Mar 14 '14 at 15:02
• I know that but most of everything we do is the same underneath the surface (like I said, changing the value of the program counter). This is no secret and I pointed it out in the answer. The event based programming is seemingly different because we move the program counter to different functions when different events occur. Obviously there is likely a loop polling to check if these events recently occurred but as a design principle it is seemingly different. – AturSams Mar 14 '14 at 15:03

Just to add to some others' answers here, something that no-one has explicitly mentioned: If you do take the risk of running your game loop in a second thread and it becomes unresponsive, you risk the OS terminating your application. That's why it's recommended to use a separate thread. Hence (for example) the NDK's native_app_glue.c/.h spawns a separate thread for your loop.