Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

So here's the situation. I'm making a game that mixes two genres; arcade shooter and puzzler. They don't intertwine TOO much; all the interaction that really goes on is that every time an enemy is destroyed, a block is created. The blocks aren't even a part of the main collision detection system; they have their own more suited to their needs. What I want to ask is this; might it be a good idea to have the arcade shooter portion run on one thread, and the puzzle game portion run on another?

share|improve this question

3 Answers 3

up vote 3 down vote accepted

Probably not, unless you want to create extra work for yourself.

Threading is an optimization, which adds significant complexity to the program, and if you don't move the right thing on to another thread it won't even add much performance. The only way to know what the right thing to optimize is, is to use a profiler.

If you do want to use threads to improve performance a task based approach is what I'd recommend.

For example, let's say that for example once you've finished writing the game you find that the arcade game code takes 20ms / frame, and the puzzle game code takes 2ms / frame. That gives a total frame time of 22ms. In that case at best moving the puzzle game to another thread saves you 10% of the frame time. However if you could split the arcade game across two threads that could gain you up to 10ms.

The task based approach has the potential for even better performance, because it can easily scale to more than two threads.

It's also worth noting that games are generally not easy to split across multiple threads, and there's much better ways to optimize Python code than using threads - for example rewriting the expensive parts of the code in a lower level language like C/C++ can give huge gains.

share|improve this answer
    
Would you mind elaborating on that? –  JesseTG Dec 10 '12 at 2:45
    
I've added some more detail, is that clearer now? –  Adam Dec 10 '12 at 23:49
    
Yes, much more so. Perhaps I'll come back to this issue when I actually write a game in C++. Thanks! –  JesseTG Dec 12 '12 at 1:14

In addition to what Adam has already said in his answer (and especially the second paragraph), it's worth noting that Python does not scale well with threads at all, because there is a global lock shared across all Python threads so that only one can run at a time, except under certain conditions. So the answer to any question like "Multithreading for XYZ in Python?" is almost always 'No'.

I'll add one thing - multithreading can indeed be used as a way to improve code organisation. But this is almost exclusively to allow a linear process to run in parallel with other processes that don't share many resources. Your situation doesn't seem to resemble this in that neither process is linear, and that you are likely to have many shared resources (eg. screen, input devices, sound system). As such it is probably better to go with the usual time-sliced approach.

share|improve this answer
    
OK, so red light for gameplay. A simple addendum; I'm going to add online high scores, and I was wondering if multithreading might be a good idea for that. One thread could be used to play an animation or handle input or something, and the other would be used to actually try to retrieve the scores. I'm using a high-level platform to get the scores (i.e. I'm playing with HTTP and JSON, not sockets). What about that? –  JesseTG Dec 12 '12 at 1:16
    
You could put a slow network operation like that in another thread, if the API is suited to that. Whether you actually get any benefit from it will depend a bit on how it's implemented. –  Kylotan Dec 12 '12 at 2:54
    
Mind elaborating on that? (Bear in mind I have very little Web/network programming background.) –  JesseTG Dec 12 '12 at 6:33
    
If the networking API expects to pause while it makes the connection, then that would hold up your program and is a good candidate for a separate thread. However, most people who make network APIs don't want to force people to add threads, so they usually include some other way that avoids the pause - in which case, you shouldn't add threads into the mix and complicate matters. –  Kylotan Dec 12 '12 at 15:33

First: Threads and processes are different on different platforms, and there is an advantage to using processes on Linux and a disadvantage on Windows. So your intended platform may drive which one you should use.

The general rule of thumb is that if you are hardware-bound, you should split blocking tasks off into their own thread. If you are computation-bound, you should split high computation tasks off into their own process.

Second: Adding concurrent processes of any sort adds complexity because you are inherently creating an asynchronous condition that requires synchronization. In other words, you must share data and time across the various tasks. Unfortunately, the programmer must explicitly identify and create a design for these tasks to communicate with each other.

Third: Testing and especially debugging becomes much harder because the tasks run independently of each other and obtaining state information for each task and the system itself is much more complex. This often means that you must increase your verbosity for logging and traces.

The general consensus is that you should not optimize your code too early. In other words, design your code as modular as possible, but do not add the extra complexity of threading until you realize that you must.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.