Log In  

Cursors and a+b is sufficient for almost anything, but what about a pause/menu button? How many controllers have there been that didn't have a start button? It would be really useful, especially for games that are a little broader in scope and could really use a pause menu of some kind.

P#16653 2015-11-14 09:54 ( Edited 2015-11-16 21:24)

Absolutely!

In the meantime, people have been hijacking the Q key from player 2's controls for this purpose, and it's kind of silly. u~u; How many NES games do you see that use player 2's controls for singleplayer stuff? Only cheat codes and Super Mario + Duck Hunt's menu thingy, me thinks. (That menu was always so fiddly for me when I was little.)

P#16654 2015-11-14 10:35 ( Edited 2015-11-14 15:35)

There's a pause button in for 0.1.4 that works like this:

Any player can press P to toggle pause. While paused, instead of calling _update() each frame, it calls a function _paused() if it exists. This way you can add your own menu code (if you want to add options or an inventory navigator or something), or display your own custom paused screen (the default one just shows PAUSED).

There are a few details I haven't resolved yet: how/if to interact with the whole-app paused mode (e.g. in the web player), and what to do about audio (pause the music? let SFXs play out and allow new ones to be played while paused?), but they can probably wait until after 0.1.4.

P#16655 2015-11-14 13:38 ( Edited 2015-11-14 18:39)

I'd much rather handle the pause state myself, though, and something like return would be much better than p. But I suppose it's better than nothing?

P#16658 2015-11-14 16:03 ( Edited 2015-11-14 21:03)

Enter is nice -- I'll map it to P by default ('P' is just an abstract button name that happens to also be P on the keyboard).

If you handled the pause state, what would it look like? I suspect that providing raw access to a third button ( btn(6) ) would be 'abused' as an in-game action button and many carts wouldn't implement pause. The advantage of _paused() is that all carts would have a standard pause mode, and a commonly understood way of doing in-game menus. It would still be possible to work around it by making _paused() a proxy function that calls _update(), but the programmer would have to be well aware of what they were doing!

P#16663 2015-11-14 16:54 ( Edited 2015-11-14 21:54)

It would work, I suppose, but it wouldn't be ideal. The extra, 'abusable' button is what I'm really looking for, not a weird solution where I have to write weird, hackish code to get it to do what I want. What's abuse to one person is just getting the control scheme to not be awful to another, right? I mean, I can't think of any console that had only a d-pad and two buttons. The current control scheme is too limiting. Even with the funky pause thing I'd probably still just use the second player's Q button.

P#16667 2015-11-14 19:40 ( Edited 2015-11-15 00:40)

Having a _paused() hook that is called when a new button is pressed states the intent of the API without constraining how it is used. It also introduces a new concept in the runtime: a user-definable interrupt. Which instruction gets preempted when _paused() is called? Does control return to that instruction when my _paused() returns? If my main code has to handle the paused state (and doesn't have a paused state if I don't implement one), then it might as well be btnp(6), or perhaps btn_pause() if you want to give it an explicit name.

If the runtime wants to define the concept of a paused state more rigidly but still allow games to customize the pause state, there could be separate _init_paused(), _update_paused() and _draw_paused() game loop hooks, along with a new _exit_paused() hook. Pressing pause toggles the behavior of the default game loop. Pico-8 can offer defaults for these hooks, so every game is pauseable. (Do something neat in the defaults like copy graphics RAM away, add a paused indicator, then when unpausing copy back and flip back to the main game loop handlers.)

Music pausing and unpausing does seem to be a sticking point, and might be worthy of a new general purpose music pause/unpause API.

With this design, you might still want general access to the pause button, so custom game loops can take advantage.

P#16669 2015-11-14 21:09 ( Edited 2015-11-15 02:09)

Idea for implementing pausing within the API:
_paused() function: what it says on the tin.
paused variable, so we can forcefully pause/unpause the game (you don't want them pausing a option screen, do you?)

@dddaaannn I don't think we'd have to do that, but rather that _draw() and _update() are ignored, leaving _paused() to deal with it all.

P#16692 2015-11-16 09:50 ( Edited 2015-11-16 14:50)

If the intent is to give carts the same capabilities during pause mode as during non-pause mode, then technically both update and draw are justified. It may be safe to assume that a cart wouldn't normally do anything computationally intensive during pause mode and only give it a draw hook without a separate update hook. But if we're restricting capabilities during pause mode, we can set that bar anywhere, including not having a hook at all (e.g. pausing pauses the console, not the game). As another example, we could have only on-pause and on-unpause hooks, and not offer a game loop during pause mode.

Good call about disabling pauseability in menus.

P#16694 2015-11-16 12:09 ( Edited 2015-11-16 17:09)

Oh that's right. Pico-8 doesn't have a way to pause and resume music at all currently, does it? ... Mmm, its music setup in general is quite extremely limited.

P#16699 2015-11-16 16:24 ( Edited 2015-11-16 21:24)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-04-13 12:32:15 | 0.012s | Q:21