MU Soapbox

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Muxify
    • Mustard
    1. Home
    2. Griatch
    3. Posts
    • Profile
    • Following 0
    • Followers 1
    • Topics 23
    • Posts 375
    • Best 172
    • Controversial 0
    • Groups 2

    Posts made by Griatch

    • RE: Evennia for MUSHers

      @surreality said in Evennia for MUSHers:

      Thank you for this. 😄 I like to tinker with things and see what they do and how they work. I'll likely peek at this in the same way, and I appreciate the mac support and instructions.

      (Anybody giving good mac support gets a major thumbs up from me. It's rare enough it deserves a specific mention and a sincere thank you.)

      Sure! We try to help as we can. Python is OS-agnostic so the only real difference is where to get the dependencies during install. Mac tends to install fine though, it's more common with Windows-install questions.

      @Thenomain said in Evennia for MUSHers:

      I can verify that the Evennia chat room is open, friendly, and usually appropriately silly. The occasions I've seen tensions rise, others have stepped in to say, "Hey, okay, let's not go there." Even tho I've done little there but kind of trade witty repartee with @Volund.

      Glad you think so! It can drift off topic quite a bit occationally, but most of the time we do talk MU*, I promise.

      As an aside, it still irks me that for the longest time the only other comment mentioning our chatroom online was some fellow complaining about it (in another forum I'm not part of). S/he replied to a thread about Evennia, being sad that our chatroom was inactive and thus not very useful . This in itself wouldn't annoy me if I didn't happen to remember that particular nickname in the logs. Before that post they joined the chatroom once, for all of ten minutes. On Christmas Eve.
      .
      Griatch

      posted in How-Tos
      Griatch
      Griatch
    • RE: How-To Contest

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

      posted in Announcements
      Griatch
      Griatch
    • Evennia for MUSHers

      If you are a MUSH user interested in trying to make your next game in Evennia but are unsure where to start, this is the introduction for you! It will go through some key differences, help with the installation and then offer some first things to try out.

      On Evennia

      Evennia googly snake
      Evennia is an open-source game server and -library for developing multiplayer text-games in Python (not only MUSH, any type of MU*). When you start Evennia you’ll have a fully functioning (if empty) game that you can connect to with normal MU* clients as well as play from any modern browser - you will also get a simple website for your game.

      By default you’ll have some 90 in-game commands as well as channels, rooms, characters and other basic building blocks. Commands can be completely changed but the default administrative command syntax is somewhat reminiscent of MUX.

      Fundamental differences between MUSH and Evennia

      Apart from the features mentioned above, Evennia works quite differently from a MUSH under the hood. Here are some fundamental differences to keep in mind.

      Developers vs Players

      In MUSH, users tend to code and expand all aspects of the game from inside it. A MUSH can thus be said to be managed solely by Players with different levels of access. Evennia on the other hand, differentiates between the role of the Player and the Developer.

      • An Evennia Developer works in Python from outside the game, in what MUSH would consider “hardcode”. Developers implement larger-scale code changes and can fundamentally change how the game works. They then load their changes into the running Evennia server. Such changes will usually not drop any connected players.
      • An Evennia Player operates from inside the game. Some staff-level players are likely to double as developers. Depending on access level, players can modify and expand the game's world by digging new rooms, creating new objects, alias commands, customize their experience and so on. Trusted staff may get access to Python via the @py command, but this would be a security risk for normal Players to use. So the Player usually operates by making use of the tools prepared for them by the Developer - tools that can be as rigid or flexible as the developer desires.

      Collaborating on a game - Python vs Softcode

      For a Player, collaborating on a game need not be too different between MUSH and Evennia. The building and description of the game world can still happen mostly in-game using build commands, using text tags and inline functions to prettify and customize the experience. Evennia offers external ways to build a world but those are optional. There is also nothing in principle stopping a Developer from offering a softcode-like language to Players if that is deemed necessary.

      For Developers of the game, the difference is larger: Code is mainly written outside the game in Python modules rather than in-game on the command line. Python is a very popular and well-supported language with tons of documentation and help to be found. The Python standard library is also a great help for not having to reinvent the wheel. But that said, while Python is considered one of the easier languages to learn and use it is undoubtedly very different from MUSH softcode.

      While softcode allows collaboration in-game, Evennia's external coding opens up for sharing using professional version control tools and bug tracking using websites like github (or bitbucket for a free private repo). Source code can be written in proper text editors and IDEs with refactoring, syntax highlighting and all other conveniences. In short, collaborative development of an Evennia game is done in the same way most professional collaborative development is done in the world, meaning all the best tools can be used.

      @parent vs @typeclass and @spawn

      Inheritance works differently in Python than in Softcode. Evennia has no concept of a "master object" that other objects inherit from. There is in fact no reason at all to introduce "virtual objects" in the game world - code and data are kept separate from one another.

      In Python (which is an object oriented language - read the wikipedia article for the advantages of this) one instead creates classes - these are like blueprints from which you spawn any number of object instances. Evennia also adds the extra feature that every instance is persistent in the database (this means no SQL is ever needed). To take one example, a unique character in Evennia is an instances of the class Character.

      One parallel to MUSH's @parent command may be Evennia's @typeclass command, which changes which class an already existing object is an instance of. This way you can literally turn a Character into a Flowerpot on the spot.

      if you are new to object oriented design it's important to note that all object instances of a class does not have to be identical. If they did, all Characters would be named the same. Evennia allows to customize individual objects in many different ways. One way is through Attributes, which are database-bound properties that can be linked to any object. For example, you could have an Orc class that defines all the stuff an Orc should be able to do (probably in turn inheriting from some Monster class shared by all monsters). Setting different Attributes on different instances (different strength, equipment, looks etc) would make each Orc unique despite all sharing the same class.

      The @spawn command allows one to conveniently choose between different "sets" of Attributes to put on each new Orc (like the "warrior" set or "shaman" set) . Such sets can even inherit one another which is again somewhat remniscent at least of the effect of @parent and the object-based inheritance of MUSH.

      There are other differences for sure, but that should give some feel for things. Enough with the theory. Let's get down to more practical matters next.

      Getting Evennia running

      Evennia runs on Linux/Unix, Windows and Mac. Most of the install is handled automatically but you must be familiar with the Linux/Mac terminal or the Windows console. The full install instructions (and explanations of each step) are found on the Evennia Getting Started page - look there if you run into trouble.

      1. Install Python, python-virtualenv and GIT in the way recommended by your OS. On a Debian-derived Linux (Ubuntu etc), you can do sudo apt-get install python python-dev git python-virtualenv. After this you should not need to be root/admin anymore.
      2. Create a new folder, say mud-dev, somewhere - for example in your home directory on Linux/Mac or in My Documents on Windows.
      3. Open the terminal/console and cd to the mud-dev folder. You'll stay in here from now on.
      4. Enter virtualenv pyenv - a new folder pyenv will appear. The virtualenv program allows you to install Python libraries in the pyenv folder without affecting other things on your system - it's a standard Python practice.
      5. Enter source pyenv/bin/activate (Linux/Mac) or pyenv\Scripts\Activate (Windows). This activates the virtualenv. You see that it works if the text (pyenv) appears next to the command prompt. You need to call this command every time you open a new terminal to get access to the stuff you install in the virtualenv below.
      6. git clone https://github.com/evennia/evennia.git - a new directory evennia will appear; this holds the actual Evennia code.
      7. pip install -e evennia - installs Evennia to the virtual environment. You should now have the evennia command available - try it! If there are any hick-ups, look here for linux-, mac- and windows troubleshooting respectively.
      8. Enter evennia --init mygame - this will create a new folder mygame (or whatever you choose to call it) where we’ll create our new game.
      9. cd mygame
      10. evennia migrate - this will create the database.
      11. evennia start - the server starts. You can now telnet to it on localhost, port 4000 or in your browser on http://localhost:8000.

      Welcome to Evennia! If you want to toy around you can get some first pointers in the "Next Steps" section last in this how-to. Take a moment to try things out, maybe build the tutorial world as instructed in the first room. Some things will look familiar, other things not, we’ll start addressing that in the next section.

      A first step making things more familiar

      We will here give two examples of customizing Evennia to be more familiar to a MUSH Player.

      Activating a multi-descer

      By default Evennia’s desc command updates your description and that’s it. There is a more feature-rich optional “multi-descer” in evennia/contrib/multidesc.py though. This alternative allows for managing and combining a multitude of keyed descriptions.

      To activate the multi-descer, cd to your game folder and into the commands sub-folder. There you’ll find the file default_cmdsets.py. In Python lingo all *.py files are called modules. Open the module in a text editor. We won’t go into Evennia in-game Commands and Command sets further here, but suffice to say Evennia allows you to change which commands (or versions of commands) are available to the player from moment to moment depending on circumstance.

      Add two new lines to the module as seen below:

      # the file mygame/commands/default_cmdsets.py
      # [...] 
      
      from evennia.contrib import multidescer   # <- added now
      
      class CharacterCmdSet(default_cmds.CharacterCmdSet):
          """
          The CharacterCmdSet contains general in-game commands like look,
          get etc available on in-game Character objects. It is merged with
          the PlayerCmdSet when a Player puppets a Character.
          """
          key = "DefaultCharacter"
      
          def at_cmdset_creation(self):
              """
              Populates the cmdset
              """
              super(CharacterCmdSet, self).at_cmdset_creation()
              #
              # any commands you add below will overload the default ones.
              #
              self.add(multidescer.CmdMultiDesc())      # <- added now 
      # [...]
      

      Note that Python cares about indentation, so make sure to indent with the same number of spaces as shown above!

      So what happens above? We import the module evennia/contrib/multidescer.py at the top. Once imported we can access stuff inside that module using full stop (.). The multidescer is defined as a class CmdMultiDesc (we could find this out by opening said module in a text editor). At the bottom we create a new instance of this class and add it to the CharacterCmdSet class. For the sake of this tutorial we only need to know that CharacterCmdSet contains all commands that should be be available to the Character by default.

      This whole thing will be triggered when the command set is first created, which happens on server start. So we need to reload Evennia with @reload - no one will be disconnected by doing this. If all went well you should now be able to use desc (or +desc) and find that you have more possibilities:

      > +desc eyes = His eyes are blue. 
      > +desc basic = A big guy.
      > +desc/set basic + + eyes    # we add an extra space between
      > look me
      A big guy. His eyes are blue.
      

      (See also help +desc). If there are errors a traceback will show in the server log - several lines of text showing where the error occurred. Find where the error is by locating the line number related to the default_cmdsets.py file (it's the only one you've changed so far). Most likely you mis-spelled something or missed the indentation. Fix it and either @reload again or run evennia start as needed.

      Customizing the multidescer syntax

      As seen above the multidescer uses syntax like this (where |/ are Evennia's tags for line breaks) :

      > +desc/set basic + |/|/ + cape + footwear + |/|/ + attitude 
      

      This use of + was prescribed by the Developer that coded this +desc command. What if the Player doesn’t like this syntax though? Do players need to pester the dev to change it? Not necessarily. While Evennia does not allow the player to build their own multi-descer on the command line, it does allow for re-mapping the command syntax to one they prefer. This is done using the nick command.

      Here’s a nick that changes how to input the command above:

      > nick setdesc $1 $2 $3 $4 = +desc/set $1 + |/|/ + $2 + $3 + |/|/ + $4
      

      The string on the left will be matched against your input and if matching, it will be replaced with the string on the right. The $-type tags will store space-separated arguments and put them into the replacement. The nick allows shell-like wildcards, so you can use *, ?, [...], [!...] etc to match parts of the input.

      The same description as before can now be set as

      > setdesc basic cape footwear attitude 
      

      With the nick functionality players can mitigate a lot of syntax dislikes even without the developer changing the underlying Python code.

      Next steps

      If you are a Developer and are interested in making a more MUSH-like Evennia game, a good start is to look into the Evennia Tutorial for a first MUSH-like game. That steps through building a simple little game from scratch and helps to acquaint you with the various corners of Evennia. There is also the Tutorial for running roleplaying sessions that can be of interest.

      An important aspect of making things more familiar for Players is adding new and tweaking existing commands. How this is done is covered by the Tutorial on adding new commands. You may also find it useful to shop through the evennia/contrib/ folder. The Tutorial world is a small single-player quest you can try (it’s not very MUSH-like but it does show many Evennia concepts in action). Beyond that there are many more tutorials to try out. If you feel you want a more visual overview you can also look at Evennia in pictures.

      … And of course, if you need further help you can always drop into the Evennia chatroom or post a question in our forum/mailing list!

      posted in How-Tos
      Griatch
      Griatch
    • RE: Mud Hosting, for 0 budget?

      @Arkandel said in Mud Hosting, for 0 budget?:

      @Griatch Out of morbid curiosity, assuming of course all the relevant services are present (PHP/whatever database/etc) will Evennia run on Windows?

      Of course, we have many Windows users. Python code is after all platform agnostic. Beyond Python and GIT for download/update, all dependencies are gathered automatically at install time.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: Mud Hosting, for 0 budget?

      @DnvnQuinn said in Mud Hosting, for 0 budget?:

      A while ago, going on a year +, I signed up for Freemudhost, despite numerous attempts to contact, I received no reply. I'm disabled, with 0 available income, so even the 4.50 over at Genesis Mud is too much. Now, I'm not ASKING for a free host. I'm just seeing if there is one available out there aside from Free Mud Host.

      Especially during development, using your own computer is probably the cheapest (but also consider your Internet/electricity bills!).

      This is some info we put together on our wiki for how to use your own computer as a host and to set up a free domain with FreeDNS. Just ignore the Evennia references and it should be useful for any Mu* server you want to use.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: How should we (as a community) handle MediaWiki

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

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: Telnet is Poop

      @TNP

      Whoever coded Brave New World managed it with Mediawiki. Logged scenes would transfer to the wiki somehow.

      I don't know how hard that is in a traditional MUSH server, but in principle that direction is not all that difficult I believe - taking a data table and storing it in a wiki-formatted page is just a matter of filling a template on a form the wiki understands.

      The other direction, wiki-> relevant game data feels trickier.
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • RE: Telnet is Poop

      @surreality

      Thanks for the explanation. So the way I understand the common use case, it is that you want to update, say a character data block and make sure that updates wherever it appears on your web page. Same with other data elements like factions etc. Here's how I envision a similar functionality could be integrated with vanilla Evennia:

      Distributed change is simple enough - one can build a simple django app to do that rather simply (this is what Django does after all) - it just uses the same database model for the given data wherever, which guarantees it updates everywhere. You will as an added bonus have direct access to said data inside the game already with default commands to read/write it.

      This would likely not be represented in the browser as wiki syntax however. Instead the user would be presented with web form (as flexible as you want it) that the user fills in and updates (that form could easily handle markdown etc as needed). Data created this way could be inserted in other pages (including wiki pages) but would not be updated from the wiki page explicitly.

      Using a form is not as elegant as DPLs, but works pretty much out of the box with a little work. There may be better solutions involving mediawiki itself somehow, but I'd prefer to not have to integrate that huge mass of tables into a game if possible. If one could handle the game-specific updates with forms, then one of the normal Django wiki's might be enough for maintaining lore, rules, help etc, maybe?
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • RE: Telnet is Poop

      @surreality

      Cool page, lots of nice features there!

      With "auto-populate" I presume you mean that the lists update when people make changes in-game - and vice versa. Do you have a feel for how much change happens dynamically from in-game (updating the wiki page from the game) compared to using the web interface to change things (update the game from the wiki page)?
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • RE: Telnet is Poop

      @surreality

      We might be drifting off-topic here, but this is interesting. Do you have a link to a wiki of yours I could look at to get a feel for the stuff you are doing with it?
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • RE: Telnet is Poop

      @faraday

      Yes, it's a fair point, and focusing on a given genre of text game may indeed offer an easier way in for users only interested in that particular genre. If you are planning to offer a web client as well though, I think you'd be wise to make it as easily extendable as possible - the amount of web-dev knowledge out there is so vast that you'll never know what users will want to do with it.

      @surreality

      MediaWiki is pretty comprehensive, yes. There are django authentication backends to mediawiki, but I don't know exactly how that works. Here's anyway an example of a running django-driven wiki. It uses Markdown (like musoapbox does) https://demo.django.wiki/ - not as comprehensive as mediawiki + plugins but probably useful for many a use-case (I know we'd not need anything more for Evennia docs at least).
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • RE: Telnet is Poop

      @faraday said in Telnet is Poop:

      @Griatch said in Telnet is Poop:

      Telnet still has a place I think, for the existing crowd/power users using and expecting the features of their particular third-party client. I believe aiming to offer web clients with features on par or better is the way forward though.

      Generally I agree, but the thing is that most of these cool new features would be highly game-specific. Even just that simple example you showed would make no sense on a game without combat, or a game that used a different combat system.

      You are perfectly correct, and since Evennia is game agnostic, we wouldn't customize our default client this heavily. That said, I find it pretty telling that the custom gui shown above appeared within two days of our wclient development branch merging. The modern Javascript GUI tools out there are really quite impressive.

      It's cool, I'm just not sure it's sustainable unless the MUSH community had a sudden swell of new players who also happened to be web developers.

      I would suggest that it's at least a higher chance that a new player is a web developer than them being a telnet affectionado ... 😉

      @surreality said in Telnet is Poop:

      @Griatch Any idea what the possibilities for integration with mediawiki are with that?

      Gotta be honest, having an 'in page' client that matches the look of a page is something I'd be all over; it'd just likely be more than a little complicated to pull off with the way mediawiki functions. (There are potentially some imbed workarounds, or widgets, that could be constructed, though. Maybe. Possibly.)

      While I'm not super aces on some of the specific look/effects (flashy things make something a full no-go for a number of players) the concept is A+.

      Django, which Evennia uses for Python database- and website integration, has a slew of wiki apps you can plug in to your website. I'm sure some can support mediawiki format if you must have that. I admit to not having personally tried any of the third-party ones myself so some trial & error would be needed - but per definition the wiki database tables would be available from within the game since game and website share the same database (Evennia is after all its own webserver).

      So, while I wouldn't say that integrating a wiki is trivial it's certainly doable, and you wouldn't have to do it from scratch.
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • RE: Telnet is Poop

      Telnet has some issues but I feel some disparage telnet just for the sole reason that it's old.

      Fact is telnet, as a protocol, is easy to work with. It's straightforward and simple to debug by just printing what the heck you are receiveing and sending in plain text. And over the years the MU* community has made a series of extensions to expand its capabilities to act as a game protocol, like MCC for compression (less important than it used to be), MXP for client-handled text markup, GMCP/MSDP for server/client out-of-band instructions etc. Flip on SSL and you can even give it some notion of security.

      From the server's perspective the main problem is that many of these custom MU* telnet-protocols are only vaguely standardized, and even when there is good documentation (not at all a guarantee), third-party clients are often ignoring that documentation or present lackluster, partial support. And who do users blame if their client suddenly misbehaves with a server because their client is not following specs but the server do? They sure don't blame their (often ancient) client.

      The other main drawback of telnet is of course, as mentioned already in this thread, the need for a custom client. This has a generic interface not customized for that a given game. Clients like Mudlet have worked hard to allow games to easily offer game-custom skins and settings though - games like GodWars2 have made quite impressive and easy features available this way - people playing GW2 has a Mudlet client that looks nothing like the vanilla one. Still, there's no denying that third-party clients still present a hurdle for complete newbies.

      Web clients have the advantage of being almost completely under your control as a dev (I say almost since the browser affects things too). No need to worry about weird standards or client compliance - when you control both ends of the wire you can make your client work exactly as intended. That players can easily just press a website button and be in-game is a nice bonus. The drawback is that you are then playing catch-up with the features of third-party clients that have been in development for 20+ years in some cases.

      There are lots of possibilties though. For example, here's a GIF example of user BattleJenkin's experimental (not yet official) web client for their Evennia game "World of Cool Battles":

      Client GUI

      This is replacing Evennia's default webclient GUI with a JS GUI library of their preference (it's using HTML5's canvas element). It offloads all location descriptions in its own window and uses light graphics and special effects to enhance gameplay. It's possible one could achieve similar results with Mudlet (maybe in MUSHclient too?) using GMCP/MSDP and a custom skin, but it's a nice indication of the possibilities.

      Telnet still has a place I think, for the existing crowd/power users using and expecting the features of their particular third-party client. I believe aiming to offer web clients with features on par or better is the way forward though.
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • RE: Coming Soon: Arx, After the Reckoning

      Just noticed this thread, glad to see people interested in this.

      Arx was pretty much a surprise out of nowhere for us in Evennia-land. I happened to stumble over their website during a google search and went and invited them to come chat to us (their in-game dev channel is connected to the #evennia IRC chatroom now).

      You guys have made some very impressive progress so far in a relatively short time, it's awesome to hear you may be approaching a more open testing stage!
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • RE: Evennia 0.6 released

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

      posted in Adver-tis-ments
      Griatch
      Griatch
    • RE: How does a Mu* become successful?

      @Thenomain

      Was there some particular thing you wanted me to comment on?

      @thread

      There was a mention earlier in this thread on sharing the login session of the game and the website. This has been on our todo list for quite some time and now that our latest big webclient development push has merged, I'm actually just looking into this - and finding it to probably be a lot easier to do than I thought it was, so that looks like it'll happen soonish.

      To be honest we have really not spent as much time on the django-web side of things compared to other code. We have been focusing on making a good and expandable base server. But there's a lot of possibilities on the web side. Just two days after the webclient infrastructure changes merged, an industrious user made a client GUI using Construct 2 that bounced and swayed around. 🙂 Not very useful in itself, but a fun proof-of-concept! Should have saved the anim-gif they made of it.

      To stay on the topic of this thread ... From my perspective as a server developer:

      People regularly show up at our shores setting out to create their dream Muds/Mux/Mushes/Moos/Muck/IF/edu/whatever games in Evennia. They discuss and learn and code and socialize (and help us fix bugs and suggest features!). Some are grizzled coders, others never touched code before. One guy just found this neat thing called "a mud", another is a MUSH veteran of 30 years. Some just want to rebuild their favorite game but better, another come at it with the idea of doing all things differently.
      Even though many of these won't ever reach a finalized game for all the normal reasons, they are mostly having a swell, creative time along the way. In my book, that's success right there.
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • RE: Base Code Question

      @Derp

      Language famliarity is certainly a valid reason for going with a particular system. After reading that I would honestly not had commented in this thread if @faraday had not specifically asked me to clarify something.
      .
      Griatch

      posted in MU Code
      Griatch
      Griatch
    • RE: Base Code Question

      @faraday

      You don't have to use the player/character separation, no. Evennia has four different modes for how you relate your account (aka player) and the character you puppet.The default is that you log directly into a character like in traditional engines. In that mode, the player/character separation is pretty academic and mainly useful for staff who wants to easily puppet NPCs.

      Of course, having one login (player, aka account) for playing multiple in-game characters is very useful in many types of games. But if multi-playing is not desired one can certainly just ignore the separation.

      Edit: Ninja'd by @Thenomain 🙂
      .
      Griatch

      posted in MU Code
      Griatch
      Griatch
    • Evennia 0.6 released

      Evennia is a MU* development system and server in Python.

      As of today, Evennia's "wclient" development branch merged, making me feel like ramping up the version number to the pretty arbitrary 0.6.

      This update concludes a lengthy overhaul of Evennia's HTML5 web client infrastructure, notably standardizing all commands between the server and client as well as splitting the javascript code into two - one javascript library handles all communication to the Evennia server and the other the frontend UI. The communication library will transparently downgrade the connection to AJAX/COMET long polling if the player uses a browser that can't handle websockets. This library offers events and hooks for the front-end to make use of. This split makes it easier to replace the default gui with a ui library of your own choice while not needing to worry about the server communication details. Thanks to @Glitch for offering excellent ideas and examples for the redesign of this!

      0_1463953101920_evennia_screen.png

      The default webclient gui is still mimicking a straightforward but stable "telnet-like" interface. So by default it matches what you see using the other types of client connections Evennia accepts in parallel (traditional telnet, telnet+SSL and SSH).

      Other changes involve expanded flexibility and functionality for having your client ask for all sorts of things from the server, or telling the server to report various state changes (like the client asking the server to report whenever a health attribute changes so it can update a health bar or flash the screen). On the server side, this is done by simply defining a normal function with the name (and arguments) of the client instruction you want to accept.

      There are a bunch of further changes that are interesting to those familiar with, or is already using, Evennia. More info, along with update instructions, is covered in this post on the Evennia mailing list.
      .
      Griatch

      posted in Adver-tis-ments
      Griatch
      Griatch
    • RE: Non-MU* online roleplay

      I cleaned up the mentioned Evennia for running tabletop rpgs tutorial a little. Still not tested nor fully complete but the concepts should be sound for those that want to toy with it.
      .
      Griatch

      posted in Mildly Constructive
      Griatch
      Griatch
    • 1
    • 2
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 14 / 19