Posts made by Griatch

@Thenomain

@Thenomain said in UX: It's time for The Talk:

@Groth

I would give my left...I don't know, sock...to get MCP, or even GMCP. I had completely forgotten about it. Let people build their own clients on a metadata standard.

We didn't go for MCP in Evennia, but we do have support for both GMCP, MSDP and MXP links (among other things). A client like Mudlet offers very extensive options for offering GUI-"themes" matching your particular game, using GMCP to handle interface updating and interaction.

GMCP has some decent docs these days, but for the longest time it was just defined by the biggest games that implemented it (like the IRE games). Not the best of situations, which is why we first added support for MSDP which has had a proper, central definition with standard messages for years and years.

In the case of our webclient, it's all JSON though.

@HelloProject That's awesome! Our current plan for expanding our web client gui is found here in our wiki if you hadn't seen it yet.
.
Griatch

Glad to see stuff being done in Evennia, good luck with your endeavours, and learning Python for those of you who are new to it (If you don't know a programming language it's really one of the easier general ones to learn imo).

I also encourage people to look at our tutorials. I think some of you are already there, but generally if you need tech help, don't be shy to drop a line to the forum/ML or to chat us up on IRC - our support channel tend to very active and friendly (as usual with IRC, you need to learn to hang around since people are in different time zones though).

If you have specific Evennia questions I usually notice if people address me here I, although it may be with some delay at times.
.
Griatch (Evennia lead dev)

I noticed I was mentioned, then realized that was a lot of pages ago...

I agree generally on there being opportunities to improve on UX in these games, but as usual it depends on the goal with your game. In Evennia's case we see people both from the Mud and Mush worlds (as well as some other sub genres). Some can't wait to replace Evennia's "mux-like" defaults for something they deem better in their view. Others instead complain that Evennia is not similar enough to their game of choice and do their damndest to reverse- port it.

Now, in Evennia's case the user can by default alias commands they don't like to something they prefer ( including remapping inputs, defaults etc), and store that with their player account. So at least in theory this allows users to make their ui experience more suitable to their tastes without coder intervention. Then again, the same is possible in most respectable clients so it's hardly revolutionary.

In the next Evennia version we are following Ares' lead and are allowing you to ignore prefixes you specify. So unless you explicitly create a command @desc, but call it just desc, then you could use @desc, +desc etc and it would all be identified as the same command. A small, but practical way to sidestep the legacy of those commands while retaining familiarity for the old hands (kudos to @faraday for the idea).

With the availability of web clients, I can't help but think we have only touched upon the possibilities with making awesome UI:s for this genre of games. Like @Ashen-Shugar I'm not primarily a front-end guy, but it's something I hope to explore further.
.
Griatch

@Reason Thanks, that's appreciated!
.
Griatch

Web play is the future for the medium overall IMO, not only because for catching new players but because of the abilities it offers you as the game runner to have a client you control, so to speak.
As for Evennia, we plan to gradually be expanding our default telnet-like HTML5 webclient. Our discussion for the new GUI is here for those interested.
.
Griatch

@Griatch said in What is out there? Hard and soft codebases of choice.:

Edit: But if with "passive condition" you mean something like "at the moment of entering bob, if this condition is True then get back this version of the command, otherwise this other version", then you need to do a little more work:

You could solve this by adding all your conditional commands to the cmdset and tell them not to merge but to remain separate (but same-named) in the set. You then plug in your own MULTIMATCH_ERROR handler. When you use "bob" you will then get multiple possible command-matches. The normal result on a multimatch is to give you a list of commands and let you pick the one you want to use (it may matter if you are using the "push" command on the red or blue button after all). But your multimatch handler could instead check the condition and run only the command the condition dictates.

A bit of a necro of this thread, but it struck me that that the dynamic changing of commands based on a condition is a lot easier in Evennia than I suggested above. The question was essentially "at the moment of entering bob, if this condition is True, get back this version of the bob command, otherwise get the other condition". The way to go is to use locks. Here we decide which bob command to use depending on if the caller has the Attribute "foo" or not:

from evennia import Command, CmdSet

class CmdBob1(Command):
    key = "bob"
    locks = "cmd: not attr(foo)"
    def func(self):
        # stuff this first bob command does

class CmdBob2(Command):
    key = "bob"
    locks = "cmd: attr(foo)"
    def func(self):
        # stuff this second bob command does

Explanation: Above we create two Evennia Commands, both keyed as "bob" but doing (supposedly) different things. Each also has a lock string. Locks is a mini-language in Evennia, where you call small python functions that always return True/False and combine their returns into the result of the lock. In this case the lock string is cmd:attr(foo) and cmd:not attr(foo) respectively. The cmd bit is the lock type. For a Command, if the cmd type lock is not passed, the entire Command is unavailable to the player at this time. The lock is using the attr(name) lock function. This is a predefined lock function that checks if the caller has an Attribute with the given name ("foo") at all. So in this case, if the "foo" Attribute is set, CmdBob1 will fail the lock and CmdBob2 will pass it and vice versa. You could of course define your own custom lock funcs like is_it_full_moon etc. It's a normal Python function you just tell Evennia to treat as a lock function.

