The closest thing I've found to this is Pico-8: not a computer, a piece of software, but it's very cool. It has a simple text editor for writing Lua code, a simple sprite editor, and a simple sound editor, all for creating games. It's a nice little sandbox for playing with code and creating things.
I upvoted this but I need to reiterate my support.
When I was a kid, I was heavily into video games and had a burning desire to create my own. However, the options for doing so were not great. One of my middle school teachers tried to introduce us to programming via creating Space Invaders in perl, which went as well as you might imagine. There were a few GUI game making applications that were all terrible and extremely limited. I eventually managed to make a game using Flash, but all the overhead of arcane Actionscript APIs was overwhelming and discouraging. I stopped programming and for several years thought I was going to go into media, creating films and animation. I eventually picked up programming again in college, but there were many years of programming experience I could have had if I had stuck with game dev.
I'm convinced that if PICO-8 existed when I was originally interested in making games, I never would have stopped programming. PICO-8 is the perfect balance of easy-to-learn and powerful. Lua is a good first language because it's so small, and encourages you to build your own solutions rather than rely on magical libraries. For example, I never knew how a list-shuffling algorithm (Fisher-Yates) worked until I needed to write my own because Lua and PICO-8 don't provide one.
The limited sprite and sound options encourage you to spend time not on the assets but on the gameplay (the code). It's quick to get things on screen and working because the PICO-8 API is simple, logical, and not arcane (cough Actionscript cough).
Basically, it introduces programming in an instant-gratification way that's able to grab and hold a child's attention, while still being powerful enough to produce games that aren't hamstrung by toy programming languages.
You think you had it rough, at 15 I taught myself C/C++ Win32 programming with COM and early DirectX versions from textbooks and online tutorials. I'm thankful now though, as most modern frameworks are a breeze to learn by comparison. Looking back it was a bit like learning to swim by jumping in the deep end of the pool. It certainly gave me the confidence that I can figure stuff out, even in a new domain. And it's given me some valuable lessons in what makes a good vs bad API design.
Mine was Pascal in Turbo Pascal (6?) for DOS, circa 2004. It speaks volumes to the outstanding quality of Turbo Pascal and the Pascal language that it still holds up, more than 20 years later.
I started with AppleSoft basic around 10 years old. It was fairly simple to achieve "stuff". But if your dream was videogames (and when you're 10 years old, well, you see :-)), then you ended up in front of the assembler/machine code wall. And there your dreams vanished (or you were crazy enough to learn by yourself and books).
So I think Pico8 or Scratch are cool in the sense that they give you an environment to start programming. But OTOH, if what you look after is AAA games, then you'll soon be confronted to a brand new wall, ie : DirectX, GPU, C++ whatever. Now I rememeber of Processing which is cool too.
I started with Cosmac ELF 1802 with 256 bytes of memory 128x64 graphics. I would have thought I'd died and gone to heaven if I had something that ran pico-8.
I have a Pocket CHIP. It’s really cool. Comes preloaded with PICO-8, some other software (a synth, etc.), and a dead simple graphical launcher. But under the hood it’s running full on Linux. I got the Swift compiler installed and running on mine, for example.
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.
+1 for Pico-8. It really takes you down the rabbit's hole in a way that stimulates learning all the core concepts in creating a basic game. "Cool, I have a sprite on the screen. Now, how do I make it move?". "What about gravity?". "What about collision detection?" (I've done at least 5 collision detection "engines" so far...).
Games can be compiled to HTML5, ando/or distributed as PNG files with all source code and assets included. There's also a builtin community game browser with ratings, etc. Some bigger name games were prototyped in Pico-8 (i.e., Celeste), and it has a lot of love in the indie community.
a) The code editing story was a bit nicer (better resolution / builtin support for external editing and reloading etc)
b) If there was some kid-specific introductory game programming content for it (even "type all this in and play around with it after" worked for me as a kid)
Tic-80 is slightly higher resolution than Pico-8, with a user-definable palette and a more standard lua implementation. The music editor is slightly less intuitive, though.
Pixel Vision 8 is more flexible and complex than the other alternatives. One KEY difference between it and the others is that you can define your own editor tools... but the way this is done means that you must save your work every time you switch from tool A to tool B, or your work in tool A will be lost! It also is built with a focus on interoperability with external tools; it isn't as focused as the others on being a cozy self-contained environment.
I love pico 8, but I think that Lua is probably the worst language for coding in an editor that can fit so few characters on the screen, and it feels like using an external editor defeats the point. Granted, I haven't used the software in a couple of years, has it improved on the editor front?
I'm surprised you feel that way. Lua seems like a perfect choice for pico-8. Its syntax is friendly and concise, and it's maybe simplest language to embed, with tiny footprint. Almost all other languages I know of would be a worse choice. Scratch would be nice, but graphical editor is harder to integrate. What's more suitable language in your opinion?
Well it's only because of the issue with the built-in editor, since lua isn't really that concise in terms of character count imo. Also the official tutorial is a published book which I find a little distasteful although understandable. You are right though I can't really think of a better language to use
You can attach an external editor if you want, though I think it is not needed for learning. There is more value in the tight integration than the conveniences of a great text editor.
I've used this Sublime Text Package which works well:
The great thing about Lua is the language itself is so small, and not just from an implementation perspective. The spec and documentation are also small because there's not much to learn.
You can explain it in an afternoon. Try that with C++ or JavaScript.
It's also fast and it can be made to run in deterministic time. Plus the C API is something I can actually read and understand, which is true of none of the other scripting languages I've used(Python, Perl, et. al.).
I started to program in Lua with the LÖVE game engine in early high school, and can say it's one of the main reasons I was motivated to study CS in college.
It's a simple, 2D, open-source game engine that runs on all platforms — I'd recommend this and other sandbox-style environments to anyone getting into programming.
The first version of Celeste was done in Pico-8 at a games hackathon, and the success caused the author to develop an expanded version, which in my opinion is one of the greatest platformers ever.
The pico-8 version exists as a game within the game and is great fun as well!
https://www.lexaloffle.com/pico-8.php