There's a difference between negativity and realism.

I'm happy to have a mod make the final call if that's what you really want, especially since it looks like that's the only way this ends.  Either they'll agree that you're attacking me without cause, in which case this inappropriate behavior gets put to a stop, or they agree with you and I leave without regrets because the kind of community that will put up with this isn't the kind of community I want to be in.  Honestly, at this point either satisfies me.  I can move Synthizer to a blog and Google Group or something no problem, though if I do somehow get banned because of you I would appreciate someone cross-linking the new Synthizer location to the Synthizer thread once I make one.

I'm not okay with someone trying to perform character assassination because they don't know the difference between blunt realism and toxicity.  At the end of the day a lot of people around here have learned a lot from me, and you've even got some of the people who like me the least defending me.  SO can we please put this to rest one way or another?  It's tiresome.

Yeah. Not too sure how else to phrase it, but all cogent responses have either been met with silence or "but Camlorn is negative." Maybe, but your complete and utter refusal to acknowledge them for what they are, pessimistic ramblings at worst and downright facts and math at best, tells me basically everything I need to know. None of the posts you quoted violate any guideline we've ever written, and Camlorn has been a pretty upstanding member of the community without a single warning to his name (as far as I remember). The same can't be said for you, so at this point it seems like you're refusing to accept the reality that more than a couple things he said just might possibly have factual basis.

If there is any message that could possibly be construed as abusive it's the one you're sending by calling someone an idiot and telling them to, "shut the fuck up", then following them around and criticizing them for offering help that didn't meet your idea of a good explanation. You still haven't provided anything better, so until you do I'm just going to sort of assume Camlorn neglected to quote a block of text with a couple words sprinkled on top for good measure and call it that.

This has gone on for a while and I think it'd be cool if we could return to muds, so I invite you to chime in on the following, you can just quote.

If what Camlorn is saying is false, meaning that a fair number of sighted people will actually care about your mud, what distinguishing features exist that make this the case, Especially in light of rapid VR development?

Can you name another mud that has recently received even minor traction among sighted players? I'm talking more blind than sighted or a constant count > 50 after 2010. I'd love to give it a shot and see what everyone has been doing wrong for so long.

I can think of several MUDs that have more sighted than blind players.
Aardwolf's player base, for example, is primarily sighted, and that game seems to have a pretty active community (for a MUD.)
Lost Souls which was basically my MUD home for years consists almost entirely of sighted players, with one or two blind people sprinkled in occasionally.  That MUD has a pretty small community though.
I do feel like blind players are more likely to stick with a MUD long-term, and are probably easier to attract to a new MUD.  Most of the sighted LS players that I've spoken to about this are pretty confident they'll never play another MUD, as those they've tried, like Alter Aeon, have bored them to tears.
I'm curious about how many sighted gamers play MUDs, and how their numbers compare to the number of blind gamers overall.

On the toppic of modern MUD engines, there is also Wolfmud. I haven't seen any discussion about it on here, although I haven't read all the posts. It is still in development, but it seems to follow a modern design (in Go), and I would be curious to hear what others think of it.

https://www.wolfmud.org

From what I can tell, it has an architecture reminiscent of an entity component system, though without the concept of separate systems. Game entities are all represented by the same internal object, which is basically just an object with a list of attributes. However, attributes are all specialized objects. Therefore a game object is defined by it's attributes, not it's subclass.

Although it doesn't support embedded scripting or the like, it seams to be highly data-driven (with very readable text files), so I suppose the idea is to add attributes with game specific behavior to the code base, and then specify those attributes in the data files. In that respect it is perhaps similar to Diku-derived engines, though with much more readable data files.

@110
If you don't support scripting, and you don't plan to support scripting, you have a very limited engine.  The thing about the Diku derivatives is that builders and game designers cannot make anything truly unique without coding on the engine itself, which is a big part of why most muds are the same.  Now obviously people go off and do actually code on the engines, so it's not like there aren't differentiating features, but it's definitely a problem.  It's possible that they're just not there yet, of course.

Lest someone be like "but you just got done saying scripting is bad": that's not what I'm saying about Moo.  If you have a way to keep your scripts separate from game data and in a format that's easy to roll back, it's fine.

Using an ECS isn't something that's necessarily good or bad, but Go is one of the languages which itself doesn't have tools for OOP and so that kind of forces the issue.

