Rolling Pixels: Looping Fiasco

This ‘sprint’ was a good one! This branch of work was about having a turn-based loop separated from the game’s render loop. I could see early on that trying to operate the game's turn-based rules from the render loop had problems. A quick Google search revealed agreement but no leads on solutions.  I might have been lazy about this; I found a solid <a href="https://journal.stuffwithstuff.com/2014/07/15/a-turn-based-game-loop/" rel="noopener ugc nofollow" target="_blank">article by Bob Nystrom</a> late in my search after I made some decisions. I have the player selecting, clicking, and dragging, adding to a turn queue until “End Turn” is selected. That gets the non-rendering Turn Loop going. Game objects that can act push their turns to the action turn queue (a priority queue), and then the turn loop runs through the queue of commands executing them. Right now, they just make each game object fire off an animation, all at the same time!! LMAO! I needed a “finished my turn” event to pace the commands. There’s still one call dependent on the render update loop, but I feel like I got 95% there. Refactoring may provide another look at why or making it better. Right now, I got: 1. The player sends actions to an ActionHandler queue. 2. The player ends the turn, and other game objects that can act send actions to the ActionHandler. 3. The ActionHandler sorts the queue right now by an int field called actionOrder in the commands. This is a random number for now. 4. It runs through the queue executing game object action/commands, waiting for an ActionFinished event before moving to the next command. Commands have logic to process the action and signal the game object’s animation for the action. The animation event relies on the traditional render update loop to kick it off. I think this is OK, where it belongs. <a href="https://madjay.medium.com/rolling-pixels-looping-fiasco-ce1d13d88ba1">Visit Now</a>