Best posts made by Griatch

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

@surreality

I think -- and I could be entirely wrong -- what @Thenomain is trying to say is that once you install the MUX server, you essentially type one startup command and you have what you need to begin creating a play space on the creative front.

You have the four types of objects in place -- Player, Room, Exit, and Thing -- as well as basic communication commands.

Technically speaking, if your goal was to create a very basic, statless game, you already have more or less everything you need in place to start creating your grid/playspace by just adding and describing rooms, which is as simple as: [...]

This particular example is not making MUSH/MUX any different from any other codebase out there. Even the command examples you give work the same out of the box in Evennia.

Is this in the game, or from outside of it, though?

Are all of the interplayer communication commands already established? (Say, pose, page, whisper, emit, etc.? -- I'm asking because I don't know.) This stuff is pretty big, really.

Yes, it's in the game, out of the box. Evennia is basically a "talker" by default. It comes with about 90 default commands related to server management, building and social play. They can all be modified and replaced (outside the game). What we don't offer in core are very game-specific things, with the notion that this will be dependent on the type of game you want to do and easy to add if you know your players will expect it.

Here is the list of default commands:
https://github.com/evennia/evennia/wiki/Default Command Help
Here is the starting building tutorial:
https://github.com/evennia/evennia/wiki/Building Quickstart

I would also point to the "Evennia for Mushers" article I wrote here on Musoapbox. It's linked earlier in this thread.

You can also go to http://demo.evennia.com (telnet: silvren.com port 4280) to see an almost-vanilla install in action.
.
Griatch

@HelloProject said:

And rather than paying for server space, you simply hosted the server on your own computer.

I would think this is possible with any game server though - if you accept the electricity bill and has the Internet connection for it?
.
Griatch

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

Well, I put the Arx one on @Tehom more than @Griatch.

@Tehom has really done a great job with Arx. He's not needed much help from the Evennia community at all; he mostly contributes stuff to us upstream and now and then pops in to report any weird Evennia errors he finds in the process of running Arx.

