Best posts made by Griatch

@Cobaltasaurus

Ok thanks, interesting to hear.
.
Griatch

As for learning Python, I recently wrote a tutorial for people wanting to get their very first taste of Python through Evennia-examples only. You (should) only need a text editor and Evennia up and running to start. You can find it here: https://github.com/evennia/evennia/wiki/Python-basic-introduction

@RnMissionRun
I don't agree with this notion. Of course you can always make relevant comparisons. For someone like you who used mush and now is learning Evennia, just documenting the pitfalls and things you have to think differently about to progress would be useful to others.
.
Griatch

@eye8urcake said in Evscaperoom - a full playable multiplayer 'escape room' in Evennia with a layered story and multiple endings!:

@Griatch You've got a great mind for puzzles. That's the longest I've been able to focus in what feels like forever and I really felt like I'd accomplished something in solving this even though I had to eat through some of the pie for it to catch up to where I was stuck.

I am just super impressed and your locked room made my night. Three whole hours of it.

THANK YOU! And goodnight!

That's great to hear, glad you finished it and had a good time! It's also fun how everyone winning so far seems to be drawing different conclusions at the end ...

@magee101 said in A directory of MU*'s that's actually good:

How did a question about finding games turn into codespeak? Games guys, games!

Because the "codespeak" concerns how to make such a list of games available.

As for MSSP, this is of course a very MUD-centric invention so the original specification lists things the listing-websites were interested in listing at the time of its inception. Until there is a central site that looks/lists other tags (or just lists all tags you provide) there is little point in expanding it with custom tags even though that's of course possible (it's a very straight forward telnet extension).
Having the game call the listing site (like Ares/Evennia handles its games) rather than the other way around appears to be a saner way to do it (the issue then rather becomes one of (lack of) ownership of your entry. With the Evennia listing site we have, for example, not introduced any registration concept yet, this is something we'll probably have to look into as the number of entries grows (the listing-site code is of course open-source though, so if anyone wants to make their own, feel free).
.
Griatch

There you go, here's my entry for the contest: Evennia for MUSHers.
.
Griatch

As for the reliability of websockets, the main issues we've seen had been on the game runner side, when not setting it up correcty. But yes, some people do have firewall or browser issues occasionally.

In the Evennia case we use a two-pronged approach for this - if the web client's websocket connection fails or times out the web client transparently falls back to using old-style COMET long-polling. Haven't found any browsers having issues with that combination so far. Not sure if Penn has anything like that on the Server side, but it can all have the same API so you don't need to worry about which type of connection was actually negotiated in the end.
.
Griatch

@The-Sands

I would suggest that menus is actually a pretty good option when you have 'hundreds of possible stats' to choose from - they allow users to get a chance to explore themselves what to pick without having to refer to external documentation.

EvMenus are created in-code, which means that they can be dynamically generated from a list of stats rather than you having to maintain and update it separately. The EvMenu also comes with the list_node decorator to turn a menu node into a multi-page list of alphabetized (or whatever order you prefer) list of entries for the user to select between. Below it's only 10 (rather long) options per page, but you can set that as you like:

@fortydeuce said in Coming Soon: Arx, After the Reckoning:

@griatch Please drop me a PM when it's fixed, because paging foobartholicuses all over the place is something I mess up about 25% of the time (so lazy, and so my instinct is to shorten the name).

Edit: Caught the fix! A bit easier, but I can't use equals signs with that, which is also instinctive. Still would like to be able to p der=Test and page der=Test, because that's where my instinct goes.

Sure, it should work. As for fixing, when I get around to fixing it in Evennia it does not necessarily mean it'll be fixed in Arx immediately, you'll have to ask the Arx folks for that - Evennia is the underlying Engine Arx runs on, I have nothing directly to do with Arx per se.

Edit: Here is the new Evennia issue if you are interested.
.
Griatch

@faraday said in A new platform?:

@griatch said in A new platform?:

In the Evennia case we use a two-pronged approach for this - if the web client's websocket connection fails or times out the web client transparently falls back to using old-style COMET long-polling. Haven't found any browsers having issues with that combination so far

That's why you don't see issues - because you've fallen back to not using websockets when they fail and/or are unavailable. A purely websockets-based solution is not reliable.

Well yes, that's why I pointed out a way that has worked very reliably for us. I doubt a solution like that would be impossible to implement in Penn on the server level?
.
Griatch

Since people have asked me about it, the Evscaperoom can nowadays be played in the browser at https://demo.evennia.com or via telnet at demo.evennia.com port 4000. After you connect, just write evscaperoom in the first room to start!

Please read the help carefully, due to the restrictions of the format (read my dev blog above for more info), this does not play quite like a normal MU* does.

Plenty of people have tried (and seem to have enjoyed) this, both trying to solve the puzzles and trying to deduce what the heck is actually going on in that little village by the highway. It's really fun to see people use the multi-player aspect to join a room in pairs/groups to solve it together too!

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

@faraday Yeah, in my mind right now the best approach is to very strongly encourage mentoring and buddy approaches, since I've noticed far and away the people that become acclimated to the hobby and get most involved are the ones that have someone, anyone introducing them and talking them through it in a friendly, patient way. I think it's kind of addressing the symptoms more than the core problems but I think right now it's pretty much the best we got.

@Griatch One important thing that could be missed from my post is I was really only talking a very specific style of MUSH, and this is an important one to know when looking at the design requirements between MUD and MUSH. The MUSHes I'm talking about are ones that essentially have staff acting as personalized storytellers for players, with hands on, one on one development in a table-top type of feel. That just isn't something that scales unless you keep adding more tiers of staff overseeing story development. MUDs, on the other hand, scale essentially infinitely since the environment is automated and could theoretically handle any number of players.

I don't think there is anything stopping you from incorporating automated help systems and tutorials in an otherwise very GM-run game. You could even have a simple little bot echo a few cookie-cutter emotes to the new players (being clear it's a dumb bot) so as to give them a chance to test out how emoting works in a safe environment. That will still run into a limit when it comes to the plot and the storytelling where human GMs are needed. But with a little planning one could still do a lot automated work here, I think.

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

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

