What is out there? Hard and soft codebases of choice.

Thenomain

@faraday said in What is out there? Hard and soft codebases of choice.:

@Thenomain I'm curious how you define "immediate feedback tools". Is changing code in a text editor in the server shell and typing @reload in the game not immediate?

I've had to think about this a bit, and here's what I think.

You can't do the old trick of testing your code in development in that bizarre but delightful way Mushes allow you to localize code. If you make a change, it's to the server. (New tactic: Lock the code until it's tested.)
You have to have server access to test code. You can't test concepts on someone else's server ("how does Penn do this, again?"), and you can't do it without your own complete server installation.

The problem with my communications here is that I'm talking in what sounds like absolutes, but is a matter of degrees. I don't have the language to explain what I'm thinking of, only examples. As you and @Griatch are taking those examples as specific issues and/or complaints, cross-purposes are being attained.

Let me give one more example.

Yes, I have to install the entirety of Python to play around with it (let's ignore online tools for a moment), but I can get into a limited development shell to, well, I could create a whole Python program in it, but it's not designed for that. It's designed to "play".

This is not about toys, this is about exploration, about learning, and about accessibility.

This is the specific part I was talking about earlier that I think needs help to make Evennia more accessible. (does not say to run vitualenv first, nor how)

This is my idea about what "accessibility" is about.

But for actual game devs [...]

What is an "Actual Game Dev"? A Cobalt who wants to build a quick, loose game about supernatural life in Forks, Washington and knows how to build but little else? Castle D'Image, which had no code systems to speak of? I know you don't mean this term negatively, and don't even imagine you would use it that way if you did, but this is a limiting statement. "Evennia and Ares are only for Actual Game Devs."

I do feel bad about stating it that way, but couldn't think of another way to get across that point. My inner editor is a jerk.

Ashen-Shugar

@Hexagon said in What is out there? Hard and soft codebases of choice.:

@Ashen-Shugar said in What is out there? Hard and soft codebases of choice.:

One big thing we do have with Rhost is we have a built in execscript. This is a built in function that allows you to interactively execute external script/binaries/other as a local built-in function and be able to scrape the results off it.

This sounds amazing. How fluid is it between in and out of game? Would it be possible to have it interact with a chatbot in a meaningful way, then? That was something I was always interested in. I mean, you can sort of do it already by having a bot connect to a bit flagged ROBOT I guess.

It's limited in that it doesn't allow interactive integration. Think of it like an API call.

You run an external app, it does its thing, and returns its results.

It's not able to wait for input or anything like that.

We do, however have interactive @doors that do allow you to do full interactive mode. There's still some limitations with it as it's a line mode TCP connection and not a character mode, so ncurses or similar is not possible.

But it does allow fun features like being able to connect from inside one mush to another, or playing unix empire or other line based TCP systems.

Thenomain

@Hexagon said in What is out there? Hard and soft codebases of choice.:

@Thenomain said in What is out there? Hard and soft codebases of choice.:

However, for that bridge, Mushcode is far more capable than Evennia, at present. A huge reason is because Mush has immediate feedback tools.
The documentation available for Mush is also, although ancient, creating and building on foundations. The documentation I've seen for Evennia is instructive but my small peeve that "how to start an existing game" was missing is exactly the kind of thing that frustrates me about it.

It's also been around a lot longer. You do amazing and complex things, but even having access to your Github repository still means a fair bit of sanitizing and testing before things are up and running. I do love the way you format the code, though. It's much easier to read conceptually.

Yeah, my Github is NOT drag-n-drop ready. My WoD sections, however, are pretty damn close, starting with deep explanations about how and how not to. The weather system install (linked in my post, above) is me trying to get better.

The weather system directions came after helping someone with absolutely no Unix experience set it up. This level of coding really forces you to think about your users.

Mush is almost that level of "plug and play", but I do want to note: It's always been that way. Lydia and Brazil and all the rest have focused on that since very early on. It is the exact opposite of Muds, which demand that you be a C/C++ coder to make any changes.

faraday

@Thenomain by actual game dev I meant simply someone with permission to be a coder on a game (in Ares this means access to either the server shell or git repository to push changes). This is in contrast with old Mu* servers where every player can do some level of development. It's a question of access not skill or elitism.

Thenomain

@faraday said in What is out there? Hard and soft codebases of choice.:

@Thenomain by actual game dev I meant simply someone with permission to be a coder on a game (in Ares this means access to either the server shell or git repository to push changes). This is in contrast with old Mu* servers where every player can do some level of development. It's a question of access not skill or elitism.

Okay, so if a "game dev" is anyone who can run code...no, that still doesn't make sense. I can log into a Penn game, run some code, and therefore make my own code more portable. I don't have permission to do so, and I'm not a game developer.

Again, I think we're not talking about the same thing.

faraday

@Thenomain said in What is out there? Hard and soft codebases of choice.:

Okay, so if a "game dev" is anyone who can run code...no, that still doesn't make sense. I can log into a Penn game, run some code, and therefore make my own code more portable. I don't have permission to do so, and I'm not a game developer.

Again, I think we're not talking about the same thing.

Yes, on Penn/Tiny, anyone can run code, but the overwhelming majority of people just don't. There are a handful of folks who insist on having their own +ansi or +this or +that code, but they are the exception rather than the rule.

"Game devs" are the people making the code for the game that everyone else uses. On old-MU servers, they're the ones putting globals into master rooms.

If you have a better term that avoids potential confusion, I'm happy to adopt it.

(Eta: And while we're at it, I'd love a better term than old-MU for Penn/Tiny/Rhost, because old sounds unintentionally derogatory. Softcode-based? First-gen? Anyway.)

surreality

I think -- and I could be entirely wrong -- what @Thenomain is trying to say is that once you install the MUX server, you essentially type one startup command and you have what you need to begin creating a play space on the creative front.

You have the four types of objects in place -- Player, Room, Exit, and Thing -- as well as basic communication commands.

Technically speaking, if your goal was to create a very basic, statless game, you already have more or less everything you need in place to start creating your grid/playspace by just adding and describing rooms, which is as simple as:

@dig RoomName=ExitToRoom;Alias;Alias,ExitFromNewRoomBackToThisRoom;Alias;Alias
@desc here=Here is a description of my new room!
(repeat as needed)

Most people are not going to want something that simple, but it actually is that simple if that's all you need.

Edit: And I am like... a page and a half late. Oops.

Thenomain

@faraday

I've been using: Mushes, Mushlikes, Mushcode. The last was more popular long ago.

Also, long ago about half the mushers coded. Code was simpler, and the requirements to entry were lower.

faraday

@Thenomain said in What is out there? Hard and soft codebases of choice.:

@faraday

I've been using: Mushes, Mushlikes, Mushcode. The last was more popular long ago.

Also, long ago about half the mushers coded. Code was simpler, and the requirements to entry were lower.

Ares is a MUSH though. I chose that term deliberately because from a player's perspective (and by that I mean one who is playing the game and neither coding nor creating it) it's virtually identical to PennMUSH. I've had players on the Ares alpha/beta games that didn't realize they were playing on a completely different server. They thought it was the stock Penn-FS3 setup with a few tweaks. (Which is exactly what I want, btw, to ease the transition.)

Anyway, yeah - long ago coding was more common. But I'm not trying to get back to the MU*s of yesteryear where everyone was making Falcon Controllers. I'm addressing the use cases of the types of games I see and play on, where you've got (if you're lucky) one coder or an admin determined to learn enough to limp along.

Thenomain

@faraday said in What is out there? Hard and soft codebases of choice.:

Anyway, yeah - long ago coding was more common. But I'm not trying to get back to the MU*s of yesteryear where everyone was making Falcon Controllers. I'm addressing the use cases of the types of games I see and play on, where you've got (if you're lucky) one coder or an admin determined to learn enough to limp along.