Evennia is still super intimidating (I love it in concept and if I was good with Python I've got like, 3 different ideas for the codebase ... but I am not remotely strong enough a coder to even begin).

I understand this is your perspective of it (which is fair). Any new code/language/system can be intimidating when coming to them fresh, especially if having little or no programming background.

However, those using Evennia appears to overall find it a pretty easy system to use. Yes really. I can't really say more than "appears", since I'm a bit too close to it to make definite claims like that. It would be interesting if some third party actually using Evennia for real could make a review of it on here to show the developer's perspective for once.

Yes, tech is important. Yes, it can help get new blood.
But these solutions are still geared towards 'people already here.' (aka someone brand new who has never heard of MUing is highly unlikely to grab Evennia and build a game)

You'd be surprised. People start game projects for all sorts of reasons, and a text-based game world (even multiplayer, woah!) is actually a very tempting self-learning project for getting into programming/game-dev/IT/whatever. If those devs actually end up contributing something worthwhile to the community is another matter of course. But they do come.

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

This is a very important point. For all the "bridging power" of mushcode, how many can actually use it to the level of, you know, creating a new game from scratch? I am not familiar enough with the MUSH community to know this number, but I suspect that it's not a large number.

You'd be surprised.

I know several people just within my one tiny subset of MUs that could get a game up-and-running themselves quickly. Partially, this is because installing MU (as has been noted) is generally super easy, especially if you go to a MU* host, where they give you a working environment and all you have to do is upload, extract, and start your MUSH.

That is great and a good boon. It's not what I asked though (or intended to ask). Just starting a server is one thing. The question was how many can then build a full game in mushcode off what the server offers with that download. Maybe the better question would be how many @Thenomain 's and @Volund 's are around these days? It''s not a retorical question - it would be interesting to know.

I think everyone acknowledges that MU is archaic, but it's also got a very low barrier to entry, and that's what Evennia lacks for me.

What interests me is how big a part of that "low barrier" is due to familiarity and how much this colors perceptions and comparisons. Because, as someone who has used lisp but is not a mush user, the mush softcode system is one heck of a barrier.
.
Griatch

@Jaunt

Some sort of notification notice/update on the OR address about what is happening would be useful whenever technically possible.
.
Griatch

@faraday Yes, coding a full game in any language and framework will always take a lot of work. To learn programming means both learning a language and a mindset.

It doesn't change the fact that Ruby/Python are some of the best beginner languages around. I stand by my opinion that for being programming languages they are outright easy to learn and get started in. Does that mean that it takes no effort at all? Of course not. But even minute knowledge in either will help you tremendously and is a worthwhile thing to spend time on.

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

Could you elaborate more on what you refer to by the "web template interface" here?

We were just talking about web UIs for MUSHes. I mentioned my painful experiments with Ares' web UI, we both sort of said "I wonder how Evennia does it" and went on a scavenger hunt through the code and docs before finally finding this.

Now I know that nothing in Evennia is stamped "for professionals only" but there's HTML and Javascript stuff, python stuff, Django templates, plus a separate web client and web server, plus SQL... you gotta kinda admit it's a lot to learn, yeah?

Just to explain what you are seeing - that page contains HTML with Django template markers, like {% ... %}. Those are used for "importing" other HTML pages and to populate the page with the contents of game variables like number of players etc without the need for embedded Javascript.

If you want to create a website, yes you'll need to know HTML and CSS, most likely with some Javascript thrown in. Do you have to know these to be proficient with Evennia though? No; it's all set up to run for you. There is no need to learn SQL (that's after all one big point of Django) nor how to handle a web server apart from opening the right ports. If you wanted to customize the Javascript client code then yes you'd obviously need to know Javascript, but we are aiming to make this more pluggable so you don't have to but can structure the interface more graphically (that's in the future though).

Is it a lot of stuff to learn? If you wanted to tweak and master everything we have already created, yes certainly. You don't have to though, certainly not for replicating a traditional MU*.

Allow me to update @Thenomain's list of "things". The list of things you need to know to be a beginner Evennia user is, IMO, as follows:

• To install you need to know how to install packages / dependencies in your OS of choice. You also need to know to use a terminal line / console.
• You need to be able to blindly ape one command of GIT (to clone Evennia).
• You need to know to activate the virtualenv to get access to the evennia command before you do anything.
• Basic Python. That is, the ability to write syntactically sound Python and be able to read example code with classes, functions and variables. Know how to import things from other modules and what a traceback is ... those kinds of things.
• You need to know how to use a text editor and how to switch between windows in your OS. For seeing the results in-game you need a web browser or telnet client of your choice.

With this you will be able to pick your way through most of the beginner code tutorials with your locally-running Evennia, including creating your own commands, new object types and creating a small mini-game with placeholder game mechanics. You'll be learning how to interact with the Evennia API along the way. No Django knowledge is required, no SQL is (ever) used.

It will not be an immediate success. You will make errors, you will not understand why things don't work, you will miss those indents that Python requires. Evennia will complain and spit out tracebacks left and right at the weird stuff you throw at it. You will (hopefully) ask for help and get it. But eventually you will have a feel for what goes where and how things connect.

... Then you may want to learn some few lines of Django to build database queries not covered by Evennia's normal search routines. You may want to put your code under version control if you want to collaborate on a code base. You may want to take your game online. Maybe tweak some HTML to make your game home page prettier. At some point it's your ambitions and game-goals that define what you want to go and learn next.
.
Griatch

A graphical overview of the Evennia system, for those interested: http://evennia.blogspot.se/2016/05/evennia-in-pictures.html
.
Griatch

@phase-face

Whereas you ask some good specific questions about design, I would like to be a little more generic and add that the main thing for any hobby project is to get to something playable before your determination runs out or your hard drive crashes.

In a hobby/free-time-driven game development process, 99.99% of good ideas never lead to a game people can actually play. People in this thread have good specific advice - you should heed those you like. But I'd suggest not covering all bases immediately - planning is fine but you need to eventually do something, create something you can show off. A sort of save-point you can continue from should the unforeseen happen and you have to take a break from your project.

Keep your grand plans in mind but strip most of them away for your first version - you will often find even 'must-have' features are not so must-have once you realize other things are not yet in place. The 'perpetual beta' is a tried and true concept for a reason; not assuming (indeed knowing) that your first few versions will be incomplete and imperfect can be quite liberating and allow you to get something out sooner.

Ah, ok. So I'll give two possible ways to do this; first the in-command "head-on" way and then using cmdsets.

Head on way - command with ifs

This means simply that we create the command Bob and have it check if we are in the given time slot or not. Since presumably the Wolf race has unique features (code-wise) we assume it's created as a separate Python class (let's say its path is typeclasses.wolves.Wolf). If Wolves were, say, just members of some biker gang (so human like other humans, code-wise) we could have instead just used a Tag to tag them as "Wolf" to identify them.