... We now just need to add these two commands into their own cmdsets and add them both to whatever object should be able to use or supply the "bob" command(s). When you then enter "bob" on the input line you will get the result of either CmdBob1 or CmdBob2 depending on if you have the "foo" attribute set on yourself or not.

I added it as a Q&A hint to the Evennia tips and tricks section.

It's fun to see how implicitly colored this is by the common MUSH game style dominating musoapbox . In the MUD world, 10 000 rooms could be heard as being a "large" or even "medium" grid. For a game featuring a lot of single player/group content and exploration the number of rooms is important, especially if you can claim those rooms to be of good quality (which is certainly not always the case). Below 100 rooms is generally a very small grid in a MUD. Obviously in most MUDs there is also no concept of temporary rooms or scenes, so their use is often quite fundamentally different.
Not saying there is an advantage to having 1000s of rooms (personally I prefer small grids also in a MUD setting so people actually have a chance to meet). It depends on the kind of game you want and enjoy. Just noting that it's interesting how different the expectation is between the different MU* communities and game styles.

Has had a few sources of income in no particular order:

• Selling artwork
• Making book illustrations
• Some web dev stuff
• Theoretical astrophysicist (aka astronomer)
• Commissioned public lecturing
• Computer support
• Teaching in technical/natural sciences
• Senior Python developer in industry

Has a patreon up for Evennia and for art videos/tutorials too. I get a few cents (literally) from my youtube videos too I guess.
.
Griatch

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

Specifically, Evennia generates a lot of the documentation automatically for each command; in a lot of ways, this is great; you include the documentation in the command source code, and a helpfile is made for it. No worries about documentation being out-of-date; you edit the command, you edit the description RIGHT THERE. I wish more things supported this.

Thanks, the auto-help system is helped a lot by me myself always writing documentation whenever I write code - so me documenting my commands and then immediately converting that to an in-game help entry alleviates duplicate work. Many Evennia devs have taken up on this premise. While it doesn't write the docs for you, it at least makes it more likely that your code actually does what the help file says. It's certainly true that this may well lead to "dev-written help" though. While developer and staffer is often the same, that is something each Evennia game needs to consider.

But conversely, if you alias a command to another command then 'help' for both commands will give you the same help text; this leads to the home/+home, time/@time versus guards/@guards/+guards situation you describe. And additionally, since the coder is writing the documentation right there in the command, you... well, are getting coder-written documentation. Which (as a coder) I must admit is not always the ideal; sometimes you want an editing pass by someone who doesn't think in terms of code.

If you just alias one command to another (that is, create a command @alias with aliases +alias and alias), then they will get the same auto-help (since they are all actually just the same Command). My impression from the original question was however that there are multiple different Commands, each with a (slightly) different key - that means they are completely separate Commands and thus each get their own auto-help. How a game organizes their commands is up to them.

(That said, I object on general design principle to having command, +command, and @command do different things.)

Evennia itself is guilty of this in a few cases in its default command set (@desc/desc is the one that comes to mind), but our convention is that the @ is then the more capable builder-only version. This duplicity (in the default command set at least) is going away in Evennia 0.7 when we start allowing the developer to specify which prefixes (@, +, &, ...) Evennia will simply ignore (making @desc and desc effectively the same command even without an alias).
.
Griatch

