Pico-8 was my son's very first introduction to programming. He does much more with the integrated sprite editor and sfx/music editors than he does with actual coding. I would like to get him interested in TIC-80 as a replacement.
Key weaknesses of Pico-8 for kids learning to program:
1. The editor runs at the same resolution that the games do. Maybe this is because they didn't want to make their VM flexible enough to deal with multiple resolutions, or they just wanted to make the illusion that the Pico-8 is its own machine very consistent, but the end result is still a painful code editing experience. When I make example programs for my kids, I need to compromise between descriptive variable names and indenting code blocks.
2. Deviations from the standard lua API/libraries mean that normal learning resources like PIL have to be interpreted with an asterisk.
3. This is a minor thing, but the fixed palette is annoying. In graphical terms, Pico-8 lies roughly between the Atari 2600, 7800, and NES, but all of those systems handled colors more flexibly.
4. Splore allows children to find games that are not appropriate for their age. It's just not designed for kids and parents. My son found a game featuring smoking and thought it looked SO COOL (this was easy to disabuse him of). He also found a game that puts you in the role of a cyberbully, and the subtle psychological effects of that sort of "edgy" game aren't as easily undone with a single conversation. It is possible to mitigate this by putting whitelisted carts into the bbs carts folder and then making that folder read-only.
TIC-80 improves on the first three points. The editor is still running at the same resolution as the games, but uses a higher resolution (and the editor can optionally use a thinner font). The lua implementation is much more standard. And the palette can be changed (even per-scanline, I think). The music editor lets you draw your own waveforms, but in other respects is less intuitive than Pico-8's. (I haven't looked at TIC-80's cart browser so I can't comment on it.)
All of these are explicit design choices, for example a fixed palette is important to give games a "Pico-8" look and also reduce decisions regarding color choice. I suggest you watch Joseph White's practice talk (https://www.youtube.com/watch?v=87jfTIWosBw) if you're curious about design decisions that guided Pico-8.
Multiple resolutions would absolutely break the "Fantasy console" feel of Pico-8, even though I understand why programmers universally hate that. To be fair a lot of people do code editing outside of the Pico-8 editor.
#4 is an interesting point. The trick here is that different parents have different ideas of what is and isn't appropriate, and of course different kids will have different responses. It seems like the answer is to maybe have a version of Pico-8 that removes splore and expands the demo carts with some universally safe, popular titles.
TIC-80 is cool btw and might be a better learning environment for kids. I don't like it (or any of the other fantasy console\pico-8 clones) quite as much as Pico-8 because they remove constraints, making them feel more like generic game editors and less like imaginary retro computers.
>All of these are explicit design choices, for example a fixed palette is important to give games a "Pico-8" look and also reduce decisions regarding color choice.
Indeed, which is why they won't change, which is why (for me) an alternative like TIC-80 is preferable to waiting around for Pico-8 to become what I wish it were.
The virtual console space is tantalizing, but the culture around it has different tastes from mine. For example,
>I don't like it (or any of the other fantasy console\pico-8 clones) quite as much as Pico-8 because they remove constraints
This is a pretty common sentiment on the Pico-8 boards; I understand there are people looking for a certain aesthetic thrill that comes from working within the constraints to make something unexpectedly cool. And yes, when I have time, I would like to make e.g. a metroidvania that uses individual tiles to encode 4x4 chunks of tiles to allow for a big-ass map. It just so happens that those constraints aren't necessary for, and sometimes are in tension with, the goals of a good first-coding-experience learning environment.
I also totally understand why virtual consoles almost all use BASIC or lua, but (for me, not for my kids) I wish there were an option with static types. The combination of not being able to see much code on the screen at once plus no static type checking is pretty uncomfortable for me.
> I also totally understand why virtual consoles almost all use BASIC or lua, but (for me, not for my kids) I wish there were an option with static types. The combination of not being able to see much code on the screen at once plus no static type checking is pretty uncomfortable for me
At some point the question becomes why not just use Unity, BFXR, Bosca Ceoil and ASE Sprite if you want no constraints and better tools with a similar Pico-8-ish aesthetic? That question is outside of the scope of the original post, but as I piece together your ideal fantasy console, it seems like not really a fantasy console but a simple general purpose game IDE with a statically typed language.
Edit: Btw, if what you want is a simple general purpose game IDE with a statically typed language that is somewhere in-between Unity and Pico-8 I suggest you make it or at least spec out your needs more formally! I'm definitely a fan of more people making game creation tools (and software development tools in general) that fit their needs\use cases.
The all-in-one nature of most fantasy consoles is really appealing. They are also not terribly opinionated, which can be nice. When I tried Unity its 2d story was not good and I kind of struggled with its opinions. I've heard that its 2d has improved, but haven't had the time to explore it since.
I actually do like reasonably low resolutions in-game rather than in the code editor. When I play with my kids I want it to feel like good graphics aren't too far out of reach, and low-res makes it easier to get to something in the range of acceptable. My own kids appreciate their own pixel art more than anything they do in Scratch, for example.
I also think I might be slightly younger than most fantasy console fans, maybe? When I was very young I had an Apple IIc, which was good for booting straight to BASIC, but most of my childhood programming occurred in the era that spanned from CGA cards to VGA, and then I left programming for a while when 3d acceleration became a thing. One quirk of this era was that tradeoffs between color depth and resolution were just a normal thing. So for me, it would be a natural thing for a retro game dev environment that simulated a fixed framebuffer size to support, say, a 256x192 256 color mode and a 512x384 4 color mode. An editor in that higher-resolution, low-color mode would be way more comfortable than in low-res. (Pico-8 does have an alternate resolution, but it's 64x64 and still 16 color- somewhat evocative of the old 40x40 mode that Apples had).
TIC-80 does almost, um, tic all my boxes. I mostly just want a higher-resolution code editing mode (for both me and my kids) and a static language (for me; my kids don't really have a notion of types (yet)). So obviously the solution is to fork TIC-80 and see what I can make it do...
My ideal pallete would consist of all the C64s colors and all the ZX Spectrums colors combined. A few of them would overlap, and the resulting pallete would be restrictive but pixel artists could work magic between both the familiar old hues.
My ideal machine would be a C64 and Spectrum combined, 4 commodore sound chips, screen resolution increased only about 50%, 256kB ram, possibility of running 6502 and z80 in parallel, at quadruple speed.
Could be just nostalgia, but the continuing demo scene for these computers is incredible[a] and beautiful new games also get made to the old frugal specifications.
Key weaknesses of Pico-8 for kids learning to program:
1. The editor runs at the same resolution that the games do. Maybe this is because they didn't want to make their VM flexible enough to deal with multiple resolutions, or they just wanted to make the illusion that the Pico-8 is its own machine very consistent, but the end result is still a painful code editing experience. When I make example programs for my kids, I need to compromise between descriptive variable names and indenting code blocks.
2. Deviations from the standard lua API/libraries mean that normal learning resources like PIL have to be interpreted with an asterisk.
3. This is a minor thing, but the fixed palette is annoying. In graphical terms, Pico-8 lies roughly between the Atari 2600, 7800, and NES, but all of those systems handled colors more flexibly.
4. Splore allows children to find games that are not appropriate for their age. It's just not designed for kids and parents. My son found a game featuring smoking and thought it looked SO COOL (this was easy to disabuse him of). He also found a game that puts you in the role of a cyberbully, and the subtle psychological effects of that sort of "edgy" game aren't as easily undone with a single conversation. It is possible to mitigate this by putting whitelisted carts into the bbs carts folder and then making that folder read-only.
TIC-80 improves on the first three points. The editor is still running at the same resolution as the games, but uses a higher resolution (and the editor can optionally use a thinner font). The lua implementation is much more standard. And the palette can be changed (even per-scanline, I think). The music editor lets you draw your own waveforms, but in other respects is less intuitive than Pico-8's. (I haven't looked at TIC-80's cart browser so I can't comment on it.)