I was trying to make a game where the action onscreen pauses briefly when the user has scored a hit, so that they can see that their hit has happened, but that the underlying ticker still continues and time continues to elapse.
I was finding this surprisingly hard to get working, until I stumbled across what I think is the explanation: the ticker itself stops when its actions’ conditions are unmet.
That strikes me as a puzzling feature, possibly even unintentional? It would be a bit like playing a kids game of freeze-dance, but when the leader says “Freeze!”, not only do the kids stop dancing, but time itself also stops, and everybody gets trapped in that moment forever!
Here’s an illustration:
Now that I know (or at least I think I know) what the underlying obstacle is, I’m guessing I should be able to fix my code. That said, I don’t think this ticker behaviour is documented anywhere online, and I’m guessing I’m probably not the only person who has been tripped up by it.
Hence this message. To me, the only thing that should stop a ticker should be if the user directly clicks on its little metronome pause button. Otherwise, people may find themselves puzzled by time suddenly stopping, just because the dancers were meant to freeze.
This feels almost like the “if a tree falls in a forest…” question! If there is no action for the ticker to execute, but the metronome is bouncing back and forth, is the ticker really running?
For your example here, A_updateAction becomes undefined when the user slides p_auseVarUpdates to 1. Thus, the ticker has no actions to perform, and shows up as disabled. When p_auseVarUpdates is returned to zero, the action becomes defined again, and so the ticker resumes. The only time a ticker stops is if you click into it to update some variable names — otherwise, it’ll be patiently waiting to execute a ticker whenever it is given a valid actions.
You can actually see this by capturing dt: here, if you briefly slide i_sPaused to 1 and then back to 0, you’ll see the maximum T jump to some large number, representing how many milliseconds passed between ticks of the (still-running!) ticker.
For your context of pausing the game when a hit occurs, I suspect you’ll be wanting two timers: one for “real” elapsed time, driven by t_imeReal -> t_imeReal+dt, and another for “game” elapsed time, driven by t_imeGame -> t_imeGame+{i_sPaused=1:0,dt}. That way, you can have whatever splash effects you’re looking for continue during the pause frame with t_imeReal, and the game can pick up with t_imeGame.
Thanks, that’s an excellent suggestion. Following your advice, I’m trying a version of that idea now, with a variable t_main and also a secondary one t_trial for each individual trial of the game (one trial = one space invaders ship coming in and needing to be blasted).
However, with that approach I’m running into a new problem: I seem to need to update t_trial in two different ways: one way is to increment it every dt, and the other is to reset it to zero whenever the previous space invader has been blasted and a new one comes along. The problem is that Desmos throws an error if I try to have more than one action affecting t_trial, because it views it as thereby getting defined in two different places.
I’m guessing there’s some fairly simple solution to that problem that I’m not seeing. But so far at least I am indeed not seeing it!
You can get around this restriction by making sure the two actions have mutually-exclusive conditions, I believe - for example t->t+1 {t<10}, t->0 {t=10} or similar.
Great, thanks so much. Those mutually exclusive conditions are just what I needed.
You’re right, I’m still tinkering with the same space-invaders / angle-identifying game that I was working on a while ago. I think I’m finally starting to get it to having decent game play now, in no small part thanks to you and your colleagues! Thanks! I’ll post it on Twitter when it’s presentable.
The only thing I did encounter and couldn’t quite explain was if you have a “named” action - eg. N_ext - then the ticker does not like the format N_ext {t=5} (it sees it as multiplying an action by a number), but will accept {t=5:N_ext} format instead.
Aha, interesting! I didn’t know you could do that second type of conditional syntax ordering.
I had also run into not being able to put conditions on my named actions in the ticker, but I didn’t realise this was unexpected behaviour. When I moved the conditions into the action-definition expressions they were accepted as ok.
Thanks again for telling me about the named-actions trick. That has really helped me a lot!
For a named action like A=a→1, writing A{condition} will fail because {condition} behaves like a number, and actions don’t allow for multiplication with numbers! On the flip side, {condition: A} creates a new action that is identical to action A when condition is satisfied, and undefined otherwise.
Defining an action like {condition1: a→1, condition2: a→2, condition3: a→3} is a good way to pick between the updates you want for a. If you want multiple actions to execute when a given condition is met, definitely include some parenthesis! {condition1: a→1, condition2: (a→2, b→3)} is not the same as {condition1: a→1, condition2: a→2, b→3}