Getting Young Blood Into MU*'ing

[surreality]

@faraday I may be misremembering, then, since I am cringey on wikidot. It's like moonspeak to me.

[Tehom]

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

Ditching Commands altogether is not a self-goal in my opinion however. Commands remain in use (also outside of MU*) because they are highly efficient ways to tell the computer (game) what to do. Some things can be offloaded to buttons in a GUI, and that could get you some part of the way, but only for very simple inputs without arguments. Trying to replicate complex command functionality with a GUI will quickly build up complexity in that domain instead.

I'd agree with this, but I think what might be a good evolution in the far future is to make commands into very thin text interfaces for model methods/utility function calls, which would then be accessible by web interfaces. Text commands are largely analogous to text-based Views that perform some task and output text, and ideally they'd be solely responsible for validating input and presenting text output, where all the real meat of what's being accomplished is handled elsewhere and could be called independently by whatever - text commands, web views, RESTful API calls, celery tasks, scripts, etc. You could even have shared validation by using serializers/forms in both for a very DRY approach, but would sadly greatly increase the barrier to entry.

[Griatch]

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

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

Ditching Commands altogether is not a self-goal in my opinion however. Commands remain in use (also outside of MU*) because they are highly efficient ways to tell the computer (game) what to do. Some things can be offloaded to buttons in a GUI, and that could get you some part of the way, but only for very simple inputs without arguments. Trying to replicate complex command functionality with a GUI will quickly build up complexity in that domain instead.

I'd agree with this, but I think what might be a good evolution in the far future is to make commands into very thin text interfaces for model methods/utility function calls, which would then be accessible by web interfaces. Text commands are largely analogous to text-based Views that perform some task and output text, and ideally they'd be solely responsible for validating input and presenting text output, where all the real meat of what's being accomplished is handled elsewhere and could be called independently by whatever - text commands, web views, RESTful API calls, celery tasks, scripts, etc. You could even have shared validation by using serializers/forms in both for a very DRY approach, but would sadly greatly increase the barrier to entry.

I think the notion of being able to call a Command through any client input or API call is a good one. Unless I completely misunderstand what you mean it's however also already something Evennia supports out of the box. What we don't have today is the REST API endpoints themselves, but the REST API would just be another authenticated client input in this case - same as telnet, webclient or ssh.

The input from whatever client (in Evennia known as the inputfunc) is already today completely generalized and could come from wherever client - like a telnet connection, GMCP/MSDP or a JSON blob from the webclient or an optional REST API. Once parsed by the wire protocol, the inputfunc looks the same to the system, regardless of source.

The parsing of the text inputfunc (which is the Evennia name for the In-band instructions we write on the command line) is not 100% up to each individual command class, that's true. But honestly, it's not far from it - all Evennia does outside the Command class is to figure out which command class to call. From there on, the parse method of the Command class is responsible for all parsing of the command's arguments. Through class inheritance you can have many Commands share this parse functionality, but you could easily make each do its own if you wanted to. I think it's pretty hard to imagine a more general system while keeping Commands as separate entities.

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

[surreality]

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

The input from whatever client (in Evennia known as the inputfunc) is already today completely generalized and could come from wherever client - like a telnet connection, GMCP/MSDP or a JSON blob from the webclient or an optional REST API. Once parsed by the wire protocol, the inputfunc looks the same to the system, regardless of source.

I think the thing a lot of people are trying to get across is this: everything said right here may as well be written in Aramaic to most of us -- and that's just 'what it does/can do', not even 'and here is how to do it' or 'why you'd want to do it' or 'this is what you'd want if your end goal is X'.

[faraday]

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

I think the thing a lot of people are trying to get across is this: everything said right here may as well be written in Aramaic to most of us -- and that's just 'what it does/can do', not even 'and here is how to do it' or 'why you'd want to do it' or 'this is what you'd want if your end goal is X'.

Yeah but that's because it's a highly detailed code conversation. (Referring to that small exchange between Ghost and Griatch - not the general thread of course.) What @Griatch said perfect sense to me. Unless you're a coder, you're not going to be doing your own interface layer to Evennia, so I'm not sure what it is you're looking for in terms of general information?

[Griatch]

@surreality Yeah, sorry, this is a little too much detail for being outside of an Evennia-specific forum; I can see it'd be hard to follow out of context. Tehom (who is the Arx developer for those that didn't know) asked a very technical question to which I had to reply to with equal specificity for it to make sense.