For those that are interested and want to keep in touch with the Evennia MU* development system progress, we recently opened a new devel branch for features that will eventually be released as Evennia 0.7. You can check out the project progress page here for details. Some of the points are pretty technical but others (like the prefix-ignoring inspired by @faraday's Ares) may still be interesting to Evennia devs in general. Not the least because some of the todo-points will lead to API changes.
The devel branch is not considered stable yet and there is no time frame for its merger at this point. Normal bug fixes etc will keep happening in master for now.

In other news, Evennia recently increased its unit test coverage above 50%. Still a way to go and it may not be all that relevant to the average mu player, but it warms my developer heart.
.
Griatch

Update: People reported that my fix on the Evennia side resolved the issue with mudrammer. So we could close the issue and everyone lived happily ever after in the best of worlds.
.
Griatch

@mudrammer

if the server rejects a terminal type, the server can enumerate multiple ttypes in the client by requesting ttype again

Evennia does not reject the terminal type when it keeps asking for TTYPEs. It follows the Mud Terminal Type Standard, where the server keeps asking the client for information and makes use of the info. So it properly records the client name, the XTERM terminal type and that it supports ANSI.

In this case it looks to be a bug in Evennia though, since it should have seen "XTERM" and assumed that to mean xterm256 is ok. I think I have fixed the issue, as mentioned in the Evennia issue tracker but have no access to Mudrammer so will wait to close it until it's tested.

In general, you can enforce options with @option xterm256=True. Use @option/save xterm256=True to have Evennia enforce settings persistently. For some clients not using TTYPE/MTTS this may be the only way to support its capabilities since Evennia will default to ANSI colors if it knows nothing about the client (this seems to usually be ok in practice) but will not presume xterm256 is supported.
.
Griatch

@Alzie

Ah, I see. Not sure I necessarily agree with that as a general statement, but I can certainly imagine it could be confusing for the user if they don't know what is being done during the automated setup and are later expected to operate what was installed.
.
Griatch

@Alzie

If you have root you could of course always install everything system-wide if you wanted ... but apart from remembering to turn it on, why would you, as an experienced Python dev, say virtual environments only create suffering? Could you elaborate? What would you suggest instead?

In my view, virtualenv(py2+3) and venv(py3.3+) are simple and lightweight and very useful. I personally often create one for new Python projects to isolate them and to know exactly which dependencies they have. Users can be instructed to install to a virtualenv without worrying about what preexisting parts of their system they may affect. Having things in a virtualenv also allows to install and upgrade without requiring root with has helped me many a time on remote logins. It's also excellent for testing release packages and to help users with issues since you can quickly make sure you have a Python dev environment that matches theirs. As a dev, it's also extremely useful for python2 and python3 testing in parallel.

(For those reading and not knowing what we are talking about, virtualenvs are just quick little ways to install python packages of arbitrary versions without modifying system-wide default package versions. All gets installed to a folder anywhere you want (so you just delete that to get rid of the whole environment). Not to be confused with a virtual machine or anything complex like that, it's basically just temporary rerouthing of paths and system variables that takes no extra resources.)
.
Griatch

@Thenomain and others

Just a quick update that based on the feedback here I added a reference to the shorter "flat" API of Evennia to our API index. This is a set of shortcuts available directly from the evennia top-level import and contains most basic building blocks needed to do stuff. Showing this at the top of the API doc might be easier for a newcomer to digest than the full API (which remains further down the page). Check it out here.

Note however that API docs are always terse, focused and technical without wasting much space explaining the greater picture. New users remain recommended to get a feel for Evennia development by browsing the Developer Central and do the Tutorials.
.
Griatch

@omegared

User "jrsteensen" is working on an Eclipse phase game in Evennia too. Unless you are you the same fellow with another nick, you might want to compare notes - they are active in the #evennia IRC developer chat room at irc.freenode.net (the chat room also has a browser client, a discord bridge and a Mud bridge for those preferring that).
.
Griatch

@Bobotron said in Brilliant Breakthroughs and Impossible Projects:

@Griatch
There's a common piece of code on MU*s called 'places'. It's representative of locations in a room you can sit at as groups, like 'comfy couches that sit five' or 'corner booth that sits 4'. tabletalk is a command that emits to only the people at that location, like people stuffed into the booth having a private conversation, etc.

Ah, I see. I've seen that feature under different names in different codebases. So how is the place implemented in mush? Somwthing like a property on an object in the room and when you sit by it you get a flag on yourself that the tabletalk command then checks to know who to send to?

@Thenomain said in Brilliant Breakthroughs and Impossible Projects:

@skew said in Brilliant Breakthroughs and Impossible Projects:

@Thenomain said in Brilliant Breakthroughs and Impossible Projects:

@skew said in Brilliant Breakthroughs and Impossible Projects:

Has anyone hooked the basic pose/say commands?

Yes. That's how "posebreak" works.

Sorry, hooked the entire command, ignored it, and added those commands to the soft code.

Posebreak is just using before/after, not replacing.

I believe on Eldritch I wrote a function called 'say()' which would take the arguments 'say( <sayer>, <pose-structure> )' and do all the work of working out the spacing, which is half of what say/pose does. All tabletalk ('TT') code has to do this anyhow. The trick would then be assuring parsing is maintained which, now that I think about it, shouldn't be horrible. Input as 'noparse', just before outputting apply 'objeval( %#, <blah> )', and cross your fingers.

What does "table talk code" mean in this context?
.
Griatch

Evennia has something called inline functions which are functions provided by the game dev that an unprivileged user may embed in any return string. These functions will be evaluated anew for every recipient of the string. The system is intended for creating dynamic content and also supports nesting.

Here is an example; a time zone converter. First a simplified example of the python function (made outside the game by the dev in a module the inlinefunc system looks for such functions):

def mytime( timestring, timezone, session=None):
    # ... convert difference between session time zone and given time zone and return the converted time ...
    return converted_timestring

Here, we ignore error-checking/validation for clarity. The first two arguments to mytime are input by the user while session is added by Evennia for every session receiving a string in question.

A user may now embed mytime in any output string; for example ad I'm located in central Europe I could do something like this:

page Foo = Hi, so I'll be around at $mytime(14:00, GMT+1) tomorrow.

And user Foo, being on the US east coast (GMT-5 I think?) would see:

Griatch pages: Hi, so I'll be around at 08:00 (GMT-5) tomorrow.

I take it something like this is handled directly in softcode in mush bases.
.
Griatch