look into / ask about megazeux update loop

[increpare]

I tried looking at the code myself but it was just a bit too big of a project - I should just ask :)

[zzo38]

How is the relevance of MegaZeux, in PuzzleScript?

[increpare]

Puzzlescript has functionality for realtime games - https://www.puzzlescript.net/Documentation/realtime.html , and there are several modes. This makes it quite similar to ZZT/Megazeux. But I've never been totally convinced by any of them as I implemented them(how the 'tick' of the natural world should combine with the input of the player), so an exact comparison with other similar engines might be helpful!

[zzo38]

I know how ZZT is working. The working of ZZT is that stats are executed in the order that they appear in the stat list, where the player is the first stat. Some stats are slow, and will not be executed on every turn; the exact criteria is (Cycle <> 0) and ((CurrentTick mod Cycle) = (CurrentStatTicked mod Cycle)), where Cycle controls the speed, and CurrentStatTicked is the stat nmber (zero for the player). Input is handled during the player's turn (stat 0).

MegaZeux works differently than ZZT, and does not have stats like ZZT.

[increpare]

Oh, someone who knows! Hello! Thank you for your comment!

So would you say that ZZT has a fixed timer and processes input+other events on that timer?

I'm going to past a list of timing possibilities - kind of for my own future reference, apologies if they're not so clear to read - I'm happy to answer any questions about them/clear up ambiguities, but I don't think you need to understand any of them to answer my question. 😊 [At least three of them must already be supported by puzzlescript but I'm not sure exactly which three anymore ^^ ]

This is the legend:

In the standard turn-based mode the engine just does stuff whenever you input.

A naive approach to realtime timers is to just have a game timer, and have input events trigger their own events

One problem with this is that maybe the player can move infinitely quickly if you press keys quickly.

One way of working with this is to have the input rate be throttled to the frame rate (even if the inputs are processed immediately, you can't trigger input events faster than the framerate)

One can have a fixed timer, where any events you have will trigger on that timer's tick (in puzzlescript this could take the form of queuing up multiple events and processing them all, or it could take the form of just looking at the most recent input. Or just the first. I honestly don't know what'd be best, if any)

An alternative to the above which might feel more responsive is the force a tick when you press a button - bringing

Another possibility is to poll the keys just during the regular tick - if a key not held down when the tick happens, ignore it

(this is weird because you can quickly tap keys between frames and nothing happens)

Another options is, when you press a key, to trigger the next 'frame' immediately, but to keep the subsequent frames in sync with the original timer:

Two things unaccounted for in the above list:
1 - how they handle 'again' rules. It's hairy and makes things much more complicated. Are again animations blocking of the regular timer? Are they blocking of future input if it's a realtime game? Who knows!
2 - how should key-repeat work? Well you can use the system key-repeat timer. But maybe it's better to have it synced to the engine ticks right?
3 - how you detect if you're on an input event frame vs a normie frame, and what games benefit from what systems.

[zzo38]

So would you say that ZZT has a fixed timer and processes input+other events on that timer?

Yes, that is how it is working. (You can adjust the game speed by pushing S on the title screen; some forks also allow typing ?SPEED during the game to adjust the speed.)

[increpare]

Ah thank you! Good to know!

[increpare]

Your use of ZZT-specific terminology led me to do a bit of research which helped get me better understand what's going on with how ZZT/Megazeux are structured. For future increpare I'm just going to post my list of things I found out here:

https://museumofzzt.com/article/view/503/full-motion-video-in-zzt-state-of-the-art/

ZZT runs in terms of cycles. At the default game speed, one cycle lasts two PIT10 ticks. The PIT runs at approximately 18.2 hertz, giving an end result of about 9.1 frames per second.

Questions:

• What's a board?

  • Playable map region ( https://wiki.zzt.org/wiki/Board )
  • Can contain 150 entities with stats

• What's a stat order/list

  • Internal array of active entities

• Whats a Cycle?

  • A cycle parameter how often a statted element update
  • An element with a cycle parameter of n updates once every n ticks.

• What's a player

  • first in stat list
  • responds to user input
  • can issue touch events
  • in slot 0 of stat list

• Params are passed to tickplayer - it looks like on a synchronised cycle

  • It looks like key-repeat is synced to timer, but builds up gradually
  • Looks like it just reads the last keycode maybe?
  • https://cknave.github.io/zztasm/player.html
  • https://wiki.zzt.org/wiki/Player

• Compare with megazeux, see if it uses the same terminology

  • They would if they documented it ^^
  • -MegaZeux uses cycle 1 as default (as opposed to ZZT's cycle
    3)."
    https://www.digitalmzx.com/mzx_help.html

"Given two objects running at Cycle 1, the object first appearing in the [stat order] list can send a message to the second object and have the latter react to it on the same frame."
https://wiki.zzt.org/wiki/Stat_order