Sure. It probably comes down to game styles, yes. For example a multi-descer is completely unheard of in most other genres of MU*. In other styles, dynamic descriptions is a big deal.

Here are some examples. The Evennia FuncParser inlines actually support nested calls (so they will be executed from the inside out like a regular python call), but for brevity, assume we have made some custom functions for one’s particular game and is using the rpsystem contrib:

$You() have pock-marked skin and is in his $approxage(10). He wears $clothes(). He looks $health(). 
$ifguild(thieves, He has the secret thief's guild mark on his hand.)
$ifskill_gt(detectmagic, 10, He has a faint aura of magic around him.)

Here, someone who’s can’t detect magic, doesn’t know me and is not in the thieve’s guild will see

The tall man has pock-marked skin and is in his thirties. He wears a black hoodie. He looks a bit sick.

Wheras if you are know me (has recognized me previously), is in the thieve’s guild and has enough in the detectmagic skill, you will see

Griatch has pock-marked skin and is in his thirties. He wears a black hoodie of the type that has a lot of hidden pockets. He looks a bit sick. 
He has the secret thief's guild mark on his hand. 
He has a faint aura of magic around him.

This works because when the FuncParser parses the description it is fully aware of who this description is targeted at. So we can have the $clothes() inline give some extra info (it probably checks for the looker’s thief’s guild membership inside its code), and so on.

As for the stance example, here’s how it could look for Evennia:

Director stance:

msg = f"{char.key} changes $gender(poss) stance to $stance()."

Actor stance:

msg = "$You() $conj(change) $gender(poss) stance to $stance()."

(note: The $gender() inline is not in default Evennia since core objects don’t have genders; it’s something deemed game specific. But maybe we should add it to make this structure easier to make in actor stance).

This is called in code as

room.msg_contents(msg, from_obj=char)

And would come out as

Faraday changes her stance to cover.  # director stance
You change your stance to cover.         # actor stance, your view
Faraday changes her stance to cover.  # actor stance, everyone else's view.

I’m actually curious what use cases you’ve found for descriptions.

The only thing that comes to mind is some sort of reality layering when a character has some kind of stat or attribute that lets them see additional/different information.

Like how in oWoD there’d be regular descs and Changeling Descs that only other Changelings (and those who could see Dreaming Shit) would get.

Descriptions are just one use case; another one is to implement ‘actor-stance emoting’, so that you can have your game systems send strings like “$You() $conj(smile) to $you(otherperson)” and everyone will see their appropriate strings (You vs your name etc). It’s used for prototypes and other places too.

I’m actually curious what use cases you’ve found for descriptions. I contemplated adding some substitutions like that to Ares and came up blank as to when anyone would ever need them. All I ended up doing was some simple center/right/left formatting.

I realize Evennia spans more of a gauntlet of game types, so maybe it’s more common in the RPI/MUD end of things.

Game systems (on the back-end) sending customized text in Ares is just done with locale strings - there are no special codes. But it doesn’t come up as much, since most system messages are OOC not IC.

desired output: Faraday has changed her stance to cover.

locale string: "%{name} has changed %{poss} stance to %{stance}."

code: t('fs3combat.stance_changed', :name => name, :poss => combatant.poss_pronoun, :stance => self.stance)

@somasatori

As it stands, the multidescer contrib mentioned above will probably be easier for use as a multidescer (see link above). To be honest, it was created before the FuncParser (what is called ‘code in descs’ above) existed so it’s quite likely one could implement a multuidescer using the FuncParser too, haven’t tried.

The FuncParser is overall considerably more than just ‘code in descs’ though. It is a full, safe parser, for dynamically modifying strings based on situation or who sees them. You embed strings like $foo(arg, arg) and the return of these (Python functions you implement under the hood) will replace that position in the string. Descriptions are just one use case; another one is to implement ‘actor-stance emoting’, so that you can have your game systems send strings like "$You() $conj(smile) to $you(otherperson)" and everyone will see their appropriate strings (You vs your name etc). It’s used for prototypes and other places too.

At least concerning Evennia, the FuncParser is indeed the closest we have moved to something similar to softcode, but it’s intentionally stopping at being a way to create advanced formatting solutions rather than offering the pieces needed to be turing-complete. As I also write in the documentation to it, one could in principle make some sort of LISP-like language using FuncParser (lots of parentheses, all functional programming), but it’s not something I plan to add to core Evennia at least.

As for a multidescer - yes Evennia has an optional multidescer contrib. I created one once people from another MUSH-heavy forum told me that this was one of the more common things MUSHers use softcode for. You can read about the Evennia implementation here: https://www.evennia.com/docs/latest/Contribs/Contrib-Multidescer.html

I think with Ares, I’d compare the engine to hardcode and the plugins to softcode.

You can make a very loose analogy, but plugins are lacking nearly all of the core traits that usually define “softcode”:

• The LISP-based MUSH Code scripting language itself
• The ability to create commands / systems live from the MU client command line
• The ability to for players to create their own personal code
• The distinction between “WHO” as the hardcoded command and “+who” as the softcoded version that exists in parallel

Same with Evennia’s Python code.

If you want to do your own alias for a command and you can’t convince an admin to add it for you, you can use your client. If you want to charge what commands you run on login, there is already a command for that. Outfits and multi descers are also already there.

How important is the character description anymore?

I can tolerate a lot of evolutionary bullshit that comes with changing times, but if we’re doing away with reading and writing in a text-based game, that’s where I draw the line.

On the anecdotal side, lately what I’ve usually seen are people posing their outfit of the day in their opening pose.

I use multidescers myself, so no shade towards writing static descriptions, but it seems to be less of a trend to write many static descriptions. Although you said that you don’t have any stated timeline for opening, it’s still best not to add undue additional work unless, like Faraday said, you really want to go for the fun / technical challenge.

@Pavel I don’t think I agree with that. The most natural way softcode is useful is to [run code()] in a desc.

You’re approaching a problem (wanting to put “code” into descs) with a particular solution already in mind (softcode). But that solution has a lot of baggage and risks.

If you take a step back and ask why you want to put code into descs, you might find that the uses are far narrower than you imagine and can be solved in different ways.

For example, Ares doesn’t have placeholder objects, but mostly people use those for things like rings and signs. Instead it offers a robust details system that can add those kinds of descs to rooms and players with a simple command. Most of the code people put into room descs is to adjust for time of day and such. Ares does that via the “vista” commands.

Now maybe your game’s needs are unique and you really do need softcode. Or maybe you just want to do it for the fun / technical challenge. In that case go for it.

All I’m saying is that the plethora of games running on Evennia and Ares without softcode challenges the assumption that softcode is essential for MUs.

@Pavel I don’t think I agree with that. The most natural way softcode is useful is to [run code()] in a desc.

But we’ll see. All of this is last on my list of features anyway.

That is what I do with my Evennia game core, I process descs through the funcparser. This allows me to pull in data and do formatting just like you would do with softcode on MUSH, only without the overhead and security issues.

Ex:

    def get_desc(self, looker=None):

        desc = self.db.desc or ''
        if not desc:
            return ''
        parser = FuncParser(dict(FUNCPARSER_CALLABLES, **LOCAL_FUNCPARSER_CALLABLES))
        parsed_string = parser.parse(desc,
            raise_errors=False,
            escape=False,
            strip=False,
            return_str=True
        )

        return parsed_string

But we’ll see. All of this is last on my list of features anyway.

Yeah, the hardcode/softcode delineation doesn’t make much sense here.
@Roz said in What is a MUSH?:

Lol thank you for bringing my attention to the fact that I wrote the WRONG WORD there. I meant gamewide code vs player code.

Yeah I don’t want to nitpick wording, but I think it’s an important distinction because “hardcode” and “softcode” have very heavy connotations in traditional MU circles. The idea that “hardcode” is this heavyweight thing that can’t easily be changed (and generally shouldn’t be messed with in most cases) and that “softcode” is where you put your game-specific commands like sheets and multi-descers.

None of that applies to platforms like Evennia and Ares, which is why neither use those terms. Their code is server-side (like traditional hardcode) but flexible and game-specific (like traditional softcode).

So when Ares/Evennia devs say “you don’t need softcode” that doesn’t mean there are no multidescers, sheets, or commands to describe rooms. It just means those things are coded as server-side game code not coded-thru-MU-client game/player code.

@mietze said in What is a MUSH?:

I always assumed that was the reason why a lot of games stopped letting people custom stuff. I don’t know if lag is a problem now though. This was in the days of dial up internet.

The main issue is actually security. Unless you have things meticulously locked down, it’s very easy for malicious players to exploit coded systems when you let them write their own code. This is doubly true in Evennia and Ares due to the underpinning languages (Python/Ruby).

It’s so easy to shoot yourself in the foot and compromise your game (or even your entire server) if you don’t have things set up right. And for what? So someone can code their own Falcon Controller or use a different syntax for the multi-descer instead of the built-in one? It’s just not a good tradeoff IMHO.

I always assumed that was the reason why a lot of games stopped letting people custom stuff. I don’t know if lag is a problem now though. This was in the days of dial up internet.

@Roz said in What is a MUSH?:

I can understand the delineation between gamewide code and system code here

Yeah, the hardcode/softcode delineation doesn’t make much sense here.

Lol thank you for bringing my attention to the fact that I wrote the WRONG WORD there. I meant gamewide code vs player code.

I can understand the delineation between gamewide code and system code here

Yeah, the hardcode/softcode delineation doesn’t make much sense here.

Things like XP are coded game systems.

True, but they’re also traditionally softcode.

Whereas things like

@Polk said in What is a MUSH?:

desc a house.

are traditionally hardcode. (Yes, some places have it as softcode, but @desc is hardcode and more usual).

So what you’re really thinking of is having more tools available to players that many places have often left in the hands of coders or staff?

@STD See I’m miscommunicating something here. Things like XP are coded game systems.

A player might do something like desc a house.

I mean, that’s not really player softcode, either? I think every MU* I’ve been on have had game systems for players to be able to desc their stuff.