The PocketCHIP comes with a touch screen, so I'm wondering if Pico-8 games will be able to take advantage of that event?
I know we'll be able to use the touch for drawing sprites in the editor and stuff, but what about in the game. Will there be a ontouch() function or something like that? Or does a touch just register as a Z or X key press?
It'll probably do the same as clicking with your mouse on pico8's window in game
nothing.
The current product direction implies no. The desktop app uses the mouse but the mouse is unavailable to games. More input options diminishes the ability for all games to run on all platforms, and adds complexity to the API that may not be friendly for novices, depending on how it's designed. I suspect the "stays small, runs everywhere" idea trumps most feature ideas--though I don't know how much "everywhere" is important.
To date, the only platforms actually confined to the current supported inputs are custom-built arcade/handheld devices. If we call those second-tier platforms, then desktop, web, and mobile would support a single-click/touch sampling API like (x, y) = click() (the current coords for a single-click or single-touch, or nil,nil if not clicked/touched) comparable to btn(button_id). clickp() comparable to btnp().
Platform bifurcation isn't impossible, but would probably require more resources than Lexaloffle has to support. Imagine Pico Touch, a platform in the Pico family that runs all Pico-8 games plus a new set of Pico Touch games with additional APIs. shrug
Some of pico's controls are based on right clicking. Will you be able to hold a key right click by touch?
I think that adding mouse support kinda goes against the spirit of the fantasy console.
In my mind, the fantasy console is sold to the public with a pad that has 4way D-PAD, 2 action buttons and a pause button (enter on PC, opens the menu).
Devs have mouse (and keyboard) support, because the imaginary dev kit does ;)
I would vote against mouse support. There are plenty of other engines that allow us to make mouse driven games.
Seems a shame to limit what could be done - just as there are games where a D-Pad is the "right" choice, there are certainly situations where touch or mouse would be nicer. Avoiding adding a useful feature because some future platform might not support it (so far as I can tell, all current ones support either mouse or touch) seems to be paying a penalty for a non-issue. If you are really concerned about it... just don't use the feature, but crippling things because of maybe-problems seems odd.
I'd actually prefer the opposite - oddball controllers were common for consoles. My atari (400, to be fair) had keyboard, trackpad, joystick, paddle and rotary controllers.
Not that it matters too much - with gpio support on the CHIPS pico-8, we can add all sorts of fun controllers :-)
Limiting what can be done is the entire point of Pico-8. Inputs are limited just as graphics, sound, and memory are limited. We can and should continue to discuss what limits we find productive vs. arbitrarily constraining, but it's important to keep that design concept in mind.
Most interesting to me is how relative that concept is. What feels like an arbitrary constraint to one person may be the one thing allowing another person to participate comfortably. That makes Pico-8 an experiment in community building more than anything else, navigating the balances that involve and inspire the most people. There are reasons I am here and not in some Unity forum somewhere. :)
Amusingly - apparently the mouse is available, see https://www.lexaloffle.com/bbs/?tid=3549
What is interesting to me is it is kind of an unsupported, hidden thing - and that strongly recalls (in my mind) weird tricks that devs used to get the most out of old limited hardware like the Atari 2600. I'm torn - I do want to be able to support the mouse - but there is something cool about "no, no mouse" and really there is, but it's a puzzle to figure out and use. I am not sure if I like it or don't like it, but it's very interesting - and that's kinda fun.
It would probably be cool if more things - say, raw keyboard input - was actually in there, somewhere, waiting for people to explore the system enough to run across it. Hidden gems of usefulness waiting to be discovered (and of course, no promises that they will work on every platform, because hey - undocumented, and so unofficial). Kind of a meta-game being played with developers...
One thing I would prefer to see internalized, rather than eating tokens, is a two-point button system (button.previous, button.current) test that outputs:
0, 0 = BUTTON_OFF()
0, 1 = BUTTON_PUSH()
1, 1 = BUTTON_HOLD()
1, 0 = BUTTON_RELEASE()
With only a couple of buttons to work with, and a big variety of projects - and especially in implementing stuff like retro platforming physics and the like, this sort of button-checking is pretty crucial. Don't get me wrong, it's not like it would be difficult to implement manually... but it's more the point that several of us WILL do so, and then it's just eating up a bunch of tokens/code space that we could use on the fun creative side of our projects instead.
btnp() exists, and behaves the way it does for a reason. It's a deliberate attempt to make it hard to do Terraria style RSI-as-game-balance.
There's an example of how to get those extra buttons states in the MORE INPUT cartridge here:
[Please log in to post a comment]
