It is nice to see that you want to learn about the possibilities of multi-threading, but you also have to think of a good scenario to learn it in. Multi-threading can make sense, but not in every situation. Your game is not one of them.
At universities, the hardest part of teaching students new concepts is finding examples of where they can be used efficiently. This is also very true of multi-threading as well. Often, I find that the practice scenarios that are conceived are far too synthetic to show any real benefit of multi-threading, but I also understand that coming up with a meaningful task for students to work on for the duration of a week is also a daunting task. A sacrifice had to be made, and any good lecturer will also explain this. The worst that can happen is that one learns how to employ multi-threading, but not
where it should be employed. This gives students a false sense of security when they make such decisions, often leading to sub-optimally designed code, because "they learned that employing advanced concepts leads to improved performance". This is normally rectified in more advanced courses that in my opinion should be mandatory, but aren't. I can only hope that these people learn from their experience that their eagerness to simultaneously employ everything they have learned can ultimately be their undoing.
Since you don't seem to have any time constraints, I would recommend coming up with separate projects each targeted at learning individual concepts. It is already enough of a learning adventure working on your own game. You don't have to mix in other concepts just because you can.
Good scenarios to employ multi-threading in generally consist of parallel independent computation that saturates a processor. I need not explain that multi-threading only really started to make sense with the advent of processors that also support it.
The parallel part should hopefully be obvious. Independent means that data of one thread should not (if at all) rely too much on data from another thread, leading to the threads not having to wait for each other. This provides near linear speedup in most cases. The last part about processor saturation is harder to understand. Many beginners tend to base their performance assessments on some task manager that shows processor utilization
of the whole system. Obviously, if your code only contributes to a minority of the total (outside of your process as well) work that has to be done, running it over multiple threads won't make much of a difference. This is easily detected using profiling tools, as others have already stated, so it is very strongly recommended to profile before writing multi-threaded code. If you have background knowledge of the algorithms that you employ in your code, and their time and space complexity, it will also help you to determine if and where to optimize using multiple threads.
Based on that, I have to tell you that the best examples to learn from are those that deal with some sort of well known algorithm. Indeed many AAA games that employ multi-threading themselves only do so when executing said algorithms, which often end up being part of external libraries that were already optimized. I don't have any insider information, but I can assume that many of them also pre-maturely optimize other parts of their code and end up eating a lot of processor time through the overhead that is incurred. This is often passed on to the consumers by media as "badly optimized" or even "un-optimized" games. Sometimes they even tell consumers that it simply lies in the nature of what has to be computed that the processor requirements are so high, hoping that laypeople won't suspect any lack of effort on their side.
I know this is asking much of you, but if you really heed what I have said, and want to learn about multi-threading in an isolated environment,
this list could be of interest to you. You will probably find a few algorithms you have heard of before on that list as well. Try implementing some of them,
first without multi-threading, profile and then using the profiling information, optimize the hot spots. This way, you will get a feeling for the entire process from start to finish as well.
Learning is a good thing. Learning the wrong way is bad.