It spawned (and keep spawning) games that all feel the same. People patch DIKU with layer upon layer of hackish C code in order to make their games stand out from the baseline DIKU. It doesn't change the fact that the out-of-the-box nature of DIKU has made it a very, very successful engine.
Griatch

It also resulted in an endless wave of stock MUDs that people have been griping about for as long as I have been playing.

Don't I know it.

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

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

I think there are a lot of improvements that could be done here (certainly on the part of Evennia). But I also think that there is a limit to how much a game engine can help you ('you' in the general sense, not you in particular). We are not anywhere near said limit yet, mind you. But I don't think it's realistic for people to expect to be able to run a multiplayer MMO from scratch without having any technical skills or willingness to pick up such skills. "Just" being creative is all fine and dandy if you have someone else doing the coding, but if you are setting out to make a game on your own you must be expected to actually learn the craft, IMO.
.
Griatch

I think the willingness will usually be there if the barrier to entry is low enough. One thing that struck me recently is an informal poll of web developers that showed a pretty significant number of them got their start by modifying html in Neopets or similar games. The key there, to me, is "modifying" - adoption is far higher if they can easily find existing code and change it to produce a result rather than try to create something from scratch.

For example, in Evennia, you currently generate typeclasses that are stub child classes of Evennia's parent classes. You could do the same thing with commands, and have docstrings in the modules that either contain or link to tutorials on where to find the parent classes and how to modify/replace their code in the children in their game directories. Parent classes that are used by default when generating the gamedirs could also be based on prompted values during initial setup: based on their choices, you use one contrib or another. I'm a little ambivalent there: copy and pasting the code in its entirety would probably be easier on people than dealing with inheritance, but would also mean they'd get completely out of date from upstream changes in Evennia. Maybe explicit super() calls with comments that always explain what that means?