You certainly don't need to know these internal implementation details to use Evennia.
.
Griatch

[surreality]

@faraday It is, yes. Thing is, Ghost is talking about using these features to make things accessible to players and the people creating for them. That's... not that.

This is the kind of thing that would put me off trying it, even if the end goal is what I have in mind. I am not a coder, but a lot of people have still come to me with even more basic knowledge in search of help, and they're the people who have an active interest in creating and running a game. We outnumber the coders (unfortunately). Making things accessible to us is a huge part of making things accessible to the players.

[Griatch]

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

@faraday It is, yes. Thing is, Ghost is talking about using these features to make things accessible to players and the people creating for them. That's... not that.

This is the kind of thing that would put me off trying it, even if the end goal is what I have in mind. I am not a coder, but a lot of people have still come to me with even more basic knowledge in search of help, and they're the people who have an active interest in creating and running a game. We outnumber the coders (unfortunately). Making things accessible to us is a huge part of making things accessible to the players.

Did you meant to address that to me, maybe? Edit: I missed that Faraday posted in between.

[surreality]

@Griatch Was in reply to faraday's comment, but is generally to the thread. Making things accessible to creators is typically a matter of translation, but it's pretty important. It happens with any specialized terminology, really.

[faraday]

@surreality Yeah but creators don't need to know every nitty gritty thing that goes on under the hood of the game server. Sometimes highly-technical questions require highly-technical answers. One can argue this thread isn't the right place for it, but somewhere at some point those types of conversations need to happen.

Both Evennia and Ares offer tutorials that describe what game creators need to know to make a game. That, it seems, is your primary concern and I agree 100% that it's important.

[surreality]

@faraday Yep, that's it in a nutshell. It's like military terminology, really -- at a certain point, the eyes cross and there's a fizzle-pop and a burning smell.

[Griatch]

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

@Griatch Was in reply to faraday's comment, but is generally to the thread. Making things accessible to creators is typically a matter of translation, but it's pretty important. It happens with any specialized terminology, really.

I hear what you are saying. Lowering the threshold is important. But don't forget that coders are not just blindly spewing out code for someone else either. Coders are "creators" too - we should not forget them nor decline to give them the tools they need as well. I personally want to have all the power of code at my fingertips when I create, thank you very much.

[surreality]

@Griatch I don't think anyone is blindly doing... anything, so I'm not sure where that impression comes from. It's specialized knowledge, which is kinda the antithesis of blind anything.

[Griatch]

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

@Griatch I don't think anyone is blindly doing... anything, so I'm not sure where that impression comes from. It's specialized knowledge, which is kinda the antithesis of blind anything.

Disregard the use of the word blind then, I didn't intend that as the important bit. I was just pointing out that in addressing "the needs for creators", we should not forget that coders are actually 'creators' as well.

[friarzen]

Correct me if I'm wrong but I think @ghost's point was more coming from the "I'm a builder and want to present the player with something that isn't +docrap/with-some crazy=bullshit_syntax"?

For example presenting an HTML table of the character sheet with +/- buttons next to values to create the character....

[surreality]

@Griatch I really don't think anyone has.

[Ghost]

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

Correct me if I'm wrong but I think @ghost's point was more coming from the "I'm a builder and want to present the player with something that isn't +docrap/with-some crazy=bullshit_syntax"?

For example presenting an HTML table of the character sheet with +/- buttons next to values to create the character....

^yes.

[Griatch]

@friarzen, @Ghost
The Evennia web-based chargen template is not nearly as snazzy or feature-ful as Ares' out of the box I imagine. But everything's there to expand on if one wants it.

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 ...

[faraday]

@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).

[Ghost]

I should also take a moment to say that while I still think the cultural aspects of the hobby must be focused on to attract (and keep) newer players, I also don't want to downplay the hard work that people have put into codebases, games, wikis, etc. It's all free web/unix development and it's not easy stuff.

So please don't think that I'm saying that it's all for naught. I think there has been a lot of evolution in the last few years, and I think it's been great for the veteran mushers. I'm just saying that I think it may be worthwhile to put heads together and plot out a future design for what the hobby could look like from a code perspective in the way the IAB or WWW Consortium have done.

I do see a possibility with some work that the format could have a bit of a renaissance, but it also may be important to understand where the hobby falls on the gaming-versus-writing description. It's a bit fuzzy, too, exactly what the hobby itself is given that the hobby is shared with automated bot-killing MUDs and heavy code-fixated MOOs.