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.
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.