I've been using the Pico-8 for a while now, since it's pretty much everything I've ever wanted in a "fantasy console", and I would have made one almost exactly like it (albeit with a larger palette and looser limits, perhaps...) if and when designing and programming one myself. So to skip that entire process and jump straight into making nifty little widgets and toys for this device... Well it's been quite a dream come true!
That said, Pico-8 is far from being without issues, and more keep cropping up the more I play with it. So, outside of bug reports, here's a small laundry list of things I "want", or would be nice to have at some point...
Note: This is a blog post, an off-the-cuff rattling of random things I personally would desire. I'm not expecting it to be directly acted on or hotly debated or anything like that, this just keeps track of what I want so I don't forget, you know?
The ability to call non-system functions without arguments in the same way as system functions, eg. as "run" instead of "run()". Maybe before trying to process the input as a Lua script, it should try to see if there's a global variable by that name first, and if that variable is a function, call it?! There's no reason to make such a distinction in most cases.
How about a find(needle,haystack) function? It would search strings for substrings or arrays for values and return a number from 1 to #haystack where it's found or nil, false, 0, -1, or whatever when it's not.
I often find myself needing a pause button, even if it's not a game button. The only way to pause a game right now, if it's not in the web player (which can be paused by clicking on it, as counter-intuitive as that sounds!), is to press Esc to kill the entire program, which often has unfortunate side effects like stopping the music or reverting the map, sprite, and sound data.
If it doesn't already, when Lua "runs out of memory", it should first try to garbage collect and see if that frees enough space to keep going.
I need the type() function back so I can have mixed type arrays again. Without it, and without tostring(), there's no way to avoid accidentally crashing the script trying to concatenate arbitrary values to print debug text and whatnot... I'm forced to carefully distinguish variables and keep it all totally separate. Bogus, man!
I want the _G table back so I can iterate through variables in the global namespace or "construct" variable names by string concatenation. It would have to be lower-cased to _g in Pico-8 due to the whole mono-case thing it has going on.
load()'s silent failure is a troublemaker, and there isn't an exists()... So either make load() return a meaningful value (a boolean perhaps) or add an exists() that checks for a file or make ls() return a list of files or something... Come on...
- Change the hardcoded _mainloop function so that it works more like this:
local must_draw = true
while _update or _draw do
if _update then _update() end
if _draw and (must_draw or stat(1) < 1.0) then
must_draw = false
else must_draw = true end
(This was the closest approximation I was able to make without knowing the actual script source.) That way, programs can have only an _update loop or only a _draw loop, swap them out, or even terminate the main loop by removing them both. There is currently no way to exit the main loop otherwise, as far as I'm aware. * I miss metatables, but considering Pico-8's constraints they're not high on my priority list for the return of...
Correct me if I'm wrong, but based on our chat discussions, I believe you're referring to calling functions from the command line interface, where "ls" is a command but "foo()" is a function call, and "ls()" just happens to be available as a function from Lua the way it's currently implemented. Making the arg list optional for all function calls makes the grammar ambiguous, so it'd have to be limited to the case you describe, where the function reference is the only thing in the REPL statement.
My personal preference would be to go the other way: make the command line into a real Lua REPL, so you can eval and see the results of arbitrary expressions. With that feature, if "foo" is a name associated with a function value, typing "foo" would print a brief string representation of its function value. This would be useful for debugging: you can put a new built-in function call into the source to escape into the REPL at a breakpoint, evaluate expressions and such, then resume execution. Maybe this happens on a separate display area from the main game, with keyboard shortcuts to switch between them.
The current command line is trying to be more like an Apple II BASIC prompt, which shares a display with the game, offers command-based system interactions, and also evals statements (but not expressions). Novice devs might benefit more from two new panes in the dev interface: a filesystem GUI, and a REPL GUI. The biggest tradeoff would be not being able to type "rectfill(10,10,20,20,2)" and have the result appear on the same screen as the command. A Logo-style split screen as a feature of the REPL pane would be one possible solution.
I'm not sure how useful it is to terminate the game loop in the main use cases for Pico-8. The web player will display the REPL if execution falls off the bottom of a cart, but won't let you type into it, and I'm guessing that's by design and probably something we want to keep for the play-only distribution of carts. I know we've been talking about fun ways to build game-like interactions around the REPL, but I don't think that's going to be generally useful. :)
Yes, I can already write my own game loop using flip. In many cases, I have to. I don't want to have to.
Yes, I want to be able to make a Pico-8 text adventure that works by pushing argument-less functions to the global state and expects the user to run them simply by typing their name. In fact, I would gladly go further and make it so that strings which start with a function name, followed by a whitespace, followed by more alphanumerics (which are NOT magic symbols like = or += or () or whatever) would call the function with the rest of the string as a single argument.
Why? Because the only other option is turning the entire game into a clunky old RPG name input keyboard that you have to pad around with the arrow keys and Z/X to use. That's stupid and can't be the entire game, yet there's no other option. There is no "keyboard attachment" that can take the place of player 2's controls or anything like a real console. You could even do that on the NES because all of the inputs add up to 8 boolean values, which can be translated into a single byte for what key is being pressed. For the Pico-8 there is just no options.
Yes, I know you can't use the console / prompt / REPL / whatever in the web player. But I don't always make games for the web player. I'm a big dreamer, even here.
In that case, what you're really asking for is keyboard input for games, and built-ins for text input and string management. That's not unreasonable, depending on how we interpret the "console" concept. If Pico-8 is trying to capture an 8-bit feel by allowing development in situ ala Apple II, then you'd expect that everything available to the dev environment to be available to the game. But it's pretty clear from the design that the actual intent is to enable the development and distribution of NES-like games, and it just so happens that the dev environment shares many but not all of its features with the runtime environment.
Using the development environment as a runtime environment for a game is a neat hack, but it's working outside of the design, where we should expect some fringe. I don't think we should expect the design to change to make specific hacks easier. I'm all for pushing on the edges to find new potential directions, but it's worth acknowledging where the line is when we do.
Besides, don't you need mouse input for your graphics editor? ;)
[Please log in to post a comment]