This is maybe getting a little bit too technical, but overall - yes, this is the conundrum we have faced since the dawn of Evennia: Are the default commands contribs or a part of core (they started out as contribs but moved to core since we update them so often)? Are they meant to be overridden like a typeclass or are they just placeholders that you are expected to replace wholesale? The issue with copying code straight up is, as you say, that you are throwing away all free upstream support you get from Evennia development. In contrast, the drawback of using an empty child class (or super() calls ... what a nightmare to maintain!) is that it doesn't really offer very much functionality over just copying just the stuff you need.

You are not the first one to point out that there are a few too many steps to adding a new command though; and there is some merit in that adding empty class templates might aid discovery some more.
.
Griatch

Interesting thread. Out of curiosity l looked into using Django with mediawiki and promptly found this: https://pypi.python.org/pypi/django-semantic-mediawiki/0.1 which is basically a direct integration of Django's (and thus Evennias) database with the mediawiki API. I've not tested it, but it might be an interesting project for an Evennia user interested in modifying and accessing wiki data directly from in-game (make a wiki page for your character and see it in-game, the wiki page updating as things happen to the char in-game ... auto-post logs, sync avatar images to show in the web client etc etc...)
.
Griatch

@tce said in Evscaperoom - a full playable multiplayer 'escape room' in Evennia with a layered story and multiple endings!:

Oh, hey. This reminds me of the quests from DragonMUD and gives me all kinds of nostalgia fuzzies

I never played DragonMUD but glad to hear this gives good vibes.
.
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 ...

@WTFE 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.:

An interesting observation. I've not heard the term "Kingdom of nouns design" before, would you mind elaborating what you refer to by that?

I won't elaborate on it. I'll let the guy who coined the phrase do it for me.

The way I interpret that is he doesn't think objects should make the work of functions. Which is not very relevant for Python that has no problem to support functional programming where it makes more sense. Evennia uses objects for example for Commands for a very specific reason - functions are too limited for the functionality of Commands. In other places (such as for creating menus or spawning mechanisms) we instead rely on functions because the complexity of an object is not needed.

I would need a more concise example of what you mean here to reply.

As for "explorability", I guess this comes down to what one is used to. Most previous Python users that interact with us seem to report that they find Evennia pretty easy to get to grips with, many being productive within a day of finding it and asking some basic questions. But it varies greatly and there is no denying that starting to use any new library will always be a hurdle. We can only do our best to make it easier. So if you have any ideas for how to make Evennia more "explorable" I'd be genuinely happy to hear them!

Well, item #1: the Evennia installation process is terrible. I mean utterly God-awful. When I finally got something that worked, I was never actually quite certain if I'd done it right or if I'd merely stumbled accidentally over a configuration that would work right up to the point it stops. Work on your installation process and please, PLEASE, PLEASE, PLEASE, MOTHERFUCKING PLEASE cut down on the number of "install this, then install this, then install this, then configure this, then do this, then do that" steps. An ideal setup process should involve one step: ./setup (or equivalent). You're not making enterprisey software here. Enterprise management are idiots and will tolerate things like Entrust's fifteen-stage (with three reboots!) installation process. Hobbyists ... not so much.

I'm sorry to hear you had issues with the install process. Which OS did you install on?
There is a briefer point-by-point summary up top but the main install text is indeed pretty lengthy. It's possible we can cut down on that; the text is explaining how to set up things also for those without any previous Python environment. It also helps to troubleshoot known issues . Assuming you start with a sane Python dev environment, installing consists of activating a python virtualenv (a standard practice for Python programs), cloning the evennia repo and then running pip install -e evennia.

While we will eventually also put the package on pypi (so you can get evennia with pip install evennia), using GIT will likely remain the most convenient way for developers to access Evennia since that gives easy access to the source for reference. For the same reason we can't really distribute a monolithic binary. It's great with feedback and critique though, thanks for that, we'll try to take it to heart to make things easier!

