Teaching my kid to code with a modern MUD
tau.dev
tau.dev
I think this is an awesome project for them both. And it's totally understandable to use an LLM for the base project as it's a 'fun' thing from the read. it doesn't look like it's trying to compete with anything....
The kid can learn within an environment created by parent, so they can also collaborate on improving that environment, while the kid also has their own learning _within_ that environment.
This seems like a wonderfully geeky adventure to go on if ur kid enjoys it :D love it. hope it will spark some cool interactions between them and make some epic memories :)
Also, maybe people forget how it was like back in the day.
I am not _too_ old - pentium 1 was my first PC. I learned making games in PASCAL, QBASIC and later custom C implementations that came with like 'gamemaker ' CDs etc. this was all very complicated to learn at a young age... Had to get many books and things (no internet!) at the PC shop to try and get my head around it. Never quite did until much later in my life!
Sure things like Scratch exists, but this beauty of this one is that this one is _theirs_. Surely we can recognize the enjoyment that might bring to a parent and kids' lives? Learning is a bonus! Not everything is about being technically the best of the best -_- stop being Marines at everyhting. We're not at war with eachother over who writes the best code.
Good use of LLM technology to make a project in my mind. props!
As a start, why do you disagree and how would you further this discussion?
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).
This is not a genie you can put back in a bottle.
I can create things in a few months that would have taken years of work by a small team to do before, for less than the cost of buying pizza.
For me it’s as wonderful as good compilers. Today reminds me of when it was no longer necessary to hand code machine language, then it was assembly that winked out in favour of strong compilers. Those skills were all superseded by higher levels of abstraction, just like coding is giving way to system engineering.
Of course if you don’t keep ascending the abstraction ladder, or your vision doesn’t accommodate the requirements of the next rung up, I guess that must feel more like an end than a beginning.
One day, I suppose, there won’t be any more rungs to reach for and we will all be truly be obsolete. At that point, we will have achieved and suffered the goal of all life, to give birth to a generation that replaces us and makes us irrelevant, I suppose. That will be, I think, both a triumph and a tragedy. A disaster if we don’t make sure it isn’t, if we lose our humanity in the becoming.
But I think we aren’t quite there yet.
Give me 100:1 bets at 1000:1 odds all day, every day. For me, that’s stability. And for that plan, AI is a force multiplier.
I wish you well, and as jobs go, I am sure that health care must be more fulfilling than technical work, and probably a better use of human energy.
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.)
Planet Source Code was possibly the original github.
You'd be surprised what kids can make once you give them the basic building blocks: https://jump.academy/projects/fruit-drop
Sometimes we will let them use AI to make a focused change to their project, like "make the character do a flip when he jumps", then they're getting a fairly controlled diff surrounded by a ton of context, which I think really does boost their coding "literacy". I'd rather my students be able to read code well than write a for loop from memory, so I've found it useful in that sense.
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?
It's an ad for their website.
Hacking up a pre-existing MUD was the perfect mix of immediacy / interactivity and fun to hook me. So thankful to that guy, wherever he is. He probably changed the course of my life.
There's a lot of fun "lego-style" creativity to be had in designing rooms, mobs and coming up with grand area designs.
Cool idea.
Curious if that’s coincidence or if players of UO brought that over most likely from MUDs.
The couple MUD communities I participated in eventually collapsed under drama explosions from terminally online people. Some really manipulative and cruel stuff from people who would present themselves as noble community leaders, work themselves into positions of power, then grind down everyone in the out group until the rest of the community stopped playing.
I would log in to a couple of them once a year. It was the same small ingroup of people idling away. All the recent posts on the in-game message board were from the new people complaining, admonishing, or introducing more rules to tighten their grip on anyone who remained. Really sad to see the same pattern collapse multiple different communities in the same way.
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.
Limited set, yes. I was never a hardcore player. I would drop in for some months, then disappear again for months as I had other things going on in my life.
Quickly, no. Some of the MUDs are still running today (as I mentioned) but my in and out nature made the dramatic changes more obvious. I would spend the summer away doing something, and come back to discover someone new had worked their way into the admin staff and was stirring the pot at every opportunity. One time I came back and the MUD was taken offline because the staff was infighting so much about it.
> 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
I'm not pretending my experience was common to all MUDs because I didn't play a large number. However the ones I did play eventually succumbed to admin and staff drama.
Your assumption is backwards: It wasn't the people breaking rules who were causing problems. It was the people who were making rules. Some of them came up with increasingly specific things that were decided to be against an ever longer list of rules, which became the weapon which they could wield against anyone they didn't like. Temporary bans and restrictions were handed out selectively to their political adversaries.
The people who have the most time and energy to give for moderation, are the same ones most in love with the control for it’s own sake.
The few remaining forums I frequent have survived because they have no tolerance for admins who push their own agendas. They've all erred on the side of minimal rules and bans only in extreme cases. Every forum I've been on that went all-in on rules and heavy moderation has collapsed, or at least driven away the core users and left roaming packs of ingroup people who care more about picking apart everyone else than being part of the community. It's weird how many different places I've watched this happen online.
Since the advent of MUD gaming, there has been a wide variety of codebases, servers, and clients, with distinct genealogical lineages, that appeal to quite distinct sectors of nerd-dom, and sometimes with very little overlap in the player base.
The original big-3 "non-Tiny" MUDs were: AberMUD, DikuMUD, and LPMud. These were largely unknown to me as I never played any of them, but they were mostly known as combat-based, player-programmable, and even quite distinctly European, for the most part. I could be wrong.
TinyMUD Classic began at CMU with Jim Aspnes, but quicky a lot of forks developed that resulted in MUCK, MUSH, MOO, FuzzBall and other interesting derivatives. The Tiny* class shared a lot of playerbase, because the appeal was mostly the same; all were user-extensible but only some were programmable; none were combat-based or adversarial. They mostly tended to evolve into social and chat functions, once they were established and built-up.
There are plenty of other MUD types and in the 90s, every budding programmer had ideas and forked a codebase for their own purposes. But it still baffles me, when commenters here and there wax nostalgic about those MUD days, I really have no idea what sort of game they're referring to, if they cannot be more specific.
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?
What GP is referring to and complaining is that when people say MUD, they're probably referring to either:
- A MUD based on some derivative of the TinyMUD codebase, colloquially called "MUs"
- Literally any other "MUD"
These two categories of "games" are both legitimately called "MUDs" but also have almost nothing in common with each other. The union of "MU" players and "MUD" players is not that large, in my experience. MU servers tend to function somewhere between glorified Discord servers and sandbox programming environments.
Even more specifically, within the MU* space, the different forks of TinyMUD ended up adopting different subcultures, programming languages, and general vibes. Despite all being superficially similar, telling someone you play a:
- MUSH
- MUCK
- MOO
says a great deal about both you and server. MUCKs are furry subculture for the most part and use Forth for programming, while MUSHes are ... more Star Trek/Lord of the Rings coded. With other weird differences: MUSHes tend to have elaborate mail and Discord-like comm systems built in, MUCKs tend to eschew those in favor of "hanging out in the same virtual room".
IME there isn't this same feeling in "other MUDs". You don't "identify" DikuMUD or LPMUD players in the same way, so I don't think the question makes sense to anyone who isn't a MU* player.
The difference here is almost entirely cultural, since technologically, LPMUDs and MUSH/MOO/MUCKs aren't that dissimilar. But LPMUDs are almost never used the same way, at least I've never seen it.
I don’t want my 7yo to have a phone or iPad, so he’s not been able to use the PoweredUp hubs unless I’m there and can lend him my phone :(
But he has a nixos laptop, and after flashing the hubs he can now program Lego technic with Scratch, no iPad or phone needed :)
Then I've created an engine in it to create very similar text-based adventure games like this one. I've also used a similar low-level language to describe the game logic. Later I've ported the engine into a native app (Win, Linux, WASM) with more features, like point'n'click interface (the bytecode remained backward compatible, it can play games created with the fantasy console).
https://gitlab.com/bztsrc/meg4_advgame
As a demonstration, I've ported a classic C= 64 game, you can try it out here (runs in the browser too). This game was a pretty big deal in my country in the '80s, and its creator was legendary.
https://bztsrc.gitlab.io/meg4_advgame/idoregesz.html
The description of the language, the bytecode, and the engine et al can be found here https://bztsrc.gitlab.io/meg4_advgame/ for those who are interested. The C= 64 game's source also available in the repo.
Full disclosure: my solution is 100% AI-free.
https://breaka.club/blog/why-were-building-clubs-for-kids
The primary mechanism through which kids create their game worlds is taking photos of their own hand drawn artwork.
I found traditional game dev tooling was far too technical and verbose for my daughter to stay interested. Honestly, it's not just a matter of her losing interest due to the complexity. Frankly, I don't want her sitting in front of a screen that long. She's a kid and I want her doing typical kid stuff. She and her younger sisters play sports, draw, paint, perform magic shows, and sing and dance around the house like complete nutbags — and I love it!
So whilst what I've built is highly technical for me to maintain, I'm not trying to expose all that complexity to kids. At least, not yet. I'm mostly interested in fueling creativity and letting kids explore. That's not to say kids that want to dive deep can't — we offer visual coding experiences etc. The intent is kids gain access to new features through self directed exploration and play. If some kids stop at just play, that's OK. The primary game mechanics (drawing and building worlds) are still inherently creative.
Although my approach is different, there is a heap in this article I resonant with. The hacking mentality, and letting kids go beyond the artificial constraints in particular. There's still much of Breaka Club that I can improve on. I'm running a limited in-school pilot at present and that's already yielded some really interesting insights. I'm really keen to continue to see what others put out in this space. I think it's drastically underserved and there's plenty of room for multiple approaches.
Now I'm teaching my son how to read on the same server.
I am not happy with the 'kids learn 2 code' space.. which is usually just a bunch of pseudo code move commands to make a character traverse a maze. I think the learning ceiling on this kind of setup is low.
but this seems like something much better. I have myself been doing more ai-powered coding / learning projects with my kids. a ton of potential in this space.
Also, that ASCII art(or pixel art?) as the header looks serene. Any tips/rabbit holes on achieving that art style?
Edit: To clarify, the languages I created were also half-assed - it's very difficult to create a good one.
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.
Also, it'd be far too low level in comparison to what the guy did - ultimately, this is a game engine. Proper comparison would maybe be against Inform 7.
Hopefully he doesn't come to regret it either.