# in a module, say, "commands.bob.py"
from evennia import Command
from evennia.utils import gametime

def check_full_moon():
    # let's assume every 30 days in game-time is a full moon
    # I can't be bothered doing the logics for limiting it to 0-3AM but
    # it would happen here.
    return (gametime.gametime() * 3600 * 24) % 30 == 0

class CmdBob(Command):
    key = "bob"
    def func(self):
        if self.caller.is_typeclass("typeclasses.characters.Wolf") and self.caller.check_full_moon():
            # do Wolf stuff 
        else:
            # do non-Wolf stuff

Next just add Bob to the Character Command set, which all characters start out having. Again, most of the code was already filled out by Evennia from the start, so one plugs in the command where indicated.

from commands import bob
class CharacterCmdSet(CmdSet):
    # [...]
    def at_cmdset_creation(self):
        # [...]
        self.add(bob.CmdBob())

After a @reload the "bob" command is available and will behave differently for wolves. Now this is straight-forward and may well be enough for your needs. It has some maintenance problems though. Say you have other classes like Druid, Fae and Moon dragon that all have special things happen during a full moon. You now have to expand CmdBob to account for all those. What if it's not just bob, but a whole slew of commands that should change like this? You would need to update them all. So far it's certainly doable. But then what happens if Wolves lose their special Bob when someone casts a spell or hits them with silver? You would then have to expand on your if statements. To be clear - this may well be ok for your game. But it may also be easy to forget to update a particular condition and the code could become hard to read and maintain.

CmdSet way

This will instead implement two versions of the Bob command, the normal one and the Wolf one.

# in a module, say, "commands.bob.py"
from evennia import Command, CmdSet
class CmdBob(Command):
    key = "bob"
   def func(self):
       # do normal bob stuff
        
class CmdBobWolf(Command):
     key = "bob"
     def func(self):
         # do wolf-bob stuff

 class CmdSetWolf(CmdSet):
     def at_cmdset_creation(self):
         self.add(CmdBobWolf())

Note that if CmdBobWolf shared a lot of features with the normal CmdBob we could have inherited from it and just replaced some things. We also create a new cmdset CmdSetWolf only holding this single command (for now). We add the normal CmdBob to the CharacterCmdSet as shown earlier.

Next we will use a Script to track time. A Script is a sort of virtual object that has no existence in-game. It can store data etc like an in-game object but also has an in-built timer.

from evennia import Script
from typeclasses.wolves import Wolf 
from commands import bob
class  MoonScript(Script):
    key = "moonscript"
    interval = 60 * 60  # calls self.at_repeat every hour
    persistent = True # will survive a shutdown
    self.db.is_full_moon = False

    def at_repeat(self):
         # fires every self.interval seconds
         if check_full_moon():                
            if not self.db.is_full_moon:
                self.db.is_full_moon = True
                # find all wolves and let the wolf-bob cmdset merge onto
                # the existing one. All this will do is to change how "bob" works.
                for wolf in Wolf.objects.all():
                    wolf.cmdset.add(bob.CmdSetWolf)
        elif self.db.is_full_moon:
            # the full moon passed.
            self.db.is_full_moon = False
            for wolf in Wolf.objects.all():
                wolf.cmdset.remove(bob.CmdSetWolf)

So what the Script does is that it will check every hour if there is a full moon, and if so add the CmdSetWolf to all wolves in the game. When the check fails it removes it again, restoring the default "bob" command. In a real game you will probably let your Weather or Calendar script do this job, alongside announcing to the world that the full moon has risen.

Using cmdsets rather than if statements in one command has the advantage of containment: You could store everything wolf-related in one place, in relative isolation from others. Sure, there may be details that still require some if checks but by replacing the entire command you could plug in the command in new situations without changing of the command code.