The fact that their site says it's got a 30 year history but I've never heard of it and also they're rewriting from scratch raises a *bunch* of questions.  Also, this rewrite has been going on since 2012, and his announcement says he redid it for learning.  That's all fine, but none of it is the hallmark of a good OSS project.  Maybe it's amazing, and yes I'm being pessimistic again, but this has so far hit all of my red flags.

Especially note this, from the latest release notes (10 years into development!):

That's something that should be in the earliest release of your engine, not 10 years into development: synchronous network writes mean that after about 20 players at most you're literally just not responding, and he's literally using a language specifically designed for async writes.

And, like.  This is my point.  All of the modern engines are of this level of quality.

I'm not going to code review Ranvier to find out, but it's hitting less red flags.  Wolf is just up front hitting all of them.  However "we don't lock you into a network layer and we don't lock you into a database" are usually red flags in general.  it's a bad sign when the first thing a codebase advertises are the ability to customize things that you shouldn't ever need to customize.

Just look at what it takes to make a simple quest goal: https://ranviermud.com/building/quests/

Also, I immediately see a problem with this for performance: if every quest goal has to watch every event in the game, then your performance for evaluating quests is O(quests).  If the rest of the engine is this "flexible" then performance on everything is O(N) or worse and it'll fall down for large worlds, since the performance profile is world size and not number of logged in players.  Also, notice how complicated just giving the player some experience is.  I've seen Lost Souls's source code (was a wizard, briefly) and this is worse than what I remember of that, in terms of complexity, and Lost Souls literally customizes messages based off what your player character "knows" (e.g. if you haven't learned what steel is, you see a generic description of steel that doesn't say steel).

If you want a good shorthand for whether one of these might be quality, ask whether or not they've got games written with it.  That's really the easiest way.  No game means it's probably not prod-ready, or that the people behind it aren't focusing on making a game in the first place but instead fulfilling their programmer itch, but fulfilling your programmer itch does not finished and stable software make.

You put the event on the item, so that only events for the item in question fire.  Or you put the event on the quest giver, so that the quest giver only evaluates players when they enter the room of the quest giver.  You can periodically sweep all players in the game to check their objectives every 5 minutes.  Lots of ways like that.  But I suspect that why Ranvier doesn't like these is that they immediately limit what you can do.  Either Ranvier has more docs somewhere that explain how to optimize this, or they haven't yet built a big enough world that they've got events registered from thousands or tens of thousands of things.  It's possible that those .on calls are somehow "only when events happen in this area" or something like that, which would make it better; there is a world in which the underlying machinery here invisibly optimizes well beyond what I expect, and as i said I'm not code reviewing it and just gave it a cursory glance.

Circle lets you attach scripts to objects as a builder, which trigger only when events happen to those objects.  Most of the LPC mudlibs call special functions on your objects or give you special functions to wire up events, but again, they only trigger when things happen in your object's environment.  Once upon a time I knew what godwars and diku did, but it's been way too long, and I was less interested in those because all of those seem to have identical gameplay.  The problem with global events, whether it be anything muds or otherwise, is that you eventually end up with thousands of functions that fire, 99.99% of which don't do anything for this one.  But you have to call them all and they have to run their checks and it adds up.  Now imagine what happens when the newbie builder who can't really code tries to use this and you don't review their code because it's your weekend project and they decided to put something expensive that runs on the get event for every item in the world.  The trick is to build constraints into your system, so that the system can cheaply throw out events that are definitely not of interest.  For a good example of this, look at how the DOM events work, with the bubbling architecture.  it's not the best example because it's still powerful enough to let you shoot yourself in the foot by attaching events to the window, but it makes it very easy to only subscribe to parts of the page rather than all of it.

Counterintuitively, you don't have to optimize this on day one, or even in year 5.  You optimize it when it becomes a problem, as with anything else performance related.  But you do want to always make sure that your API is written so that those optimizations are possible.  That's really more general advice than events, but if your event API is "I can subscribe to this global event and that's it" you end up with a bunch of code that does that, and then you can't optimize the implementation without changing all of the code using it, and not just swapping out lists for hashtables or something simpler.  This is one of those weird things where how you do it is actually way less important than the interface to other modules.

I'd love to see camlorn spend his time code reviewing ranvier (node.js) or evennia btw.

Definition stupid: 1. silly or unwise; showing poor judgment or little intelligence: 2. annoying, ...