Getting Young Blood Into MU*'ing

[Tinuviel]

@Three-Eyed-Crow Aye, most of them are real-time, like "traditional" MU RP. But there's also capacity, since scenes are set places, that you can log in to the web client and pose as if you were on a forum.

That bit kind of makes me roll my eyes.

@faraday said in Getting Young Blood Into MU*'ing:

Folks can side-eye it all they want, but it's not doing anything that MUSHers haven't been doing for years.

Just because people have been doing it for a while doesn't mean it's not worthy of side-eye. I hated WoD timestops as much as anyone.

[Auspice]

@Tinuviel Then login and play! GOD.

[Tinuviel]

@Auspice Nah.

[Doom Guy]

@Arkandel said in Getting Young Blood Into MU*'ing:

An interface that doesn't look like it was created thirty years ago. A black screen on a dedicated telnet client downloaded from some obscure web site riddled with features and terminology that makes no sense to an outsider isn't it.

Good idea. Maybe I'll act on that.

[Tehom]

@Griatch said in Getting Young Blood Into MU*'ing:

Could you elaborate on what you think should work differently (apart from adding a RESTful API as a new input in the first place)?
.
Griatch

What I was more thinking about was the response rather than the request, if that makes sense. Evennia does support using input_funcs out of the box to call commands: but those commands do not currently have a generalized way set up to generate a response afaik, it assumes that the only meaningful output needs to take place in-game. If we're assuming that the text response is just one type of View, that's not necessarily the case - we want any sort of action to generate some sort of JSON response which we'd pass along to wherever. So what I was picturing was commands calling methods in objects that'd return some dict-like structure that could be converted to JSON for web responses, though you could do the same thing with commands directly as well.

[Griatch]

@faraday said in Getting Young Blood Into MU*'ing:

@Griatch said in Getting Young Blood Into MU*'ing:

But overall - this thread makes me feel like that I should really sit down to learn more web-dev stuff. I can do it, but it's not really coming easily to me, dammit ...

Web dev doesn't come easy to anyone. And that's kind of the problem I ran into with Ares. It's 1000% easier to add the text-based commands to Ares than to add anything on the web side. It can be overwhelming, especially to folks without a lot of coding experience. People have done it, but it is not an easy learning curve.

Also, with Django - I wouldn't be surprised if you eventually run into the same issues I had when Ares was using server-side rendering. The more I added to the portal and the more people used it, it started to really impact server performance. That's why I shifted to a Javascript framework for the front-end. Not only did it improve performance, it also enabled more client-side fancy features. Unfortunately, that just adds yet another several layers of complexity to the mix (and another language to learn).

I think my main personal iffiness with web development is that my goal is generally to make code that others can easily follow and understand (and potentially expand). And contrary to coding Python, when it comes to JS, CSS or even HTML etc I don't feel confident that I know what is a "good practice" or even if such a thing truly exists in some cases.

As for performance, I'm not (at this time) quite as worried about web adding any more overhead than it already does; the Twisted+Django combination Evennia uses is quite optimized for this kind of thing. That said, as much non-game critical things should certainly be offloaded to the client side. We support optional graphics, video and music in the client for those so inclined, and that's of course not something we'd ever care to stream from the server.

@faraday said in Getting Young Blood Into MU*'ing:

@mietze said in Getting Young Blood Into MU*'ing:

That is super niche. It doesn't surprise me that people who find that lacking will lean more into other stuff. Or that people who do enjoy it also enjoy other things and will divide their time further because there's more options for pastimes.

I don't see any evidence that it has to remain "super niche" though. People who enjoy video games will sit down and play them for hours on end, so we know there are people with blocks of free time on their hands. MUDs are still pretty huge. Play by post forum sites boast thousands of members and hundreds of games, so we know there are people who enjoy text-based RP. Storium had almost 7000 backers, but if you follow the community you'll see common complaints about the slow pacing and games fizzling out because one person dropped out, things that MU's dynamic/revolving-door nature do help to address.

I find it impossible to believe that there aren't a decent number of potential MU players out there.

But to snag them, we need more approachable tech, better tutorials/welcome wagons, and people willing to bend a little to accommodate them in actual RP. It's the latter that I see as the biggest challenge.

I agree with this optimism. Whereas I don't expect MU*ing to ever be the "next big thing" again on the whole, I do think that technology alongside better practices can go a long way into tapping into a today unseen player base.

I also don't understand people's aversion to web clients. I can accept the reluctance if the web client doesn't have some/all the features they expect/need/love in their third-party client. But my impression from other threads is that some just don't want a web client, period - regardless of its features.