So if a Druid casts a spell on the Wolf, all you now need to do is to call wolf.cmdset.remove(bob.CmdSetWolf) on the wolf to have it loose all its moon-given powers at once. Importantly, if the wolf meanwhile has sipped a magical potion having it gain the AwesomeFlyingCmdSet (giving say the "fly" and "leap" commands), removing the CmdSetWolf will only remove that cmdset. The normal "bob" command will be used but "fly" and "leap" will remain until the Druid uses their next spell ...

This also exposes a limit with the CommandSet system - you operate on Cmdsets, not on individual Commands (one Command could go into many different cmdsets). So if you have many commands in CmdSetWolf but only wanted to remove one of them, you'd be out of luck. For that level of precision you'd either have to fall back to doing if-checks in the command, use cmdsets with one Command each or overload the cmdset anew with the changed command structure.
.
Griatch

@Shincashay As a side project, I was at one time working on a contrib for Evennia that implements what is summarized in the Evennia for tabletop RPGs tutorial and then some. What I had in mind was the ability for a GM (or group of GMs) to announce stories for a limited number of players signed up for their particular game using a lobby-like setup. I pictured this literally as a way for people to run text-based tabletop systems for others rather than something MUSH-like though.

The project stalled since I work on finishing Evennia 0.8. But it's an interesting project I might pick up again some time. So if you have any technical questions concerning implementing your storyteller playground I'm happy to help trying to answer them!
.
Griatch

@Bobotron said:

Volund was on MUSH earlier today talking about converting, straight over, a Penn DB into Python. He didn't seem to be having immediate luck, but there you go.

I believe he succeeded with that now.
.
Griatch

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

As for merge conflicts - absolutely those can happen. But I think by making it pluggable you're just trading one kind of headache for another. For starters, it's more complexity for the designer to worry about. Also, if someone makes a custom version of the Bob command and you make an upstream change to the core Bob command, then they've got a philosophical merge conflict whether they've modified BobCmd or overridden it with MyBobCmd. Editing in place allows you to use the built-in git merge tools to resolve trivial conflicts automatically, and gives you help in resolving more complex ones.

Sure, I can see both points of that argument. I can certainly see a nice hacking potential your way (in a good way). The thing with the "philosophical" merge conflict is however that if there are things that don't work you can always revert to "vanilla" Evennia to figure out if the problem you are having is in your code or not. Likewise, since we offer (defacto) user help and support, it helps a lot to be able to say "I'm using the same Evennia version you are and I can't reproduce your problem" - and be sure of the boundaries between upstream and custom code.

