With the current state of the enemies, there is no possible way to make the game working, let alone “fun.” While A* algorithm is usable in terms of functionality, it does not bode well during runtime when turrets are being placed and the enemies needed to recalculate their paths entirely. However, since I have not been able to work out a suitable solution to the MT-D*-Lite with ACO issue, I have to, at a minimum, get A* enemies to a point of functioning in terms of our game; thus, brings me to the focus of the week, multithreading.
Attempting to incorporate multithreading into our game presents a few challenges. While we had set up a thread pool in the beginning makings of our game engine, it has never actually been used or testing thoroughly for functionality. And as I have found, the threading system we had in place does not function properly. After solving the initial hurdle, I am now able to properly generate jobs and insert to a queue waiting to be executed by available threads. But of course, things never work as smoothly as intended.
The second challenge comes with the fact that while we had the foresight to include a threading system in our engine, we most certainly have not utilized it, and therefore, everything thus far is not thread-safe. And finally, the main challenge, what and where to thread. While I have a pretty good idea of where the performance hold-up is located, we profiled our game to be sure. The results confirmed my suspicion that the main culprit is the A* calculations, additionally, physics system is also taking a considerable amount of time. Upon discovering the results, I was able to the multithread the collision testing on the physics and allowed the A* calculations to happen within threads, which was the main issue that caused the game to hang due to is blocking updates while waiting for the calculations to finish.