@Tehom said in Getting Young Blood Into MU*'ing:

@Griatch said in Getting Young Blood Into MU*'ing:

Could you elaborate on what you think should work differently (apart from adding a RESTful API as a new input in the first place)?
.
Griatch

What I was more thinking about was the response rather than the request, if that makes sense. Evennia does support using input_funcs out of the box to call commands: but those commands do not currently have a generalized way set up to generate a response afaik, it assumes that the only meaningful output needs to take place in-game. If we're assuming that the text response is just one type of View, that's not necessarily the case - we want any sort of action to generate some sort of JSON response which we'd pass along to wherever. So what I was picturing was commands calling methods in objects that'd return some dict-like structure that could be converted to JSON for web responses, though you could do the same thing with commands directly as well.

The caller.msg is the response. The msg method works perfectly for use as a JSON response since it you can send multiple outputfuncs through it at the same time - caller.msg(text=..., foo=..., prompt=..., help=...) etc.

You are correct however that many of the default commands use not one single msg call but multiple. To truly make them suitable for a proper RESTful exchange, one would need to consolidate the commands func methods into each only having one return before exiting.
I don't think this would be too hard, honestly. The use of multiple msg-calls is more a sign of laziness than anything. Rewriting commands so as to concatenate the result text (or whatever output) into a string/dict and then only return it once at the end of each Command.func is only a matter of refactoring code. Which is not hard, just takes time to do for 90+ default commands.

Thinking more on it, the main issue with doing something like this comes in interactive commands. If you use a delay or have a prompt using the @interactive decorator, the execution of the Command's func method will pause mid-way and wait for the user to enter a reply/input before continuing. Something like that does not really seem suitable for a REST-based communication. REST requests are expected to run in isolation and not being dependent on what came before, after all. Any ideas?
.
Griatch

[faraday]

@Tinuviel said in Getting Young Blood Into MU*'ing:

@faraday said in Getting Young Blood Into MU*'ing:

Folks can side-eye it all they want, but it's not doing anything that MUSHers haven't been doing for years.

Just because people have been doing it for a while doesn't mean it's not worthy of side-eye. I hated WoD timestops as much as anyone.

So then don't play in those scenes maybe? But if I want to spin up a multi-day scene to play with my friend from England whose timezone doesn't line up with mine, or my friend from Seattle who is super-busy with a new baby and can't get online for hours at a time, then that's my business, not yours. Allowing more flexibility hurts nobody and enables RP that simply wouldn't happen otherwise.

[Tinuviel]

@faraday said in Getting Young Blood Into MU*'ing:

Allowing more flexibility hurts nobody

So long as it's only "allowing more flexibility" and not a new paradigm.

[faraday]

@Tinuviel said in Getting Young Blood Into MU*'ing:

So long as it's only "allowing more flexibility" and not a new paradigm.

That is entirely in the hands of the MU community. MU players control what becomes the norm by how they behave.

The one practical thing holding it back from becoming the norm, IMHO, is the MU time clock. IC time continues to pass for the rest of the game even if your scene is lagging. It's the same reason people hate timestops. It ties your hands from continuing with other RP, and potentially makes your own RP moot based on other things that have now transpired.

That natural tension doesn't disappear just because somebody's using a different MUSH client to participate in the scene.

[Lotherio]

This thread blew up, I can't read 9 pages to see if this has been covered.

A large barrier to entry for Mu* compared to forum/discord/other game (like RP on WoW or Minecraft) is ... the cost of entry.

I remember back in the 90s my group discussed the need for 2nd+ editions, which is because some companies can only sustain by releasing new editions. If everyone in the hobby has 1st edition and nothing else sales ...

Most Mu*s have some system and knowing the system is a barrier to entry which requires having the books for that system.

As a teen or young 20-something with little disposable income, would I be more inclined to play on a forum or discord where I don't necessarily need to know rules or buy books ... or jump into any number of Mu*s that require one book to really know the system and usually use a handful of others to make it more 'complete'?

Lots of places use a specific theme (aside from system) and that requires having read the books to get through CG half the time.

I prefer simple universal systems and original theme, but that's not really the go to for most folks who have been in the hobby for a while it seems. So by being specific and using well established themes, we're in part creating the barrier to entry. The young blood will find a place to play that doesn't require an expenditure of resources (money and/or lots of reading time just to understand the basics before getting into specific theme/house rules for that setting).

[Apos]

@Tehom said in Getting Young Blood Into MU*'ing:

@Griatch said in Getting Young Blood Into MU*'ing:

Could you elaborate on what you think should work differently (apart from adding a RESTful API as a new input in the first place)?
.
Griatch

What I was more thinking about was the response rather than the request, if that makes sense. Evennia does support using input_funcs out of the box to call commands: but those commands do not currently have a generalized way set up to generate a response afaik, it assumes that the only meaningful output needs to take place in-game. If we're assuming that the text response is just one type of View, that's not necessarily the case - we want any sort of action to generate some sort of JSON response which we'd pass along to wherever. So what I was picturing was commands calling methods in objects that'd return some dict-like structure that could be converted to JSON for web responses, though you could do the same thing with commands directly as well.

Just to translate for everyone that is wondering what Tehom is talking about in his discussion with Griatch and isn't familiar with the coding terminology, let me briefly (and maybe at least partly accurately) summarize:

He is saying that since people trying to create their own games using evennia would probably instinctively first go to changing commands (you know, the really common ones shared across games that Evennia has out of the box also), it should probably be a lot easier for a coder to learn to do that. Since there's an awful lot of ways something can be coded and implemented, he was debating about ways to set it up so it's a lot more accessible for new coders to do it, rather than very experienced ones, since a new coder sitting down to try to learn python and django and use Evennia is going to want to do that early on, and it probably shouldn't need more advanced concepts. That's why it's such a technical discussion, because they are basically coders talking about what might be easiest out of a wide range of choices.

[Doozer]

@Lotherio I’m co-sign to this.

[Thenomain]

@Lotherio

Do you have a recommendation for system?

Hold on, let me strike that out:

Do you have a recommendation for system?

Do you have a set of recommendations for systems?

I know that I'm making this a "setting + system" discussion in asking, but a lot of generic systems can be tweaked, which while would require a little bit of reading to see how things have changed, I think we can talk about this without the inevitability of "your setting and system must be married at the hip".

The number of @faraday's FS3 games out there right now are good evidence that this isn't true. Each of the games must fall upon a certain scope, but scope and setting can be quite different. BSG vs. Gothic Americana, for instance. Similar scope, but wildly different setting.

So I am interested in what you have to say and would like to read the pamphlet. Do continue.

--

This reminds me of the number of times I've heard people, here and elsewhere, complain that people will try to play a game without reading the source material. The idea that the source material is a barrier to entry and therefore we should ease up on it also changes what kinds of games that would help the hobby. "Babylon 5" and "Dresden Files" (even using a more generic system) become less tenable choices.

I do think that picking system and picking setting are different situations, but demanding people Know All Phase 3 Marvel Movies is a consideration alongside Buying Every WoD Book In Existence.

[Ganymede]

@Thenomain said in Getting Young Blood Into MU*'ing:

I do think that picking system and picking setting are different situations, but demanding people Know All Phase 3 Marvel Movies is a consideration alongside Buying Every WoD Book In Existence.

The WoD 2E books are all fairly self-sufficient. Having the CoD helps, but you don't need it.

Granted, those books are voluminous and horrifyingly dry at times.

[Lisse24]

@Ganymede said in Getting Young Blood Into MU*'ing:

@Thenomain said in Getting Young Blood Into MU*'ing:

I do think that picking system and picking setting are different situations, but demanding people Know All Phase 3 Marvel Movies is a consideration alongside Buying Every WoD Book In Existence.

The WoD 2E books are all fairly self-sufficient. Having the CoD helps, but you don't need it.

Granted, those books are voluminous and horrifyingly dry at times.

And horribly written from an instructional design POV (though slightly better than their predecessors).

[Groth]

@Griatch said in Getting Young Blood Into MU*'ing:

Thinking more on it, the main issue with doing something like this comes in interactive commands. If you use a delay or have a prompt using the @interactive decorator, the execution of the Command's func method will pause mid-way and wait for the user to enter a reply/input before continuing. Something like that does not really seem suitable for a REST-based communication. REST requests are expected to run in isolation and not being dependent on what came before, after all. Any ideas?
.
Griatch

Just get rid of interactive commands entirely, they cause nothing but trouble and I've never seen them be particularly useful.

Anything that can be done with an interactive prompt can just as easily be done by just tracking the relevant variables and have the prompt tell the user which command to use.

[Thenomain]

@Ganymede said in Getting Young Blood Into MU*'ing:

The WoD 2E books are all fairly self-sufficient. Having the CoD helps, but you don't need it.

