Struggle with the storing and executing of "between turn" things.

[togFox]

I have a turn based game. I can process inputs and movements and combat and outcomes and results and all that state-based stuff. Bread and butter stuff that happens in every game.

I struggle to control the flow of "between" activities. Example, when moving from one hex to another, there is a bunch of animations and sounds that need to happen while traversing between hexes. Sometimes multiple things have to happen and I assume ppl have some sort of queue with a timer(?) that ensures things are managed at the right pace and sequence?

For example, if you had to draw a person moving from one hex to another (animation) while a fireball heads to the previous hex that the player is leaving (animation) while playing an explosion sound when the fireball ends (but at the right time and not too soon) while ensuring the player animation stops at the correct pix/hex and ensuring player control/input is STOPPED until all of that is completed.

How you track and sync all that? I bumble through but I'm convinced I'm not doing it right.

[togFox]

I'm thinking I need a state-machine (which most games are) with a state that is "in between" turns.

When the game is "in between" then the love.update() needs to do a few things:
- ensure player input is ignored
- have a queue of some sort that tracks the animations needed including where and how long they execute
- another queue of sound effects that tracks when the audio starts and stops
- execute both queues during each dt/game loop, ensuring the clean up each queue as activities execute and expire
- ensure it can leave the "in between" state and move to a state where player once again has control. This event can also be in a queue.

Or something like that.

[dusoft]

I'm thinking I need a state-machine (which most games are) with a state that is "in between" turns.

When the game is "in between" then the love.update() needs to do a few things:
- ensure player input is ignored
- have a queue of some sort that tracks the animations needed including where and how long they execute
- another queue of sound effects that tracks when the audio starts and stops
- execute both queues during each dt/game loop, ensuring the clean up each queue as activities execute and expire
- ensure it can leave the "in between" state and move to a state where player once again has control. This event can also be in a queue.

Or something like that.

HUMP Timer works well for me. However, it does not have a "follow" function where you could have multiple objects with tweenings following each other. This can be built into a table of seconds though and using Timer.after function in each step.

[dusoft]

I'm thinking I need a state-machine (which most games are) with a state that is "in between" turns.

When the game is "in between" then the love.update() needs to do a few things:
- ensure player input is ignored
- have a queue of some sort that tracks the animations needed including where and how long they execute
- another queue of sound effects that tracks when the audio starts and stops
- execute both queues during each dt/game loop, ensuring the clean up each queue as activities execute and expire
- ensure it can leave the "in between" state and move to a state where player once again has control. This event can also be in a queue.

Or something like that.

Since I am using state manager, it's easier to cope with cases like this. Each state knows what input (or no input) is allowed. Time.after can switch state automatically after certain amount of time, when animations (calculations...) happen.

But sure, queues would be tables for me with each mapped point of time when timer or tweenings need to be called.

[RNavega]

That sound pretty cool actually, do you have any clips of it in action? Even if it's placeholder/rough graphics.

I struggle to control the flow of "between" activities. Example, when moving from one hex to another, there is a bunch of animations and sounds that need to happen while traversing between hexes.

(...)

How you track and sync all that? I bumble through but I'm convinced I'm not doing it right.

If I was asked to work on something like that, I'd design it like this:
There are two structures here: one is an ordered structure like a list / queue / stack of things, let's call it "T" for brevity, and this list holds things that need to be triggered. The other is a collection (doesn't matter if it's ordered) of things that are happening right now and need constant updates until they finish, let's call it "U".

When the turn has finished and you want to enter the "cinematic mode" (that passive mode where the player only watches things unfold), internally the program enters the state in this step #1 below here:

1. In this game state, remove the first item in the ordered list T. This item holds some data and a function. The function is called with that data, and it's expected to "do one or more immediate things in the game, and initialize animated things for this cinematic step". This might be asking a character to move, or creating projectiles, or playing a sound etc. These animated things don't start right now, they are just activated, and the way that they'll be updated is by adding anything that needs to be animated to the collection U.
   So when this item executes, something in the game can happen immediately, as well as zero or more things that happen over time can be created/reset and added to collection U.
   The item was removed from list T, so the list shrunk in size, and then you go to the step below.
   ---
2. You enter another game state, which is "update the things in list U until all of them are finished". On each frame, you update all the things in collection U, and each thing represents some animated element or effect etc that is being performed. Each thing must mark themselves as "finished" once their animation / effect has ended. There might be just one thing, or even many things happening simultaneously: imagine a special attack that fires many projectiles towards different tiles, so each projectile is a separate object that was added to collection U that animates towards the tile it's targeting, and after each projectile hits, some damage effect / explosion animation can be created and added to U. So in this state not only do all the things in U get animated, but those things can cause even more things to be created and added to U, like a chain reaction.
   However, eventually all of the animated objects in U will finish (it might take up to a few seconds), and once everything in U has finished you go back to step #1.

After going back and forth with those 2 steps above, you'll have performed the entire list of things to do. The entire inbetween-turns cinematic.

When the game is "in between" then the love.update() needs to do a few things:
- ensure player input is ignored

Regarding ignoring the player input while all of this happens: you're actually partially ignoring it, right? Or rather, there are layers to this event handling: you have the "system" layer that keeps listening for important keys like Alt + F4, Esc etc so the player at any moment can pause / change settings / exit the game no matter what's happening (always being responsive is super important), and the "gameplay" layer where it routes input events to actual gameplay things.
The UI gets controlled by both those layers: it can bring up a pause screen when commanded by the "system" layer for example, and can do other things (like moving the camera, selecting a unit etc) when commanded by the "gameplay" layer.

Even during that passive cinematic mode you should give the player some control with the "gameplay" layer still reacting to input: allowing the player to hold a key to speed-up the cinematic (you multiply 'dt' by a constant so the things execute faster, like mult. dt by 2 to double the speed) or pressing a key to outright skip those things (when pressed, you ask all the U elements to finish at once so the next item on T will be executed right away).