So Ares' goal is different than Evennia's. I imagine that Ares will also present the more typical simplified installation requirements of Mushes.

We could call Ares something different. How about ... hmm ... a MULORG? MERINGUE? MIP? MUM, Multi-User Mush?

Ashen-Shugar

@Thenomain said in What is out there? Hard and soft codebases of choice.:

We could call Ares something different. How about ... hmm ... a MULORG? MERINGUE? MIP? MUM, Multi-User Mush?

MULLED.

Multi User Low Level Environment Director

Then his plugins can be names of alcohol. Wine, Beer, Scotch, Whisky....

WTFE

@faraday said in What is out there? Hard and soft codebases of choice.:

@Thenomain I'm curious how you define "immediate feedback tools". Is changing code in a text editor in the server shell and typing @reload in the game not immediate?

I grant that neither Evennia nor Ares can compete with the old MU servers in allowing any old player to fiddle with the code. But for actual game devs, I don't quite see the distinction that you seem to be alluding to.

Every step between "typing code" and "seeing the results of the typed code" is a barrier. This is why, for example, I will always prefer programming embedded systems in Forth over C (or, better, Modula-2). Here's my programming work cycle in Forth:

Come up with a crazy idea.
Type in the code for that crazy idea.
Run the code and watch it crash and burn.
Repeat until this doesn't crash and burn.

