Or I could just keep them as seperate processes (or maybe just threads) and make the graphics maintain a queue of the actions. So if the graphics is animating Tom the Monster walking over this way, the game doesn't have to wait for anything (since it already knew where Tom the Monster was long before it told the graphics) and could just start going through the AI. The game only ever really needs to wait for the user because it can't just start running AI for a character the user controls.
You haven't gotten anywhere near this point yet, have you?
Yes, the actual game logic does wait for user input. However, since you're using graphics to communicate events and results, the player needs to see that. The player would probably want to know where the AI has moved Alice the NPC before shifting focus on the next character. If the camera is far away that the entire battlefield is visible (similar to the recent King's Bounty games), this wouldn't be a problem. But usage of camera centering implies that's not the case. Also, what you're saying is that you want the game to shift to the Bob the PC when Alice the NPC has made an attack on Carol the PC (or even Bob the PC!) and the animation is still running... way before the damage numbers show up. The player won't be able to see the results unless this information is displayed in an on-screen combat log (again, similar to the recent King's Bounty games).
I do agree with the others who have given you advice. But probably the best way for you to figure out the best way would be just trying to do it yourself and figuring it out from there.
As someone who's also working on a turn-based hexagonal grid SRPG, I do wish you the best of luck along your journey. You'll need it... especially when working on meaningful battle mechanics and programing the AI for all that.
