For us it's seems so uninspring because what we are used to is now the old way of digital creation/execution. It's a big change many aren't thrilled with including myself which I should because I can now create all my crazy ideas on my own without hiring back-end or iPhone developers as previously have done for my startups. Yet, i am unspired by this new way even when I used Codex to create a few of my ideas already (soon i will be starting my new healthcare career after 17 years in research/design & web dev).

Planet Source Code was possibly the original github.

In these toolkits, as long as you're making the idiomatic kind of game they're designed to produce, then you don't end up needing to learn a single thing about programming. Your game can be expressed 100% within the higher-level abstraction, with no reference to things like "variables" or "states".

And in some ways, that's good! (RPG Maker 95 was a good entry point into game development for 11-year-old me, way back when, as I didn't know any programming at that point [and found myself bouncing off of tools like QBASIC that required it.] I found toolkits like these a great "gateway drug": one that let me try out simple ideas, that fed an addiction to thinking about game design, leading to my ambitions gradually growing, wanting to make gradually-more-complex experiences, and so running up against the limits of the tools, where the "escape hatch" of [visual] programming became very gradually required, leading to a very gentle and gradual exposure to those concepts.)

But of course, if this isn't just a kid doing a self-motivated dive into "game dev", but a parent trying to give their kid a view into "what makes a computer a special thing, different from other tools" [i.e. that it is an infinitely-extensible tool, one that can be programmed by the end user to do anything they want], then these game-dev toolkit apps are still just "apps" (they even show up on game consoles!) and so don't quite tap into the feeling of "having an idea for literally anything you might want the computer to do, and being able to make that happen" that actual programming does. The "magic" of these toolkits feels like it lives in the app, not in what you're doing with it. There's no sense, when employing these toolkits, that (as Abelson and Sussman might say) you're casting a spell upon reality with the computer as your wand.

---

But that being said, when I've seen a parent trying to instil that particular feeling into a child of theirs, they rarely do so by trying to put the kid into the critical path for "doing the actual programming."

Learning to program, and experiencing "getting a computer to do exactly what you want", are two very different things; and I think a lot of people hold the opinion that kids generally won't care about / have patience for the former, until after you get them hooked on the feeling of the latter. (Until then, "programming" is just weird algebra that can print text on the screen, i.e. something they likely won't see what's so exciting about.)

So the general approach I've seen, before LLMs, was essentially for the parent to play the role of a coding-agent LLM, at the same time that they're also playing the role of a guide/educator. The parent prompts the kid to specify what they want to happen on the screen; and the parent themselves then codes that up (ideally in as high-abstraction-level a language+framework for this as possible, and so requiring as little fiddly glue code as possible, so as to get the change done before the kid loses interest.)

The parent can certainly then point to the code on screen and explain how each line makes what happens, happen; but first they have to run the program. For the wonder comes only when the spell is cast: the runes on the screen disappear, and in their place comes the actual result, a particular experience pulled from the space of all possibility by that particular configuration of words and symbols.

In that framing, the only thing that changes from the kid's perspective, when the parent is using a coding-agent LLM, is that the parent can take what the kid is suggesting should happen, formalize it, punch it into a tool, and come back with the "right" runes to make it happen, very quickly.

A child doesn't care where the runes were sourced from. A child doesn't yet understand that there is an art and a craft to programming at all; that some code is more maintainable than others; that there exist any structural or stylistic choices to be made, beyond just "saying that which is required to cast that spell from among all spells." The closest analogy they'll be aware of in their everyday life is math, and math (at elementary-school level) is all about canonical forms. They'll assume that the coding-agent LLM, as a tool, is simply automating "getting the right answer" for the choice of runes, in a similar way to how a calculator automates "getting the right answer" for an arithmetic problem.

The awareness that source code is not just a language spoken to machines, but a language programmers speak to each-other and to themselves in the future, just isn't relevant to this kind of early lesson. It's not something they'd notice or think about, or understand if you tried to explain it to them.

The magic, at that early point in one's life, is that "mere text on a screen" can make things happen at all; can make the sorts of cool things happen that their imagination is full of; and is in fact responsible for making happen every cool thing (and all the boring things, too) they've ever seen a computer or other bit of consumer electronics do.

And also, that those symbols aren't simply a communication to some fancy toolkit app; that those symbols can be written in regular old Notepad if you like, and they'll still be just as potent, for it's the symbols themselves that have power. (This lesson being especially potent if you demonstrate with a scripting language built into the OS, e.g. Windows batch files, such that you can simply "Save As" the text file and then double-click it.)

For instance, I am wondering what exactly you are responding to with this comment, since the game described in the article is not really about teaching the kid to code with AI at all? I mean, what you wrote is interesting, but it isn't really topical

The blog post that I read mentions a single generative AI feature baked into the game that allows the player to create a single item once per day using a text prompt. But it is one single feature with limited uses. The blog post devotes very little ink towards describing it, and it is very clear that the goal of the project is not to use AI to teach coding, but more to provide a constrained, hackable sandbox environment with a deliberately impaired scripting language -- so, lots of "basic building blocks" as you say.

Was there something else in the post that I missed?

e.g. I started with Ruby on Rails. Not even Ruby. The feedback loop is what convinced me that I wanted to write software and then dive into the fundamentals.

It makes zero sense to start people off in an actually bad programming environment.

Try Snap! Instead of Scratch.

Further, I expect an even smaller subset of people who have played MUDs are aware of the 'distinct genealogical lineages' you describe. As someone who spent my teens browsing mudconnector and dabbling in lots of random MUDs listed there, I started hazily noticing patterns in structure, design, mechanics, and even networking to some extent, and suspecting that certain games existed within specific 'traditions' of MUD development or even used similar libraries or frameworks, but I didn't have the context or curiosity to dig deeper.

Like everything, this can be modeled as a funnel: of the relatively small number of people on planet Earth who know that MUDs exist, only a tiny fraction has even connected to one, an even tinier fraction of those spent meaningful time on one, and an even smaller number of these who have thought to contextualize and taxonomize what they were played

Anyway, I am curious what level of specificity would you find normal?

I played some MUDs that were quite solid; PaderMUD/Xyllomer in the late 1990s (peak count connection at about 60 different people in late 1998). GEAS (similar code base) was also quite ok-ish up to 2013, though admin made too many mistakes (Asralites, aka the warclergy, were pimp-nerfed via divine codex to disallow them from starting wars, the old 'who' was stolen by PO Allalltar and PO Okkita and many more mistakes). But community wise both had many great roleplayers and your description appears to be hugely one-sided in that you never found competent roleplayers that would narrate a storyline (or usually several, if you had enough players) at the same time. Often "drama" is just roleplay and reaction by characters to in-game situations. I am aware that some players sabotage(d) MUDs and cliques rose past 1998 or so; and many older players gave up due to lack of time and what not. So the genre struggled already past 1998 and maintaining MUDs was much harder. But things such as "grind down everyone" can only happen if the rules are broken and the code is broken really. I also highly doubt that players were the primary "until the rest of the community stopped playing" as a problem - perhaps it applies to the MUDs you frequented, but very clearly this was not the case for all MUDs, so I suspect you had a very limited set of exposure to MUDs. I mentioned two; you did not mention any MUD specifically. Can you mention which MUDs you played extensively for a while?

As for pattern collapsing MUDs, I actually agree; in particular those who held the monopoly over the game code, can really quickly ruin a game. This does not even happen deliberately all of the time; old admin stopped playing their own MUDs and after +30 years they no longer understand why some code changes ruined the MUD. It's a tragedy without a good fix, because they are old and lack time to play, so they slowly stop understanding the game they still make code changes to.