One of the "good parts" of Java that has intrigued me is that one can program multiple threads.
Now, there has been some back and forth whether the "best way" to run a game loop is to use the classic form (while loop that executes updates then display then sleeps to fill out the duration of the loop) or to do so via a Timer that iterates, launching a new thread for every game cycle. As multithreading continues to be a place where Java excels, it seems to me that a Timer-based game loop system makes a lot of sense, and may end up being a better choice than the classic game loop. But the classic game loop is definitely the most popular choice currently.
Does this seem reasonable, or does it betray some misconceptions about multithreading and Timers on my part? Or maybe the game loop itself is not an area where multithreaded aspects make too much difference. Maybe the key aspects of multiprocessing is, rather, in the ability to have parallel threads handling the increasingly complex graphics (lots of calculations in 3D) and sound playback.
Anyway, I'm curious what sort of matches you see there being between the language's "good parts" and game programming.
Personally, I think spawning a new thread per cycle makes very little sense.
You use threads when you want to do two things at the same time. Do you want to draw the two cycles at the same time? No, you always want to draw them one after the other. So just use a single thread. If you use multiple threads you are going to introduce a *lot* more complexity. What if the timer spawns two threads, and the latest one finishes its cycle before the old one?
I agree that spawning a thread per cycle doesn't make a whole lot of sense, unless you plan on having multiple cycles occurring at the same time (which doesn't make a lot of sense, either).
If you are talking about a single-player game, then you might want to think about having a single thread per entity in the game (such as the AIs) and let each thread use a cycle for a synchronization point (the hard part of doing multi-threaded programming is the synchronization and data sharing).
If you are thinking about a multi-player game, then things get more interesting-- using multiple threads on the server, one for each player (or one for each player's interaction) can let you spread the server side of the game over multiple cores in a way that allows much better use of modern multi-core chips. I spent a couple of years working on such a project in Sun Labs; the result is available in open-source format under Project RedDwarf. There were a lot of interesting ideas in the server only some of which we had time to finish up before Oracle took over Sun (and decided that they didn't do games, and hence cancelled the project).
What if the timer spawns two threads, and the latest one finishes its cycle before the old one?
I decided to check this out. The following code and the Console results shows that the threads spawned by a single Timer do not overlap. Or rather, "what happens" is that the new thread is blocked by the previous thread.
I think that the classic game loop is often placed on its own thread anyway, so having a sequence of threads that never consume more than a single thread, perhaps that is not such a bad thing?
The benefit of the Timer is that it automatically keeps the frame rate even, without requiring calculations to determine elapsed time per frame. The contingencies written to manage overages with a classic game loop can also be applied to the Timer thread instance.
But to go back to my first question, I can see that there probably isn't anything to be gained, in terms of multiprocessors with this particular aspect of game code. Maybe, just maybe, it would be an interesting exercise to write two loops, one for updating game state, the other for refreshing the display, and have them work concurrently at separate rates. The suggested possible use, separating out AI, also makes a lot of sense to me.
However it is neat to consider the uses in multi-player games. I hadn't heard about Project RedDwarf. This looks very cool! Thank you for the link.