Also we've got different user bases. A lot of my target audience won't be modifying the commands at all (since they're using Ares because they lack a coder) or just won't bother upgrading. So it's quite possible that your strategy works best for Evennia. It's a question of tradeoffs.

Certainly. Ares (from what I gather) uses a command syntax that your user base already knows and expects and may not be likely to change as you say. If you don't expect heavy customization of your command structure or syntax there is little need to cater for it.
.
Griatch

@kumakun said in Potential Supernatural Game:

@faraday Nice! Ares is in Ruby right? I've always been curious about language. I'm leaning towards Evennia, because Python! but I'd /really/ like to work with Python 3+

Ruby and Python are pretty similar conceptually; each has their ups and downs, strengths and weaknesses.

Evennia is currently using Python 2. Next version of Evennia (0.8) which is soon coming out will be the last one to use that. Evennia 0.9 will use Python 3. But to be honest - I use Python 3 daily in a professional capacity and it's not like it's a big fundamental difference to switch between the Python versions.
.
Griatch

@Thenomain said:

@Ide said:

Given that some experienced softcoders write softcode offline and formatted anyway, the difference between mu* softcode and Evennia Python is a little fuzzy.

It's no guarantee that the content creators of a game have access to the server for uploading their creations. To try and make my point, I focus on the "builder" level of coding: setting up rooms, locks, descriptions, more locks, day/night ambiance effects, setting up places, views, and so forth.

A lot of the time builders are interacting with softcode and don't realize it; it's for this reason that I believe that Griatch is making the distinction between "main game development" (mostly what I do these days) and "in-game building" (and toy-making).

But let's face it, a lot of the cool Mush tricks that we've done over the years are because we didn't need server-level access to try new things. I built a repeat-until loop using nothing more than @trigger and @if and if you don't think that's fun then you're probably sane, but I didn't need to beg for server space or access to make increasingly complex and fun toys. If I did, then I probably wouldn't've bothered.

I'm answering these posts in a bit of a wrong order, sorry about that.

In short - yes you are correct here: If you are used to games where the normal player can do cool programming in softcode without any input from staff, then Evennia will not appease your needs, at least not out of the box: we are currently not offering safe program-flow structures on the in-game command line (Also, before anyone asks, alas you can't safely use Python itself to fill this role - this is the cost we pay for Python's awesome introspection and flexibility - it is not designed to be programmed by untrusted programmers ... which, from the perspective of the server-owner, every player is. Hence our in-game @py command can and should only be made available to superusers.).

Our suggested solution is for the coder to provide the builder with sophisticated build commands - and with the full access to the entire Python library in the wild you can make those very powerful if you want. But that said - if people want to they could of course also build their own softcode-like mini-language in Python and offer that; our Command system could support it without any modification. So far no MUSH developer working with Evennia has expressed any such desire but maybe that's coming.

As a side note, I should point out that "server level access" is not what it once was. Modern version control systems usually don't require code contributors to have any access to the running server whatsoever. Contributors can just push their code to the repository (which may sit on a free, private repo on say, bitbucket) and make a push request. The server owner can review this and pull down and merge (or not) as they see fit. There is no security issues here (as long as you check the code) and no reason to limit who may offer input. This workflow is definitely not as "direct" as in-game softcode and more relevant to bigger code development and staff collaborators than to a specific experimenting player though.
.
Griatch

@Lithium

Python knows nothing about mushes, it's just a language. That is what Evennia is for - it supplies the resources relevant for use in a mu environment. If resources are missing we can add them or have them as optional contribs.

It's quite clear that Python has many, many more help resources than mushcode has as a language, simply because so many more people use Python in the world than mushcode. But there is no denying that by comparison very few use Python for the specific use of creating a Mu - as far as Python goes, Evennia is one of the few runners in that race. Here mushcode has decades of lead; it's after all the only thing mushcode is used for, anywhere (as far as I know?).

Now, I personally agree with @faraday that someone who mastered something like mushcode should be well in place for learning something like Python or Ruby. The workflow may be the more jarring aspect (as has been discussed at length here). So if you know mushcode already and it fulfills all your needs for the games you want to create, I agree you may very well be best off sticking to it. The toolboxes offered by Evennia (or Ares) and the workflow they work best with is not necessarily the right fit for everyone.
.
Griatch

To avoid cluttering this thread with overall Evennia discussion, I made another one here: http://musoapbox.net/topic/2490/make-evennia-more-accessibility-ideas
.
Griatch

@Thenomain said:

@Griatch said:

As a side note, I should point out that "server level access" is not what it once was.

This is an important note, yes, but I was summarizing for both expediency and to keep from making myself look like an idiot. I wouldn't have the time to review code that, e.g., makes an object follow me from room to room. I have come to trust the server itself to be trustworthy in making this something that can be performed without breaking security. Theno, install my Follow code! Theno, install these three different multidescers! Theno, one of the multidescers is not working please debug it! Theno, that bug has been in for months but people still use it even halfway broken can you take a moment to fix it for us please?

Yeah, this happens. The most fun was when someone fixed some of our code, it ended up more broken, and she refused to fix the bugs leaving me responsible for code that I subcontracted out so that I didn't have to worry about it in the first place. I can be pretty draconian about what I allow in the Master Room (game-wide code implementations) anymore.

@Thenomain

To exemplify this in the standard Evennia paradigm, things like "code to make people follow me" is fundamental enough to be developed during the actual construction of your game, something part of your design specification or added as a later, formal patch.

What you are referring to as "things you don't have time for" really describes the normal debug cycle of almost all other computer programs in the world. It's cool that softcode lets you-the-admin off the hook in the sense that you don't need to worry about contributed softcode taking over your computer. There is no denying it works. I'm not so sure this lack of central oversight is the best practice for a long-running multiplayer game you want to consistently and stably maintain though. This has nothing to do with softcode per se: it's just that code that is "safe" from the server perspective doesn't necessarily mean code that is actually working/efficient/readable/upgradable. Again, remember that I'm referring to core system code here, not creative builder stuff.

Under a version control system, even if a buggy update slipped through the net, you could then easily look back in the file history to see where a particular line was changed and by who - and then reverse that code back to the (in your example slightly better working) previous version with equal ease.

Btw, to show you are truly draconian you demand unit tests ...

Mind, I did promise @Chime that I would make the MUSHlike interfaces if she did what you guys are doing, so I am willing to make it happen. The question is do I have the time and drive. You know how that goes.

I'd be interested in hearing what MUSHlike interfaces you promised and what you consider such interfaces to be! What do you mean by "if she did what you guys are doing" though - could you clarify what you refer to?
.
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

@wyrdathru said in Make Evennia 'more accessible' - ideas?:

@Griatch What's the state of Ainneve? I've been out of touch with the whole engine and associated projects. The Evennia minimum viable game is great for developers, but contribs for basic systems commonly found are always welcomed by games at laucnh, especially if highly configurable to suit their needs. There's major benefit to this, but obviously one-size-fits-all systems can be a nightmare if poorly designed, so need to be highly modular.

Ainneve is under development by the community, but not really a viable game at the moment. We actually have a pretty big library of contribs already, with new ones coming in regularly. But even Ainneve is going to more like the Diku-style of game than a MUSH-type base like I think this community would be more helped by.
Volund is working on his big MUSH base, but considering how he keeps reworking and refining that indefinitely I don't know what time frame he envisions for it.

My long term ambition to help the project is feed back contribs with enough flexibility through configuration for regularly used systems, which I know some people have done, and I think is highly valuable.

That is always helpful! Check out the existing contribs to see what's already available.

This is a lot of dev work, so I'll mull over other potential ideas to assist in the accessibility for new starters.

Do tell when you come up with any further ideas.

@tehom said in Make Evennia 'more accessible' - ideas?:

I think the two major pain points are not having some common features out of the box that people need to implement themselves, like bulletin boards, and the difficulty in installation/configuration. While I think the 'getting started' guide is great, it's still not a trivial matter for people who are new to python or otherwise uncomfortable with setting up an environment.

As for the bulletin board, there is @Sparks Paxboards which works well as an Evennia bulletin board (mirroring an in-game bulleting board to a web equivalent). It might still be slightly too primitive to add as a core Evennia component - but with some further refinement they would work very well to integrate into Evennia proper I think.
As for installation/configuration - more specific suggestions are needed there I think (like @Thenomain does below).

I don't know if there's really any easy solutions to the latter, aside from far-off-in-the-future solutions like having an installer on windows that'd prompt them for configuration choices and handle most things for them. It'd probably make the most sense to get a checklist of features that MUSH players would want supported out of the box, and add them as contribs or even to core as example commands.

With a PyPi package or even a OS-specific installer you could simplify things ... but honestly I'm not sure hiding away the Evennia sources is doing a newcomer any favors. You code Evennia by extending its base classes. The Evennia source code is written to be read, with among the highest ratios of code-to-comments in the OSS world (yes really) - it's a resource that will likely have to remain up-front also in the future; updating with GIT also makes our users see fixes much faster.

Maybe some of the existing tutorials could then focus on common use-cases of extending the existing contribs to add functionality that we don't necessarily want in an unopinionated framework but would be commonly requested.

That would be interesting, yes. With the exception of vincent's In-game Python, contribs are not accompanied with tutorials to any great extent if at all.

@thenomain said in Make Evennia 'more accessible' - ideas?:

Getting the system started and into the part of the system where coding happens—which can happen in multiple places—is a distinct challenge for me. While people have told me what Django is a few times, I don't remember why I need it so talking about it can be distracting. While I use git/Github to store my code, I don't use it to code.

This and the rest of this post gives me a feeling that the main issue is a confusion of terms. Maybe we'll simply create a page with an indexed glossary of terms explaining what things are and what/where they are useful.

While TinyMUX can be a pain to get compiled right, once it's compiled there's a single button to press to start the game, log in, and get confused by the next layer of "build the game".

This is the same for Evennia (minus the compiling); the virtualenv aspect is pretty much a non-issue once you understand what it does, but I understand that if that first step is not clear this can be very confusing indeed. As said, a glossary would be useful.

Evennia's documentation is good, but...here, look, here's a part from the first documentation page:

• The Getting Started page helps installing and starting Evennia for the first time.
• The Admin Docs covers running and maintaining an Evennia server.
• The Builder Docs helps for starting to build a game world using Evennia.
• The Developer Central describes how Evennia works and is used by coders.
• The Tutorials & Examples contains help pages on a step-by-step or tutorial format.
• The API documentation is created from the latest source code.

Okay, so I assume I look at "The Getting Started page". Yup, there's how to install and get running. I'm on a Mac so sure, let me look there:

cd mygame
evennia migrate  # (this creates the database)
evennia start    # (make sure to create a superuser when asked. Email is optional.)

Except that I know there's another step that I'm missing because it runs in ... virtualeng? veng? vengence? Something.

The virtualenv is explained there, but clearly not well enough

Okay, let's try the Administration page. Ahha! "Starting, stopping, reloading and resetting Evennia." Here it is!

A common reason for not seeing the evennia command is to forget to (re)start the virtual environment (in a folder called pyenv if you followed the Getting Started page). You need to do this every time you start a new terminal/console and should see (pyenv) at the beginning of the line. The virtualenv allows to install all Python dependencies without needing root or disturbing the global packages in the repo (which are often older).

source pyenv/bin/activate (Linux/Unix)
pyenv/Scripts/activate` (Windows)

... What?

Wait, do you want me to run this every time I log into the shell? I know almost nothing about pyenv. This is a step up from a true newbie who will know literally nothing about it.

Ok, that is good feedback, will try to clarify that (answer is - whenever you want to run the evennia program you needs to activate the virtualenv first, since evennia and its dependencies are only installed in the virtualenv). Again, centralizing this information in a glossary one can refer to from many places would probably help too - then one need only iterate on the phrasing and clarity in one place.

My solution? I like how MediaWiki does it. There's a full "we know you're a newbie let's try to help" page and then there are a number of "this is what's going on behind the scenes with this particular aspect" pages. This is how I drill down to the various setup security levels and new namespaces. It was absolutely confusing at first but because I could go up a level I never felt entirely without hope.

Incidentally, "Startup scripts for remote servers" points to the same file which does not have any startup scripts for remote servers.

That sounds like a 'bug' in the wiki linking. Thanks for pointing it out!

In updating:

When you're wanting to apply updates, simply cd to your cloned evennia root directory and type:

Do I need to be in pyenv?

Once one understands what virtualenv is this would be clear I think (again probably something to add in a new glossary entry). Answer is no, git is a separate (non-Python) program from evennia and thus has nothing to to do with virtualenv, which only deals with python packages.

When the database schema changes, you just go to your game folder and run:

Do I need to be in pyenv?

I know you are making a point with the repeat questions, but to answer - yes, because you are running evennia migrate, you must be in the virtualenv, since that's where Evennia is installed. Oh, and pyenv is just the name you gave the folder when you first ran the virtualenv command - the place on your drive where Python packages will be installed - it could be named anything.

(Extra credit: Does git pull tell me when my database schema changes?)

Yes. The schema is described by small snippets of Python code named "migrations". These are "applied" to change the database schema from one state to another. When upstream Evennia changes its schema we usually instruct users (in commit messages and in the forum/chat) to run evennia migrate so they get the latest version of the schema. We don't go into this in the Getting Started instructions because that felt like a little too much info out the gate.

Alright, let's look at the beginning developer docs!

Explore Evennia interactively

When new to Evennia it can be hard to find things or figure out what is available. Evennia offers a special interactive python shell that allows you to experiment and try out things. It's recommended to use ipython for this since the vanilla python prompt is very limited. Here are some simple commands to get started:

# [open a new console/terminal]
# [activate your evennia virtualenv in this console/terminal]
pip install ipython # [only needed the first time]
cd mygame
evennia shell

Wait, do I need to enter pyenv here?

You are using the evennia command, so yes.

I think this is enough for now. I know I sound like I'm complaining. I am not. I am horrible at pointing things out gently, so I do it the way I do it while I get better at doing it.

These are valuable points, and explaining them has given me some better ideas of how to explain the virtualenv in that future glossary I'll add. Thanks!

If I had a better grasp of how people learn I could add examples of why the documentation is confusing, but for now I'll explain why it's confusing for me.

It's really hard to know what is difficult for others, so this is very useful info I think.

I sincerely hope that helps.

It does!
.
Griatch