@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

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

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

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

@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

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

3. Build web interfaces supported by code: By this I dont mean a web interface that connects people to the command line environment. Build web interfaces that never get to CLI. If you want the player base to evolve, then the hobby itself needs to evolve. Evennia and python are a good start, but ultimately the command line environment and clunky unix format needs to evolve. Move away from "commands" and do things like create an API interface that will take the arguments from the commands in easier web-based interfaces. THE CLOSEST YOU CAN GET TO A WEB PAGE THAT IS 90% TYPING AND SOME LOGGING, THE BETTER. To evolve, there are simply a number of things that need to be automated, and the things I've seen are a good start, but the constant return back to the command line (even if there is a web interface to connect to it) is rough. Mush clients. Etc. They're godsends compared to telnet back in the day for us, but not attractive compared to other formats out there.

You have some very good points in your post; let me single out this one, since it's the one that most closely relates to things I can affect.

The combination of "moving away from commands" and "A web page that is 90% typing and some logging", makes me guess that you are referring to some sort of natural-language input syntax. I can certainly see that for some things, like emotes.

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 would say that an input line that offers command suggestions as you start typing, including which arguments applies in the location as well as with a simple way to pop up a help tip, would go a long way towards discovery for a new player. A webclient could certainly offer that. In the same way, one can and should other conveniences from the chat-program world. Like seeing "..." when a player in the same room is typing, for example.

