I’m intermediately experienced with java, and I was wondering how a game should be threaded.
I’m not entirely confident that I know how threads work, so any information on this topic would be great! 
The only thing I really know about threads is that they allow operations to be done without causing the main thread to lag or sleep.
Thanks in advance!
1 thread for logic and rendering. That’s all.
Extra threads should be for very time consuming operations that do not need to run at the same time as the logic, such as reading files, loading resources, and path finding.
And maybe a thread for music and sound as well.
@ra4king - Do you second this? (I imagine it would be mainly for the loading of sounds which I would generally pre-cache)
Also. When you say 1 thread for logic and rendering, you mean 1 thread total? as in I can just use the main thread?
or do you mean 1 thread for each? Because with my non-optimized rendering of a skybox and a 64x64 grid of cubes, it takes about 2 seconds to finish defining all of the vertices and to initialize the drawing of each. (after this, my fps is fine) and that is what brought me to asking this question.
What you can do is do not render anything that you can not see, so reducing the 64x64 cube to something that maybe only shows the front side of the cube or something, this will reduce the time.
edit: im assuming you mean a 64x64x64 or something of cubes, so you can render just the outside, but dont render the inside this will reduce it massively from
262144 cubes completely rendered
to
24576 cubes rendering the entire outer of the cube, where you can remove the rendering from the back (as the player cant see the back, that will just reduce it to like 20576 cubes. which should definitely be under 1 second
ra4king is completely right.
1 required thread
Extra optional threads…
Any other thread will slow down your game to a snails pace for no reason. Also, you’ll have to deal with synchronizing threads… which is totally not fun when you have to use the java lock and unl… Yeah, stick to 1 thread for game actions, and keep your game quick and headache free.
It is only a 64x64 space (4096 cubes…I assume this adds up to 49152 faces…12 for each cube (front and back?)) but every face of every cube is being drawn (front, and back). It was just for testing, I wasn’t trying to optimize the rendering. I just wasn’t sure if threading would be involved as part of the optimization or not, but they have answered my question
Thank you everyone for the replies! If only I could get this many on my other questions >.>
A: It depends.
Multiple threads only really help on multi-core processors, most of the time they just over-complicate issues. Though the recommendations for splitting off things like loading and audio can benefit any application, your best bet is that if you don’t understand threading well, just don’t use more than the main thread. Most classes that benefit from them will create their own threads anyway.
One problem with mixing libraries is if they are not thread-safe then using multiple threads where not initiated on their own will require more programming, and a lot more work. However, if you’re making it playable over the network, you will need at least two threads, one for the network and the main thread. Networking complicates matters because of this, and probably why most games are not over the net. Network events will happen out of synch with your main thread all the time, thus why you need the thread exclusively for network data transfer.
Yes, playback of audio should always be done in a separate thread, and a higher priority one ideally. However, whether you need to create the Thread yourself depends on which audio library you are using. Most higher level audio libraries will handle this themselves. You should be aware of this if you are manually writing bytes to a JavaSound audio line. I’d use something like TinySound if you need to use JavaSound, rather than using the higher level (Clip) stuff built into JavaSound itself.
In a multiplayer environment it can be sueful to collect all player input in a queue and let a pool of worker threads handle the queued actions. That way you can scale parallelism very nicely.
In single player games the only thing that comes to my mind in addition to the suggestions above is to prefetch data from disk in a thread of it’s own. If your game needs to access a lot of data and you can’t keep all of it in memory at once - in that case the thread would have to estimate the next needed data chunks and read them parallel to the game, so they are readily available when needed.
like nsigma said, most libraries do this by default, so you who is just using those libs, doesnt have to create threads manually or anything.
thats true for most of the stuff like audio and maybe input.
situations that force you to built your own thread structure for things like streaming stuff in the background or AI/pathfinding or whatever, should be avoided, unless you really really know what you are doing and/or the scope is small and clear
loading some stuff in the background, where synchronization isnt all that important, may not be that much code and might be ok
but you dont want to do 8 core PS3 dev if you have no experience with it.
The proper number of threads to use if you don’t understand threading: 1
I would say the vast majority of 2D OpenGL games will run efficiently enough in a single thread; and thus multi-threading (which greatly increases the complexity of your engine) falls under premature optimization.
Yes. Agreed.
Limitation on agreement ( ;D ):
In special cases multithreading improves performance cracily… (I, for example, had a pretty cpu-intensive light “calculator” (no, not a gl-lighting “engine”)) Without threading out the light calculation I got about 20-30 fps (yeah, this was a big issue), then I got 200-300 fps… which is… quite awesome
I disagree. Making threadable game logic is very easy at times. Collision detection, AI, etc can be threaded pretty easily. If you’re interested you can take a look at a small library I wrote just for this: http://code.google.com/p/small-java-threading-library/
1.) Animation ( you don’t want animation to freeze while you’re waiting for a process to finish )
2.) User Input ( when I click something, I want to see immediate feedback )… I found that this was critical when I was programming my 2D side scroller.
3.) Networking ( latecy on bad connections can reach 2,000ms… you shouldn’t hold up other processes because you’re waiting for a reply from the server )
4.) Any additional assets that aren’t critical to gameplay, but are “nice to haves”… I.E. Music… If I’m playing WoW, and the music fades in 15 seconds after I log in, I might not even notice, and I’d much rather be running around Stormwind for 15 seconds without sound, then waiting 15 seconds at the load screen waiting for them to start simultaneously.
Hope this helps.
-Pickle
I usually have animation and networking in the same process/thread. With non-blocking reads of course.
I use one thread for logic and rendering, one thread for resource loading, and one for each sound in the game. I use the standard EDT to poll input.
A thread per sound isn’t a good idea.
Rule of thumb: 1.5-3.0 “active” threads per core per timeslice for max throughput.