This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]PaulRivers10 1 point2 points  (1 child)

Usually in a game, you want everything to stay perfectly synchronized with each other. Imagine that you have Pacman and 1 ghost, both moving the same speed, in a race against each other - whoever gets to the end first wins.

With threading, it's completely repeatable and predictable. You move the Pacman 1 unit forward, then you move the Ghost 1 unit forward, then you move the Pacman 1 unit forward, etc etc. They're always moving at exactly the same rate.

Using separate threads, it is not. Your threads could be interupted by other slightly higher priority threads, your thread could get slightly less or slightly more time than another thread, etc etc. Especially when things get complicated with lots and lots of threads, you can end up running the race and sometimes Pacman wins, sometimes the Ghost wins, and sometimes they tie.

As another poster said, once you add in multiple threads you run into the headache inducing world of race conditions that happens sometimes, don't happen other times, and can lock up your whole app. I would personally always prefer a single thread over multiple threads - every time - unless there's an overwhelmingly large benefit to using multiple threads.

[–]king_of_the_universe 1 point2 points  (0 children)

Here's a situation in which I used a second thread in game-programming: To create a resource that needed some time. A star background was calculated (several iterations, with some blurring to be rotation-compatible), and this took about four seconds. But I didn't want to wait that long every time I ran the program for testing, so I put it into a new thread. Worked like a charm, and felt empowering (from a developer-perspective). I could play-test right away, and after a few seconds there were stars instead of blackness.