Here's my programming work cycle in C (or Modula-2):

Come up with a crazy idea.
Type in the code for that crazy idea.
Compile that code (and correct the inevitable whining from the compiler over trivial shit).
Link that code.
Flash that code onto the MCU.
Fire up the debugger.
Run the code and watch it crash and burn.
Repeat until this doesn't crash and burn.

(I'm being a bit facetious with the descriptions, but the general process is sound.)

What this means is that from the point of conception to the point of inception there is a very little gap (typing the code) when I program in Forth whereas when I use a language like C (or Modula-2) there's a quite larger gap. The immediacy of the Forth approach gets me to functioning and tested code far more quickly by keeping my thoughts on the problem domain (instead of the plumbing) for longer.

In the end I may finally implement the program's final version in a compiled language, but nothing beats a hosted interpreted language (or a language whose compile/link/load cycle is so fast it emulates one) for raw exploration of concept space.

This is MUSHcode's single strength.

As I've gone on at length in other places (including several variants of WORA), MUSHcode is a fucking blight of a programming language. It not only fosters bad programming habits, it demands them. It actively resists any attempt to do the right thing.

Yet, I would far rather try setting up a MUSH server--despite hating the technology it's based on!--over setting up a game on Evennia. Why? Because the barrier between conceiving of something and seeing it work is far, far, far smaller.

Firing up a text editor, editing code there, then switching to your game and typing @reload isn't as onerous a task as the horrible, horrible, horrible steps I take to get my C code working on an MCU, but it's a far cry from "the point of entry is the point of output" that fosters the best exploratory work. You're still switching out of your concept space and worrying about the plumbing. When you factor into that the API I linked to earlier with its myriad of StateManagerFactoryManagerStateManager types and other crud from shitty OOP methodology you have something that divorces you so far from the actual game design that it's actually kind of comical to see.

(And that's not even mentioning the horror that is its installation procedure. Or its obnoxious resource requirements. Or ...)

The Evennia project looks like a very well-constructed project that ... solves exactly the wrong problem, IMO. I wish it well, but I don't really expect it to do well in the long term.

Griatch

@Thenomain

People like you and I can do some amazingly complex things in Mushcode, but it takes a level of effort that oustrips Mushcode's standard use case.

This is a very important point. For all the "bridging power" of mushcode, how many can actually use it to the level of, you know, creating a new game from scratch? I am not familiar enough with the MUSH community to know this number, but I suspect that it's not a large number.

(Note that I'm not talking about plugging in a pre-made system here. That is obviously a great boon of the mushcode ecosystem but has less to do with its inherent "bridging power" and more to do with a backlog of decades of people using it for a very specific set of game styles. For Evennia (or Ares) to catch up with that aspect comes down to adoption and time.)

You can't do the old trick of testing your code in development in that bizarre but delightful way Mushes allow you to localize code. If you make a change, it's to the server. (New tactic: Lock the code until it's tested.)

This is what version control is for, but no, it doesn't work in the same way as mushcode.

You have to have server access to test code. You can't test concepts on someone else's server ("how does Penn do this, again?"), and you can't do it without your own complete server installation.

That sounds like a correct observation.

The problem with my communications here is that I'm talking in what sounds like absolutes, but is a matter of degrees. I don't have the language to explain what I'm thinking of, only examples. As you and @Griatch are taking those examples as specific issues and/or complaints, cross-purposes are being attained.

Let me give one more example.

Yes, I have to install the entirety of Python to play around with it (let's ignore online tools for a moment), but I can get into a limited development shell to, well, I could create a whole Python program in it, but it's not designed for that. It's designed to "play".

Are you here comparing "playing" in the raw Python shell to "playing" with code in Evennia? The latter you do (and people commonly do) with the @py command, which allows you to modify the running game in raw Python from in-game. But no, it's indeed not as easy as a full python input line. It's a lot more convenient to just test out Python snippets in the real python interpreter shell (in a separate window).

This is the specific part I was talking about earlier that I think needs help to make Evennia more accessible. (does not say to run vitualenv first, nor how)

Thankyou, that is good and useful feedback. The page was updated to make this clearer, check it out.

Actual Game Dev

This (to me) is a person willing/interested in creating a text-based MMO. In the hobby-world of MU* it generally also means running and maintaining said game. This is accomplished using whichever tools they choose. If they also play the game is irrelevant to the definition. If you are using the build tools (however they may look) in an official capacity to expand and improve the game, you are also a game dev.

If you are a regular player that are using the build tools to expand the game world/game experience on your own volition you are not a game dev IMO - you are then a content creator or maybe a modder. Which can be super-important and something an individual game may really want to support by adding resources to make such activities easier.

@surreality

I think -- and I could be entirely wrong -- what @Thenomain is trying to say is that once you install the MUX server, you essentially type one startup command and you have what you need to begin creating a play space on the creative front.

You have the four types of objects in place -- Player, Room, Exit, and Thing -- as well as basic communication commands.

Technically speaking, if your goal was to create a very basic, statless game, you already have more or less everything you need in place to start creating your grid/playspace by just adding and describing rooms, which is as simple as: [...]

This particular example is not making MUSH/MUX any different from any other codebase out there. Even the command examples you give work the same out of the box in Evennia.

@WTFE

Given that the process in Evennia is, as you yourself admit,

Come up with a crazy idea.
Type in the code for that crazy idea in your code editor.
Switch to game and run @reload to watch it crash and burn.
Repeat until this doesn't crash and burn.

Yet, I would far rather try setting up a MUSH server--despite hating the technology it's based on!--over setting up a game on Evennia. Why? Because the barrier between conceiving of something and seeing it work is far, far, far smaller.

Firing up a text editor, editing code there, then switching to your game and typing @reload isn't as onerous a task as the horrible, horrible, horrible steps I take to get my C code working on an MCU, but it's a far cry from "the point of entry is the point of output" that fosters the best exploratory work. You're still switching out of your concept space and worrying about the plumbing. When you factor into that the API I linked to earlier with its myriad of StateManagerFactoryManagerStateManager types and other crud from shitty OOP methodology you have something that divorces you so far from the actual game design that it's actually kind of comical to see.

A proper Python text editor will make all of Evennia's API directly available to as you type, with inline documentation, auto-completion and direct syntax checking and testing. It's quite clear your dislike for OOP is the main beef here. Fair enough - if you prefer Mushcode over Evennia's solution that's your call.

surreality

@Griatch said in What is out there? Hard and soft codebases of choice.:

@surreality

I think -- and I could be entirely wrong -- what @Thenomain is trying to say is that once you install the MUX server, you essentially type one startup command and you have what you need to begin creating a play space on the creative front.

You have the four types of objects in place -- Player, Room, Exit, and Thing -- as well as basic communication commands.

Technically speaking, if your goal was to create a very basic, statless game, you already have more or less everything you need in place to start creating your grid/playspace by just adding and describing rooms, which is as simple as: [...]

This particular example is not making MUSH/MUX any different from any other codebase out there. Even the command examples you give work the same out of the box in Evennia.

Is this in the game, or from outside of it, though?

Are all of the interplayer communication commands already established? (Say, pose, page, whisper, emit, etc.? -- I'm asking because I don't know.) This stuff is pretty big, really.

Griatch

@surreality said in What is out there? Hard and soft codebases of choice.:

@Griatch said in What is out there? Hard and soft codebases of choice.:

@surreality

I think -- and I could be entirely wrong -- what @Thenomain is trying to say is that once you install the MUX server, you essentially type one startup command and you have what you need to begin creating a play space on the creative front.

You have the four types of objects in place -- Player, Room, Exit, and Thing -- as well as basic communication commands.

Technically speaking, if your goal was to create a very basic, statless game, you already have more or less everything you need in place to start creating your grid/playspace by just adding and describing rooms, which is as simple as: [...]

This particular example is not making MUSH/MUX any different from any other codebase out there. Even the command examples you give work the same out of the box in Evennia.

Is this in the game, or from outside of it, though?

Are all of the interplayer communication commands already established? (Say, pose, page, whisper, emit, etc.? -- I'm asking because I don't know.) This stuff is pretty big, really.

Yes, it's in the game, out of the box. Evennia is basically a "talker" by default. It comes with about 90 default commands related to server management, building and social play. They can all be modified and replaced (outside the game). What we don't offer in core are very game-specific things, with the notion that this will be dependent on the type of game you want to do and easy to add if you know your players will expect it.

Here is the list of default commands:
https://github.com/evennia/evennia/wiki/Default Command Help
Here is the starting building tutorial:
https://github.com/evennia/evennia/wiki/Building Quickstart

I would also point to the "Evennia for Mushers" article I wrote here on Musoapbox. It's linked earlier in this thread.

You can also go to http://demo.evennia.com (telnet: silvren.com port 4280) to see an almost-vanilla install in action.
.
Griatch

krmbm

@Griatch said in What is out there? Hard and soft codebases of choice.:

This is a very important point. For all the "bridging power" of mushcode, how many can actually use it to the level of, you know, creating a new game from scratch? I am not familiar enough with the MUSH community to know this number, but I suspect that it's not a large number.

You'd be surprised.

I know several people just within my one tiny subset of MUs that could get a game up-and-running themselves quickly. Partially, this is because installing MU (as has been noted) is generally super easy, especially if you go to a MU* host, where they give you a working environment and all you have to do is upload, extract, and start your MUSH.

I think everyone acknowledges that MU is archaic, but it's also got a very low barrier to entry, and that's what Evennia lacks for me.

I wish the project luck. I think it has great potential. But I think, as someone else in the thread said, it might not be the right solution for bringing MUSH into the 21st century.

(I also acknowledge that, as a grown-up with a kid and a job and everything, I don't have the time and energy that I did 20 years ago to sit and learn a whole new system just to support my hobby. Maybe some youngster will figure it out for me.)

golgoth

@krmbm I learn 2 hours a day. 1 before work, 1 when I get ready to sleep. Adulting is harder than I expected.

Griatch

@krmbm said in What is out there? Hard and soft codebases of choice.:

@Griatch said in What is out there? Hard and soft codebases of choice.:

This is a very important point. For all the "bridging power" of mushcode, how many can actually use it to the level of, you know, creating a new game from scratch? I am not familiar enough with the MUSH community to know this number, but I suspect that it's not a large number.

You'd be surprised.

I know several people just within my one tiny subset of MUs that could get a game up-and-running themselves quickly. Partially, this is because installing MU (as has been noted) is generally super easy, especially if you go to a MU* host, where they give you a working environment and all you have to do is upload, extract, and start your MUSH.

That is great and a good boon. It's not what I asked though (or intended to ask). Just starting a server is one thing. The question was how many can then build a full game in mushcode off what the server offers with that download. Maybe the better question would be how many @Thenomain 's and @Volund 's are around these days? It''s not a retorical question - it would be interesting to know.

I think everyone acknowledges that MU is archaic, but it's also got a very low barrier to entry, and that's what Evennia lacks for me.

What interests me is how big a part of that "low barrier" is due to familiarity and how much this colors perceptions and comparisons. Because, as someone who has used lisp but is not a mush user, the mush softcode system is one heck of a barrier.
.
Griatch

faraday

@WTFE said in What is out there? Hard and soft codebases of choice.:

In the end I may finally implement the program's final version in a compiled language, but nothing beats a hosted interpreted language (or a language whose compile/link/load cycle is so fast it emulates one) for raw exploration of concept space.

I completely agree with you that this is MUSHcode's strength. And if that's your primary goal in your game and you're willing to learn MUSHcode to do so, then clearly the first-gen MUSH servers are for you.

But as @Griatch pointed out, the workflow for Ares/Evennia is nowhere near as onerous as the C example you cited. I logged in yesterday and someone reported a bug in the mail system. I fired up my SSH client, edited one file, typed reload and voila - the bug was fixed in about 2 minutes.

Yes, it requires an extra step of having an ssh client running in a separate window. No argument. But IMHO that is an extremely minor addition to the workflow. And in exchange for that small amount of friction, I get, among other things:

Coding in Ruby instead of in a 30-year-old derivative of a language (Lisp) that nobody uses any more, with all associated benefits (off the shelf libraries, whitespace, comments, community help, editor tools, etc.)
Easy version control, without having to run things through a MUSHCode formatter/unformatter, with all associated benefits (history, merges, backing out changes, easily accepting contributions, etc.)
Seamless sharing of code between my local development environment and the real game server. (Having a local environment is an option, not a necessity, but one way to address @Thenomain's point about fiddling with code before publishing it live.)

If none of that appeals to you, that's totally cool. First-gen MUSH servers aren't going anywhere. My goal with Ares is not to replace them, but to provide an alternative that makes it easier to install, play, and code a game. If nobody uses it but me, I'm fine with that

To @surreality's question about out-of-the-box config, I'd say that's another core difference between Evennia and Ares: Evennia is set up with basic "talker" commands like Penn/Tiny, without the game-specific stuff. Ares comes out of the box with all that plus all of the things you'd normally find in a softcode package like mine/Volund's/Theno's. (List of AresMUSH Plugins) It's a difference between open MU* framework vs. MUSH-in-a-box.

WTFE

@faraday said in What is out there? Hard and soft codebases of choice.:

@WTFE said in What is out there? Hard and soft codebases of choice.:

In the end I may finally implement the program's final version in a compiled language, but nothing beats a hosted interpreted language (or a language whose compile/link/load cycle is so fast it emulates one) for raw exploration of concept space.

I completely agree with you that this is MUSHcode's strength. And if that's your primary goal in your game and you're willing to learn MUSHcode to do so, then clearly the first-gen MUSH servers are for you.

Except you missed the part where I said that MUSHcode is a fucking horror of a language.

My issue with Evennia is that it is (correctly) predicated on the observable fact that MUSH servers are dying-to-dead technology barely being propped up by increasing cruft at all levels. (Some of the work people are putting into MUSH servers is incredibly creative, but it's gilding a turd in the end.) But Evennia is the other kind of turd: the overengineered mess. It solves, IMO, almost, but not quite, exactly the wrong problems and in the process of doing so removes one of the few virtues that MUSH servers have.

And it didn't need to.

For example, there are other embeddable languages out there that you can incorporate into a custom server that will bring you up out of the stone age. Off the top of my head I can cite Lua and Tcl as possible contenders (with Lua going more up the list because it's quite a bit more modern and popular a language). The choice of Python + Django + MySQL + <insert long list technologies here> with the full-blown methodology of semi-professional software development expectations is actively offputting for hobbyist-oriented pretendy fun-time games, IMO.

IMO an ideal MU* server replacement would:

Not be telnet based. Period. Supporting telnet as a deprecated legacy, sure, but the telnet ship has sailed. And foundered on shoals in the middle of the fucking Pacific. And then sunk to the bottom. All the telnet extensions that MUSHes and their clients have fitfully tried to incorporate over the years are more turd-gilding. A MU* server replacement should be where most people reside on the Innarwebtubes these days: the web (or mobile apps if you must).
Be a trivial installation. IDEALLY it should be a single-executable installation. "Copy this file into your PATH" or even better "run ./my_funky_server --install and stand back". (Don't believe this is possible? Take a gander at the Fossil SCM: full-fledged DSCM, web server, scriptable wiki, document server and quite a bit more ... and all in a single executable that is about 9MB on my system right now. This includes the baked-in SQL database…)
Support both in-game coding and out-of-game coding. There are some who want the shell+text-editor+RCS+… infrastructure and there are some who want the in-game immediacy. Why not support both? Hell, why not let people decide which tasks they want to perform where? Maybe game systems at one site are done in external modules while in-game gewgaws are coded inline. Perhaps even … <gasp!> let people move things from one domain to another (provided they have the privs, natch!). Let them tinker with things online, then export the tinkered items into the formal development environment for all the crunchy VCS, modularity, and other goodness.
As a furtherance of the previous, why not support multiple languages? Python for the plug-ins, say, while Lua is used in-game. Or any other pairing (or more!) of languages. Hell, publish a socket/RESTful interface specification and let anybody plug in any language that can talk sockets and/or HTTP (or WebSockets if you want to be hipster). Out of the box you support a small, carefully selected set of languages, but keep it wide open for extension.

But as @Griatch pointed out, the workflow for Ares/Evennia is nowhere near as onerous as the C example you cited. I logged in yesterday and someone reported a bug in the mail system. I fired up my SSH client, edited one file, typed reload and voila - the bug was fixed in about 2 minutes.

Now factor in debugging to find the problem. It's a lot easier to debug a system that gives you its guts at point of usage... (I go back to my use of Forth in embedded systems when exploring hardware, for example, or prototyping applications. Or often actually delivering them.)