Item #2: There's very little that can be done in the environment itself. Yet doing things in the environment itself is the very essence of explorability. Everything in Evennia is done out of band. Compare and contrast with MUSHes (terrible as they are!) where any user can go in and start tinkering around with MUSHcode like this:

&FUN_ANSIFY me=foreach(me/fun_randansi,%0)
&FUN_RANDANSI me=ansi(+[randword([colors()])],%0)
&CMD_ANSIFY_CHAT me=$.ca *=*:@chat %0=[ufun(me/fun_ansify,%1)]
&CMD_ANSIFY_PAGE me=$.pa *=*:page %0=[ufun(me/fun_ansify,%1)]
&CMD_ANSIFY_TALK me=$.a *:say [ufun(me/fun_ansify,%0)]

I mean seriously, this is an incredibly crappy programming language ... but it's a programming language available to the end-user at point of usage. This fosters explorability.

Evennia does not allow unprivileged players access to programming tools out of the box, this is true (see also Evennia for MUSHers for some more elaboration on this). I can see the value of this argument if you want your players to explore coding as part of your game design. I'm not sure it's all that relevant for you downloading Evennia though? After all, you have all the exploratory tools available at your fingertips. You can explore and code to your heart's extent without any compilation and you will see the results of your work in-game immediately after just a @reload. And you can also experiment directly in-game by executing Python directly from the command line with @py.

In my youth BASIC was the gateway drug that led to an explosion of people learning to program. BASIC is a shit language, just like MUSHcode, but it was better than any of the alternatives available at the time because it was a shit language that was there in front of you. You typed at it and it gave you its (sometimes insane) response. It was BASIC and this explorability that led to where I am now almost casually doing R&D work in embedded systems. If I'd grown up in the Dark Ages of Exploration (the '90s and '00s) I'd never have gotten to where I am now.

BASIC was great on the Commodore 64 in the 80's (which is when I came into contact with it). And I can see the argument about having the code at hand if you want a game where unprivileged players can get creative with code. I cannot really relate to this notion (anymore) as a game developer though - the immediacy of the telnet just doesn't outweigh the advantages of a proper development environment (to me).
.
Griatch

http://evennia.blogspot.com/2021/01/happy-new-years-2021-evennia-things-to.html?m=1

A happy-new-years-blog post summing up some of the new things being worked on for the Python MU development system Evennia in 2021!

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

@Jennkryst to be clear, I will never make a for profit or fee based mush. Ever. I owned my own business for many years, it is a lot of work. I also though that process became aware of some of the more annoying things about private contracting, reporting online income, how my municipality and state expects the same to be collected, ect.

I also think staffing on a volunteer basis can be bad enough with people's entitlement and pressure, the last thing I want is some kid chasing me around screaming "I PAID my two dollars!!!"

I think the only sane payment solution for a hobby endeavor like this (at least for the sanity of the hobbyist) is something like Patreon - with an explicit notice that donations are completely optional and won't give the donor anything in return except the knowledge that they are supporting something they like.

@faraday

Evennia runs within about 40MB from the onset, but yeah, it will scale up considerably for a production game so you are probably right that the deluxe package is still too low in practice. Most users run on AWS or DigitalOcean or other on-demand services. As for the web port, sure it's rare for port 80 to be available on anything but your own self-hosted server so most often it runs on something higher. We default to port 8000.
.
Griatch

@Jaunt I like the concept of the command-less emote with @ in it. Is this just a random example idea or something you are actually planning/have made for Redshift?
.
Griatch
(who recently made a contrib emote system for Evennia but used the "emote" Command and didn't consider making it as a "no-match" system command. Cool idea!)

@Derp Offering a pointless "shiny" may be ok I guess. But the context of this question (in my mind) is avoiding getting to a point where donors get the expectations of "paying customers". As long as it's clear to both sides that donations are just that and are not making you a "paying customer" I think any payment solution is fine.

Otherwise I feel that you as a "hobbyist" are moving beyond it being just a hobby and need to correspondingly step up to the expectations of a paying customer base. If that's your goal, great, that means you just started a small business. If not, it's a line one should not cross without forethought.