After having gone through Signs of Sorcery for CoD nMage 2e, and knowing about the upcoming Contagion Chronicle, I'm going to have to argue the point. If you pull elements from these books, you (plural/general) are either asking people to obtain the books or not use any element from them until they can find some other way to learn the rule or setting change.

So players who decide to just wing it rather than fight that barrier are often not unreasonable, and game creators should keep this in mind when adding material, and players should keep this in mind when reacting to those who might not know these things.

Addendum: All this within reason. If someone won't change their tune after being told that their choices break setting, then well, you tried.

[Griatch]

@Groth said in Getting Young Blood Into MU*'ing:

@Griatch said in Getting Young Blood Into MU*'ing:

Thinking more on it, the main issue with doing something like this comes in interactive commands. If you use a delay or have a prompt using the @interactive decorator, the execution of the Command's func method will pause mid-way and wait for the user to enter a reply/input before continuing. Something like that does not really seem suitable for a REST-based communication. REST requests are expected to run in isolation and not being dependent on what came before, after all. Any ideas?
.
Griatch

Just get rid of interactive commands entirely, they cause nothing but trouble and I've never seen them be particularly useful.

Anything that can be done with an interactive prompt can just as easily be done by just tracking the relevant variables and have the prompt tell the user which command to use.

They are exceptionally useful for a game designer though. Evennia has dynamic systems for making building command question/answer pairs (the EvMenu for example). But for ease of coding, this function:

# this code runs when, say, command A is passed
@interactive
def func(self): 
    # do stuff 
    answer = yield("Do you want to truly continue?") 
    # do something depending on answer 

is a far cry better in developer-ease and readability than having command A ask the question, store the "question state" in a variable and then instruct the user to fire up command B (or take the next unmatched input if A sets it up as a special game state) in order to get the player's answer. So while the effect of course can be mimicked by other means, it makes for very fast development and very readable/maintainable code.

It's possible that one has to stay away from such convenience if wanting to be fully REST compliant, but I'd personally hardly say the functionality is not useful.
.
Griatch

[Lotherio]

@Thenomain said in Getting Young Blood Into MU*'ing:

@Lotherio

Do you have a set of recommendations for systems?
....
So I am interested in what you have to say and would like to read the pamphlet. Do continue.
....
I do think that picking system and picking setting are different situations, but demanding people Know All Phase 3 Marvel Movies is a consideration alongside Buying Every WoD Book In Existence.

For systems, versatility. I was a fan of D6, not because I was an uber fan of Star Wars but because it was easily customizable even before it was released as Open D6. I'm a fan of FS3, because even as you pointed out, wildly different settings fit under the system. I know @Faraday is adamant about what settings fit the bill for the system out of the bottle, but it is adaptable and others have tried and continuously do try to fit it into other bottles.

The issue is that others argue the system when really young blood just need some basic stats (attributes/skills/etc.) and dice to decide, not an in-depth war game or combat heavy RPG that more typical TT players seem to favor.

Literally if I go to an RPG forum for some type of RP, the system is not an issue and really its whatever the ST recommends using. Same with other on-line RP mediums, most young blood do not even use dice. Yet, we'll argue semantics over whether total dice pool (total face values) vs counting successes (each dice over a certain number) is better or worse.

I see this as a barrier to entry. Coming into some conversation about which dice to use in some complex formula I imagine is like 'no thanks, I'll go back to my forum RP where its more collaborative writing and less rules lawyering.'

And it is the same with setting, even if difference in scope. If someone offers historical but its more Hollywood historical, arguments abound. Would I rather play on some new original setting place or Dragonlance with however many hundreds of books if cannon and if I play a dwarf wrong because of some obscure book I'll be called on it? The former for me.

I don't really have any answer. Like the Dark Crystal thread about it being a good idea is cringe-worthy for me, because at some point its a bunch of 'what system works best', and those who watch some of the these 'theme' would be a good game discussions probably notice once two to four people debate the best system for the game, the thread starts to die off.

[faraday]

@Griatch said in Getting Young Blood Into MU*'ing:

It's possible that one has to stay away from such convenience if wanting to be fully REST compliant, but I'd personally hardly say the functionality is not useful.

I would not say it's "not useful", but I would venture to say it's not essential.

Ares doesn't have a way to do that sort of direct query-response command, in part because PennMUSH never did. Maybe Penn does now, but it's not something I ever really encountered in MUSHing. And you see a shift away from interactive commands in regular command line interfaces, mostly for automation reasons. So generally I find it jarring.

It's pretty straightforward to store a variable so you can do chargen/next or store a prior state to do destroy/confirm after you tried to destroy something.