(More contributors are welcome ... alas I'm not personally as much of a web-dev as I am a server developer.)
.
Griatch

@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

@faraday Actually, I don't under-estimate the power of this - DIKU is by far the most commonly used server of all, probably mainly because it comes with a full game system - vanilla fantasy with classes and everything. 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.

(I'm not trying to compare Ares to Diku per se btw, just noting that I'm aware that providing a playable base game will help adoption). It's quite possible that you are right and that a highly opinionated server is a much faster way towards making people get going with your platform.
I picture Ares and Evennia in many ways cater to different user demographics though. I see Evennia catering to developers first hand. It's their job to in turn cater to players with the games they create. The stuff we add to the core library to help get them going is bonus stuff as far as I'm concerned.
I think (from what I understand) that your primary audience are game runners primarily and developers second. Which are perfectly fine and parallel approaches.
.
Griatch

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

This raises some interesting points. Are there ways to set up a world so that the players can impact and change it without GM intervention?

This game style is commonly referred to as a MUD
.
Griatch

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

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

This is an interesting point of view. Using the command line is generally an important skill to have when doing anything programming- related though.

That's the thing, though -- running a game, ideally, shouldn't require programming. It shouldn't require you to be a server admin. I can spin up a whole website in 10 minutes with Wix or Wordpress or whatever. I can set up a Discord voice chat server or forum or Storium game with a few clicks.

I've made Ares as easy as I can imagine given the tech requirements. You don't need to do any code to set up a game, but it still requires you to ssh onto a server and mess around with the command line occasionally. That is freaking intimidating to a large number of people, and it's an obstacle to having more games. Having (comparatively) few games, in turn, is an obstacle to having more people.

Ares is doing a good job here! It is able to do this by committing to a highly specialized game style and genre out of the box. It's important to separate a game administrator from a game developer I think. For those that have no programming knowledge, a pre-prepared game template is definitely going to lower the point of entry considerably. For those that do have the programming knowledge or willingness to learn it, they generally hate to have to tear down the pre-made stuff since they want to build their own thing anyway (this is really a matter of audience of course).

That said, we have wanted to have more pre-made template-games for Evennia for a long time. The Ainneve project was/is specifically aimed to that goal. Progress has unfortunately been a slow though

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

@faraday Power-upvote. There are lots of us who can't code a bit, but we might make badass games, for all the world knows, if we were just empowered to do it.

Empowering people to create is something every engine dev wants I think. Thing is, unless you want exactly the game mechanic as someone already did that you can then just add a world to, you will at some point have to get down to programming. All we can do is try to make that step easier, but the step will have to be made eventually.

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

There is an upper bound to how many people staff can invest their time in and entertain, and if they aren't doing this then there is not much difference between MUs and less arcane RP formats. Table top writ large can only be writ so large before people are constantly forgotten and left out.

Someone could advertise hard on all the younger demographic RP communities but there's only a point in doing that if you can support them, and take the time to help get them into the game. I mean the larger RP forums, chat room type places have tens of thousands of users and I'd guess maybe like a tenth of a percent have even ever heard of MUs, but if I threw down ads and had like, 100 people log in as guests to ask questions on how to MU, there's no way I could support that.

It's a good point, a huge influx of newbies need to be properly handled to actually make the best of the new influx. That's where tutorials and easier entry goes a long way, limiting the amount of personal instruction is needed.
(having too many new players is a bit of a luxury problem anyway of course).

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

I have a few things on my wishlist for the far off future.

I would love is to have something sort of similar to django-cookiecutter but for game templates out of the box, but even more accessible than that: some sort of wizard where someone who has absolutely no programming experience could enter a bunch of values to customize a game experience out of the box. Ideally we'd configure their settings file for them, then apply some fixture or database seed values for a game genre, and then the rest is up to them. For example, selecting 'medieval fantasy game' might add a 'contribs.fantasy_template' to INSTALLED_APPS which would more or less be what Ainneve is supposed to be, automatically adding relevant commands, etc.

I think the biggest hurdles coming into this hobby are getting started as a game-runner and getting past the text-based interface for a player. Ares is making great strides with both areas. I think it's unfortunately very rare for most people who want to make a game to have both boundless motivation to do both heavy lifting of creative writing work and want to tinker with deployment/configuration/coding on the technical side. Anything that makes either area easier probably would increase adoption proportionally to how painless they are, imo.

Yes, I agree something cookiecutter-like would be great to have for various genres so as to make it faster to get started with a game structure. Ainneve is a step in that direction, albeit slowly moving.

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

Double-posting here, sorry.

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

I love Ares, but I don't want to forget my love of Evennia either. There's something that feels more like 'game' there, and it's pretty slick and modernized too. I've thought that Ares comes off as more of a collaborative writing tool for RP and Evennia comes off as an RP-centric game.

You know this of course, but just to be clear Evennia (nor Ares) is not itself a 'game'. Evennia is a system for creating multiplayer text games and in this it's probably a little more general than Ares (which focuses, at least out of the box, on a specific game genre). Many use Evennia for making RP-heavy games, but quite a few also work to create more twitchy and reflex-based text games.

Both of these approaches are awesome and valid, and both can be spawned up easily and functionally in-browser. I feel lucky to have both any time I'm forced to fire up a client program (gross, how 90s).

Having a webclient is a requirement these days; we just need to keep spiffing it up so as to be a true contender to a stand-alone client - and then go beyond ... somehow.

The sort of places we've applied our collective experience over years and decades evolving ideas together to build. Maybe we can do the same thing and put our heads together to come up with game settings that would work and appeal to fresh meat -- get them in the door and twitching our webs.

I'm not sure a single killer-game is something realistic to achieve, at least not one decided on-by-committe. But I do think that breaking out of the legacy command syntaxes, making sure to always have proper tutorials and offering more quality-of-life features specifically aimed at newbs would go a long way, regardless of genre. Maybe one could make a framework for this that people could easily plug in and fill with their game-specific info. It's something I could probably add to (in my case) Evennia with relative ease, coming to think of it.
.
Griatch

This is an interesting thread. I'm personally of the opinion that there's a huge potential user-base out there that would be interested in some variation of shared text- based multiplayer world for their RP needs. There is also a community of visually- impaired players out there that are specifically interested in those games.

A powerful (and accessible) web presence/client is likely the minimum requirement, but things like marketing would also be important - which brings up the general lack of money in this hobby as a limiter, of course.

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

@gryphter I've been trying to poke at Evennia, but as soon as it asks me to do something with windows command lines I burst into uncontrollable tears, so.

This is an interesting point of view. Using the command line is generally an important skill to have when doing anything programming- related though.
... That said, the Windows default command line is admittedly awful. If you are on Windows10, it's really better to use the Linux subsystem for Windows, which supposedly has a sane terminal and gives you access to Linux functionality and convenience.

Anyway, if you need help to get started, drop into the Evennia dev chat on IRC or Discord, we are happy to talk you through getting set up and beyond.
.
Griatch

@Sparks said in Evennia 0.9 released:

@Griatch said in Evennia 0.9 released:

The player-options have been partially converted to use a generic format with
validation. This is specifically used for styling information, and allow e.g.
a player to specify how EvTables are displayed to them (like changing the
colors and symbols used). (PR by Volund).

Oh thank the lord; this means in my little custom core I've been writing for future projects, I can kill off my @display command; that was meant to let you set all your UI preferences (header/footer colors for all output, EvTable styling, etc.) One less thing in the core, one more thing in the base and globally used... that's a win. Remind me to thank Volund later.

This still needs more docs. But it's there.

(Though the idea of converting all of Arx's codebase from Evennia 0.7/Python 2.7 to Evennia 0.9/Python 3.7 gives me a mild feeling of existential terror.)

Friarzen already made a draft PR for this process for Arx. So hopefully it should not be too horrible.
.
Griatch

Evennia 0.9 - June 2019

As of today, version 0.9 of Evennia, the Python MU-creation system is out!

Jump to the bottom of this post to see upgrade/install instructions.

This is a rather big release that marks a few important milestones. See
the changelog
for more details.

We drop support for Python2. Evennia now requires at least Python 3.7

This has been a long time coming. Python2 reaches the end of its upstream
support at the end of this year. This means that existing game code needs to
convert to use Python3.7 as well. For most users, this should hopefully not
be more than an afternoon's work.

As part of this, we also updated our dependecy versions to match. We are now
also using the more modern and well-supported Autobahn for webclient support
(removing the old tmwx library).

A new webclient UI, using the golden-layout library

This makes for a much slicker and faster webclient UI. It allows tabs as well
as click-and-drag of panes. A player can now drag and re-arrange window panes
as desired, assigning message-types to each pane (like having 'look' output in
one window and tells in another etc).

The webclient can also now have any number of input panes, organized and placed
anywhere on the screen (or tabbed). Each input pane has its own separate
history.

Support for Grapevine

Grapevine is a inter-MUD chat network (https://grapevine.haus). In the same
vein as for IRC, Grapevine channels can be linked to Evennia in-game channels
and allow for players to communicate between MUDs.

The Evennia Game Index now a part of Core

The client for the Evennia Game Index (originally created by Greg Taylor) was
moved from being a contrib to being a part of the core. This means it's
configured not as a server plugin anymore (remove this from the
mygame/server/conf/server_services_plugins.py if you used it before)

The new evennia connections wizard will help to set up your game for the game
index. For now, that's all the wizard does, maybe it will be expanded in the
future.

We have also changed the policy a little for the index. You may now list your
game even if you are not allowing any external players on it yet - just leave
your telnet/webclient links empty. This allows for very early concept games to
tell us they exist and potentially make us excited about what to come!

No more @ in default command names

We have now dropped the @-prefix from all default commands. So @dig is now
written as dig in help files etc. Evennia will however ignore several common
prefixes by default, so you can still write @dig (or +dig) if you prefer.
And if you explicitly give your command a key starting with @, it will still
be required, same as now.

Django standard initiative

User strikaco has made a series of contributions to make it easier to link
Evennia typeclasses to Django forms and generic/admin views. This makes it
easier to build and extend functionality to access resources from a future
website.

Several utilities that before were located in default Commands (like creating
a new character or verifying a password) is now found as helper methods on
the base typeclasses.

Signal handlers

A series of new Django signals now fire for various important event:
Puppet/Unpuppet, Object create/rename, Login/Logout, Login fails, Account
create/rename etc. This allows code to plug into the server from anywhere
in situations where overriding hooks would be less cumbersome. (PRs by Volund).

Global Scripts

One can now specify (in settings) global scripts that should always be available. These can
always be found as properties on the evennia.GLOBAL_SCRIPTS container. (PR by
Volund).

Generic Player Options

The player-options have been partially converted to use a generic format with
validation. This is specifically used for styling information, and allow e.g.
a player to specify how EvTables are displayed to them (like changing the
colors and symbols used). (PR by Volund).

As part of this, Commands have new helper methods client_width and
styled_table/header/separator/footer for producing various text decorators
that are then aware of whatever options the user has set.

Interactive decorator

The new @interactive decorator makes it easier to do asynchronous programming
without needing to use Twisted deferreds and Callbacks. Here is an example:

from evennia.utils import interactive

@interactive
def myfunc(caller): 
    caller.msg("First message")
    yield(5)
    caller.msg("Five seconds later")

    resp = yield("Write something")
    caller.msg(f"You wrote '{resp}'")

This will will echo a text, wait 5 seconds, echo something else and then ask
the user for input. All asynchronously without affecing other players. This was
always possible using call_async, but this style should be easier to read.

Evscaperoom engine

Evscaperoom is a full puzzle engine for making multiplayer 'escape rooms' in
Evennia. This is the engine I created for my entry to the MUD-Coder's Guild
2019 Game Jam.

Other

• Spawner was updated
• Simplified Chinese translations (by MaxAlex).
• Lots of Bug fixes

More detailed info is found in the CHANGELOG.md file.

Install / Upgrading

You need to install Python3.7 for your system.

If you are installing from scratch

Once you have Python3.7, use the Getting Started Instructions in the wiki.

Updating an existing game

Make sure to stop Evennia completely (evennia stop) before you pull the
latest Evennia version (once Evennia is updated to Py3, the old code will
fail to stop, if so, manually kill the twistd processes on your machine).

To be extra safe, make sure to make a copy of your entire game dir.

If you use a virtualenv (highly recommended), you need to create a new one
with Python3.7. Deactivate the old one and delete (or rename) the old evenv
virtualenv folder. Then install Evennia in it with as usual with

pip install -e evennia

You should see Evennia 0.9 being installed along with py3 versions of all
dependencies.

Most likely you'll need to modify your game dir to change the old Py2 code to
Py3. You can try using the 2to3 program:

pip install 2to3

This should make the 2to3 command directly available in your terminal (make sure
to backup your game dir first!)

cd mygame
2to3 .

This will go through your game dir and modify the code to be compatible with
python3. This should handle most differences but you may still need to look
carefully at the changes to make sure it does what you expect. The most common
things a regular Evennia dev will need to change are:

• print txt must now be written as print(txt). The 2to3 should handle
  all of these.
• mydict.items(), .values() and .keys() now return generators rather
  than listsk. The 2to3 program will likely wrap these in list() to mimic
  the old behavior. This works, but you should consider removing these if you
  are only iterating over the result, having a generator is faster for that.

When you are satisfied, try

evennia migrate

If this fails, you may need to fix some other Py3 conversion. You can find more
info here: https://docs.python.org/3/howto/pyporting.html Continue until the
migrations pass. Once they do, try evennia start --log and make sure the server
starts fully and that the game works correctly.

What now?

Now begins a period of bug fixing in the master (0.9) branch. If you like
bleeding edge and used to follow the develop branch, you are best off
switching to master right now since that will be the most updated one for a
while.

If you find any issues, report them to the issue tracker https://github.com/evennia/evennia/issues.

Most of the docs have been updated, but there is no doubt going to be some
things still lagging behind or things not yet properly documented. Please
report/fix that when you come upon it.

Enjoy!
Griatch

Digital Ocean is indeed a good choice. I set up a droplet to run Evennia with my Evsvaperoom game the other day and it was a breeze. I should write a tutorial for it one of those days ...

As for servers, others have said it well already (your choice depends on what you want and your coding chops). I just want to point out that while Evennia is indeed a Mu* creation toolkit of sorts, and the core is deliberately 'bare', there are a lot of contribs to play with and build on these days. So you don't need to do many things fully from scratch unless you really want to. But there is also no denying that if you have no desire for any coding at all, Evennia is not the server/codebase for you.
.
Griatch

Looks like Evscaperoom won the game jam! Woo!
Not a huge field of competitors, alas, but still.

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

Having had someone just burst into a room a friend and I were working through and immediately eat a slice of pie, broadcasting the hint to the whole room -

Please give us an option to make private rooms that other people can't join in future things like this.

Heh, that must be a pretty rare thing to happen, but I understand it's frustrating if you were trying to solve it 'blind' (can't unsee the hint after all). This is a one-month game-jam project though, so won't be adding more features right now (still two days left to vote if you like it!). But thanks for the suggestion, I'll keep it in mind for the future!

Overall, loving it, we're just going to back out and get back to where we were later.

Glad you enjoy it! I've found that people have a lot of fun solving this together, having someone to bounce ideas off is just that little bit more enjoyable.
.
Griatch

https://evennia.blogspot.com/2019/05/creating-evscaperoom-part-2.html

This is the second part of my two-part post-mortem dev blog about making the Evscaperoom. This one focuses more on the technical aspects.