+ 
+
Evennia
+The Python MU* Development Library
+-
+
+
- 2018 (4)
+
+
-
+
+
+
- + September 30 + + +
- + August 18 + + +
- + January 27 + + +
- + January 5 + + +
+
+ - 2021 (2) + + + + +
- 2016 (7)
+
+
-
+
+
+
- + November 30 + + +
- + October 13 + + +
- + July 1 + + +
- + May 31 + + +
- + May 22 + + +
- + March 24 + + +
- + February 14 + + +
+
+ - 2017 (6)
+
+
-
+
+
+
- + October 29 + + +
- + October 1 + + +
- + September 20 + + +
- + August 25 + + +
- + April 23 + + +
- + February 5 + + +
+
+ - 2019 (7) + + + + +
- 2020 (3)
+
+
-
+
+
+
- + November 14 + + +
- + October 20 + + +
- + April 14 + + +
+
+ - 2015 (1)
+
+
-
+
+
+
- + December 17 + + +
+
+ - 2018 (4)
+
+
-
+
+
+
- + September 30 + + +
- + August 18 + + +
- + January 27 + + +
- + January 5 + + +
+
+ - 2021 (2) + + + + +
- 2016 (7)
+
+
-
+
+
+
- + November 30 + + +
- + October 13 + + +
- + July 1 + + +
- + May 31 + + +
- + May 22 + + +
- + March 24 + + +
- + February 14 + + +
+
+ - 2017 (6)
+
+
-
+
+
+
- + October 29 + + +
- + October 1 + + +
- + September 20 + + +
- + August 25 + + +
- + April 23 + + +
- + February 5 + + +
+
+ - 2019 (7) + + + + +
- 2020 (3)
+
+
-
+
+
+
- + November 14 + + +
- + October 20 + + +
- + April 14 + + +
+
+ - 2015 (1)
+
+
-
+
+
+
- + December 17 + + +
+
+ -
+
I reworked the way on-object Attributes was cached (from a stupid but simple way to a lot more sophisticated but harder way) and achieved three times faster performance in certain special cases people had complained about. Other issues also came to view while diving into this, which could be fixed.
+
+ -
+
I reworked the venerable batch command and batchcode processors (these allow to create a game world from a script file) and made their inputs make more sense to people. This was one of the older parts of Evennia and apart from the module needing a big refactoring to be easier to read, some parts were pretty fragile and prone to break. Especially when passing it file names tended to be confusing since it understood only certain relative paths to the files to read in and not even I could remember if one should include the file ending or not. This was cleaned up a lot.
+
+ -
+
Lots of changes and updates were made to the RPSystem contrib, which optionally adds more advanced roleplaying mechanics to Evennia. The use of this in Evennia's demo game (Ainneve, being separately developed) helps a lot for ironing out any remaining wrinkles.
+
+ -
+
Lots and lots of other fixes and smaller feature updates were done (About 150 commits and 50 Issues closed since end of summer).
+
+ -
+
Map system contrib (merged), for creating a world based on ASCII map. Talking about maps, users contributed not just one but two new tutorials for implementing both static and dynamic maps with Evennia.
+
+ -
+
Webclient notifications (pending), for making the webclient show us in a clearer way when it gets updated in a different tab. A more advanced implementation awaits the webclient being expanded with a proper client-side option window; there is currently a feature request for this if anyone's interested in taking it on.
+
+ -
+
AI system contrib (pending). This is a full AI backend for adding complex behaviors to game agents. It uses Behavioral trees and is designed to be modified both in code and from inside the game.
+
+ -
+
Action system contrib (pending). This contrib assigns the actions of Characters a time cost and delays the results of commands the given time. It also allows players to go into turn-based mode to enforce a strict action order.
+
+ -
+
Lots of now closed PRs were contributed by the Arx lead developer to fix various bugs and edge-cases as they came up in live use.
+
+ -
+
evennia.js, acts as a library for handling all communication with the server part of Evennia. It offers events for a gui library to plug into and send/receive. It will also gracefully degrade from a websocket connection to AJAX/COMET long-polling if the player uses an older browser.
+
+ -
+
evennia_gui.js is the default front-end and implements a traditional and stable "telnet-like" interface. The html part uses uses Django templating to make it easy to customize and expand. Since this simply makes use of the resources offered by evennia.js, one could pretty easily slip in some other gui library here, or set up calls to get all sorts of interesting information from the server (which talks back using inputfuncs).
+
+ -
+
Direct function callback. The instruction from the client should be able to trigger a named server-side function. This is the core of the inputfunc system described previously.
+
+ -
+
Field/Attribute monitoring. The client should be able to request monitoring of an object's database fields or Attributes. For example, the client may request to be notified whenever the Character's "health" Attribute changes in some way. This is now handled by the new monitorhandler. See below.
+
+ -
+
Non-persistent function repeats. One should be able to set up a repeating ticker that survives a server reload but does not survive a cold shutdown - this mimics the life cycle of server Sessions. Scripts could do this already but I wanted to be able to use the TickerHandler for quick assignment. Problem was that the Tickerhandler in master branch is not only always-persistent, it also only calls database object methods. So I have now expanded the tickerhandler to also accept arbitrary module functions, without any connection to a database object.
+
+ - 2018 (4)
+
+
-
+
+
+
- + September 30 + + +
- + August 18 + + +
- + January 27 + + +
- + January 5 + + +
+
+ - 2021 (2) + + + + +
- 2016 (7)
+
+
-
+
+
+
- + November 30 + + +
- + October 13 + + +
- + July 1 + + +
- + May 31 + + +
- + May 22 + + +
- + March 24 + + +
- + February 14 + + +
+
+ - 2017 (6)
+
+
-
+
+
+
- + October 29 + + +
- + October 1 + + +
- + September 20 + + +
- + August 25 + + +
- + April 23 + + +
- + February 5 + + +
+
+ - 2019 (7) + + + + +
- 2020 (3)
+
+
-
+
+
+
- + November 14 + + +
- + October 20 + + +
- + April 14 + + +
+
+ - 2015 (1)
+
+
-
+
+
+
- + December 17 + + +
+
+ -
+
Character concept - The general idea behind your player character (PC), like “The scarred veteran”, “The grumpy old magician” or “The swashbuckling bounty-hunter”.
+
+ -
+
IC/OOC - In-Character/Out-Of-Character.
+
+ -
+
Emote/pose - This is the common way to roleplay in MUDs. This displays a free-form action to the room, such as “The tall man sighs heavily”. Some MUDs offer a slew of special commands for particular actions or special syntax to decorate poses. Some games use specific “say” commands for verbal communication whereas others make say’s part of the emote completely.
+
+ -
+
Action/static pose - a pose that “lingers”, such as The tall man is sitting by the bar. Commonly static poses remain assigned to your character’s description until you change it or exit the room, meaning that new people entering will immediately see your current status.
+
+ -
+
NPC - Non-Player Character. Also known as a “mob”. An in-game character that is controlled by the computer, such as a bartender or a city guard.
+
+ -
+
vNPC - a “virtual” NPC. This NPC does not actually exist in code but they should be there. Even though there are only two Players and a City guard in the central plaza, that place is actually packed with people most of the day. Most RP-heavy muds ask players to imagine vNPCs being all around them and have it influence their roleplay.
+
+ -
+
Godmodding - this is considered very bad form. Godmodding means to include another Player’s character in your roleplay in a way that takes control away from them unfairly. Depending on the game, disagreements on how to resolve a situation may be down to skill checks, die rolls or calling in a staff arbiter.
+
+ -
+
Evennia separates
+Playerobjects fromCharacterobjects in that the former is an OOC entity that can puppet one or more of the latter. The namePlayerwas a source of some confusion since this is used differently in other code bases.Playerhas now been renamed toAccountto make its function clearer.
+ -
+
Evennia's in-built website now uses our own theme and
+bootstrapunder the hood to make it easier to modify as well as rescale it better on mobile devices (webclient is not updated at this point).
+ -
+
Shared logins between webclient and website, with the ability to log out of each independently of the other if so desired.
+
+ -
+
Prefix-ignoring - All default commands are now renamed without their @-prefixes. Both @examine, +examine or examine will now all point to the same command. You can customize which prefixes Evennia simply ignores when searching for a command. The mechanic is clever though - if you create a command with a specific key "+foo", then that will still work and won't clash with another command named just "foo".
+
+ -
+
Easy pause mechanisms using
+yieldstatements directly in Command code (just doyield 10in your command code to have it pause ten seconds without blocking anyone else). You can also doretval = yield "Do you want to accept?"and have the command pause (non-blocking) for the player's input before continuing.
+ -
+
The optional In-Game-Python contrib by Vincent le Geoff allows for coding and scripting in-game using full-fledged Python to make events and triggers. It's not a safe softcode-style language (you have the full power of Python which is not good for untrusted users) but is intended for trusted builders to make complex scripting from the command line.
+
+ -
+
Wilderness/maps - Creation of dynamic or static maps based on ascii-maps for dynamically creating rooms and to show when moving around. (titeuf87, Cloud Keeper)
+
+ -
+
Full turn-based combat system, meant to expand for a desired system (battlejenkins)
+
+ -
+
Alternative Unix-style command base for Evennia, for those that prefer to enter commands like you do on the unix command line (with
+--flagsetc) (Vincent le Geoff)
+ -
+
Multidescer, which together with Evennia's nick replacement system can be heavily customized in-game (me).
+
+ -
+
Mail - a
+@brandymail-style in-game mail-system (grungies1138)
+ -
+
Clothing system, for layered outfits adding to the wearer's desc when worn (battlejenkins).
+
+ -
+
EvMenu formatting functions now part of class - EvMenu no longer accepts formatting functions as inputs, these are now part of the EvMenu class. To override the formatting of EvMenu nodes you should now override EvMenu and replace the format method you want. This brings EvMenu more in line with other services in Evennia, all of which are built around overriding.
+
+ -
+
Scripts are now valid message senders - Also Scripts can now act as "sender" of a Msg, for example to a Channel or a player.
+
+ -
+
Due to the new prefix-ignoring above, @desc (builder-level description-setting) was renamed to setdesc to make it clearly separate from desc (used by a player setting their own description). This was actually the only clash we had to resolve this way in the default commands.
+
+ -
+
Permission Hierarchy names change - To make Evennia's permission hierarchy better reflect how Evennia actually works, the old Players, Player Helpers, Builders, Wizards, Immortals hierarchy has changed to Player, Helper, Builder, Admin, Developer. Singular/Plural form is now ignored so Builder and Builders will both work (this was a common source of simple errors) Old permissions will be renamed as part of the migration process. The distribution of responsibilities has not changed: Wizards (which in some other systems was the highest level, which confused some) always had the power to affect player accounts (like an admin) whereas Immortals had server-level access such as @py - that is, they were developers. The new names hopefully makes this distinction clearer.
+
+ -
+
All manager methods now return querysets - Some of these used to return lists which was a throwback to an older version of Typeclasses. With manager methods returning querysets one can chain queries onto their results like you can with any django query.
+
+ -
+
PrettyTable was removed from the codebase. You can still fetch it for your game if you prefer (it's on pypi). But EvTable has more functionality as well as color-support.
+
+ -
+
Add *kwargs support to all object at_ hooks - All object at_ hooks, such as at_look, at_give etc now has an additional **kwarg argument. This allows developers to send arbitrary data to those hooks so they can expand on them without changing the API.
+
+ -
+
Remove {-color tags - The use of {r, {n etc was deprecated**** for years and have now been completely removed from Evennia's core in favor of only one form, namely |r, |n etc. However, the color parser is now pluggable and the {-style as well as the %c style color tags etc can be re-added to your game since they are now in a contrib.
+
+ -
+
Updated hooks for say/whisper commands - There are now at_before/after_say sub-hooks to allow say to be more easily customized. There is still ongoing discussion on the best way to handle this (see e.g. this PR).
+
+ -
+
More compact distribution of ports - Before, Evennia distributed its ports widely, such as using 4000, 4001, 8000, 8001, 5001, 8022, some of which appeared close but actually was unrelated in functionality. They were also scattered throughout the settings file. The port definitions have now all moved more closer together, at the top of the settings file. Evennia will now use ports 4000-4006 by default (fewer depending on which protocols you want to start). This should make it easier to assign port ranges when wanting to run multiple Evennia instances on the same machine.
+
+ -
+
Change how auto-login works - It used to be that once you logged into the website, every time you went to the webclient you would auto-login, even if you manually quite the webclient before. Only way to really log out (to change account, say) would be to first log out of the website. Now this will work more intuitively - you will still auto-login but if you log out of the webclient you "decouple" from the login state of the website and need to re-login to the webclient next time, even if you are still logged into the website.
+
+ -
+
Better idle disconnects - This is a long-running pet peeve for many. Idle timeouts will now honor a particular lock. Setting this lock allows selected entities (for example staff and bots) to avoid getting timed out like everyone else.
+
+ -
+
A slew of bug fixes and other tweaks. See here for the list.
+
+ -
+
The Player is the Django Auth user, storing the password. Such a user Django expects to exist from the beginning of the migration history.
+
+ -
+
The Player model sits in a application (folder) named "players". This folder should also be renamed to "accounts", meaning any in-migration references to this from other apps would become invalid.
+
+ -
+
Our migration must both work for old and new users. That is, we cannot expect people to all have existing databases to migrate. Some will need to create the database from scratch and must be able to do so without needing to do any changes to the migration structure.
+
+ -
+
We have a lot of references to "player" throughout the code, all of which must be renamed.
+
+ -
+
The migration, including renames, should be possible to do by new users with newbie-level Python and database skills.
+
+ -
+
One of my first tries wiped the migrations table completely, renamed the folder and just assumed Player never existed. This sounds good on paper and works perfectly for fresh databases. But existing databases will still contain the old Player-related models. With the old migrations gone, this is now all wrong and there is no information on how to migrate it.
+
+ -
+
I tried initiating fresh migrations with a player model state so you can move an existing database over to it. But then fresh databases doesn't work instead, since the player folder is gone. Also, you run into trouble with the auth system.
+
+ -
+
I next tried to keep the old migrations (those we know work both for old and new databases) but to migrate it in-place. I did many different attempts at this, but every time one of the restraints above would get in the way.
+
+ -
+
Eventually I wrote raw SQL code in the migrations to modify the database tables retroactively. That is, I basically manually removed all traces of Player in the database where it was, copying things table by table. This was very work-intensive but overall decently successful. With proper error-checking I could get most of the migration to work from old databases as well as for new databases. The trouble was the migrations themselves. No matter how I tried, I couldn't get the migration history to accept what I had done - the dependencies now longer made sense on the database level (since I had manually edited things) and adding new migrations in the future would have been tricky.
+
+ -
+
First I copied of the
+playersfolder and renamed it and everything in it to accounts. I added this to settings.INSTALLED_APPS. I also copied the migrations from player and renamed everything in them appropriately - those migrations thus look like Account has always existed - so when you run the migration from scratch the database will be created normally. Note that this also means setting the Account as the auth user from the beginning of the migration history. This would be fine when migrating from scratch except for the fact that it would clash with the still existing Player model saying the same thing. We dodge this problem by the way we run this migration (we'll get to this later).
+ -
+
Next I added one new migration in the Account app - this is the migration that copies the data from the player to the equivalent account-named copies in the database. Since Player will not exist if you run this from scratch you have to make sure that the Player model exists at that point in the migration chain. You can't just do this with a normal import and traceback, you need to use the migration infrastructure. This kind of check works:
+
+ -
+
Now, a lot of my other apps/models has ForeignKey or Many2Many relations to the Player model. Aided by viewing the tables in the database I visited all of those and added a migration to each where I duplicated the player-relation with a duplicate account relation. So at this point I had set up a parallel, co-existing duplicate of the Player model, named Account.
+
+ -
+
I now made sure to commit my changes to git and tag this position in the version history with a clear git tag for later reference. This is an important step. We are saving the historical point in time where the player- and account-apps coexisted.5. The git position safely saved, I now went about purging player. I removed the player app and its folder.
+
+ -
+
Since the player folder is not there, it's migrations are not there either. So in another app (any would work) I made a migration to remove the player tables from the database. Thing is, the missing player app means other migrations also cannot reference it. It is possible I could have waited to remove the player/ folder so as to be able to do this bit in pure Python. On the other hand, that might have caused issues since you would be trying to migrate with two Auth users - not sure. As it were, I ended up purging the now useless player-tables with raw SQL:
+
+ -
+
If they are starting fresh, they just run evennia migrate as usual. All migrations referencing player will detect that there is no such app and just be skipped. They are finished, hooray!
+
+ -
+
If they have an existing database, they should make a copy of my renaming-program, then check out the tagged point in the git history I created above, a time when players and accounts coexisted in code.
+
+ -
+
Since an important aspect of Evennia is that users create their own game in a "game" folder, the user can now use my renaming program to interactively rename all occurrencies of
+playerintoaccount(the term 'player' is so ubiquitous that they may have used in in different places they don't want to rename).
+ -
+
Next they run migrations at that point of the git history. This duplicates player data into its renamed counterparts.
+
+ -
+
Now they should check out the latest Evennia again, jumping back to a point where the players application is gone and only accounts exists.
+
+ -
+
Note that our migration history is wrong at this point. It will still contain references to migrations from the now nonexisting players app. When trying to run from scratch, those will fail. We need to force Django to forget that. So the user must here go into their database of choice and run the single SQL statement DELETE FROM django_migations; . This clears the migration history. This is a step I wanted to avoid (since it requires users to use SQL) but in the end I concluded it must be done (and is hopefully a simple enough instruction).
+
+ -
+
Next, we trick the database to again think that we have run all the migrations from the beginning (this time without any mention of players). This is done with the --fake switch: evennia migrate --fake . This fake-applies all migrations and stores in the database that they have run.
+
+ -
+
However, the last few migrations are the ones I added just above. Those actually remove the player-related tables from the database. We really do want to run those. So we fake-fake undo those with evennia migrate --fake typeclasses 0007, which is the application and migration number I used to wipe players. This causes django to forget those migrations so we can run them again.
+
+ -
+
Finally we run evennia migrate. This runs the previously "forgotten" migrations and purges the last vestigest of players from the database. Done!
+
+ -
+
Contrib: Turn-based combat system - this is a full, if intentionally bare-bones implementation of a combat system, meant as a template to put in your particular game system into.
+
+ -
+
Contrib: Clothing sytem - a roleplaying mechanic where a character can 'wear' items and have this show in their descriptions. Worn items can also be layered to hide that underneath. Had plenty of opportunities for extensions to a given game.
+
+ -
+
Contrib: An 'event' system is in the works, for allowing privileged builders to add dynamic code to objects that fires when particular events happen. The PR is not yet merged but promises the oft pondered feature of in-game coding without using softcode (and notably also without the security of softcode!).
+
+ -
+
A lot of PRs, especially from one user, dealt with cleanup and adherence to PEP8 as well as fixing the 'alerts' given by LGTM on our code (LGTM is by the way a pretty nifty service, they parse the code from the github repo without actually running it and try to find problems. Abiding by their advice results is cleaner code and it also found some actual edge-case bugs here and there not covered by unit tests. The joint effort has brought us down from some 600+ alerts to somewhere around 90 - the remaining ones are alerts which I don't agree with or which are not important enough to spend effort on).
+
+ -
+
The help mechanics of Evennia were improved by splitting up the default help command into smaller parts, making it easier to inject some changes to your help system without completely replacing the default one.
+
+ -
+
Evennia's Xterm256 implementation was not correctly including the additional greyscale colors, those were added with new tags |=a ... |=z.
+
+ -
+
Evennia has the ability to relay data to external services through 'bots'. An example of this is the IRC bot, which is a sort of 'player' that sits in an in-game channel and connects that to a counterpart-bot sitting in a remote IRC channel. It allows for direct game-IRC communication, something enjoyed by people in the Evennia demo for many years now. The way the bot was defined used to be pretty hard-coded though. A crafty contributor changed that though, but incorporating the bot mechanism into Evennia's normal message flow. This allows for adding new types of bots or extending existing ones without having to modify Evennia's core. There is already an alternative IRC bot out there that represents everyone in the IRC room as a room full of people in the MUD.
+
+ -
+
Evennia's Attributes is a database table connected to other objects via a ForeignKey relation. This relation is cached on the object. A user however found that for certain implementations, such as using Attributes for large coordinate systems, non-matches (that is failed Attribute lookups on the object) can also be cached and leads to dramatic speed increases for those particular use cases. A PR followed. You live and learn.
+
+ -
+
Another contributor helped improve the EvEditor (Evennia's VIM-like in-game text editor) by giving it a code-mode for editing Python code in-game with auto-indents and code execution. Jump into the code mode with the command @py/edit.
+
+ -
+
Time scheduling is another feature that has been discussed now and then and has now been added through a PR. This means that rather than specifying 'Do this in 400 seconds' you can say 'do this at 12AM, in-game time'. The core system works with the real-world time units. If you want 10 hours to a day or two weeks to a month the same contributor also made an optional calendar contrib for that!
+
+ -
+
A new 'whisper' command was added to the Default cmdset. It's an in-game command for whispering to someone in the same room without other people hearing it. This is a nice thing to have considering Evennia is out-of-the-box pretty much offering the features of a 'talker' type of game.
+
+ -
+
Lots of bug fixes big and small!
+
+ -
+
Some at_* hooks were added, such as at_give(giver, getter). This allows for finer control of the give process without handling all the logics at the command level. There are others hooks in the works but those will not be added until in Evennia 0.7.
+
+ - 2018 (4)
+
+
-
+
+
+
- + September 30 + + +
- + August 18 + + +
- + January 27 + + +
- + January 5 + + +
+
+ - 2021 (2) + + + + +
- 2016 (7)
+
+
-
+
+
+
- + November 30 + + +
- + October 13 + + +
- + July 1 + + +
- + May 31 + + +
- + May 22 + + +
- + March 24 + + +
- + February 14 + + +
+
+ - 2017 (6)
+
+
-
+
+
+
- + October 29 + + +
- + October 1 + + +
- + September 20 + + +
- + August 25 + + +
- + April 23 + + +
- + February 5 + + +
+
+ - 2019 (7) + + + + +
- 2020 (3)
+
+
-
+
+
+
- + November 14 + + +
- + October 20 + + +
- + April 14 + + +
+
+ - 2015 (1)
+
+
-
+
+
+
- + December 17 + + +
+
+ -
+
They allow you to customize individual objects easier. For example you could have a 'Goblin' base prototype with inheriting prototypes Goblin Wizard" and "Goblin Chieftain" - all using the same Typeclass, but with different Attributes, equipment etc.
+
+ -
+
Prototypes can be manipulated and scripted by builders without needing full Python access. This means that while the Typeclasses are designed and supplied by the Python developer, the builders can then use that typeclass to make very different types of object instances in-game.
+
+ -
+
The Portal - this is what players connect to with their clients.
+
+ -
+
The Server - this is the actual game, with the database etc. This can be shutdown and started again without anyone connected to the Portal getting kicked from the game. This allows for hot-adding new Python code into the running Server without any downtime.
+
+ -
+
When starting, the Launcher spawns a new program, the Runner, and then exits. The Runner stays up and starts the Portal and Server. When it starts the Server, it does so in a blocking way and sits waiting in a stalled loop for the Server process to end. As the Server and Portal start they record their current process-ids in .pid files.
+
+ -
+
When reloading, the Launcher writes a flag in a little .restart file. The Launcher then looks up the Server's .pid file and sends a SIGINT signal to that process to tell it to gracefully shut down. As the Server process dies, the Runner next looks at the Server's .restart file. If that indicates a reload is desired, The Runner steps in its loop and starts up a new Server process.
+
+ -
+
When stopping, everything happens like when reloading, except the .restart file tells the Runner that it should just exit the loop and let the Server stay down. The Launcher also looks at the Portal's .pid file and sends a SIGINT signal to kill it. Internally the processes catch the SIGINT and close gracefully.
+
+ -
+
When starting, the Launcher spawns the Portal and tries to connect to it as an AMP client as soon as it can. The Portal in turn spawns the Server. When the Server AMP client connects back to the Portal, the Portal reports back to the Launcher over the AMP connection. The Launcher then prints to the user and disconnects.
+
+ -
+
When reloading, the Launcher connects to the Portal and gives it a reload-command. The Portal then tells the Server (over their AMP connection) to shutdown. Once the Portal sees that the Server has disconnected, it spawns a new Server. Since the Portal itself knows if a reload or shutdown is desired no external .restart (or .pid) files are needed. It reports the status back to the Launcher that can then disconnect.
+
+ -
+
When stopping, the Launcher sends the "Stop Server" command to the Portal. The Portal tells the Server to shut down and when it has done so it reports back to the Launcher that the Server has stopped. The Launcher then sends the "Stop Portal" command to also stop the Portal. The Launcher waits until the Portal's AMP port dies, at which point it reports the shutdown to the user and stops itself.
+
+ - 2018 (4)
+
+
-
+
+
+
- + September 30 + + +
- + August 18 + + +
- + January 27 + + +
- + January 5 + + +
+
+ - 2021 (2) + + + + +
- 2016 (7)
+
+
-
+
+
+
- + November 30 + + +
- + October 13 + + +
- + July 1 + + +
- + May 31 + + +
- + May 22 + + +
- + March 24 + + +
- + February 14 + + +
+
+ - 2017 (6)
+
+
-
+
+
+
- + October 29 + + +
- + October 1 + + +
- + September 20 + + +
- + August 25 + + +
- + April 23 + + +
- + February 5 + + +
+
+ - 2019 (7) + + + + +
- 2020 (3)
+
+
-
+
+
+
- + November 14 + + +
- + October 20 + + +
- + April 14 + + +
+
+ - 2015 (1)
+
+
-
+
+
+
- + December 17 + + +
+
+ -
+
As soon as an item/resource is discovered, everyone in the room must be able to access it immediately.
+
+ -
+
There can be no inventory. Nothing can ever be picked up and tied to a specific player.
+
+ -
+
As soon as a discovery is made, this must be echoed to the entire room (it must not be up to the finder to announce what they found to everyone else).
+
+ - No puzzles must require more than one player to solve. While one could indeed create some very cool puzzles where people collaborate, it's simply not feasible to do so with random strangers on the internet. At any moment the other guy may log off and leave you stuck. And that's if you even find someone logged in at the same time in the first place! The room should always be possible to solve solo, from beginning to end. +
-
+
The 'normal' state: When you use look you see the room description.
+
+ -
+
The 'focused' state: You focus on a specific object with the examine
+command (aliases are ex or just e). Now object-specific actions become available to you. Use examine again to "un-focus".
+ - 2021 (5)
+
- 2018 (4)
+ +- - November 10 + September 30
- - October 1 + August 18
- - May 1 + January 27 +
- + January 5 + + +
- 2021 (2) + +
--
+
+
- March 21 @@ -63,13 +75,137 @@
- 2020 (1) +
- 2016 (7) + +
+ +-
+
+
+
- + November 30 + + +
- + October 13 + + +
- + July 1 + + +
- + May 31 + + +
- + May 22 + + +
- + March 24 + + +
- + February 14 + + +
- 2017 (6) + +
+ +-
+
+
+
- + October 29 + + +
- + October 1 + + +
- + September 20 + + +
- + August 25 + + +
- + April 23 + + +
- + February 5 + + +
- 2019 (7) + + +
+ +- 2020 (3)
+ +- - May 2 + November 14 + + +
- + October 20 + + +
- + April 14 + + +
- 2015 (1) + +
-
+
+
+
- + December 17
- 2018 (4)
-
+
Big web client improvements (courtesy of contributor friarzen) - players can now save and restore pane layouts directly in the client (so you could have a separate pane for channel chatter, another for look-returns, two input panes etc etc).
+
+ -
+
The layout changes makes it easier for devs to create default layouts to offer to players of their game. People in the Evennia community have already started doing very cool stuff with this, I'll try to gather screenshots for a future blog.
+
+ -
+
Allow to redirect video/music to separate panes.
+
+ -
+
Many other fixes, such as improving the input-history behavior.
+
+ -
+
The EvMenu class was refactored to be easier to override. For example, all messages now go through EvMenu.msg which allows for easy customization. It also defaults to sending with a type of "menu", making it easier to redirect menus to seprate panes in the webclient.
+
+ -
+
In a node, EvMenu is now accessed via the much more logically named .ndb._evmenu instead of .ndb._menutree (the old name still works for backwards compatibility, but is deprecated).
+
+ -
+
New optional EvMenu template system for quickly building simpler EvMenus without needing so much code. This makes it easy to catch and parse arbitrary input from the user and redirect to the correct node as needed. Creating menu nodes as functions still work (and is a lot more powerful), this can be mixed with templating to create different effects.
+
+ -
+
INLINEFUNC_STACK_MAXSIZE is an integer that allows to control how big the inlinefunc nesting stacksize is.
+
+ -
+
New DEFAULT_CHANNELS setting to allow customization of which channels should be initialized on startup. This can be modified after initial server start.
+
+ -
+
CHANNEL_HANDLER_CLASS allows for specifying an alternative to the default ChannelHandler if wanting to change how Channels behave.
+
+ -
+
SERVER_LOG_DAY_ROTATION defines how many days the server log should run before being force-rotated (default is seven days).
+
+ -
+
SERVER_LOG_MAX_SIZE specifies how big the log must be before it auto-rotates (even if SERVER_LOG_DAY_ROTATION days has not passed yet).
+
+ -
+
PORTAL_LOG_DAY_ROTATION, PORTA_LOG_MAX_SIZE - equivalent for the Portal.
+
+ -
+
The EvMore pager saw big performance speedups, making the viewing of large numbers of entries much snappier. You can now also paginate EvTables directly and create custom pagers by override the EvMore class (useful if you want to e.g. do a EvTable per-page).
+
+ -
+
Improvement to the multi-match parser: Trying to get for example 3-box will now fail with a no-found if there are only two boxes in the room (before it would show the multi-match menu).
+
+ -
+
New inside_rec lockfunc to recursively check if an object is inside another. Putting this on a room will thus also check the contents of any objects in the room, not only the contents themselves. Or if you had something in your wallet (a container).
+
+ -
+
New $random inlinefunc for producing a random number in strings.
+
+ -
+
TickerHandler.add() now returns a store_key to uniquely describe the ticker just added. The TickerHandler.remove() accepts a new kwarg store_key for removing the ticker - this makes it easier to manage tickers instead having to insert the full specifications of the ticker to remove it.
+
+ -
+
Many fixes to the spawn command and prototype functionality. The new spawn/raw flag will now return the prototype-dict so one can manually edit and copy&paste it.
+
+ -
+
The evennia.GLOBAL_SCRIPTS container will now contain all global scripts, not only those explicitly created with the GLOBAL_SCRIPTS setting.
+
+ -
+
The list_to_string utility converts a list to a nice string-representation, such as ["a", "b", "c", "d"] -> "a, b, c and d". The function is renamed to iter_to_string (but old name still works) and now also works with generators and will not crash even when provided a single value.
+
+ -
+
A lot of bug fixes and stability fixes!
+
+ -
+
New evennia.com: https://evennia.com
+
+ -
+
New static documentation: https://evennia.com/docs/latest
+
+ -
+
EvMore will paginate and properly handle both EvTables and database query output. For huge data sets, pagination can give a 100-fold speed-increase. This is noticeable e.g. in the scripts and spawn/list commands, once you have a lot of items.
+
+ -
+
EvMenu templating language, to make it easier to create simpler menus.
+
+ -
+
Webclient improvements: Cleanup of interface and the ability for players to save/load their pane layouts from the client. The developer can still provide a default for them to start out with.
+
+ -
+
MUD/Evennia Intro wizard to the tutorial world to explain basic game controls in an interactive way.
+
+ -
+
Default channels can now be defined in settings instead of having to do so from in-game.
+
+ -
+
New documentation system (see below).
+
+ -
+
Many, many bug fixes and optimizations!
+
+ -
+
Napoleon to convert Google-style docstrings to reST on the fly
+
+ -
+
recommonmark to convert our markdown wiki pages to reST on compile-time
+
+ -
+
sphinx-multiversion to merge docs from one or more GIT branches into a documentation where you can select between the versions.
+
+ -
+
Whereas the wiki is itself version-controlled, we cannot show multiple versions of the wiki at the same time. This makes it hard to update the documentation at the same time as non-released code is being written. This is probably my main reason for doing the change.
+
+ -
+
The wiki today consists of some 200+ pages. It is hard to get an overview of what is where and what needs to be updated.
+
+ -
+
The wiki word-search functionality is not really great.
+
+ -
+
It's impossible to review changes before they go live, to check consistency and style. This has led to some documentation pages overlapping.
+
+ -
+
Building the documentation to local HTML or PDF is an archaic process that I doubt anyone but me has done with any regularity.
+
+
-
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ A summary of a year
+ ¶
+ - December 17, 2015
+
+A summary of a year
+
+As 2015 is slowly drawing to an end, I looked back through Evennia's repository to see just what was going on this year. And it turns out it was a lot! I honestly didn't remember some things happened as recently as they did.
+Note: For those reading this not familiar with Evennia, it's a Python library for creating MUDs (text-based multiplayer games).
+Making Evennia into a library
+In February of 2015 we merged what was likely the biggest change happening for a good while in Evennia - the complete refactoring of the Evennia repository into a library. It used to be that when you cloned the Evennia repo, it would come with a pre-made game/ folder where you were supposed to put your custom files. Mixing the stuff you downloaded from us with your own files (which you might want to keep under version control of your own) was not a very clean solution.
+In the big "library update", we instead created a stand-alone evennia program which you use to create your own "game dir" with pre-created templates. Not only does this allow you to treat the cloned evennia repo as a proper library, you can also use the same evennia install for multiple games and makes it a lot clearer just what comes from us and what is your custom code.
+Below is a fun Gource representation (courtesy of Youtuber Landon Wilkins) of how the Evennia repository structure has changed over the years. You can see the latest library-change a little after the 3minute, 20 second mark.
+Typeclasses into proxies
+At the same time as the library change, I also completely overhauled the way typeclasses are represented in Evennia: Typeclasses are Python classes that links back to a database model under the hood. They used to use a custom overloading of varioust get/set methods, now they instead utilize django proxy models extended to support multiple inheritance. T
+his radically increased performance and made the code considerably cleaner, as well as completely hid the core django model from the end user (no longer a need to track if you were dealing with a model or its typeclass - you only ever run into typeclasses). This, together with the library-model led to some changes in people's source codes.
+Even so, this change led to a lot less problems and edge-cases than I had anticipated: it seems more people had issues with upgrading django than with adopting their codes to the new typeclass changes ...
+Evennia Autodocs
+Following the big library merger I sat down to write a more comprehensive autodoc utility. We had been distributing a Doxygen config file with the repo for a long time, but I wanted something that integrated with our github wiki, using markdown in the source (because frankly, while Sphinx produces very pretty output, ReST markup looks really ugly in source code, in my opinion).
+The result was the api2md program, which is now a part of our wiki repository. It allows our source code to be decorated in "Google style", very readable output:
+
+def funcname(a, b, c, d=False): """
+
+ This is a brief introduction to the
+
+ function/class/method
+
+
+
+ Args:
+
+ a (str): This is a string argument that
+
+ we can talk about over multiple lines.
+
+ b (int or str): Another argument
+
+ c (list): A list argument
+
+ d (bool, optional): An optional keyword argument
+
+
+
+ Returns:
+
+ str: The result of the function
+
+
+
+ Notes:
+
+ This is an example function. If `d=True`, something
+
+ amazing will happen.
+
+
+
+ """
+
+
+This will be parsed and converted to a Markdown entry and put into the Github wiki, one page per module. The result is the automatically generated Evennia API autodocs, reachable as any other wiki page.
+The convertion/prettification of all core functions of Evennia to actually use the Google-style docstrings took almost all year, finishing late in autumn. But now almost all of Evennia uses this style. Coincidentally this also secures us at a 45% comment/code ratio. This places us in the top 10% of well-documented open-source projects according to openhub (gotta love statistics).
+Imaginary realities / Optional Realities
+Spring of 2015 saw some more articles for the Imaginary Realities e-zine as well as some for the newly-opened Optional Realities web forum (unrelated, despite the similar name). The latter was made by a team working on a commercial Evennia-based sci-fi game, but the forums were open for other games (of any engine) and general discussion on mud and mud design.
+Optional Realities published an impressive range of articles (one every week for several months) and organized several very interesting mud-related contests. It did, I think, a lot for bringing some new life to the mud-development scene. Unfortunately Optional Realities suffered a complete database loss towards the end of the year, forcing it to sort of reboot from scratch. I hope it will rebound and that the articles can be put back online again!
+Ainneve
+Over summer I put out a general roll call for developers willing to lead the development of a small but fully functioning Evennia demo game - a project separate from the main Evennia development. The idea is to have something working for people to rip out and start from. The response to my request was very good and we relatively quickly ended up with two devs willing to lead and direct the effort.
+The work-in-progress demo game they started is called Ainneve. It uses the base Open Adventure RPG rules and is distributed using the same liberal licence as Evennia.
+Ainneve has been sputtering along throughout autumn and winter, and while progress has been a bit ... sporadic, it seems to attract new volunteers to help out. As more of the base systems gets finalized there is going to be even more "low hanging fruit" for people to jump in and help with.
+EvMenu, EvMore and EvEditor, RPSystem
+In July I merged some new systems into Evennia's utilities library. EvMenu is a class that builds an in-game menu. It uses multiple-choice questions for the user to navigate its nodes. I had a "menusystem" in our contrib/ folder since many years, but it was showing its age and when I found I myself didn't really understand how it was working I found it time to make something more flexible.
+The EvMore is a page-scroller that allows the server to pause long texts and wait for the user to press a key before continuing. It's functionality is similar to the unix more program.
+For its part, EvEditor has existed for a while as well, but it was moved from the contrib folder into the main utilility library as it turned out to be an important and common resource (it's basically a mud-version of the classic vi editor).
+Finally, some months later, in September, I added the rpsystem and rplanguage contribution modules. The former is an author-stance recognition system similar to what is seen in some rp-heavy muds (where you don't know/see people's name off the bat, but only their description, until you manually assign a name to them).
+The rplanguage module is used for handling foreign (fantasy) languages by obfuscating words heard by different parties depending on their relative language skills.
+Python 3 ... some day
+As we know, Evennia uses Python 2. In autumn of 2015 first one and then two of our users took upon themselves to help make Evennia a little more ready for running also under Python 3. After a lot of work, Evennia's core is now using code syntax that is compatible with both Python 2 and 3.
+We don't run under Python 3 at this point though. This is not something under our control, but is due to Twisted not supporting Python 3 yet. But when it becomes possible, we are now better prepared for transitioning to a point where we can (hopefully) support both main Python versions.
+EvCast
+In September, user whitenoise started his "EvCast" video tutorial series on Evennia. There are so far two episodes, one on installing Evennia and the second on general Python concepts you need to use Evennia efficiently:
+
+Python.__init__ Podcast
+In the end of September I was interviewed by the hosts of the python.init podcast. Turned into more than an hour of discussion about Evennia. T'was fun! You can listen to it here.
+Nested inlinefuncs
+Towards the end of the year I got (via Optional Realities) lured to participate in another text-gaming related website, musoapbox. This is a forum primarily populated by players from the MUSH-side of text-gaming. After some back and forth they made a strong case for increasing the functionality of Evennia's inlinefunctions.
+An inlinefunction is, in Evennia, a function call embedded in a string sent to the server. This is parsed and executed (no, there is no dangerous eval happening, the call is parsed as text and then called as a normal function call). It allows for text to be dynamically replaced at run-time. What the MUSHers suggested was to also allow those inlinefunc's to be nestable - that is, to implement a call stack. The nestable form of inlinefuncs was merged with Evennia master at the end of November.
+Patreon
+This actually happened already back in February: after some requests for more ways to support Evennia development, I opened a Patreon page. And here at the end of the year, a whole ten patrons have signed up for it. Very encouraging!
+Next year
+In 2016 the first upcoming thing that comes to mind is push out the changes to the webclient infrastructure. That has been a long time coming since I've been unsure of how to proceed on it for quite some time. The goal is to make the webclient a lot more "pluggable" and modular than it is, and to clean up its API and way of communicating with the server. Overall I think the web-side of things need some love.
+I'll likely put together some more general-use contribs as well, I have some possibles in mind.
+We'll continue squashing bugs and work down our roadmap.
+I'll also try to get an Evennia Wikipedia.org page together, if you want to look at how it's progressing and help editing it, see the Evennia mailing list for the link.
+... And a lot more I don't know yet, no doubt! On towards a new year!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2016.html b/devblog/html/devblog2016.html
new file mode 100644
index 0000000000..fb4165edac
--- /dev/null
+++ b/devblog/html/devblog2016.html
@@ -0,0 +1,533 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Birthday retrospective
+ ¶
+ - November 30, 2016
+
+
+So, recently Evennia celebrated its ten-year anniversary. That is, it was on Nov 20, 2006, Greg Taylor made the first repo commit to what would eventually become the Evennia of today. Greg has said that Evennia started out as a "weird experiment" of building a MUD/MUX using Django. The strange name he got from a cheesy NPC in the Guild Wars MMORPG and Greg's first post to the mailing list also echoes the experimental intention of the codebase. The merger with Twisted came pretty early too, replacing the early asyncore hack he used and immediately seeing a massive speedup. Evennia got attention from the MUD community - clearly a Python-based MUD system sounded attractive.
+When I first joined the project I had been looking at doing something MUD-like in Python for a good while. I had looked over the various existing Python code bases at the time and found them all to be either abandoned or very limited. I had a few week's stunt working with pymoo before asking myself why I was going through the trouble of parsing a custom script language ... in Python ... Why not use Python throughout? This is when I came upon Evennia. I started making contributions and around 2010 I took over the development as real life commitments forced Greg to step down.
+Over the years we have gone through a series of changes. We have gone from using SVN to Mercurial and then to using GIT. We have transited from GoogleCode to GitHub - the main problem of which was converting the wiki documentation (Evennia has extensive documentation).
+For a long time we used Python's reload() function to add code to the running game. It worked ... sometimes, depending on what you changed. Eventually it turned out to be so unpredictable that we now use two processes, one to connect clients to and the other running the game, meaning we can completely restart one process without disconnecting anyone.
+Back in the day you were also expected to create your own game in a folder game/ inside the Evennia repo itself. It made it really hard for us to update that folder without creating merge conflicts all over. Now Evennia is a proper library and the code you write is properly separated from ours.
+So in summary, many things have happened over the years, much of it documented in this blog. With 3500 commits, 28 000 lines of code (+46% comments) and some 25 people contributing in the last year, Openhub lists us as
+
+"A mature, well-established codebase with a stable commit history, a large development team and very well documented source code".
+
+It's just words compiled by an algorithm, but they still feel kinda good!
+While Evennia was always meant to be used for any type of multiplayer text game, this general use have been expanded and cleaned up a lot over the years.
+This has been reflected in the width of people wanting to use it for different genres: Over time the MUSH people influenced us into adding the option to play the same character from many different clients at the same time (apparently, playing on the bus and then continuing on another device later is common for such games). Others have wanted to use Evennia for interactive fiction, for hack&slash, deep roleplay, strategy, education or just for learning Python.
+Since Evennia is a framework/library and tries to not impose any particular game systems, it means there is much work to do when building a game using Evennia. The result is that there are dozens of games "in production" using Evennia (and more we probably don't know about), but few public releases yet.
+The first active "game" may have been an Evennia game/chat supporting the Russian version of 4chan... The community driven Evennia demo-game Ainneve is also progressing, recently adding combat for testing. This is aimed at offering an example of more game-specific code people can build from (the way Diku does). There are similar projects meant for helping people create RPI (RolePlay Intensive) and MUSH-style games. That said, the Evennia-game Arx, After the Reckoning is progressing through beta at a good clip and is showing all signs of becoming the first full-fledged released Evennia game.
+So cheers, Evennia for turning 10. That's enough of the introspection and history. I'll get back to more technical aspects in the next post.
+
+
+
+
+
+
+
+ Season of fixes
+ ¶
+ - October 13, 2016
+
+
+The last few months has been dominated by bug-fixing and testing in Evennia-land. A lot more new users appears to be starting to use Evennia, especially from the MUSH world where the Evennia-based Arx, After the Reckoning is, while still in alpha, currently leading the charge.
+With a new influx of users comes the application of all sorts of use- and edge-cases that stretch and exercise the framework in all the places where it matters. There is no better test of code than new users trying to use it unsupervised! Evennia is holding up well overall but there are always things that can be improved.
+
+
+A fun thing with a growing user base is that we are also starting to see a lot more Pull requests and contributions. Thanks a lot, keep 'em coming!
+
+
+The fixing and tightening of the nuts and bolts will likely continue the remainder of the year. I'm currently working on a refactoring of the way command sets are merged together (see the end of my blog post on Evennia in pictures for a brief summary of the command system). But with so much new blood in the community, who can tell where things will turn from here!
+
+
+
+
+
+
+
+ The art of sharing nicks and descriptions
+ ¶
+ - July 1, 2016
+
+
+In the month or so since the merger of Evennia's development branch and all its web-client updates, we have been in bug-fixing mode as more people use and stress the code.
+There have been some new features as well though - I thought it could be interesting to those of you not slavishly following the mailing list.
+Shared web login
+When you are logged into the website you will now also auto-login to your account in the web client - no need to re-enter the login information! The inverse is also true. You still need to connect to game at least once to create the account, but after that you will stay connected while the browser session lasts.
+Behind the scenes the shared login uses cookies linked to server-side Django sessions which is a robust and safe way to manage access tokens. Obviously browser sessions are irrelevant to telnet- or ssh connections.
+Extended Nicks
+Evennia's nick(name) system is a way to create a personal alias for things in game - both to on-the-fly replacing text you input and for referring to in-game objects. In the old implementation this replacement was simply matched from the beginning of the input - if the string matched, it was replaced with the nick.
+In this new implementation, the matching part can be much more elaborate. For example you can catch arguments and put those arguments into the replacement nick in another order.
+Let's say we often use the @dig command this limited way:
+
+@dig roomname;alias = exit;alias, backexit;alias
+
+Let's say we find this syntax unintuitive. The new nick system allows to change this by catching the arguments in your nick and put it into the "real" command. Here is an example of a syntax putting the aliases in parentheses and separating all components with commas:
+> nick newroom $1($2), $3($4), $5($6) = @dig $1;$2 = $3;$4, $5;$6
+From here on you can now create your rooms with entries like this:
+> newroom The great castle(castle), to the castle(castle), back to the path(back)
+Multidescer contrib
+I have added a new "multidescer" to the contrib folder. A multidescer is (I think) a MUSH term for a mechanism managing more than one description. You can then combine any of these various descriptions into your "active" description.
+An example of usage:
+desc hat = a blue hat.
+desc basic = This is a tall man with narrow features.
+desc clothing = He is wearing black, flowing robes.
+These commands store the description on the Character and references them as unique keywords. Next we can combine these strings together in any order to build the actual current description:
+> desc/set basic + |/ + clothing + On his head he has + hat
+> look self
+This is a tall man with narrow features.
+He is wearing black, flowing robes. On his head he has a blue hat.
+This allows for both very flexible and easy-to-update descriptions but also a way to handle freeform equipment and clothing. And you can of course use the nick system to pre-format the output
+> nick setdesc $1 $2 $3 $4 = $1 + |/ + clothing + On his head he has a $4
+This way you can clothe yourself in different outfits easily using the same output format:
+> setdesc basic clothing hat
+The multidescer is a single, self-contained command that is easy to import and add to your game as needed.
+... There's also plenty of bug fixes, documentation work and other minor things or course.
+Anyway, summer is now upon us here in the northern hemisphere so things will calm down for a bit, at least from my end. Have a good 'un!
+
+
+
+
+
+
+
+ Evennia in Pictures
+ ¶
+ - May 31, 2016
+
+This article describes the MU* development system Evennia using pictures!
+This article was originally written for Optional Realities.
+Since it is no longer available to read on OR, I'm reposting it in full here.
+Figure 1: The parts of the Evennia library
+
+Evennia is a game development library. What you see in Figure 1 is the part you download from us. This will not run on its own, we will soon initialize the missing “jigsaw puzzle” piece on the left. But first let’s look at what we’ve got.
+Looking at Figure 1 you will notice that Evennia internally has two components, the Portal and the Server. These will run as separate processes.
+The Portal tracks all connections to the outside world and understands Telnet protocols, websockets, SSH and so on. It knows nothing about the database or the game state. Data sent between the Portal and the Server is protocol-agnostic, meaning the Server sends/receives the same data regardless of how the user is connected. Hiding behind the Portal also means that the Server can be completely rebooted without anyone getting disconnected.
+The Server is the main “mud driver” and handles everything related to the game world and its database. It's asynchronous and uses Twisted. In the same process of the Server is also the Evennia web server component that serves the game’s website. That the Server and webserver are accessing the database in the same process allows for a consistent game state without any concerns for caching or race condition issues.
+Now, let’s get a game going. We’ll call it mygame. Original, isn’t it?
+Figure 2: The full setup for mygame
+
+After installing evennia you will have the evennia command available. Using this you create a game directory - the darker grey piece in Figure 2 that was missing previously. This is where you will create your dream game!
+During initialization, Evennia will create Python module templates in mygame/ and link up all configurations to make mygame a fully functioning, if empty, game, ready to start extending. Two more commands will create your database and then start the server. From this point on, mygame is up and running and you can connect to your new game with telnet on localhost:4000 or by pointing your browser to http://localhost:4001.
+Now, our new mygame world needs Characters, locations, items and more! These we commonly refer to as game entities. Let’s see how Evennia handles those.
+Figure 3: The Database Abstraction of Evennia entities
+
+Evennia is fully persistent and abstracts its database in Python using Django. The database tables are few and generic, each represented by a single Python class. As seen in Figure 3, the example ObjectDB Python class represents one database table. The properties on the class are the columns (fields) of the table. Each row is an instance of the class (one entity in the game).
+Among the example columns shown is the key (name) of the ObjectDB entity as well as a Foreign key-relationship for its current “location”. From the above we can see that Trigger is in the Dungeon, carrying his trusty crossbow Old Betsy!
+The db_typeclass_path is an important field. This is a python-style path and tells Evennia which subclass of ObjectDB is actually representing this entity.
+Figure 4: Inheriting classes to customize entities
+
+In Figure 4 we see the (somewhat simplified) Python class inheritance tree that you as an Evennia developer will see, along with the three instanced entities.
+ObjectDB represents stuff you will actually see in-game and its child classes implement all the handlers, helper code and the hook methods that Evennia makes use of. In your mygame/ folder you just import these and overload the things you want to modify. In this way, the Crossbow is modified to do the stuff only crossbows can do and CastleRoom adds whatever it is that is special about rooms in the castle.
+When creating a new entity in-game, a new row will automatically be created in the database table and then “Trigger” will appear in-game! If we, in code, search the database for Trigger, we will get an instance of the Character class back - a Python object we can work with normally.
+Looking at this you may think that you will be making a lot of classes for every different object in the game. Your exact layout is up to you but Evennia also offers other ways to customize each individual object, as exemplified by Figure 5.
+Figure 5: Adding persistent Attributes to a game entity.
+
+The Attribute is another class directly tied to the database behind the scenes. Each Attribute basically has a key, a value and a ForeignKey relation to another ObjectDB. An Attribute serializes Python constructs into the database, meaning you can store basically any valid Python, like the dictionary of skills seen in Figure 5. The “strength” and “skills” Attributes will henceforth be reachable directly from the Trigger object. This (and a few other resources) allow you to create individualized entities while only needing to create classes for those that really behave fundamentally different.
+Figure 6: Sessions, Players and Objects
+
+Trigger is most likely played by a human. This human connects to the game via one or more Sessions, one for each client they connect with. Their account on mygame is represented by a PlayerDB entity. The PlayerDB holds the password and other account info but has no existence in the game world. Through the PlayerDB entity, Sessions can control (“puppet”) one or more ObjectDB entities in-game.
+In Figure 6, a user is connected to the game with three Sessions simultaneously. They are logged in to their Player account Richard. Through these Sessions they are simultaneously puppeting the in-game entities Trigger and Sir Hiss. Evennia can be configured to allow or disallow a range of different gaming styles like this.
+Now, for users to be able to control their game entities and actually play the game, they need to be able to send Commands.
+Figure 7: Commands are Python classes too
+
+Commands represent anything a user can input actively to the game, such as the look command, get, quit, emote and so on.
+Each Command handles both argument parsing and execution. Since each Command is described with a normal Python class, it means that you can implement parsing once and then just have the rest of your commands inherit the effect. In Figure 7, the DIKUCommand parent class implements parsing of all the syntax common for all DIKU-style commands so CmdLook and others won’t have to.
+Figure 8: Commands are grouped together in sets and always associated with game entities.
+
+Commands in Evennia are always joined together in Command Sets. These are containers that can hold many Command instances. A given Command class can contribute Command instances to any number of Command Sets. These sets are always associated with game entities. In Figure 8, Trigger has received a Command Set with a bunch of useful commands that he (and by extension his controlling Player) can now use.
+Figure 9: Command Sets can affect those around them
+
+Trigger’s Command Set is only available to himself. In Figure 8 we put a Command Set with three commands on the Dungeon room. The room itself has no use for commands but we configure this set to affect those inside it instead. Note that we let these be different versions of these commands (hence the different color)! We’ll explain why below.
+Figure 10: The name Command “Set” is not just a name
+
+Command Sets can be dynamically (and temporarily) merged together in a similar fashion as Set Theory, except the merge priority can be customized. In Figure 10 we see a Union-type merger where the Commands from Dungeon of the same name temporarily override the commands from Trigger. While in the Dungeon, Trigger will be using this version of those commands. When Trigger leaves, his own Command Set will be restored unharmed.
+Why would we want to do this? Consider for example that the dungeon is in darkness. We can then let the Dungeon’s version of the look command only show the contents of the room if Trigger is carrying a light source. You might also not be able to easily get things in the room without light - you might even be fumbling randomly in your inventory!
+Any number of Command Sets can be merged on the fly. This allows you to implement multiple overlapping states (like combat in a darkened room while intoxicated) without needing huge if statements for every possible combination. The merger is non-destructive, so you can remove cmdsets to get back previous states as needed.
+… And that’s how many illustrations I have the stamina to draw at this time. Hopefully this quick illustrated dive into Evennia helps to clarify some of the basic features of the system!
+
+
+
+
+
+
+
+ Evennia 0.6!
+ ¶
+ - May 22, 2016
+
+
+As of today, I merged the development branch to make version 0.6 of the MU* development system and server Evennia.
+Evennia 0.6 comes with a lot of updates, mainly in the way Evennia talks to the outside world. All communication is now standardized, so there are no particular treatment of things like text - text is just one of any standardized commands being passed between the server the client (whether over telnet, ssh, websockets or ajax/comet).
+For example the user can now easily plug in "inputfuncs" to handle any data coming from the client. If you want your client to offer some particular functionality, you just need to plop in a python function to handle it, server-side. We also now offer a lot of utility functions for things like monitoring change (tell the client whenever your health status changes so it can update a health bar or flash the screen).
+The HTML5 webclient has itself updated considerably. Most is happening behind the scenes though. Notably the webclient's javascript component is split into two:
+
+
+
+There are a truckload of more updates and features that are covered on the mailing list.
+
+
+
+
+
+
+
+ Technical stuff happening
+ ¶
+ - March 24, 2016
+
+
+Hi folks, a bit more technical entry this time. These usually go onto the Evennia mailing list but I thought it would be interesting to put it in the dev-blog for once.
+So, I'm now halfway through the TODO list issue of the wclient development branch as alluded to in the last post. The wclient branch aims to rework and beef up the web client infrastructure of Evennia.
+The first steps, which has been done a while was converting the SSH/SSL and IRC input/output protocols to use the new protocol infrastructure (telnet and websockets was done since before). That's just under-the-hood stuff though. Today I finished the changes to the Monitor/TickerHandlers, which may be of more general interest.
+With the changes to the the way OOB (Out-Of-Band) messages are passing through Evennia (see this mailing list post for more details), the OOBHandler is no more. As discussed there, the handling of incoming data is becoming a lot freer and will be easily expandable to everyone wanting to make for a custom client experience. The idea is thus for Evennia to offer resources for various input commands to make use of, rather than prescribing such functionality in a monolothic way in the OOBHandler. There were three main functionalities the OOBHandler offered, and which will now be offered by separate components:
+
+
+The MonitorHandler
+evennia.MONITOR_HANDLER is the new singleton managing monitoring of on-object field/attribute changes. It is used like this:
+MONITOR_HANDLER.add(obj, field_or_attrname, callback, **kwargs)
+
+Here obj is a database entity, like a Character or another Object. The field_or_attrname is a string giving the name of a db_* database field (like "db_key", "db_location" etc). Any name not starting with db_ is assumed to be the name of an on-object Attribute (like "health"). Henceforth, whenever this field or attribute changes in any way (that is, whenever it is re-saved to the database), the callback will be called with the optional kwargs, as well as a way to easily get to the changed value. As all handlers you can also list and remove monitors using the standard MONITOR_HANDLER.remove(), .all() etc.
+The TickerHandler
+evennia.TICKER_HANDLER should be familiar to Evennia users from before - it's been around for a good while. It allows for creating arbitrary "tickers" that is being "subscribed" to - one ticker will call all subscribers rather than each object or function having its own timer.
+Before, the syntax for adding a new ticker required you specify a typeclassed entity and the name of the method on it to call every N seconds. This will now change. This is the new callsign for creating a new ticker:
+TICKER_HANDLER.add(interval, callback, idstring="", persistent=True, *args, **kwargs)
+
+Here**, interval,** like before, defines how often to call **callback(*args, kwargs).
+The big change here is that callback should be given as a valid, already imported callable, which can be either an on-entity method (like obj.func) or a global function in any module (like world.test.func) - the TickerHandler will analyze it and internally store it properly.
+idstring works as before, to separate tickers with the same intervals. Finally persistent=False means the ticker will behave the same way a Script with persistent=False does: it will survive a server reload but will not survive a server shutdown. This latter functionality is particularly useful for client-side commands since the client Session will also not survive a shutdown.
+... So this is a rather big API change to the TickerHandler, which will mean some conflicts for those of you relying heavily on tickers. Easiest will definitely be to simply stop the old and start new ones. It's not clear yet if we'll offer some automated way to convert old tickers to new ones. Chime in if this is something important to you.
+Happening Next
+The next steps involves making use of these new utilities to implement the basic OOB commands recommended by the MSDP and GMCP protocols along with some recommended functionality. We'll see how long that takes, but progress is being made. And if you are a web guy, do consider helping out.
+
+
+
+
+
+
+
+ Climbing up Branches
+ ¶
+ - February 14, 2016
+
+
+Today I pushed the latest Evennia development branch "wclient". This has a bunch of updates to how Evennia's webclient infrastructure works, by making all exchanged data be treated equal (instead of treating text separately from other types of client instructions).
+It also reworks the javascript client into a library that should be a lot easier to expand on and customize. The actual client GUI is still pretty rudimentary though, so I hope a user with more web development experience can take upon themselves to look it over for best practices.
+A much more detailed description of what is currently going on (including how to check out the latest for yourself) is found in this mailing list post. Enjoy!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2017.html b/devblog/html/devblog2017.html
new file mode 100644
index 0000000000..abb0936264
--- /dev/null
+++ b/devblog/html/devblog2017.html
@@ -0,0 +1,713 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Getting a MUD RP scene going
+ ¶
+ - October 29, 2017
+
+This article is a little different from the normal more technical Evennia-specific content of this blog. It was originally published as a light-hearted addition to the Imaginary Realities e-zine many years ago. While IR is still online it has since dozed off. So I'm reposting it here to bring it to a new audience.
+In roleplay-heavy MUDs (and in other categories of text-based roleplaying games), the concept of scenes become important. A scene in this concept is simply a situation big or small that involves you and your fellow players in interesting role play. A scene can be as simple as two players meeting in the street and exchanging a few words to the dramatic conclusion to a staff-driven quest. Whenever role player-interested players meet, a scene may happen.
+But sometimes scenes won’t come naturally. Sometimes your favourite game has only a few people online, or most of them are hovering in private areas. It’s time to go proactive. Below I offer some archetypes, tropes and ideas for how to get a random Scene started and people interested. The list is based on one I did for a RP-heavy MUD I played some time back.
+Some terms used in the list:
+
+
+Scene starters
+Scene starters are for when you are alone in a room hoping for others to join you (we've all done it). It is considerably easier to run Scene starters if there is some OOC way for other players to know where to find you (such as a list showing who's interesting in roleplay and where they are in the game). If not, it’s best to prepare your starter in a commonly visited central location or hub. You normally trigger the starter whenever another Player enters.
+The Scene starters below are intended as ideas and suggestions, but are also examples of archetypical behaviour I’ve observed myself.
+
The Barfly
+A role playing mud classic since time immemorial. The barfly is alone in a tavern and tends their drink, waiting for things to happen. A passive role, but trivial to setup and easy for other players to jump in on - they just slide up to the bar and ask what's up. Fun variations is the drunk barfly or really, really sad/happy barfly, states which immediately give other Players things to ask about and work with.
+
The Strider
+This is the "dark stranger in the corner" variation of the barfly. It is simple to execute - just sit in a dark tavern corner looking glum and mysterious. Often used by newbie players unsure of the game’s commands. The problem is that unless they know the Strider from before it's hard for other Characters to include him/her in their roleplay in a realistic way. The whole IC point of this trope is after all to avoid attention.
+
The Busybody
+The busybody is keeping busy in this room. Most commonly they are performing their job. If they own a bar or run the shop, they tend it. If they are guardsmen they are standing on patrol. If they are wee jesters they are making fools out of themselves. And so on. This is a great starter since it is both natural, realistic and in-character all at once. The nature of their work may occasionally make it easier or harder for other Characters come up with reasons to interact with them though - it might be harder to motivate why some characters would strike up a conversation with a guardsman than they would with a street vendor.
+The Demagogue
+
This more involved starter involves striking up a loud conversation with an NPC/vNPC. Whenever another Character enters, the Demagogue plays out a small scene where they are "arguing" with the NPC, playing both roles. The argument could be "continuing" or just starting as the new PC enters. It could be about anything from tavern prices to refuting a made-up insult. The advantage of this is that it gives immediate character to the demagogue and to the NPC both. It also makes it easy for the newcomer to get into the scene just by taking sides in the debate.
+
+The Damsel in Distress
+This starter, which of course works both for male and female Characters, sets up the damsel as being in a dependency situation to whomever enters the room next. It involves describing the damsel in a sort of precarious situation that clearly requires an extra hand to resolve. This could be anything: Having their hands full and nearly dropping stuff. Chasing a dog that is running off with their book. Being accosted by vNPC ruffians (which should bugger off quickly, unless roleplaying completely “virtual” combat is your cup of tea). Either way the newcomer has an ongoing scene to react to, and roleplay immediately ensues.
+The Organizer
+
This starter requires that the game has a developed in-game message- or mailing system. If so - use it to explicitly and in-character invite people to a scene! If the organizer is in a position of in-game power, this could make good IC sense - like the lord calling on their vassals to attend some sort of function. But anything from calling in a favor to suggesting a business opportunity or looking for a job works. Throw a party. Get drunk and send an ill-advised love letter. This starter works exceptionally well in combination with Stage director or Aggravator for getting selected Players into a memorable scene.
+
+The Aggravator
+The aggravator starts off on the wrong foot with people. Maybe they lash out due to some perceived injustice or they are just grumpy. This starter does not fit all character concepts. The aggravator should accuse the newly arrived PC for something. It could be something from their common history or something made-up out of the blue. It is an active starter in that it leads the way and forces other PCs into roleplay - if nothing else in order to defend themselves. A simple example is to chide the newly arrived PC for not stopping the vNPC that just ran past them out the door. It's important not to take the aggravator trope too far, especially not when using vNPCs. The idea is to get a scene started with some tension, not to get the other (possibly random) PC into real trouble. No god-modding, remember. If the two Characters are actual enemies though, it may be another matter ...
+The Stage Director
+
This is a more sophisticated starter that is halfway to improvised theater. It sets up a whole little scene involving some event with a number of semi-named vNPCs. The stage director could be directly involved or be a spectator (in which case other PCs can walk up to them and ask what's going on). The event could be anything from a trite bar brawl to a domestic dispute in progress. Or why not a marriage proposal between two vNPCs in the middle of the street! If the stage director is threatened in some way, this is a large-scale version of damsel in distress.
+The nice thing about staged scenes like this is that it gives depth and personality to the game and is often highly appreciated by other Players. If done well, the stage director could give everyone involved a true feeling of being in a living environment.
+The scene could continue to be played out around the PCs also as they interact, making this starter potentially demanding on the stage director. If the other Players are experienced they should pick up on this and maybe even contribute their own vNPCs to the scenario (or the stage director could actively invite other Players to do so). It's important to remember to avoid god-modding here - never dictate another PCs actions, let other Players react as they see fit.
+
+The Lazy Bum
+This is unfortunately the most common of starters and we've probably all done it one time or another. It does not involve anything but simply standing in a room. No action set, no nothing. Just being there, the Character staring blankly into space until something happens. Yeah.
+Scene entrances
+Here are some ideas on how to enter a scene/room with one or more other PCs already involved in role play. It should be noted that if other PCs already have a scene going they might be OOC annoyed if the newcomer muscles in with some room-changing entrance. So you as a Player have to show some consideration here. Check the land and eventual actions set on people in the room. If a great scene is already in progress you shouldn’t need to start your own - instead try to get in on the action!
+
The Mouse
+The most common of entering schemes. The Mouse walks into the room/area not drawing attention to themselves. A simple, passive setup that fits many situations and Character concepts. The mouse is a useful way to enter an already running scene. It is a bit overused though, possibly being The lazy bum of entrances. It seem to imply that it is up to others to notice and respond to the mouse. If really aiming for anonymity, the mouse must emote explicitly that they are not drawing attention to themselves, making it clear to other characters they need not go out of their way to be courteous and notice the newcomer.
+The Ignoranti
+
The ignoranti acts as if they do not notice the other Characters in the room. This entrance variant is useful for crowded or large locations. It is also realistic - just because the “chock-full” tavern has only two PCs in it, it doesn’t mean you would actually immediately notice them. vNPCs are everywhere. The ignoranti must emote their ignorance explicitly, with something like "S/he does not notice the others yet". This entrance makes for a nice variation by allowing the ignoranti and other PCs to "accidentally" bump into each other later in a very natural way.
+
+The Walker
+The walker is just "passing through" this area. This entrance is useful for outdoor areas or minor streets were many Character concepts probably have no real reason to be hanging about more than necessary. The walker is really heading somewhere else and just happens to stop to chat with people in this room. It's an effective entrance that allows for quick, logical exits as well (they just have to 'be on their way'). This is far better than the more common approach of just congesting onto a street room and start greeting people as if all you do is stand in the street all day.
+The Planned Visitor
+
This is a variation on The busybody and the opposite of The walker. The planned visitor needs to come to this room, and that is not in order to chat with random PCs. The visitor will start to perform whatever they are here to do and interaction with others is mere a side effect. The classic take on this trope is to read message boards or to order food and drink. More imaginative ones could be to ask the NPC barkeep for a job, look for a vNPC (which turns out to not be here), repair something, do some sort of inspection or setup for an artistic performance. If done well, others will have plenty of opportunity to ask The Planned Visitor what they are up to. It also makes for a thematic way to exit the scene once you declare your business there done.
+
The Wet Kitten
+A classic that involves entering a scene drenched to the bone, shivering from cold, gasping from heat or otherwise be dramatically and visually affected by whatever weather or situation reigns outside. Common to taverns everywhere. For some reason this entrance rarely instills as much sympathy as one would think - but at least it opens up for other Characters to comment on the weather. Taken to the extreme, this becomes a variation on Damsel in Distress.
+The Third Wheel
+
This is an active, provocative entrance and a variant on the aggravator. It should directly interrupt and involve other PCs in the room entered. The trivial confrontational way to do this is for the intruder to muscle or elbow past other PCs in a rude way, maybe even (attempting to) give them a rough shove (remember to avoid god-modding). This is sure to start off a scene! The more common third-wheel approach is to walk up to another group of conversing PCs and simply jump into their conversation mid-sentence. How this is received depends on the situation and Characters involved.
+In both cases it's important to make it clear that your actions is a conscious RP choice - it’s your Character which is inconsiderate, not the Player behind it. In other words, emote something like “... He/She does not seem to notice or care that s/he is intruding...”
+
The Theatrist
+This is an on-the-fly version of the Stage director or demagogue. Only use if it's clear the currently ongoing scene allows it (so its often a good idea to follow a few emotes in the room before setting this one off). Just like stage director, it starts some sort of background action in the room based on vNPCs. Maybe a brawl, an argument or some other event like a happy announcement. Maybe a vNPC starts hitting on a PC. Or, like the demagogue, the theatrist gets involved in a discussion with an NPC/vNPC. Bartender NPCs are classically useful targets for this. Again, the theatrist must be considerate here, and perceptive so as to not take over an already running scene. Some PCs might forcibly choose to ignore the events going on in order to focus on their ongoing RP, so don't shove it down their throats (no god-modding!)
+
The Non-sequitur
+This, strangely rare, entrance involves running into a crowded room, shouting "Monkeeey!" and then run out again. This one will at least lead to roleplay for the confused people in the room you just visited. And no, don't do this unless you have a very specific and suitable character concept, kids.
+
+The Newbie
+The classic newbie entrance involves walking into a room and saying "Hello" to no one in particular. Bonus points if this is done while ignoring the fact that the room's on fire and the PCs within are all involved in mortal combat. Luckily this entrance trope screams newbie so clearly that players may be urged to pity and lenience. It may in fact be the trigger for getting a more experienced player to take the newbie under their wing and explain a thing or two.
+
+
+
+
+
+
+
+ Evennia in Hacktobergest 2017
+ ¶
+ - October 1, 2017
+
+
+Evennia, the Python MUD/MUSH/MU* creation library participates in the Hacktoberfest 2017 (sign up on that page)! Hacktoberfest is open for all open-source projects like ours. After registering, if you make at least four Pull Requests to a public repo on Github during October (need not just be to Evennia), you win a limited-edition T-shirt!
+The help Evennia out and get your T-Shirt, look at our Issue Tracker. I have marked some issues with "Hacktoberfest" but you could take on any issue you want. Take a look in particular at the Unit test issue if you are looking to get into contributing on a smaller scale while helping us tremendously.
+If you have any questions on contributing (or it's your first time making a Pull Request), don't be shy to drop into #evennia on irc.freenode.net or ask in our forum/mailing list. Have fun!
+
+
+
+
+
+
+
+ Evennia 0.7 released
+ ¶
+ - September 20, 2017
+
+Evennia 0.7 released
+
+As of today Evennia 0.7 is officially out! Evennia is a Python framework and -server for creating text-based multiplayer games (MU*).
+A big thank you to all collaborators that have helped with code and testing along the way!
+Here is the hefty forum post that details how you migrate to Evennia 0.7.
+Evennia 0.7 comes with a range of changes and updates (these are just the ones merged from the latest devel branch, a lot more has happened since 0.6 that were already in master):
+
+
+New contribs (optional plugins) (selection, new since 0.6 but many have been available on master branch for a while):
+
+
+A more technical list from the main announcement post:
+
+
+
+
+
+
+
+
+
+ Renaming Django's Auth User and App
+ ¶
+ - August 25, 2017
+
+
+Now that Evennia's devel branch (what will become Evennia 0.7) is slowly approaching completion, I thought I'd try to document an aspect of it that probably took me the longest to figure out. One change in Evennia 0.7 is that the Django model named "Player" changes name to "Account". Over time it has become clear that the old name didn't properly reflected the intention of the model. Sounds like a simple change, right? Well, it was not.
+Briefly on migrations
+First some background. A Django migration is a small Python file sitting in migrations/ sub folders throughout Evennia. A migration describes how our database schema changes over time, so as we change or update fields or add new features we add new migrations to describe how to go from the old to the new state. You apply them with the evennia migrate command we sometimes ask you to run. If we did not supply migrations, anyone with an existing Evennia database would have to either start from scratch or manually go in and tweak their database to match every upstream change we did.
+Each migration file has a sequential number, like migration_name.0002.py etc. Migrations will run in order but each migration can also "depend" on another. This means for example that a migration in the player/ folder (application) knows that it need to wait for the changes done by a migration in the typeclasses/ folder/app before it can run. Finally, Django stores a table in the database to know which migrations were already run so to not apply them more than once.
+For reference, Evennia is wrapping the django manage commands, so where I refer to evennia migrate below you would use manage.py migrate in most Django applications.
+Our problem
+So I wanted to migrate the database change "Rename the Player model to Account". We had to do this under a series of additional constraints however:
+
+
+Some false starts
+There is no lack of tutorials and help online for solving the problem of renaming a model. I think I tested most of them. But none I found actually ended up addressing these restraints. Especially point 2 in combination with point 3 above is a killer.
+
+
+In the end I concluded that I had to abandon the notion that users be able to just do a single migrate command. Some more work would be needed on the user's part.
+The solution
+In the end I needed to combine the power of migrations with the power of Git. Using Git resolved the Gordian knot about the player folder. Basically the process goes like this:
+
+
+
+ # ...
+
+
+
+ def forwards(apps, schema_editor):
+
+ try:
+
+ PlayerDB = apps.get_model("players", "PlayerDB")
+
+ except LookupError:
+
+ return
+
+
+
+ # copy data from player-tables to database tables here
+
+
+
+ class Migrations(migrations.Migration):
+
+ # ...
+
+ operations = [
+
+ migrations.RunPython(forwards, migrations.RunPython.noop)
+
+ ]
+
+
+
+
+
+ from django.db import connection
+
+
+
+ # ...
+
+
+
+ def _table_exists(db_cursor, tablename):
+
+ "Returns bool if table exists or not"
+
+ sql_check_exists = "SELECT * from %s;" % tablename
+
+ ### [Renaming Django's Auth User and App](https://evennia.blogspot.com/2017/08/renaming-djangos-auth-user-and-app.html)
+
+
+
+And with this, the migration's design was complete. Below is how to actually use it ...
+Running the final migration
+In brief, what our users will do after pulling the latest code is as follows:
+
+
+Conclusions
+And that's it. It's a bit more involved for the end user than I would have liked, and took me much longer than expected to figure out. But it's possible to reproduce and you only need to do it once - and only if you have a database to convert. Whereas this is necessarily specified for Evennia, I hope this might give a hint for other django users aiming to do something like this!
+
+
+
+
+
+
+
+ The luxury of a creative community
+ ¶
+ - April 23, 2017
+
+
+For this blog post I want to focus on the series of very nice pull requests coming in from a growing cadre of contributors over the last few months.
+Contributed goodness
+People have put in a lot of good work to boost Evennia, both by improving existing things and by adding new features. Thanks a lot everyone (below is just a small selection)!
+
+
+About that Evennia 0.7 ...
+So while PRs are popping up left and right in master I've been working in the devel branch towards what will be the Evennia 0.7 release. The branch is not ready for public consumption and testing yet But tentatively it's about halfway there as I am slowly progressing through the tickets. Most of the upcoming features were covered in the previous blog post so I'll leave it at that.
+I just want to end by saying that it's a very luxurious (and awesome) feeling for me to see master-branch Evennia expand with lots of new stuff "without me" so to speak. The power of Open Source indeed!
+
+
+
+
+
+
+
+ News items from the new year
+ ¶
+ - February 5, 2017
+
+
+The last few months have been mostly occupied with fixing bugs and straightening out usage quirks as more and more people take Evennia through its paces.
+Webclient progress
+One of our contributors, mewser/titeuf87 has put in work on implementing part of our roadmap for the webclient. In the first merged batch, the client now has an option window for adjusting and saving settings. This is an important first step towards expanding the client's functionality. Other features is showing help in an (optional) popup window and to report window activity by popup and/or sound.
+The goal for the future is to allow the user or developer to split the client window into panes to which they can then direct various output from the server as they please It's early days still but some of the example designs being discussed can be found in the wiki webclient brainstorm (see the title image of this blog for one of the mockups).
+New server stuff
+Last year saw the death of our old demo server on horizondark.com, luckily the new one at silvren.com has worked out fine with no hickups. As part of setting that up, we also got together a more proper list of recommended hosts for Evennia games. Evennia requires more memory than your average C code base so this is important information to have. It seems most of our users run Evennia on various cloud hosting services rather than from a traditional remote server login.
+Arx going strong
+The currently largest Evennia game, the mush Arx - After the Reckoning has helped a lot in stress testing. Their lead coder Tehom has also been active both in reporting issues and fixing them - kudos! There are however some lingering issues which appears rarely enough that they have not been possible to reproduce yet; we're working on those. Overall though I must say that considering how active Arx is, I would have expected to have seen even more "childhood diseases" than we have.
+Launch scripts and discussions
+It is always interesting with feedback, and some time back another discussion thread erupted over on musoapbox, here. The musoapbox regulars have strong opinions about many things and this time some were critical of Evennia's install process. They felt it was too elaborate with too many steps, especially if you are approaching the system with no knowledge about Python. Apparently the average MUSH server has a much shorter path to go (even though that does require C compiling). Whereas I don't necessarily agree with all notions in that thread, it's valuable feedback - I've long acknowledged that it's hard to know just what is hard or not for a beginner.
+Whereas we are planning to eventually move Evennia to pypi (so you can do pip install evennia), the instructions around getting virtualenv setup is not likely to change. So there is now unix shell scripts supplied with the system for installing on debian-derived systems (Debian, Ubuntu, Mint etc). I also made scripts for automating the setup and launch of Evennia and to use it with linux' initd within the scope of a virtualenv.
+So far these scripts are not tested by enough people to warrant them being generally recommended, but if you are on a supported OS and is interested to try they are found from the top of the Evennia repo, in bin/unix/. More info can be found on their documentation page.
+Docker
+Speaking of installing, Evennia now has an official Docker image, courtesy of the work of contributor and Ainneve dev feend78. The image is automatically kept up-to.date with the latest Evennia repo and allows Evennia to be easily deployed in a production environment (most cloud services supports this). See Docker wiki page for more info.
+Lots of new PRs
+There was a whole slew of contributions waiting for me when returning from Chistmas break, and this has not slowed since. Github makes it easy to contribute and I think we are really starting to see this effect (Google Code back in the day was not as simple in this regard). The best thing with many of these PRs is that they address common things that people need to do but which could be made simpler or more flexible. It's hard to plan for all possibilities, so many people using the system is the best way to find such solutions.
+Apart from the map-creation contribs from last year we also have a new Wildnerness system by mewser/titeuf87. This implements wilderness according to an old idea I had on the mailing list - instead of making a room per location, players get a single room. The room tracks its coordinate in the wildnerness and updates its description and exits dynamically every time you move. This way you could in principle have an infinite wilderness without it taking any space. It's great to see the idea turned into a practical implementation and that it seems to work so well. Will be fun to see what people can do with it in the future!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2018.html b/devblog/html/devblog2018.html
new file mode 100644
index 0000000000..1404b2252c
--- /dev/null
+++ b/devblog/html/devblog2018.html
@@ -0,0 +1,415 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Evennia 0.8 released
+ ¶
+ - September 30, 2018
+
+
After about a year of work and almost 540 commits from close to 20 contributors, Evennia 0.8 is out! Evennia is a Python game server for creating text-based multiplayer games (MUDs, Mushes, etc) using Django and Twisted.
+Some of the upcoming improvements have been covered by previous dev blogs, such as the completely reworked server infrastructure:
+
+as well as the new Online Creation System that allows for editing in-game prototypes using a powerful menu system:
+
+Other improvements are in the web client, which supports split-panes out of the box. The user can split the output area in any number of panes, resize as desired and then assign different types of content to each pane. You can also have panes that absorb "all the rest" or "all" of the content.
+
+There are still some bits which are a bit shaky and there is still much to do with the web client (for example, not that many outgoing messages yet defaults to being tagged in a way that the webclient recognizes). But it's a step forward!
+There are many other improvements for developers, such as easier tools for running debuggers and a lot of new utilities and helper functions. The menu-creation tool (EvMenu) has seen a lot of improvements and also sport a few new decorators for quickly creating multi-page menus with full functionality to flip through and select large numbers of options.
+The community has also chipped in with a large number of optional contributions for developers to use for their own game, such as a full turn-based combat system (divided into convenient chunks for the dev to pick and choose support for everything from magic and potions to equipment and ranged attacks). There are also a range of helper functions for creating simpler menus and build commands as well as auditing tools and additions making better use of Django's very mature security features.
+The more detailed list of improvements and changes can be found in the announcement here. As usual, please report any issues to the issue tracker on github.
+Future
+In the immediate future, we'll focus on resolving any bugs that may have slipped through the cracks and also resolve some other issues in the pipeline.
+But beyond that, work on Evennia 0.9 will begin. And before you ask - yes Evennia 0.9 is the version where we'll move fully to Python3. Our dependencies have now reached a point where this is possible and there will be no intermediary Python2/3 version. There is no timeline for the 0.9 release but it should hopefully not be too tricky for the community to make the jump when the time comes.
+
+
+
+
+
+
+
+ Inline building in upcoming Evennia 0.8
+ ¶
+ - August 18, 2018
+
+
+Evennia, the Python MUD-server game development kit, is slowly creeping closer to its 0.8 release.
+In our development branch I've just pushed the first version of the new OLC (OnLine Creator) system. This is a system to allow builders (who may have limited coding knowledge) to customize and spawn new in-game objects more easily without code access. It's started with the olc command in-game. This is a visual system for manipulating Evennia Prototypes.
+Briefly on Prototypes
+The Prototype is an Evennia concept that has been around a good while. The prototype is a Python dictionary that holds specific keys with values representing properties on a game object. Here's an example of a simple prototype:
+
+ {"key": "My house",
+
+ "typeclass": "typeclasses.houses.MyHouse"}
+
+
+By passing this dict to the spawner, a new object named "My house" will be created. It will be set up with the given typeclass (a 'typeclass' is, in Evennia lingo, a Python class with a database backend). A prototype can specify all aspects of an in-game object - its attributes (like description and other game-specific properties), tags, aliases, location and so on. Prototypes also support inheritance - so you can expand on an existing template without having to add everything fresh every time.
+There are two main reasons for the Prototypes existing in Evennia:
+
+
+What's new
+As said, Prototypes have been around for a good while in Evennia. But in the past they were either manually entered directly as a dict on the command line, or created in code and read from a Python module. The former solution is cumbersome and requires that you know how to build a proper-syntax Python dictionary. The latter requires server code access, making them less useful to builders than they could be.
+Note: If you are visually impaired, each image is also a link to a text-only version.
+
+In Evennia 0.8, while you can still insert the Prototype as a raw dict, spawn/menu or the new olc command opens a new menu-driven interface.
+
+More importantly, builders can now create, save and load prototypes in the database for themselves and other builders to use. The prototypes can be tagged and searched as a joint resource. Builders can also lock prototypes if others are not to be able to read or use them to spawn things. Developers can still supply module-based "read-only" prototypes (for use as starting points or examples to their Builders, for example).
+
+You can now also use the menu to search for and create a new Prototype based on an existing object (if you have access to do so). This makes it quick to start up a new prototype and tweak it for spawning other similar objects. Of course you could spawn temporary objects without saving the prototype as well.
+![The Typeclass defines what 'type' of object this is - the actual working code to use. All spawned objects must have a typeclass. If not given here, the typeclass must be set in one of the prototype's parents. [No typeclass set] ______________________________________________________________________________________________________________________________________________ Back (prototype-parent) | Forward (key) | Index | Validate prototype | Quit 1: evennia.contrib.tutorial_world.mob.Mob 7: evennia.contrib.tutorial_world.objects.TutorialObject 2: evennia.contrib.tutorial_world.objects.Climbable 8: evennia.contrib.tutorial_world.objects.Weapon 3: evennia.contrib.tutorial_world.objects.CrumblingWall 9: evennia.contrib.tutorial_world.objects.WeaponRack 4: evennia.contrib.tutorial_world.objects.LightSource 10: evennia.contrib.tutorial_world.rooms.BridgeRoom 5: evennia.contrib.tutorial_world.objects.Obelisk current: (1/3) 6: evennia.contrib.tutorial_world.objects.Readable next page](https://1.bp.blogspot.com/-DYcYStEWXKk/W3f_-bnH4vI/AAAAAAAAJJY/iv4-GN8NTpUCpBvyXBwMUABG8TTPJYN9ACLcBGAs/s400/Screenshot%2Bfrom%2B2018-08-18%2B13-15-44.png "Typeclass selection, miltipage")
+Builders will likely not know which typeclasses are available in the code base. There are new a few ways to list them. The menu display makes use of Evennia 0.8's new EvMenu improvements, which allows for automatically creating multi-page listings (see example above).
+There is also a new switch to the typeclass command, /list, that will list all available typeclasses outside of the OLC.
+Protfuncs
+Another new feature are Protfuncs. Similarly to how Inlinefuncs allows for calling for the result of a function call inside a text string, Protfuncs allows for calling functions inside a prototype's values. It's given on the form $funcname(arguments), where arguments could themselves contain one or more nested Protfuncs.
+As with other such systems in Evennia, only Python functions in a specific module or modules (given by settings) are available for use as Protfuncs in-game. A bunch of default ones are included out of the box. Protfuncs are called at the time of spawning. So for example, you could set the Attribute
+
+Strength = $randint(5, 20)
+
+to automatically spawn objects with a random strength between 5 and 20.
+![prototype-key: goblin, -tags: [], -locks: spawn:all();edit:all() -desc: Built from goblin prototype-parent: None key: goblin aliases: monster, mob attrs: desc = You see nothing special. strength = $randint(5,20) agility = $random(6,20) magic = 0 tags: mob (category: None) locks: call:true();control:id(1) or perm(Admin);delete:id(1) or perm(Admin);edit:perm(Admin);examine:perm(Builder);get:all();puppet:pperm(Developer) ;tell:perm(Admin);view:all() location: #2 home: #2 No validation errors found. (but errors could still happen at spawn-time) ______________________________________________________________________________________________________________________________________________ Actions: examine <num> | remove <num> Back (index) | Validate prototype | Quit 1: Spawn in prototype's defined location (#2) 2: Spawn in Griatch's location (Limbo) 3: Spawn in Griatch's inventory 4: Update 2 existing objects with this prototype](https://1.bp.blogspot.com/-qHeRpEQTEzU/W3gFpJ9ge5I/AAAAAAAAJJw/-PVcelDk2CsIW1nJwWvMjazcJ9LyKx5pgCLcBGAs/s400/Screenshot%2Bfrom%2B2018-08-18%2B13-40-04.png "Spawning screen")
+When spawning, the olc will validate the prototype and run tests on any Protfunc used. For convenience you can override the spawn-location if any is hard-coded in the prototype.
+
+The system will also allow you to try updating existing objects created from the same-named prototype earlier. It will sample the existing objects and calculate a 'diff' to apply. This is bit is still a bit iffy, with edge cases that still needs fixing.
+Current status
+The OLC is currently in the develop branch of Evennia - what will soon(ish) merge to become Evennia 0.8.
+It's a pretty big piece of code and as such it's still a bit unstable and there are edge cases and display issues to fix. But it would be great with more people trying it out and reporting errors so the childhood issues can be ironed out before release!
+
+
+
+
+
+
+
+ Kicking into gear from a distance
+ ¶
+ - January 27, 2018
+
+
+The last few weeks I have reworked the way Evennia's startup procedure works. This is now finished in the develop branch so I thought I'd mention a little what's going on.
+Evennia, being a server for creating and running text-games (MU*s), consists of two main processes:
+
+
+Since Evennia should be easy to set up and also run easily on Windows as well as on Linux/Mac, we have foregone using the linux process management services but instead offered our own solution. This is how the reload mechanism currently looks in master branch:
+
+Here I've excluded connections irrelevant to reloading, such as the Twisted AMP connection between Portal and Server. Dashed lines suggest a more "temporary" connection than a solid line.
+The Launcher is the evennia program one uses to interact with the Server in the terminal/console. You give it commands like evennia start/stop/reload.
+
+
+The original reason for this Server-Portal-Runner setup is that the Portal is also reloadable in the same way (it's not shown above). But over time I've found that having the Portal reloadable is not very useful - since players get disconnected when the Portal reloads one can just as well stop and start both processes. There are also a few issues with the setup, such as the .pid files going stale if the server is killed in some catastrophic way and various issues with reliably sending signals under Windows. Also, the interactive mode works a little strangely since closing the terminal will actually kill the Runner, not the Server/Portal - so they will keep on running except they can no longer reload ...
+It overall feels a little ... fiddly.
+In develop branch, this is now the new process management setup:
+
+The Portal is now a Twisted AMP server, while the Evennia Server and Launcher are AMP clients. The Runner is no more.
+
+
+So far I really like how this new setup works and while there were some initial issues on Windows (spawning new processes does not quite work they way you expect on that platform) I think this should conceptually be more OS-agnostic than sending kill-signals.
+This solution gives much more control over the processes. It's easy to start/stop the Server behind the portal at will. The Portal knows the Server state and stores the executable-string needed to start the Server. Thus the Server can also itself request to be reloaded by just mimicking the Launcher's instructions.
+The launcher is now only a client connecting to a port, so one difference with this setup is that there is no more 'interactive' mode - that is the Server/Portal will always run as daemons rather than giving log messages directly in the terminal/console. For that reason the Launcher instead has an in-built log-tailing mechanism now. With this the launcher will combine the server/portal logs and print them in real time to easily see errors etc during development.
+The merger of the develop branch is still a good bit off, but anyone may try it out already here: https://github.com/evennia/evennia/tree/develop . Report problems to the issue tracker as usual.
+
+
+
+
+
+
+
+ New year, new stuff
+ ¶
+ - January 5, 2018
+
+
+Happy 2018 everyone! Here's a little summary of the past Evennia year and what is brewing.
+(Evennia is a Python server- and toolbox for creating text-based multiplayer games (MU*)).
+The biggest challenge for me last year Evennia-wise was the release of Evennia 0.7. Especially designing the migration process for arbitrary users migrating the Django auth-user took a lot of thought to figure out as described in my blog post here. But now 0.7 is released and a few initial minor adjustments could be made after feedback from daring pilot testers. The final process of migrating from 0.6 to 0.7 is, while involved, a step-by-step copy&paste list that has worked fine for most to follow. I've gotten far fewer questions and complains about it than could be expected so that's a good sign.
+Working away on the boring but important behind-the-scenes stuff made me less able to keep up with more "mundane" issues and bugs popping up, or with adding new "fun" features to existing code. Luckily the Evennia community has really been thriving this year; It feels like new users pop up in the support channel all the time now. The number of pull requests both fixing issues and offering new features and contribs have really picked up. A bigger part of my time has been spent reviewing Pull Requests this year than any other I think. I would like to take the opportunity to thank everyone contributing, it's really awesome to see others donating their time and energy adding to Evennia. The Hacktoberfest participation was also surprisingly effective in getting people to create PRs - I have a feeling some were just happy to have an "excuse" for getting started to contribute. We should attend that next year too.
+One thing we added with 0.7 was a more formal branching structure: Evennia now uses fixed master and develop branches, where master is for bug-fixes and develop is for new features (things that will eventually become evennia 0.8). This is simple but enough for our needs; it also makes it easier to track new from old now that we are actually doing releases.
+Now that Twisted is at a point where this is possible for us to do, we also now have a sort-of plan for finally moving Evennia to Python 3. I won't personally be actively working on it until after 0.8 is out though. I don't expect both Evennia 0.8 and 0.9 (which will be pure py3) to get released this year, but we'll see - so far contributors have done all the work on the conversion.
+At any rate, this coming year will probably be dominated by catching up on issues and edge cases that are lining our Issue tracker. One side effect of more newcomers is more eyes on the code and finding the creaky-bits. At least for me, most of my Evennia-time will be spent resolving bugs and issues. The fun thing is that unlike previous years this is not only up to me anymore - hopefully others will keep helping to resolve issues/bugs to broaden our bandwidth when it comes to keeping Evennia stable. The faster we can handle the backlog of issues the faster we can focus on new shiny features after all.
+Finally, a continued great thank you to those of you contributing to the Patreon. Even small donations have a great encouraging value when working on something as niche as a Python MU* game server in 2018 - thanks a lot!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2019.html b/devblog/html/devblog2019.html
new file mode 100644
index 0000000000..838772a70b
--- /dev/null
+++ b/devblog/html/devblog2019.html
@@ -0,0 +1,725 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Blackifying and fixing bugs
+ ¶
+ - September 30, 2019
+
+
+Since version 0.9 of Evennia, the MU*-creation framework, was released, work has mainly been focused on bug fixing. But there few new features also already sneaked into master branch, despite technically being changes slated for Evennia 1.0.
+On Frontends
+Contributor friarzen has chipped away at improving Evennia's HTML5 web client. It already had the ability to structure and spawn any number of nested text panes. In the future we want to extend the user's ability to save an restore its layouts and allow developers to offer pre-prepared layouts for their games. Already now though, it has gotten plugins for handling both graphics, sounds and video:
+
+
+Inline image by me (deviantart.com/griatch-art)
+
+A related fun development is Castlelore Studios' development of an Unreal Engine Evennia plugin (this is unaffiliated with core Evennia development and I've not tried it, but it looks pretty nifty!):
+
+
+Image ©Castlelore Studios
+
+On Black
+Evennia's source code is extensively documented and was sort of adhering to the Python formatting standard PEP8. But many places were sort of hit-and-miss and others were formatted with slight variations due to who wrote the code.
+After pre-work and recommendation by Greg Taylor, Evennia has adopted the black autoformatter for its source code. I'm not really convinced that black produces the best output of all possible outputs every time, but as Greg puts it, it's at least consistent in style. We use a line width of 100.
+I have set it up so that whenever a new commit is added to the repo, the black formatter will run on it. It may still produce line widths >100 at times (especially for long strings), but otherwise this reduces the number of different PEP8 infractions in the code a lot.
+On Python3
+Overall the move to Python3 appears to have been pretty uneventful for most users. I've not heard almost any complaints or requests for help with converting an existing game.
+The purely Python2-to-Python3 related bugs have been very limited after launch; almost all have been with unicode/bytes when sending data over the wire.
+People have wholeheartedly adopted the new f-strings though, and some spontaneous PRs have already been made towards converting some of Evennia existing code into using them.
+Post-launch we moved to Django 2.2.2, but the Django 2+ upgrades have been pretty uneventful so far.Some people had issues installing Twisted on Windows since there was no py3.7 binary wheel (causing them to have to compile it from scratch). The rise of the Linux Subsystem on Windows have alleviated most of this though and I've not seen any Windows install issues in a while.
+On Future
+For now we'll stay in bug-fixing mode, with the ocational new feature popping up here and there. In the future we'll move to the develop branch again. I have a slew of things in mind for 1.0.
+Apart from bug fixing and cleaning up the API in several places, I plan to make use of the feedback received over the years to make Evennia a little more accessible for a new user. This means I'll also try reworking and consolidating the tutorials so one can follow them with a more coherent "red thread", as well as improving the documentation in various other ways to help newcomers with the common questions we hear a lot.
+The current project plan (subject to change) is found here. Lots of things to do!
+
+
+
+
+
+
+
+ Evennia 0.9 released
+ ¶
+ - July 4, 2019
+
+
+Last week we released Evennia 0.9, the next version of the open source Python MU* creation system.
+This release is the result of about 10 months of development, featuring 771 commits, 70 closed pull requests from the community and something like 80 issues and feature/requests closed. Thanks everyone!
+The main feature of Evennia 0.9 is that we have finally made the move to Python3. And we burn the bridges behind us; as announced in previous posts we completely drop Python2 support and move exclusively to only support the latest Python3.7.
+Overall the move to Python3 was not too bloody (and much work towards a never published py2+3 version was already done by Evennia contributors in a separate branch earlier). The main issues I ran into were mainly in the changes in how Python3 separates strings from bytes. This became crticial since Evennia implements several connection protocols; there were a lot of edge cases and weird errors appearing where data went to and from the wire.
+A regular user has it a lot easier though. So far people have not had too much trouble converting their games from 2.7 to 3.7. The biggest Linux distros don't all have Py3.7 out of the box though, so that may be a concern for some, we'll see.
+... but Py3 is nowhere all there is to find in this release though! There are a plethora of more features in the latest Evennia, all to make it easier to make the text-based multiplayer game of your dreams.
+You can see a summary of new features in the ML announcement and even more details in the actual CHANGELOG file.
+So what's up next?
+Now follows a period of bug-fixing and stabilizing. Maybe resolve some of those long-standing "tech-dept" issues and overall make Evennia more stable.
+Eventually work will then commence (in the develop branch) on version 1.0 of Evennia. For this next release I think I'll step back from new features a bit and focus on refactoring and cleanup of the API as well as other things around the library's distribution, documentation and presentation.
+But for now, onward to summer vacations.
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 2
+ ¶
+ - May 26, 2019
+
+
+
+
+This is part two of my post-mortem dev-blog about Evscaperoom, the multiplayer, text-based 'escape room' I wrote in Python and Evennia. You can read the first part of the dev blog here.
+This was a game-jam entry I created in a month for the Mud Coder's guild's Game Jam. The theme was One Room. You can play the game for free in your browser or with a traditional MUD client. There are no spoilers in these blog posts.
+Update: These days you can play the Evscaperoom by logging into the Evennia demo game at https://demo.evennia.com. It's just one of the exits you can get through when you enter.
+The first part dealt with the overall game-design aspects. This second, final part will go into details of the code and the systems I built to quickly create all the content. The code referenced here is released under the BSD license and is available on github.
+At the time of this post, players have played Evscaperoom for a little more than a week. At the end I'll share some observations and things I learned along the way.
+Ease of building
+Over the one-month game jam, I spent about four days making the game's 'engine' and toolset with Evennia. The rest of the time was spent using those tools to actually create game content (the story, puzzles etc).
+An important thing was that I didn't want to do any traditional in-game 'building'. That is - no logging into the game and running various commands to build objects and rooms. This is partly because I wanted rooms to be buildable on-demand, but also because I didn't want my game to only exist in the database but in actual version-controllable python modules.
+So all of the Evscaperoom is created in code (notably in the game states discussed below). This made it so that I could add unit tests to quickly find bugs and edge cases. It also made it easy to just clone the full game to an online server, init a database and run Evennia on it in a docker when time came to make it public.
+Overall game structure
+
+Main menu
+The game loop is simple: When you log in to the game, you get into a menu where you can create a new room to solve or join an existing one. Quitting a room brings you back to that menu. Quitting again leaves the game entirely. In between, you remain inside a single game location ('room').
+To make it easier for people to agree to meet up in a room, i made a little 'fantasy name generator' to make unique random names of the rooms. It felt more thematic than showing room id's. The generator combines phonemes together with some very simple logic. Not all comes out easy-to-pronounce, but the result is at least identifiable, like the Sheru and Uyoha above.
+I decided that I should not keep empty rooms around, so whenever a room has no more players in it, it's deleted from the database along with all its content. This means players can't really log off and come back to the same room unless a friend stays behind. I felt it was worth keeping things clean and avoid a growing backlog of empty, unsolved rooms. It is, unfortunately, quite common for players to log in, create a room and then immediately log off.
+I distribute Evscaperoom as an Evennia 'game dir'. Once you've installed Evennia you can just clone the evscaperoom repo and start a new multiplayer server with it. While the game dir has some Evennia templates in it by default, Almost all the custom logic for this game is in the evscaperoom/ folder. The only other modification I did was to make sure Evennia rerouted new players into the Evscaperoom menu when they connect.
+Room class
+Since all of the gameplay happens in a single room, it made sense to center all of the data-storage around a new, custom Evennia Room class. This "EvscapeRoom" class holds all resources for this room. Evennia makes sure to persist it all to the database for you.
+The Evennia API provides a lot of powerful but game-general functions. Since our use-case for this game is very strictly defined, I made a slew of helper functions to cut down on boiler plate and pre-set options I wanted to always use.
+For example, I added helper methods both for creating and finding objects in the room. On creation, all objects are tagged with the room's unique hash, meaning that one can be sure to never have any cross-over between rooms (like accidentally finding the object in another room (that of course has the exact same name). Since I also decided to never have more than one object with a given name per room, I could make these methods very simple.
+The room class also has helpers for finding all players in the room and for sending messages to them. It also catches players leaving so that eventual on-character variables can be cleaned.
+Importantly, the very action of deleting the room will automatically clean all resources tied to it, keeping things tidy.
+Commands and Objects
+
+The help screen, show all top-level commands
+As discussed in part one of this blog, the Evscaperoom, uses a 'focus' mode: The player must examine/focus on an object first in order to operate or use it.
+The basic command syntax is:
+> command [target]
+The parsing I made actually allows for a more complex syntax, but in the end this was all that was really needed, since the currently 'focused' object does not need to be specified. This is the process of using one object with another:
+> examine key
+
+~~ key (examining) ~~
+
+This is a brass key.
+
+
+
+(To unlock something with it, use insert into <target>)
+
+
+> insert into door
+You unlock the **door** with the **key**!
+
+(the into is optional). Here, we focus on the key. We get the key's description and a hint that you can insert it into things. We then insert it into the door, which is another object in the room. The insert command knows that we are focusing on the key already and that it should look into the room for an object door to use this with.
+Technically, these on-object 'actions' (like insert above), are dynamically generated. Here is an example of the key object:
+
+class Key(EvscaperoomObject):
+
+ def at_focus_insert(self, caller, **kwargs):
+
+ target = kwargs['args']
+
+ obj = caller.search(obj)
+
+ if not obj:
+
+ return
+
+ if obj.check_flag("can_use_key"):
+
+ obj.handle_insert(self)
+
+
+Not shown here is that I made a wrapper for the "no-match" command of Evennia. This command fires when no other commands match. I made this instead analyze the currently 'focused' object to see if it had a method at_focus_<command_name> on it. If so, I inject the supplied arguments into that method as a keyword argument args.
+So when you focus on the key and give the insert command, the at_focus_insert method on the key will be called with a target to insert the key into_._ We search for the target (the door in the example), check if it even accepts keys and then pass the key to that object to handle. It would then be up to the door to figure out if this particular key unlocks it.
+I created a library of base objects that I can just use as mixins for the object I want to create. Here's an example:
+
+from evscaperoom import objects
+
+
+
+class Box(objects.Openable,
+
+ objects.CodeInput,
+
+ objects.Movable):
+
+ # ...
+
+
+This class will offer actions to open, insert a code and move the object around. It will need some more configuration and addition of messages to show etc. But overall, this method-to-command solution ended up being very stable and extremely easy to use to make complex, interactive objects.
+Room states
+I think of the escape room as going through a series of states. A change of state could for example be that the user solved a puzzle to open a secret wall. That wall is now open, making new items and puzzles available. This means room description should change along with new objects being created or old ones deleted.
+I chose to represent states as Python modules in a folder. To be a state, each module needs to have a global-level class State inheriting from my new BaseState class. This class has methods for initializing and cleaning up the state, as well as was for figuring out which state to go to next. As the system initializes the new state, it gets the current room as argument, so it can modify it.
+This is a (simplified) example of a state module:
+
+# module `state_001_start.py`
+
+
+
+from evscaperoom.state import BaseState
+
+from evscaperoom import objects
+
+
+
+MUG_DESC = """
+
+A blue mug filled with a swirling liquid.
+
+On it is written "DRINK ME" with big letters.
+
+"""
+
+
+
+class Mug(objects.EvscapeRoomObject):
+
+ def at_focus_drink(self, caller, **kwargs):
+
+ caller.msg(f"You drink {self.key}.")
+
+ self.next_state() # trigger next state
+
+
+
+class State(BaseState):
+
+
+
+ hints = ["You are feeling a little thirsty...",
+
+ "Drink from the mug, dummy."]
+
+
+
+ next_state = "state_002_big_puzzle"
+
+
+
+ def init(self):
+
+ mug = self.create_object(
+
+ Mug, key="wooden mug", aliases=["mug"])
+
+ mug.db.desc = MUG_DESC.strip()
+
+
+In this simple state, a mug is created, and when you drink from it, the next state is triggered. The base object has a helper function to trigger the next state since I found that interactive with an object is almost always the reason for switching states.
+The state-class has a lot of useful properties to set, such as which the next state should be (this can be overridden in case of branching paths). You can also store
+a sequence of hints specific for that state.
+Informing the room
+I wrote the content in second-person perspective ("You open the door"). This is however a multiplayer game and I didn't intially appreciate how many texts must also exist in a third-party form for the rest of the room to see ("Griatch opens the door").
+As the amount of text grew (the Evscaperoom has close to 10 000 lines of code, a lot of which is content strings), it became clear that it would not be feasible to manually supply third-persion version strings as well.
+The solution was to add parsing and translation of pronouns and verbs (a concept I first saw on the game Armageddon).
+I write the string like this:
+
+ OPEN_TEXT = "~You ~open the *door."
+
+
+The ~ marks text that should be parsed for second/third-person use (I'll discuss the *door marking in the next section). This I then send to a helper method that either sends it only to you (which means it comes back pretty much the same, but without the special markers) or to you and to the room, in which it will look different depending on who receives it:
+I see
+You open the [door].
+
+
+
+Others see
+Griatch opens the [door].
+
+English is luckily pretty easy to use for this kind of automatic translation - in general you can just add an "s" to the end of the verb. I made a simple mapping for the few irregular verbs I ended up using.
+Overall, this made it quick to present multiple viewpoints with minimal extra text to write.
+
+
+The option menu
+
+The *door -style marking allowed me to generalize how target-able objects in the room were displayed. This meant that users can customize how objects are shown to them. The default is to mark them both with colors and square brackets (this makes it clear also for people with screen readers). But one can also use only colors or turn off the marking completely (hard mode).
+Bringing it online
+Evennia is both a mud framework and mudserver as well as a webserver based on Twisted. It runs the game's website (with the help of Django) and also provides its own HTML5 webclient. I tweaked the default website text and played a little with CSS but otherwise didn't spend too much time on this bit.
+I got a $5/month DigitalOcean droplet with Ubuntu. I made a new, unprivileged "evennia" user on it and cloned the evscaperoom repo to it. I then started a tmux session and ran the Evennia docker image in there. Getting the game online took maybe thirty minutes, most of which was me figuring out where to open the droplet and DigitalOcean firewalls.
+I then pointed http://experimental.evennia.com at the droplet's IP and that was it!
+Updating the online server is now only a matter of pushing changes to my github repo, pulling it to the server and reloading Evennia; Before release, I used a private github repo for this, afterwards I simply made it public. Pretty straightforward.
+Some lessons learned
+I have gotten pretty positive reviews on Evscaperoom so far. In the first two days people stumbled on some edge-case bugs, but after that it has been very stable. Mostly I've had to make small typos and grammar corrections as I (or players) spot them.
+There were nevertheless some things I learned, some of which led to more real improvements post-launch.
+No amount of help is too much help
+
+
+The header shows how to get out of focus mode
+
+Firstly, the focus-system (examine, then do stuff) is a little un-orthodox and needs to be explained. I saw people logging in, examining exactly one thing and then logging out. Eventually I found out (because a user told me), that this was likely because they could not figure out how to leave the focus mode. They'd just flounder about, think the game was buggy and log off.
+The answer (just run examine again) is found with the help command, but clearly this was not intuitive. The solution was to add an explicit help text to the top every time you examine something. After this, the confusion seems to have gone away.
+Make it easy to connect for all tastes
+Another example - a commenting user had pretty strong opinions about the fact that you used to have to supply a username and password to play the game. They suggested this was a 'huge hurdle'. Not sure if that's true. But unless you want to use a particular name, there is also no actual gameplay reason to formally authenticate for Evscaperoom.
+This was easy to fix. Evennia has guest-player support out of the box so I just activated that and supplied some more fantasy-sounding names than the default "Guest 1", "Guest 2" etc. Since then, maybe 40% of players connecting have chosen to do so as an anonymous guest. I don't know if those would have left completely if the option was not available, but it's at least a convenient shortcut for getting into the game.
+Everything takes longer than expected
+I already knew this one, but still I fell into the trap of thinking that things were going well and that there would be plenty of time to finish before deadline.
+Creating text content is a lot faster than creating graphical assets, but it's still a lot of work. Just the ending 'cinematics' took me almost two days to finish and clean up at the end.
+For once I did pick a reasonable scale for this project though. So while the last few days of the Jam was more intense than I would have liked, I never truly felt like I would not be able to finish in time.
+Building a MU* game in pure code is awesome
+Evennia tries to not instil and specific game type, hence its tools are very general. Wrapping these general tools as a highly opinionated and game-specific toolbox enforced to me just how easy it is to do things when you don't need to cover the general case.
+Using the tools and creating content purely in-code was great and ended up leading to a very fast content creation. Python works perfectly as a scripting language and I don't think there is a reason for using in-game building at all for your game, especially not when you are working on your own like this.
+I made a few admin-only commands to jump between states and to set flags, but otherwise most bugs were caught by a generic unit test that just looped over all founds states and tried to initialize them, one after another.
+Conclusions
+For all my work on the Evennia library/server, I've not actually used it for games of my own very much. This was a great opportunity for doing so. It also gave me the opportunity to test the Python3-development branch of Evennia in a production setting.
+I found a few edge-case library bugs which I fixed, but overall things worked very smoothly, also for this kind of game which is certainly far away from the normal MU*-mold that most use Evennia for. I am a bit biased, but overall I felt Evennia to be very mature for the use of making a game from scratch.
+In the future I will most likely break out the 'engine' and tools of the Evscaperoom into an Evennia contrib so that others can make similar games with it easily.
+Looking forward to future game jams now!
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 1
+ ¶
+ - May 18, 2019
+
+
+Over the last month (April-May 2019) I have taken part in the Mud Coder's Guild Game Jam "Enter the (Multi-User) Dungeon". This year the theme for the jam was One Room.
+The result was Evscaperoom, an text-based multi-player "escape-room" written in Python using the Evennia MU* creation system. You can play it from that link in your browser or MU*-client of choice. If you are so inclined, you can also vote for it here in the jam (well, no more).
+This little series of (likely two) dev-blog entries will try to recount the planning and technical aspects of the Evscaperoom. This is also for myself - I'd better write stuff down now while it's still fresh in my mind!
+Update: The Evscaperoom can these days be played by connecting to the Evennia game demo at https://demo.evennia.com.
+Inception
+When I first heard about the upcoming game-jam's theme of One Room, an 'escape room' was the first thing that came to mind, not the least because I just recently got to solve my my own first real-world escape-room as a gift on my birthday.
+If you are not familiar with escape-rooms, the premise is simple - you are locked into a room and have to figure out a way to get out of it by solving practical puzzles and finding hidden clues in the room.
+While you could create such a thing in your own bedroom (and there are also some one-use board game variants), most escape-rooms are managed by companies selling this as an experience for small groups. You usually have one hour to escape and if you get stuck you can press a button (or similar) to get a hint.
+I thought making a computer escape-room. Not only can you do things in the computer that you cannot do in the real world, restricting the game to a single room limits so that it's conceivable to actually finish the damned thing in a month.
+A concern I had was that everyone else in the jam surely must have went for the same obvious idea. In the end that was not an issue at all though.
+Basic premises
+I was pretty confident that I would technically be able to create the game in time (not only is Python and Evennia perfect for this kind of fast experimentation and prototyping, I know the engine very well). But that's not enough; I had to first decide on how the thing should actually play. Here are the questions I had to consider:
+Room State
+An escape room can be seen as going through multiple states as puzzles are solved. For example, you may open a cabinet and that may open up new puzzles to solve. This is fine in a single-player game, but how to handle it in a multi-player environment?
+My first thought was that each object may have multiple states and that players could co-exist in the same room, seeing different states at the same time. I really started planning for this. It would certainly be possible to implement.
+But in the end I considered how a real-world escape-room works - people in the same room solves it together. For there to be any meaning with multi-player, they must share the room state.
+So what I went with was a solution where players can create their own room or join an existing one. Each such room is generated on the fly (and filled with objects etc) and will change as players solve it. Once complete and/or everyone leaves, the room is deleted along with all objects in it. Clean and tidy.
+So how to describe these states? I pictured that these would be described as normal Python modules with a start- and end function that initialized each state and cleaned it up when a new state was started. In the beginning I pictured these states as being pretty small (like one state to change one thing in the room). In the end though, the entire Evscaperoom fits in 12 state modules. I'll describe them in more detail in the second part of this post.
+Accessibility and "pixel-hunting" in text
+When I first started writing descriptions I didn't always note which objects where interactive. It's a very simple and tempting puzzle to add - mention an object as part of a larger description and let the player figure out that it's something they can interact with. This practice is sort-of equivalent to pixel-hunting in graphical games - sweeping with the mouse across the screen until you find that little spot on the screen that you can do something with.
+Problem is, pixel-hunting's not really fun. You easily get stuck and when you eventually find out what was blocking you, you don't really feel clever but only frustrated. So I decided that I should clearly mark every object that people could interact with and focus puzzles on better things.
+In fact, in the end I made it an option:
+![Option menu ('quit' to return) 1: ( ) No item markings (hard mode) 2: ( ) Items marked as item (with color) 3: (*) Items are marked as [item] (screenreader friendly) 4: ( ) Screenreader mode](https://3.bp.blogspot.com/-HdLAfVl8P5A/XOAWjd_zoDI/AAAAAAAAKek/GBrnsZDvck0rkeBW2WVLZHXNG6ePqKEjgCEwYBhgL/s400/Screenshot%2Bfrom%2B2019-05-17%2B11-49-20.png "In-game option menu")
+As part of this I had to remind myself never to use colors only when marking important information: Visually impaired people with screen readers will simply miss that. Not to mention that some just disable colors in their clients.
+So while I personally think option 2 above is the most visually pleasing, Evscaperoom defaults to the third option. It should should start everyone off on equal footing. Evennia has a screen-reader mode out of the box, but I moved it into the menu here for easy access.
+Inventory and collaboration
+In a puzzle-game, you often find objects and combine them with other things. Again, this is simple to do in a single-player game: Players just pick things up and use them later.
+But in a multi-player game this offers a huge risk: players that pick up something important and then log off. The remaining players in that room would then be stuck in an unsolvable room - and it would be very hard for them to know this.
+In principle you could try to 'clean' player inventories when they leave, but not only does it add complexity, there is another issue with players picking things up: It means that the person first to find/pick up the item is the only one that can use it and look at it. Others won't have access until the first player gives it up. Trusting that to anonymous players online is not a good idea.
+So in the end I arrived at the following conclusions:
+
+
+As a side-effect of this I also set a limit to the kind of puzzles I would allow:
+
+
+Focusing on objects
+So without inventory system, how do you interact with objects? A trademark of any puzzle is using one object with another and also to explore things closer to find clues. I turned to graphical adventure games for inspiration:
+
+Secret of Monkey Island ©1990 LucasArts. Image from old-games.com
+A common way to operate on an object in traditional adventure games is to hover the mouse over it and then select the action you want to apply to it. In later (3D) games you might even zoom in of the object and rotate it around with your mouse to see if there are some clues to be had.
+While Evennia and modern UI clients may allow you to use the mouse to select objects, I wanted this to work the traditional MUD-way, by inserting commands. So I decided that you as a player would be in one of two states:
+
+
+![A small stone fireplace sits in the middle of the wall opposite the [door]. On the chimney hangs a small oil [painting] of a man. Hanging over the hearth is a black [cauldron]. The piles of [ashes] below are cold. (It looks like fireplace may be suitable to [climb].)](https://2.bp.blogspot.com/-E-J-PZZ2KbY/XOAWidK1Y_I/AAAAAAAAKek/mcWbgVNkvVkBBZEUpOuaaWyBVkNoE7K9gCEwYBhgL/s400/Screenshot%2Bfrom%2B2019-05-17%2B11-41-50.png "Examining a fireplace")
+In the example above, the fireplace points out other objects you could also focus on, whereas the last parenthesis includes one or more "actions" that you can perform on the fireplace only when you have it focused.
+This ends up pretty different from most traditional MUD-style inputs. When I first released this to the public, I found people logged off after their first examine. It turned out that they couldn't figure out how to leave the focus mode. So they just assumed the thing was buggy and quit instead. Of course it's mentioned if you care to write help, but this is clearly one step too many for such an important UI concept.
+So I ended up adding the header above that always reminds you. And since then I've not seen any confusion over how the focus mode works.
+For making it easy to focus on things, I also decided that each room would only ever have one object named a particular thing. So there is for example only one single object in the game named "key" that you can focus on.
+Communication
+I wanted players to co-exist in the same room so that they could collaborate on solving it. This meant communication must be possible. I pictured people would want to point things out and talk to each other.
+In my first round of revisions I had a truckload of individual emotes; you could
+point at target
+for example. In the end I just limited it to
+say/shout/whisper
+and
+emote
+And seeing what people actually use, this is more than enough (say alone is probably 99% of what people need, really). I had a notion that the shout/whisper could be used in a puzzle later but in the end I decided that communication commands should be strictly between players and not have anything to do with the puzzles.
+I removed all other interaction: There is no fighting and without an inventory or requirement to collaborate on puzzles, there is no need for other interactions than to communicate.
+First version you didn't even see what the others did, but eventually I added so that you at least saw what other players were focusing on at the moment (and of course if some major thing was solved/found).
+In the end I don't even list characters as objects in the room (you have to use the who command to see who's in there with you).
+
+The main help command output.
+Story
+It's very common for this type of game to have a dangerous or scary theme. Things like "get out before the bomb explodes", "save the space ship before the engines overheat", "flee the axe murderer before he comes back" etc). I'm no stranger to dark themes, but for this I wanted something friendlier and brighter, maybe with a some dark undercurrents here and there.
+My Jester character is someone I've not only depicted in art, but she's also an old RP character and literary protagonist of mine. Who else would find it funny to lock someone into a room only to provide crazy puzzles and hints for them to get out again? So my flimsy 'premise' was this:
+The village Jester wants to win the pie eating contest. You are one of her most dangerous opponents. She tricked you to her cabin and now you are locked in! If you don't get out in time, she'll get to eat all those pies on her own and surely win!
+That's it - this became the premise from which the entire game flowed. I quickly decided that it to be a very "small-scale" story: no life-or-death situation, no saving of the world. The drama takes place in a small village with an "adversary" that doesn't really want to hurt you, but only to eat more pies than you.
+From this, the way to offer hints came naturally - just eat a slice of "hintberry pie" the jester made (she even encourage you to eat it). It gives you a hint but is also very filling. So if you eat too much, how will you beat her in the contest later, even if you do get out?
+To further the rustic and friendly tone I made sure the story took place on a warm summer day. Many descriptions describe sunshine, chirping birds and the smell of pie. I aimed at letting the text point out quirky and slightly comedic tone of the puzzles the Jester left behind. The player also sometimes gets teased by the game when doing things that does not make sense.
+I won't go into the story further here - it's best if you experience it yourself. Let's just say that the village has some old secrets. And and the Jester has her own ways of doing things and of telling a story. The game has multiple endings and so far people have drawn very different conclusions in the end.
+Scoring
+Most often in escape rooms, final score is determined by the time and the number of hints used. I do keep the latter - for every pie you eat, you get a penalty on your final score.
+As for time - this background story would fit very well with a time limit (get out in X time, after which the pie-eating contest will start!). But from experience with other online text-based games I decided against this. Not only should a player be able to take a break, they may also want to wait for a friend to leave and come back etc.
+But more importantly, I want players to explore and read all my carefully crafted descriptions! So I'd much rather prefer they take their time and reward them for being thorough.
+So in the end I give specific scores for actions throughout the game instead. Most points are for doing things that drive the story forward, such as using something or solving a puzzle. But a significant portion of the score comes from turning every stone and trying everything out. The nice side-effect of this is that even if you know exactly how to solve everything and rush through the game you will still not end up with a perfect score.
+The final score, adjusted by hints is then used to determine if you make it in time to the contest and how you fare. This means that if you explore carefully you have a "buffer" of points so eating a few pies may still land you a good result in the end.
+First sketch
+I really entered the game 'building' aspect with no real notion of how the Jester's cabin should look nor which puzzles should be in it. I tried to write things down beforehand but it didn't really work for me.
+So in the end I decided "let's just put a lot of interesting stuff in the room and then I'll figure out how they interact with each other". I'm sure this is different from game-maker to game-maker. But for me, this process worked perfectly.
+
+
+My first, very rough, sketch of the Jester's cabin
+
+The above, first sketch ended up being what I used, although many of the objects mentioned never ended up in the final game and some things switched places. I did some other sketches too, but they'd be spoilers so I won't show them here ...
+The actual game logic
+The Evscaperoom principles outlined above deviate quite a bit from the traditional MU* style of game play.
+While Evennia provides everything for database management, in-game objects, commands, networking and other resources, the specifics of your game is something you need to make yourself - and you have the full power of Python to do it!
+So for the first three days of the jam I used Evennia to build the custom game logic needed to provide the evscaperoom style of game play. I also made the tools I needed to quickly create the game content (which then took me the rest of the jam to make).
+In part 2 of this blog post I will cover the technical details of the Evscaperoom I built. I'll also go through some issues I ran into and conclusions I drew. I'll link to that from here when it's available!
+
+
+
+
+
+
+
+ Podcast about Evennia
+ ¶
+ - May 9, 2019
+
+
+I was interviewed on the (pretty grandiosely named) podcast Titans of Text the other day.
+In the interview, which are run by people from the MUD Coder's Guild (a great initiative!), I talk a bit about the history of Evennia, the text-based multiplayer game engine I'm working on, and go into some various technical aspects of the engine as well. Check it out and support the podcast!
+
+
+
+
+
+
+
+
+ Steaming on Eating Jam
+ ¶
+ - April 25, 2019
+
+
+In the last few months, development of the upcoming Evennia 0.9 has been steaming on. Evennia is, as you may know, a Python library for creating text-based multiplayer games (MUDs, MUSH etc).
+But it's not all backend work! There is also some sweet game-jamming going on, I get to that at the end.
+Evennia progress towards Python3
+The regular Evennia develop branch is now running completely in Python 3. Since we are using some new features of this Python release, we will be aiming for Python 3.7 as a minimum version once Evennia 0.9 goes stable. We will also use Django 2.1 and likely Twisted 19 - so we'll be pretty much up-to-date on all our main dependencies.
+Now, while the release of Evennia 0.9 is still some time away (there are a bunch of regular bug fixes and minor features that I want to get in there too (see the progress here on the github 0.9 project page), it's worth to consider how much work it'll be for you to migrate and if you should wait or jump in right now.
+If you are new, I still recommend you use regular master branch Evennia (using Python 2.7). This is for which all wiki articles and documentation online is currently written after all. Once we move to python3, you'll need to convert your code ... but syntactically the two are really not that different and conversion should not be much of an issue.
+Not only are there automatic converters for most stuff, you should only need to do one pass to make sure things work and then you'll be done. This article is pretty old but it serves well to identify the main differences. Later Py3 versions just adds new stuff which you would just not have had access to in Python2.7. Once 0.9 is released, we'll also make guides for how you go about converting existing code (apart from the wealth of info on this topic online).
+That said, if you are feeling more adventurous, or really want to use Python3 right away, many of the Evennia developer regulars have been running and testing develop branch for months now. It's overall been a pretty painless transition - as said, py3 is not that different from py2.
+However, develop branch has other features beyond the py3 jump. And those are not yet documented in the main docs. So you'll have to contend with that (but asking in chat/forum works of course). However while it works fine for development already, as a matter of principle I do not recommend ever using Evennia's develop branch for a production game - it can change quickly and may occationally be broken. You have been warned!
+Game Jam
+We are now a little more than a week into the Mud Coders Guild's second yearly Game Jam. This year's theme is "One Room".
+I really hope some more Evennia devs jump on this one because Evennia is perfect for this kind of experimental games. This is because Evennia is not imposing a game style on you - while there are default commands you are free to replace or customize the commands, objects and every aspect of your game to be as specific as you want to your game.
+For example, I have a small Game Jam contribution in the works, where I very quickly reworked the default Evennia setup to pretty much make it into a different genre of game.
+Usually the systems I make for Evennia are generic and intended for any game-type. By contrast, making somehing highly niched is super-fast to do: Building a whole new framework for game mechanisms along with build helpers for me to quickly make content took no more than three days.
+There will no doubt be some iteration, but I hope to spend the rest of the jam time on content and gameplay. I have some RL things happening in the coming weeks (including work on Evennia proper) but if I can get the time to tie my jam entry together, I'll likely make one or two blog posts about how it was developed and my reasons for making the choices i did. Most likely the code will appear as an Evennia contribution in case people want to do something similar for their own projects.
+So, busy days.
+
+
+
+
+
+
+
+ Into 2019
+ ¶
+ - January 2, 2019
+
+
+A new year has come around and it's time to both look back at the old and onward to the future of Evennia, the Python MUD creation system!
+Last year
+
+Last year saw the release of Evennia 0.8. This version of Evennia changes some fundamental aspects of the server infrastructure so that the server can truly run in daemon mode as you would expect (no more running it in a GnuScreen session if you want to see logging to the terminal). It also adds the new Online Creation System, which lets builders create and define prototypes using a menu system as well as big improvements in the web client, such as multiple window-panes (allows the user to assign text to different windows to keep their client uncluttered) as well as plenty of fixes and features to help ease life for the Evennia developer. Thanks again to everyone who helped out and contributed to the release of Evennia 0.8!
+On a personal note, I spoke about Evennia at PyCon Sweden this December, which was fun. I might put up my talk and make a more detailed blog post about that in the future, but my talk got a surprising amount of attention and positive feedback. Clearly many people have fond memories of MUDs and enjoy seeing they are not only still around but are possible to create in Python!
+This year
+
+Now we are steaming ahead towards Evennia 0.9! Already we have had a large number of contributions towards this release. A coming change is a much improved central way to make typeclass information available to a website as well as central ways to do various common operations like creating characters and linking them to Accounts. Much of this functionality is today hidden in the various default commands. In Evennia 0.9 they will be moved into more easily-findable locations as library functions everyone can just trigger without having to copy functionality.
+The biggest change for Evennia 0.9 is however that we will now finally move Evennia over to Python 3. This is now possible as all our dependencies are now sufficiently ported. As discussed in the community for a long time, this will be a clean break - we will not offer any mid-way solution of Python2/3 but will drop Python2 support entirely. We will at the same time move to Django 2.+. In Django 0.9 we will however probably not use any special Python3 features yet. It should hopefully not be too difficult for our users to upgrade, but we'll of course publish extensive instructions and help when that time comes.
+We will likely support a minimum of Python 3.6 and maybe 3.7. This work is currently happening in a separate branch develop-py3 which will soonish merge into the current Python2.7-based develop branch and become Evennia 0.9 when it merges into master branch at an unknown time later this year.
+There are a slew of other things planned for Evennia 0.9 and you can follow the progress from our project page. If you want to help out you are of course also very welcome. If you are new and are interested in getting your feet wet in helping out with Open-source development, we have a list of good first issues you could jump into.
+Onward into the new year!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2020.html b/devblog/html/devblog2020.html
index 22398fec04..19761fd282 100644
--- a/devblog/html/devblog2020.html
+++ b/devblog/html/devblog2020.html
@@ -35,23 +35,35 @@
-
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
-
- Initial-Blog
- ¶
- - May 2, 2020
+
+ Evennia 0.9.5 released
+ ¶
+ - November 14, 2020
-A way to do things
-
This is a test blog page for using markdown to write
-Evennia devblog posts.
-Starting out
-I'm experimenting with a new section of the docs containing these
-blog posts (obviously the blogs are CC anyway).
+
+As of today, Evennia 0.9.5 is out. Evennia is a Python based library and framework for creating text-based multiplayer games (MUD/MU*).
+This is a gradual improvement halfway between 0.9 and the upcoming 1.0. So if you have been keeping up-to-date with the master branch of Evennia over the last year you will not notice much difference from this release (time to upgrade if you haven't been keeping up though!).
+While an interim release, there are still a lot of things that has happened since v0.9:
+Webclient improvements
+
+
+EvMenu improvements
+EvMenu is a powerful system for creating in-game text menus.
+
+
+New settings
+
+
+Other improvements
+
+
+See the changelog here.
+New documentation system
+The bigger change with 0.9.5 is that we are moving to a new documentation system. The details of the long road to do this is documented in my previous post. The point is that we are stopping the use of the Github wiki in favor of statically generated documentation hosted on github pages. At the same time we also move the old evennia.com website from Google-sites to Github.
+Check it out:
+
+
+As for the docs, they will be maturing for a long time still. The old wiki will not be updated anymore, but it will also not be going anywhere in the short term. Version 0.9.5 of the docs is pretty much a copy of the wiki and I hope to not have to spend too much more work maintaining it since the wiki is still around.
+New updates and documentation features will primarily be happening in the 1.0-dev version of the documentation. This will include refactoring all pages as well as a new intro-tutorial and many other things.
+But that's for future blogs ...
+
+
+
+ On using Markdown with Sphinx
+ ¶
+ - October 20, 2020
+
+
+Last post I wrote about the upcoming v1.0 of Evennia, the Python MU* creation engine. We are not getting to that 1.0 version quite yet though: The next release will be 0.9.5, hopefully out relatively soon (TM).
+Evennia 0.9.5 is, as you may guess, an intermediary release. Apart from the 1.0 roadmap just not being done yet, there is one other big reason for this - we are introducing documentation versioning and for that a proper release is needed as a base to start from. Version 0.9.5 contains everything already in master branch, so if you have kept up-to-date you won't notice too much difference. Here are some highlights compared to version 0.9:
+
+
+Many contributors helped out along the way. See the changelog where contributors of the bigger new features are listed.
+The path to a new documentation
+For many years we've used the Github wiki as our documentation hub. It has served us well. But as mentioned in my previous post, it has its drawbacks, in particular when it comes to handling documentation for multiple Evennia versions in parallel.
+After considering a bunch of options, I eventually went with sphinx, because it has such a good autodoc functionality (parsing of the source-code docstrings). This is despite our wiki docs are all in markdown and I dislike restructured text quite a bit. Our code also uses friendly and in-code-readable Google-style docstrings instead of Sphinx' hideous and unreadable format.
+Luckily there are extensions for Sphinx to handle this:
+
+
+What could go wrong? Well, it's been quite a ride.
+Getting Markdown into reST
+Linking to things in recommonmark turned out to be very flaky. I ended up forking and merging a bunch of PRs from the project but that was not enough: Clearly this thing was not built to convert 200 pages of technical markdown from a github wiki.
+My custom fork of recommonmark had to be tweaked a bit for my needs, such as not having to specify the .md file ending in every link and make sure the url-resolver worked as I expected. There were a bunch of other things but I will probably not merge this back, the changes are pretty Evennia-specific.
+Even so, many of my wiki links just wouldn't work. This is not necessarily recommonmark's fault, but how sphinx works by grouping things into toctrees, something that the Evennia wiki doesn't have.
+Also, the recommonmark way to make a toctree in Markdown is to make a list of links - you can't have any descriptive text, making the listing quite useless (apparently people only want bland lists of link-names?). After trying to figure out a way to make this work I eventually capitulated - I make pretty lists in Markdown while using a "hidden" toctree to inform sphinx how the pages are related.
+Getting the wiki into the new doc site
+This required more custom code. I wrote a custom importer that reads the wiki and cleans/reformats it in places where recommonmark just dies on them. I also made a preprocessor that not only finds orphan pages but also builds a toctree and remaps all links in all documents to their actual location on compilation. The remapper makes it a lot easier to move things around. The drawback is that every page needs to be uniquely named. Since this was already the case in the wiki, this was a good tradeoff. So with a lot of custom code the wiki eventually could port automatically.
+The thing is, that even with all this processing, recommonmark doesn't support stuff like Markdown tables, so you still have to fall back to reST notation for those. And Napoleon, while doing a good job of parsing google docstrings, do not expect Markdown. So the end result is mostly markdown but we still have to fall back to reST for some things. It's probably as far as we get.
+Deploying the docs
+Figuring out how to build and deploy these components together was the next challenge. Sphinx' default Makefile was quite anemic and I also wanted something that regular contributors could use to test their documentation contributions easily. I ended up having to expand the Makefile quite a lot while also adding separate deploy scripts and interfaces to github actions (which we recently started using too).
+Finally, the versioning. The sphinx-multiversion plugin works by extracting the branches you choose from git and running the sphinx compiler in each branch. The plugin initially had a bug with how our docs are located (not at the root of the package) but after I reported it, it was quickly fixed. The result is a static document site where you can select between the available versions in the sidebar.
+I've not gotten down to trying to make LaTeX/PDF generation work yet. I'm dreading it quite a bit...
+Where we are
+The github wiki is now closed for external contributions. The v0.9.5 of the new documentation will pretty much be an import of the last state of the wiki with some minor cleanup (such as tables). While we'll fix outright errors in it, I don't plan to do many fixes of purely visual glitches from the conversion - the old wiki is still there should that be a problem.
+The main refactoring and cleanup of the documentation to fit its new home will instead happen in v1.0. While the rough structure of this is already in place, it's very much a work in progress at this point.
+Conclusions
+Evennia 0.9.5 has a lot of features, but the biggest things are 'meta' changes in the project itself. After it is out, it's onward towards 1.0 again!
+
+
+
+
+
+
+
+ Spring updates while trying to stay healthy
+ ¶
+ - April 14, 2020
+
+
+So, spring grows nearer for those of us on the Northern hemisphere. With everyone hopefully hunkered down and safe from the Covid-19 pandemic, I thought it overdue to make another dev blog for the progress of Evennia, the Python MU*-creation system.
+The last few months have seen primarily bug fixing on the Evennia front, but it also has seen an uptick of PRs from the community and the re-opening of the develop branch in earnest. There is still quite a lot of work to do before we can add that extra 0.1 and go from version 0.9 to 1.0.
+What's in a version?
+For me personally, I never put much stock in the notion of versions. Evennia didn't even have versions until a few years back: We used to just have a rolling git release. But eventually it became clear that our user base was big enough that we needed to more clearly separate major (and possibly breaking) updates from what came before. So I started versioning at Evennia 0.5 and have had roughly a new release every year since (not a plan or a promise, it just happened to turn out that way).
+Evennia has been useful (and been used) for game development for many years already. But there is no denying that a 1.x label tends to convey more confidence in a system than a 0.x label, that's just the way things are. So while the new version is still quite some way off, there are a bunch of changes and improvements that we want to do in this release to mark the version change in a good way.
+Documentation changes
+Our documentation will move away from our trusty Github wiki. Instead we will convert the wiki into a static github page built from sources inside evennia/docs/.
+The advantage of the wiki is that it is a very low entry for people to contribute and fix things using Github's editing system. We have had a lot of use of this over the years and the wiki has served us well. The drawbacks are starting to get ever more noticeable, however:
+
+
+The change so far planned is to switch to the Sphinx documentation build-system (same as Python/Django etc is using). We will use it with extensions that allows us to still use Markdown like in the old wiki. This also allows us to build a more comprehensive (and pretty) API documentation of the entire library. We have more options to add comprehensive online search functionality in this solution as well.
+Furthermore, will hopefully be able to set it up so that we can maintain and publish separate documentations for each forthcoming release. That is, you should be able to read the docs for 1.0, 1.1 or the latest master development as you like (similarly to how Django does it, although probably not as fancy from the onset).
+This means that contributions to the documentation will be done as PRs through GitHub, just like when contributing any other code. While this does add a little more of a hurdle to contributions, hopefully the benefits will far outweigh those. Building the docs locally will not require a running Evennia server (unless you want the api docs) and we will try to set everything up for to make it easy to contribute.
+Many of the details around the docs are still up in the air. This is still very much work-in-progress, like everything else.
+Work with this has started in the static-file-docs branch of Evennia. But we have not closed the wiki either - the two will exist in parallel for now.
+PyPi
+As mentioned before, we will finally start to distribute Evennia via PyPi (the Python Package Index) - that is, you will be able to run pip install evennia. Using GIT will no longer be a requirement to get started.
+Considering how quickly people in open-source throw up their three lines of code on PyPi these days, it may be surprising Evennia is not already on PyPi. I have however felt that reading and referencing the highly-commented code is a big part and requirement for getting the most out of the library.
+With the new documentation system, this would improve. And you can of course still use git and follow master branch like the good ol' days if you want!
+Web Admin improvements
+For the longest time, the Django-admin component has been somewhat on the back-burner. With the help of community contributors, this is improving so you will be able to do more work the Admin GUI related to creating and managing objects, tie puppets to Accounts etc.
+API improvements
+Whereas the last few months have been mostly spent fixing lingering bugs, one thing planned for version 1.0 is a general cleanup of legacy strangeness in the API. For example, certain methods can return a list or a single object depending situation, which makes it hard to generalize. There are a lot of small quirks like that which we hope to address and make more consistent.
+There has also been a recent flurry of contributor PRs intended to help decouple Evennia's systems and make them easier to replace for those inclined to do so. Many of this is still being worked on, but it's likely you'll be able to replace many more "core" components for 1.0 with your own variations without doing any hacking in upstream code at all.
+... Needless to say, this is an advanced feature that most developers will never need. But Evennia was always intended to be heavily customizable and having the option is a good thing!
+Another feature that will come for 1.0 is a REST-API, added by one of our contributors. This uses Django-REST-Framework and makes it easier for external programs to authenticate and fetch data out of the Evennia database (great both for external apps, websites or custom what-have-you).
+At this time you can only fetch database objects via this interface, you cannot perform Command-calls or "play the game" this way (REST is a stateless concept and Evennia Commands tend to retain state).
+Many other fixes and contributions
+There's a truckload of stuff already available in master branch, but with the latest contributions of bigger code changes, we have started to use the Evennia develop branch again in earnest again. For a summary of the changes so far, check out the Changelog.
+However, unless you want to contribute to Evennia itself (or really, really want to be on the bleeding edge), you are still recommended to use the master branch for now. A lot of work still to do, as said.
+
+
+
+
+ 
+
+ A summary of a year
+ ¶
+ - December 17, 2015
+
+A summary of a year
+
As 2015 is slowly drawing to an end, I looked back through Evennia's repository to see just what was going on this year. And it turns out it was a lot! I honestly didn't remember some things happened as recently as they did.
+Note: For those reading this not familiar with Evennia, it's a Python library for creating MUDs (text-based multiplayer games).
+Making Evennia into a library
+In February of 2015 we merged what was likely the biggest change happening for a good while in Evennia - the complete refactoring of the Evennia repository into a library. It used to be that when you cloned the Evennia repo, it would come with a pre-made game/ folder where you were supposed to put your custom files. Mixing the stuff you downloaded from us with your own files (which you might want to keep under version control of your own) was not a very clean solution.
+In the big "library update", we instead created a stand-alone evennia program which you use to create your own "game dir" with pre-created templates. Not only does this allow you to treat the cloned evennia repo as a proper library, you can also use the same evennia install for multiple games and makes it a lot clearer just what comes from us and what is your custom code.
+Below is a fun Gource representation (courtesy of Youtuber Landon Wilkins) of how the Evennia repository structure has changed over the years. You can see the latest library-change a little after the 3minute, 20 second mark.
+Typeclasses into proxies
+At the same time as the library change, I also completely overhauled the way typeclasses are represented in Evennia: Typeclasses are Python classes that links back to a database model under the hood. They used to use a custom overloading of varioust get/set methods, now they instead utilize django proxy models extended to support multiple inheritance. T
+his radically increased performance and made the code considerably cleaner, as well as completely hid the core django model from the end user (no longer a need to track if you were dealing with a model or its typeclass - you only ever run into typeclasses). This, together with the library-model led to some changes in people's source codes.
+Even so, this change led to a lot less problems and edge-cases than I had anticipated: it seems more people had issues with upgrading django than with adopting their codes to the new typeclass changes ...
+Evennia Autodocs
+Following the big library merger I sat down to write a more comprehensive autodoc utility. We had been distributing a Doxygen config file with the repo for a long time, but I wanted something that integrated with our github wiki, using markdown in the source (because frankly, while Sphinx produces very pretty output, ReST markup looks really ugly in source code, in my opinion).
+The result was the api2md program, which is now a part of our wiki repository. It allows our source code to be decorated in "Google style", very readable output:
+
+def funcname(a, b, c, d=False): """
+
+ This is a brief introduction to the
+
+ function/class/method
+
+
+
+ Args:
+
+ a (str): This is a string argument that
+
+ we can talk about over multiple lines.
+
+ b (int or str): Another argument
+
+ c (list): A list argument
+
+ d (bool, optional): An optional keyword argument
+
+
+
+ Returns:
+
+ str: The result of the function
+
+
+
+ Notes:
+
+ This is an example function. If `d=True`, something
+
+ amazing will happen.
+
+
+
+ """
+
+This will be parsed and converted to a Markdown entry and put into the Github wiki, one page per module. The result is the automatically generated Evennia API autodocs, reachable as any other wiki page.
+The convertion/prettification of all core functions of Evennia to actually use the Google-style docstrings took almost all year, finishing late in autumn. But now almost all of Evennia uses this style. Coincidentally this also secures us at a 45% comment/code ratio. This places us in the top 10% of well-documented open-source projects according to openhub (gotta love statistics).
+Imaginary realities / Optional Realities
+Spring of 2015 saw some more articles for the Imaginary Realities e-zine as well as some for the newly-opened Optional Realities web forum (unrelated, despite the similar name). The latter was made by a team working on a commercial Evennia-based sci-fi game, but the forums were open for other games (of any engine) and general discussion on mud and mud design.
+Optional Realities published an impressive range of articles (one every week for several months) and organized several very interesting mud-related contests. It did, I think, a lot for bringing some new life to the mud-development scene. Unfortunately Optional Realities suffered a complete database loss towards the end of the year, forcing it to sort of reboot from scratch. I hope it will rebound and that the articles can be put back online again!
+Ainneve
+Over summer I put out a general roll call for developers willing to lead the development of a small but fully functioning Evennia demo game - a project separate from the main Evennia development. The idea is to have something working for people to rip out and start from. The response to my request was very good and we relatively quickly ended up with two devs willing to lead and direct the effort.
+The work-in-progress demo game they started is called Ainneve. It uses the base Open Adventure RPG rules and is distributed using the same liberal licence as Evennia.
+Ainneve has been sputtering along throughout autumn and winter, and while progress has been a bit ... sporadic, it seems to attract new volunteers to help out. As more of the base systems gets finalized there is going to be even more "low hanging fruit" for people to jump in and help with.
+EvMenu, EvMore and EvEditor, RPSystem
+In July I merged some new systems into Evennia's utilities library. EvMenu is a class that builds an in-game menu. It uses multiple-choice questions for the user to navigate its nodes. I had a "menusystem" in our contrib/ folder since many years, but it was showing its age and when I found I myself didn't really understand how it was working I found it time to make something more flexible.
+The EvMore is a page-scroller that allows the server to pause long texts and wait for the user to press a key before continuing. It's functionality is similar to the unix more program.
+For its part, EvEditor has existed for a while as well, but it was moved from the contrib folder into the main utilility library as it turned out to be an important and common resource (it's basically a mud-version of the classic vi editor).
+Finally, some months later, in September, I added the rpsystem and rplanguage contribution modules. The former is an author-stance recognition system similar to what is seen in some rp-heavy muds (where you don't know/see people's name off the bat, but only their description, until you manually assign a name to them).
+The rplanguage module is used for handling foreign (fantasy) languages by obfuscating words heard by different parties depending on their relative language skills.
+Python 3 ... some day
+As we know, Evennia uses Python 2. In autumn of 2015 first one and then two of our users took upon themselves to help make Evennia a little more ready for running also under Python 3. After a lot of work, Evennia's core is now using code syntax that is compatible with both Python 2 and 3.
+We don't run under Python 3 at this point though. This is not something under our control, but is due to Twisted not supporting Python 3 yet. But when it becomes possible, we are now better prepared for transitioning to a point where we can (hopefully) support both main Python versions.
+EvCast
+In September, user whitenoise started his "EvCast" video tutorial series on Evennia. There are so far two episodes, one on installing Evennia and the second on general Python concepts you need to use Evennia efficiently:
+ +Python.__init__ Podcast
+In the end of September I was interviewed by the hosts of the python.init podcast. Turned into more than an hour of discussion about Evennia. T'was fun! You can listen to it here.
+Nested inlinefuncs
+Towards the end of the year I got (via Optional Realities) lured to participate in another text-gaming related website, musoapbox. This is a forum primarily populated by players from the MUSH-side of text-gaming. After some back and forth they made a strong case for increasing the functionality of Evennia's inlinefunctions.
+An inlinefunction is, in Evennia, a function call embedded in a string sent to the server. This is parsed and executed (no, there is no dangerous eval happening, the call is parsed as text and then called as a normal function call). It allows for text to be dynamically replaced at run-time. What the MUSHers suggested was to also allow those inlinefunc's to be nestable - that is, to implement a call stack. The nestable form of inlinefuncs was merged with Evennia master at the end of November.
+Patreon
+This actually happened already back in February: after some requests for more ways to support Evennia development, I opened a Patreon page. And here at the end of the year, a whole ten patrons have signed up for it. Very encouraging!
+Next year
+In 2016 the first upcoming thing that comes to mind is push out the changes to the webclient infrastructure. That has been a long time coming since I've been unsure of how to proceed on it for quite some time. The goal is to make the webclient a lot more "pluggable" and modular than it is, and to clean up its API and way of communicating with the server. Overall I think the web-side of things need some love.
+I'll likely put together some more general-use contribs as well, I have some possibles in mind.
+We'll continue squashing bugs and work down our roadmap.
+I'll also try to get an Evennia Wikipedia.org page together, if you want to look at how it's progressing and help editing it, see the Evennia mailing list for the link.
+... And a lot more I don't know yet, no doubt! On towards a new year!
+ + +
+
+
Evennia
+The Python MU* Development Library
+-
+
+
-
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Birthday retrospective
+ ¶
+ - November 30, 2016
+
+
+So, recently Evennia celebrated its ten-year anniversary. That is, it was on Nov 20, 2006, Greg Taylor made the first repo commit to what would eventually become the Evennia of today. Greg has said that Evennia started out as a "weird experiment" of building a MUD/MUX using Django. The strange name he got from a cheesy NPC in the Guild Wars MMORPG and Greg's first post to the mailing list also echoes the experimental intention of the codebase. The merger with Twisted came pretty early too, replacing the early asyncore hack he used and immediately seeing a massive speedup. Evennia got attention from the MUD community - clearly a Python-based MUD system sounded attractive.
+When I first joined the project I had been looking at doing something MUD-like in Python for a good while. I had looked over the various existing Python code bases at the time and found them all to be either abandoned or very limited. I had a few week's stunt working with pymoo before asking myself why I was going through the trouble of parsing a custom script language ... in Python ... Why not use Python throughout? This is when I came upon Evennia. I started making contributions and around 2010 I took over the development as real life commitments forced Greg to step down.
+Over the years we have gone through a series of changes. We have gone from using SVN to Mercurial and then to using GIT. We have transited from GoogleCode to GitHub - the main problem of which was converting the wiki documentation (Evennia has extensive documentation).
+For a long time we used Python's reload() function to add code to the running game. It worked ... sometimes, depending on what you changed. Eventually it turned out to be so unpredictable that we now use two processes, one to connect clients to and the other running the game, meaning we can completely restart one process without disconnecting anyone.
+Back in the day you were also expected to create your own game in a folder game/ inside the Evennia repo itself. It made it really hard for us to update that folder without creating merge conflicts all over. Now Evennia is a proper library and the code you write is properly separated from ours.
+So in summary, many things have happened over the years, much of it documented in this blog. With 3500 commits, 28 000 lines of code (+46% comments) and some 25 people contributing in the last year, Openhub lists us as
+
+"A mature, well-established codebase with a stable commit history, a large development team and very well documented source code".
+
+It's just words compiled by an algorithm, but they still feel kinda good!
+While Evennia was always meant to be used for any type of multiplayer text game, this general use have been expanded and cleaned up a lot over the years.
+This has been reflected in the width of people wanting to use it for different genres: Over time the MUSH people influenced us into adding the option to play the same character from many different clients at the same time (apparently, playing on the bus and then continuing on another device later is common for such games). Others have wanted to use Evennia for interactive fiction, for hack&slash, deep roleplay, strategy, education or just for learning Python.
+Since Evennia is a framework/library and tries to not impose any particular game systems, it means there is much work to do when building a game using Evennia. The result is that there are dozens of games "in production" using Evennia (and more we probably don't know about), but few public releases yet.
+The first active "game" may have been an Evennia game/chat supporting the Russian version of 4chan... The community driven Evennia demo-game Ainneve is also progressing, recently adding combat for testing. This is aimed at offering an example of more game-specific code people can build from (the way Diku does). There are similar projects meant for helping people create RPI (RolePlay Intensive) and MUSH-style games. That said, the Evennia-game Arx, After the Reckoning is progressing through beta at a good clip and is showing all signs of becoming the first full-fledged released Evennia game.
+So cheers, Evennia for turning 10. That's enough of the introspection and history. I'll get back to more technical aspects in the next post.
+
+
+
+
+
+
+
+ Season of fixes
+ ¶
+ - October 13, 2016
+
+
+The last few months has been dominated by bug-fixing and testing in Evennia-land. A lot more new users appears to be starting to use Evennia, especially from the MUSH world where the Evennia-based Arx, After the Reckoning is, while still in alpha, currently leading the charge.
+With a new influx of users comes the application of all sorts of use- and edge-cases that stretch and exercise the framework in all the places where it matters. There is no better test of code than new users trying to use it unsupervised! Evennia is holding up well overall but there are always things that can be improved.
+
+
+A fun thing with a growing user base is that we are also starting to see a lot more Pull requests and contributions. Thanks a lot, keep 'em coming!
+
+
+The fixing and tightening of the nuts and bolts will likely continue the remainder of the year. I'm currently working on a refactoring of the way command sets are merged together (see the end of my blog post on Evennia in pictures for a brief summary of the command system). But with so much new blood in the community, who can tell where things will turn from here!
+
+
+
+
+
+
+
+ The art of sharing nicks and descriptions
+ ¶
+ - July 1, 2016
+
+
+In the month or so since the merger of Evennia's development branch and all its web-client updates, we have been in bug-fixing mode as more people use and stress the code.
+There have been some new features as well though - I thought it could be interesting to those of you not slavishly following the mailing list.
+Shared web login
+When you are logged into the website you will now also auto-login to your account in the web client - no need to re-enter the login information! The inverse is also true. You still need to connect to game at least once to create the account, but after that you will stay connected while the browser session lasts.
+Behind the scenes the shared login uses cookies linked to server-side Django sessions which is a robust and safe way to manage access tokens. Obviously browser sessions are irrelevant to telnet- or ssh connections.
+Extended Nicks
+Evennia's nick(name) system is a way to create a personal alias for things in game - both to on-the-fly replacing text you input and for referring to in-game objects. In the old implementation this replacement was simply matched from the beginning of the input - if the string matched, it was replaced with the nick.
+In this new implementation, the matching part can be much more elaborate. For example you can catch arguments and put those arguments into the replacement nick in another order.
+Let's say we often use the @dig command this limited way:
+
+@dig roomname;alias = exit;alias, backexit;alias
+
+Let's say we find this syntax unintuitive. The new nick system allows to change this by catching the arguments in your nick and put it into the "real" command. Here is an example of a syntax putting the aliases in parentheses and separating all components with commas:
+> nick newroom $1($2), $3($4), $5($6) = @dig $1;$2 = $3;$4, $5;$6
+From here on you can now create your rooms with entries like this:
+> newroom The great castle(castle), to the castle(castle), back to the path(back)
+Multidescer contrib
+I have added a new "multidescer" to the contrib folder. A multidescer is (I think) a MUSH term for a mechanism managing more than one description. You can then combine any of these various descriptions into your "active" description.
+An example of usage:
+desc hat = a blue hat.
+desc basic = This is a tall man with narrow features.
+desc clothing = He is wearing black, flowing robes.
+These commands store the description on the Character and references them as unique keywords. Next we can combine these strings together in any order to build the actual current description:
+> desc/set basic + |/ + clothing + On his head he has + hat
+> look self
+This is a tall man with narrow features.
+He is wearing black, flowing robes. On his head he has a blue hat.
+This allows for both very flexible and easy-to-update descriptions but also a way to handle freeform equipment and clothing. And you can of course use the nick system to pre-format the output
+> nick setdesc $1 $2 $3 $4 = $1 + |/ + clothing + On his head he has a $4
+This way you can clothe yourself in different outfits easily using the same output format:
+> setdesc basic clothing hat
+The multidescer is a single, self-contained command that is easy to import and add to your game as needed.
+... There's also plenty of bug fixes, documentation work and other minor things or course.
+Anyway, summer is now upon us here in the northern hemisphere so things will calm down for a bit, at least from my end. Have a good 'un!
+
+
+
+
+
+
+
+ Evennia in Pictures
+ ¶
+ - May 31, 2016
+
+This article describes the MU* development system Evennia using pictures!
+This article was originally written for Optional Realities.
+Since it is no longer available to read on OR, I'm reposting it in full here.
+Figure 1: The parts of the Evennia library
+
+Evennia is a game development library. What you see in Figure 1 is the part you download from us. This will not run on its own, we will soon initialize the missing “jigsaw puzzle” piece on the left. But first let’s look at what we’ve got.
+Looking at Figure 1 you will notice that Evennia internally has two components, the Portal and the Server. These will run as separate processes.
+The Portal tracks all connections to the outside world and understands Telnet protocols, websockets, SSH and so on. It knows nothing about the database or the game state. Data sent between the Portal and the Server is protocol-agnostic, meaning the Server sends/receives the same data regardless of how the user is connected. Hiding behind the Portal also means that the Server can be completely rebooted without anyone getting disconnected.
+The Server is the main “mud driver” and handles everything related to the game world and its database. It's asynchronous and uses Twisted. In the same process of the Server is also the Evennia web server component that serves the game’s website. That the Server and webserver are accessing the database in the same process allows for a consistent game state without any concerns for caching or race condition issues.
+Now, let’s get a game going. We’ll call it mygame. Original, isn’t it?
+Figure 2: The full setup for mygame
+
+After installing evennia you will have the evennia command available. Using this you create a game directory - the darker grey piece in Figure 2 that was missing previously. This is where you will create your dream game!
+During initialization, Evennia will create Python module templates in mygame/ and link up all configurations to make mygame a fully functioning, if empty, game, ready to start extending. Two more commands will create your database and then start the server. From this point on, mygame is up and running and you can connect to your new game with telnet on localhost:4000 or by pointing your browser to http://localhost:4001.
+Now, our new mygame world needs Characters, locations, items and more! These we commonly refer to as game entities. Let’s see how Evennia handles those.
+Figure 3: The Database Abstraction of Evennia entities
+
+Evennia is fully persistent and abstracts its database in Python using Django. The database tables are few and generic, each represented by a single Python class. As seen in Figure 3, the example ObjectDB Python class represents one database table. The properties on the class are the columns (fields) of the table. Each row is an instance of the class (one entity in the game).
+Among the example columns shown is the key (name) of the ObjectDB entity as well as a Foreign key-relationship for its current “location”. From the above we can see that Trigger is in the Dungeon, carrying his trusty crossbow Old Betsy!
+The db_typeclass_path is an important field. This is a python-style path and tells Evennia which subclass of ObjectDB is actually representing this entity.
+Figure 4: Inheriting classes to customize entities
+
+In Figure 4 we see the (somewhat simplified) Python class inheritance tree that you as an Evennia developer will see, along with the three instanced entities.
+ObjectDB represents stuff you will actually see in-game and its child classes implement all the handlers, helper code and the hook methods that Evennia makes use of. In your mygame/ folder you just import these and overload the things you want to modify. In this way, the Crossbow is modified to do the stuff only crossbows can do and CastleRoom adds whatever it is that is special about rooms in the castle.
+When creating a new entity in-game, a new row will automatically be created in the database table and then “Trigger” will appear in-game! If we, in code, search the database for Trigger, we will get an instance of the Character class back - a Python object we can work with normally.
+Looking at this you may think that you will be making a lot of classes for every different object in the game. Your exact layout is up to you but Evennia also offers other ways to customize each individual object, as exemplified by Figure 5.
+Figure 5: Adding persistent Attributes to a game entity.
+
+The Attribute is another class directly tied to the database behind the scenes. Each Attribute basically has a key, a value and a ForeignKey relation to another ObjectDB. An Attribute serializes Python constructs into the database, meaning you can store basically any valid Python, like the dictionary of skills seen in Figure 5. The “strength” and “skills” Attributes will henceforth be reachable directly from the Trigger object. This (and a few other resources) allow you to create individualized entities while only needing to create classes for those that really behave fundamentally different.
+Figure 6: Sessions, Players and Objects
+
+Trigger is most likely played by a human. This human connects to the game via one or more Sessions, one for each client they connect with. Their account on mygame is represented by a PlayerDB entity. The PlayerDB holds the password and other account info but has no existence in the game world. Through the PlayerDB entity, Sessions can control (“puppet”) one or more ObjectDB entities in-game.
+In Figure 6, a user is connected to the game with three Sessions simultaneously. They are logged in to their Player account Richard. Through these Sessions they are simultaneously puppeting the in-game entities Trigger and Sir Hiss. Evennia can be configured to allow or disallow a range of different gaming styles like this.
+Now, for users to be able to control their game entities and actually play the game, they need to be able to send Commands.
+Figure 7: Commands are Python classes too
+
+Commands represent anything a user can input actively to the game, such as the look command, get, quit, emote and so on.
+Each Command handles both argument parsing and execution. Since each Command is described with a normal Python class, it means that you can implement parsing once and then just have the rest of your commands inherit the effect. In Figure 7, the DIKUCommand parent class implements parsing of all the syntax common for all DIKU-style commands so CmdLook and others won’t have to.
+Figure 8: Commands are grouped together in sets and always associated with game entities.
+
+Commands in Evennia are always joined together in Command Sets. These are containers that can hold many Command instances. A given Command class can contribute Command instances to any number of Command Sets. These sets are always associated with game entities. In Figure 8, Trigger has received a Command Set with a bunch of useful commands that he (and by extension his controlling Player) can now use.
+Figure 9: Command Sets can affect those around them
+
+Trigger’s Command Set is only available to himself. In Figure 8 we put a Command Set with three commands on the Dungeon room. The room itself has no use for commands but we configure this set to affect those inside it instead. Note that we let these be different versions of these commands (hence the different color)! We’ll explain why below.
+Figure 10: The name Command “Set” is not just a name
+
+Command Sets can be dynamically (and temporarily) merged together in a similar fashion as Set Theory, except the merge priority can be customized. In Figure 10 we see a Union-type merger where the Commands from Dungeon of the same name temporarily override the commands from Trigger. While in the Dungeon, Trigger will be using this version of those commands. When Trigger leaves, his own Command Set will be restored unharmed.
+Why would we want to do this? Consider for example that the dungeon is in darkness. We can then let the Dungeon’s version of the look command only show the contents of the room if Trigger is carrying a light source. You might also not be able to easily get things in the room without light - you might even be fumbling randomly in your inventory!
+Any number of Command Sets can be merged on the fly. This allows you to implement multiple overlapping states (like combat in a darkened room while intoxicated) without needing huge if statements for every possible combination. The merger is non-destructive, so you can remove cmdsets to get back previous states as needed.
+… And that’s how many illustrations I have the stamina to draw at this time. Hopefully this quick illustrated dive into Evennia helps to clarify some of the basic features of the system!
+
+
+
+
+
+
+
+ Evennia 0.6!
+ ¶
+ - May 22, 2016
+
+
+As of today, I merged the development branch to make version 0.6 of the MU* development system and server Evennia.
+Evennia 0.6 comes with a lot of updates, mainly in the way Evennia talks to the outside world. All communication is now standardized, so there are no particular treatment of things like text - text is just one of any standardized commands being passed between the server the client (whether over telnet, ssh, websockets or ajax/comet).
+For example the user can now easily plug in "inputfuncs" to handle any data coming from the client. If you want your client to offer some particular functionality, you just need to plop in a python function to handle it, server-side. We also now offer a lot of utility functions for things like monitoring change (tell the client whenever your health status changes so it can update a health bar or flash the screen).
+The HTML5 webclient has itself updated considerably. Most is happening behind the scenes though. Notably the webclient's javascript component is split into two:
+
+
+
+There are a truckload of more updates and features that are covered on the mailing list.
+
+
+
+
+
+
+
+ Technical stuff happening
+ ¶
+ - March 24, 2016
+
+
+Hi folks, a bit more technical entry this time. These usually go onto the Evennia mailing list but I thought it would be interesting to put it in the dev-blog for once.
+So, I'm now halfway through the TODO list issue of the wclient development branch as alluded to in the last post. The wclient branch aims to rework and beef up the web client infrastructure of Evennia.
+The first steps, which has been done a while was converting the SSH/SSL and IRC input/output protocols to use the new protocol infrastructure (telnet and websockets was done since before). That's just under-the-hood stuff though. Today I finished the changes to the Monitor/TickerHandlers, which may be of more general interest.
+With the changes to the the way OOB (Out-Of-Band) messages are passing through Evennia (see this mailing list post for more details), the OOBHandler is no more. As discussed there, the handling of incoming data is becoming a lot freer and will be easily expandable to everyone wanting to make for a custom client experience. The idea is thus for Evennia to offer resources for various input commands to make use of, rather than prescribing such functionality in a monolothic way in the OOBHandler. There were three main functionalities the OOBHandler offered, and which will now be offered by separate components:
+
+
+The MonitorHandler
+evennia.MONITOR_HANDLER is the new singleton managing monitoring of on-object field/attribute changes. It is used like this:
+MONITOR_HANDLER.add(obj, field_or_attrname, callback, **kwargs)
+
+Here obj is a database entity, like a Character or another Object. The field_or_attrname is a string giving the name of a db_* database field (like "db_key", "db_location" etc). Any name not starting with db_ is assumed to be the name of an on-object Attribute (like "health"). Henceforth, whenever this field or attribute changes in any way (that is, whenever it is re-saved to the database), the callback will be called with the optional kwargs, as well as a way to easily get to the changed value. As all handlers you can also list and remove monitors using the standard MONITOR_HANDLER.remove(), .all() etc.
+The TickerHandler
+evennia.TICKER_HANDLER should be familiar to Evennia users from before - it's been around for a good while. It allows for creating arbitrary "tickers" that is being "subscribed" to - one ticker will call all subscribers rather than each object or function having its own timer.
+Before, the syntax for adding a new ticker required you specify a typeclassed entity and the name of the method on it to call every N seconds. This will now change. This is the new callsign for creating a new ticker:
+TICKER_HANDLER.add(interval, callback, idstring="", persistent=True, *args, **kwargs)
+
+Here**, interval,** like before, defines how often to call **callback(*args, kwargs).
+The big change here is that callback should be given as a valid, already imported callable, which can be either an on-entity method (like obj.func) or a global function in any module (like world.test.func) - the TickerHandler will analyze it and internally store it properly.
+idstring works as before, to separate tickers with the same intervals. Finally persistent=False means the ticker will behave the same way a Script with persistent=False does: it will survive a server reload but will not survive a server shutdown. This latter functionality is particularly useful for client-side commands since the client Session will also not survive a shutdown.
+... So this is a rather big API change to the TickerHandler, which will mean some conflicts for those of you relying heavily on tickers. Easiest will definitely be to simply stop the old and start new ones. It's not clear yet if we'll offer some automated way to convert old tickers to new ones. Chime in if this is something important to you.
+Happening Next
+The next steps involves making use of these new utilities to implement the basic OOB commands recommended by the MSDP and GMCP protocols along with some recommended functionality. We'll see how long that takes, but progress is being made. And if you are a web guy, do consider helping out.
+
+
+
+
+
+
+
+ Climbing up Branches
+ ¶
+ - February 14, 2016
+
+
+Today I pushed the latest Evennia development branch "wclient". This has a bunch of updates to how Evennia's webclient infrastructure works, by making all exchanged data be treated equal (instead of treating text separately from other types of client instructions).
+It also reworks the javascript client into a library that should be a lot easier to expand on and customize. The actual client GUI is still pretty rudimentary though, so I hope a user with more web development experience can take upon themselves to look it over for best practices.
+A much more detailed description of what is currently going on (including how to check out the latest for yourself) is found in this mailing list post. Enjoy!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2017.html b/devblog/html/devblog2017.html
new file mode 100644
index 0000000000..abb0936264
--- /dev/null
+++ b/devblog/html/devblog2017.html
@@ -0,0 +1,713 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Getting a MUD RP scene going
+ ¶
+ - October 29, 2017
+
+This article is a little different from the normal more technical Evennia-specific content of this blog. It was originally published as a light-hearted addition to the Imaginary Realities e-zine many years ago. While IR is still online it has since dozed off. So I'm reposting it here to bring it to a new audience.
+In roleplay-heavy MUDs (and in other categories of text-based roleplaying games), the concept of scenes become important. A scene in this concept is simply a situation big or small that involves you and your fellow players in interesting role play. A scene can be as simple as two players meeting in the street and exchanging a few words to the dramatic conclusion to a staff-driven quest. Whenever role player-interested players meet, a scene may happen.
+But sometimes scenes won’t come naturally. Sometimes your favourite game has only a few people online, or most of them are hovering in private areas. It’s time to go proactive. Below I offer some archetypes, tropes and ideas for how to get a random Scene started and people interested. The list is based on one I did for a RP-heavy MUD I played some time back.
+Some terms used in the list:
+
+
+Scene starters
+Scene starters are for when you are alone in a room hoping for others to join you (we've all done it). It is considerably easier to run Scene starters if there is some OOC way for other players to know where to find you (such as a list showing who's interesting in roleplay and where they are in the game). If not, it’s best to prepare your starter in a commonly visited central location or hub. You normally trigger the starter whenever another Player enters.
+The Scene starters below are intended as ideas and suggestions, but are also examples of archetypical behaviour I’ve observed myself.
+The Barfly
+A role playing mud classic since time immemorial. The barfly is alone in a tavern and tends their drink, waiting for things to happen. A passive role, but trivial to setup and easy for other players to jump in on - they just slide up to the bar and ask what's up. Fun variations is the drunk barfly or really, really sad/happy barfly, states which immediately give other Players things to ask about and work with.
+The Strider
+This is the "dark stranger in the corner" variation of the barfly. It is simple to execute - just sit in a dark tavern corner looking glum and mysterious. Often used by newbie players unsure of the game’s commands. The problem is that unless they know the Strider from before it's hard for other Characters to include him/her in their roleplay in a realistic way. The whole IC point of this trope is after all to avoid attention.
+ The Busybody
+The busybody is keeping busy in this room. Most commonly they are performing their job. If they own a bar or run the shop, they tend it. If they are guardsmen they are standing on patrol. If they are wee jesters they are making fools out of themselves. And so on. This is a great starter since it is both natural, realistic and in-character all at once. The nature of their work may occasionally make it easier or harder for other Characters come up with reasons to interact with them though - it might be harder to motivate why some characters would strike up a conversation with a guardsman than they would with a street vendor.
+The Demagogue
+This more involved starter involves striking up a loud conversation with an NPC/vNPC. Whenever another Character enters, the Demagogue plays out a small scene where they are "arguing" with the NPC, playing both roles. The argument could be "continuing" or just starting as the new PC enters. It could be about anything from tavern prices to refuting a made-up insult. The advantage of this is that it gives immediate character to the demagogue and to the NPC both. It also makes it easy for the newcomer to get into the scene just by taking sides in the debate.
+
+The Damsel in Distress
+This starter, which of course works both for male and female Characters, sets up the damsel as being in a dependency situation to whomever enters the room next. It involves describing the damsel in a sort of precarious situation that clearly requires an extra hand to resolve. This could be anything: Having their hands full and nearly dropping stuff. Chasing a dog that is running off with their book. Being accosted by vNPC ruffians (which should bugger off quickly, unless roleplaying completely “virtual” combat is your cup of tea). Either way the newcomer has an ongoing scene to react to, and roleplay immediately ensues.
+The Organizer
+This starter requires that the game has a developed in-game message- or mailing system. If so - use it to explicitly and in-character invite people to a scene! If the organizer is in a position of in-game power, this could make good IC sense - like the lord calling on their vassals to attend some sort of function. But anything from calling in a favor to suggesting a business opportunity or looking for a job works. Throw a party. Get drunk and send an ill-advised love letter. This starter works exceptionally well in combination with Stage director or Aggravator for getting selected Players into a memorable scene.
+
+The Aggravator
+The aggravator starts off on the wrong foot with people. Maybe they lash out due to some perceived injustice or they are just grumpy. This starter does not fit all character concepts. The aggravator should accuse the newly arrived PC for something. It could be something from their common history or something made-up out of the blue. It is an active starter in that it leads the way and forces other PCs into roleplay - if nothing else in order to defend themselves. A simple example is to chide the newly arrived PC for not stopping the vNPC that just ran past them out the door. It's important not to take the aggravator trope too far, especially not when using vNPCs. The idea is to get a scene started with some tension, not to get the other (possibly random) PC into real trouble. No god-modding, remember. If the two Characters are actual enemies though, it may be another matter ...
+The Stage Director
+This is a more sophisticated starter that is halfway to improvised theater. It sets up a whole little scene involving some event with a number of semi-named vNPCs. The stage director could be directly involved or be a spectator (in which case other PCs can walk up to them and ask what's going on). The event could be anything from a trite bar brawl to a domestic dispute in progress. Or why not a marriage proposal between two vNPCs in the middle of the street! If the stage director is threatened in some way, this is a large-scale version of damsel in distress.
+The nice thing about staged scenes like this is that it gives depth and personality to the game and is often highly appreciated by other Players. If done well, the stage director could give everyone involved a true feeling of being in a living environment.
+The scene could continue to be played out around the PCs also as they interact, making this starter potentially demanding on the stage director. If the other Players are experienced they should pick up on this and maybe even contribute their own vNPCs to the scenario (or the stage director could actively invite other Players to do so). It's important to remember to avoid god-modding here - never dictate another PCs actions, let other Players react as they see fit.
+
+The Lazy Bum
+This is unfortunately the most common of starters and we've probably all done it one time or another. It does not involve anything but simply standing in a room. No action set, no nothing. Just being there, the Character staring blankly into space until something happens. Yeah.
+Scene entrances
+Here are some ideas on how to enter a scene/room with one or more other PCs already involved in role play. It should be noted that if other PCs already have a scene going they might be OOC annoyed if the newcomer muscles in with some room-changing entrance. So you as a Player have to show some consideration here. Check the land and eventual actions set on people in the room. If a great scene is already in progress you shouldn’t need to start your own - instead try to get in on the action!
+The Mouse
+The most common of entering schemes. The Mouse walks into the room/area not drawing attention to themselves. A simple, passive setup that fits many situations and Character concepts. The mouse is a useful way to enter an already running scene. It is a bit overused though, possibly being The lazy bum of entrances. It seem to imply that it is up to others to notice and respond to the mouse. If really aiming for anonymity, the mouse must emote explicitly that they are not drawing attention to themselves, making it clear to other characters they need not go out of their way to be courteous and notice the newcomer.
+The Ignoranti
+The ignoranti acts as if they do not notice the other Characters in the room. This entrance variant is useful for crowded or large locations. It is also realistic - just because the “chock-full” tavern has only two PCs in it, it doesn’t mean you would actually immediately notice them. vNPCs are everywhere. The ignoranti must emote their ignorance explicitly, with something like "S/he does not notice the others yet". This entrance makes for a nice variation by allowing the ignoranti and other PCs to "accidentally" bump into each other later in a very natural way.
+
+The Walker
+The walker is just "passing through" this area. This entrance is useful for outdoor areas or minor streets were many Character concepts probably have no real reason to be hanging about more than necessary. The walker is really heading somewhere else and just happens to stop to chat with people in this room. It's an effective entrance that allows for quick, logical exits as well (they just have to 'be on their way'). This is far better than the more common approach of just congesting onto a street room and start greeting people as if all you do is stand in the street all day.
+The Planned Visitor
+This is a variation on The busybody and the opposite of The walker. The planned visitor needs to come to this room, and that is not in order to chat with random PCs. The visitor will start to perform whatever they are here to do and interaction with others is mere a side effect. The classic take on this trope is to read message boards or to order food and drink. More imaginative ones could be to ask the NPC barkeep for a job, look for a vNPC (which turns out to not be here), repair something, do some sort of inspection or setup for an artistic performance. If done well, others will have plenty of opportunity to ask The Planned Visitor what they are up to. It also makes for a thematic way to exit the scene once you declare your business there done.
+The Wet Kitten
+A classic that involves entering a scene drenched to the bone, shivering from cold, gasping from heat or otherwise be dramatically and visually affected by whatever weather or situation reigns outside. Common to taverns everywhere. For some reason this entrance rarely instills as much sympathy as one would think - but at least it opens up for other Characters to comment on the weather. Taken to the extreme, this becomes a variation on Damsel in Distress.
+The Third Wheel
+This is an active, provocative entrance and a variant on the aggravator. It should directly interrupt and involve other PCs in the room entered. The trivial confrontational way to do this is for the intruder to muscle or elbow past other PCs in a rude way, maybe even (attempting to) give them a rough shove (remember to avoid god-modding). This is sure to start off a scene! The more common third-wheel approach is to walk up to another group of conversing PCs and simply jump into their conversation mid-sentence. How this is received depends on the situation and Characters involved.
+In both cases it's important to make it clear that your actions is a conscious RP choice - it’s your Character which is inconsiderate, not the Player behind it. In other words, emote something like “... He/She does not seem to notice or care that s/he is intruding...”
+The Theatrist
+This is an on-the-fly version of the Stage director or demagogue. Only use if it's clear the currently ongoing scene allows it (so its often a good idea to follow a few emotes in the room before setting this one off). Just like stage director, it starts some sort of background action in the room based on vNPCs. Maybe a brawl, an argument or some other event like a happy announcement. Maybe a vNPC starts hitting on a PC. Or, like the demagogue, the theatrist gets involved in a discussion with an NPC/vNPC. Bartender NPCs are classically useful targets for this. Again, the theatrist must be considerate here, and perceptive so as to not take over an already running scene. Some PCs might forcibly choose to ignore the events going on in order to focus on their ongoing RP, so don't shove it down their throats (no god-modding!)
+The Non-sequitur
+This, strangely rare, entrance involves running into a crowded room, shouting "Monkeeey!" and then run out again. This one will at least lead to roleplay for the confused people in the room you just visited. And no, don't do this unless you have a very specific and suitable character concept, kids.
+
+The Newbie
+The classic newbie entrance involves walking into a room and saying "Hello" to no one in particular. Bonus points if this is done while ignoring the fact that the room's on fire and the PCs within are all involved in mortal combat. Luckily this entrance trope screams newbie so clearly that players may be urged to pity and lenience. It may in fact be the trigger for getting a more experienced player to take the newbie under their wing and explain a thing or two.
+
+
+
+
+
+
+
+ Evennia in Hacktobergest 2017
+ ¶
+ - October 1, 2017
+
+
+Evennia, the Python MUD/MUSH/MU* creation library participates in the Hacktoberfest 2017 (sign up on that page)! Hacktoberfest is open for all open-source projects like ours. After registering, if you make at least four Pull Requests to a public repo on Github during October (need not just be to Evennia), you win a limited-edition T-shirt!
+The help Evennia out and get your T-Shirt, look at our Issue Tracker. I have marked some issues with "Hacktoberfest" but you could take on any issue you want. Take a look in particular at the Unit test issue if you are looking to get into contributing on a smaller scale while helping us tremendously.
+If you have any questions on contributing (or it's your first time making a Pull Request), don't be shy to drop into #evennia on irc.freenode.net or ask in our forum/mailing list. Have fun!
+
+
+
+
+
+
+
+ Evennia 0.7 released
+ ¶
+ - September 20, 2017
+
+Evennia 0.7 released
+
+As of today Evennia 0.7 is officially out! Evennia is a Python framework and -server for creating text-based multiplayer games (MU*).
+A big thank you to all collaborators that have helped with code and testing along the way!
+Here is the hefty forum post that details how you migrate to Evennia 0.7.
+Evennia 0.7 comes with a range of changes and updates (these are just the ones merged from the latest devel branch, a lot more has happened since 0.6 that were already in master):
+
+
+New contribs (optional plugins) (selection, new since 0.6 but many have been available on master branch for a while):
+
+
+A more technical list from the main announcement post:
+
+
+
+
+
+
+
+
+
+ Renaming Django's Auth User and App
+ ¶
+ - August 25, 2017
+
+
+Now that Evennia's devel branch (what will become Evennia 0.7) is slowly approaching completion, I thought I'd try to document an aspect of it that probably took me the longest to figure out. One change in Evennia 0.7 is that the Django model named "Player" changes name to "Account". Over time it has become clear that the old name didn't properly reflected the intention of the model. Sounds like a simple change, right? Well, it was not.
+Briefly on migrations
+First some background. A Django migration is a small Python file sitting in migrations/ sub folders throughout Evennia. A migration describes how our database schema changes over time, so as we change or update fields or add new features we add new migrations to describe how to go from the old to the new state. You apply them with the evennia migrate command we sometimes ask you to run. If we did not supply migrations, anyone with an existing Evennia database would have to either start from scratch or manually go in and tweak their database to match every upstream change we did.
+Each migration file has a sequential number, like migration_name.0002.py etc. Migrations will run in order but each migration can also "depend" on another. This means for example that a migration in the player/ folder (application) knows that it need to wait for the changes done by a migration in the typeclasses/ folder/app before it can run. Finally, Django stores a table in the database to know which migrations were already run so to not apply them more than once.
+For reference, Evennia is wrapping the django manage commands, so where I refer to evennia migrate below you would use manage.py migrate in most Django applications.
+Our problem
+So I wanted to migrate the database change "Rename the Player model to Account". We had to do this under a series of additional constraints however:
+
+
+Some false starts
+There is no lack of tutorials and help online for solving the problem of renaming a model. I think I tested most of them. But none I found actually ended up addressing these restraints. Especially point 2 in combination with point 3 above is a killer.
+
+
+In the end I concluded that I had to abandon the notion that users be able to just do a single migrate command. Some more work would be needed on the user's part.
+The solution
+In the end I needed to combine the power of migrations with the power of Git. Using Git resolved the Gordian knot about the player folder. Basically the process goes like this:
+
+
+
+ # ...
+
+
+
+ def forwards(apps, schema_editor):
+
+ try:
+
+ PlayerDB = apps.get_model("players", "PlayerDB")
+
+ except LookupError:
+
+ return
+
+
+
+ # copy data from player-tables to database tables here
+
+
+
+ class Migrations(migrations.Migration):
+
+ # ...
+
+ operations = [
+
+ migrations.RunPython(forwards, migrations.RunPython.noop)
+
+ ]
+
+
+
+
+
+ from django.db import connection
+
+
+
+ # ...
+
+
+
+ def _table_exists(db_cursor, tablename):
+
+ "Returns bool if table exists or not"
+
+ sql_check_exists = "SELECT * from %s;" % tablename
+
+ ### [Renaming Django's Auth User and App](https://evennia.blogspot.com/2017/08/renaming-djangos-auth-user-and-app.html)
+
+
+
+And with this, the migration's design was complete. Below is how to actually use it ...
+Running the final migration
+In brief, what our users will do after pulling the latest code is as follows:
+
+
+Conclusions
+And that's it. It's a bit more involved for the end user than I would have liked, and took me much longer than expected to figure out. But it's possible to reproduce and you only need to do it once - and only if you have a database to convert. Whereas this is necessarily specified for Evennia, I hope this might give a hint for other django users aiming to do something like this!
+
+
+
+
+
+
+
+ The luxury of a creative community
+ ¶
+ - April 23, 2017
+
+
+For this blog post I want to focus on the series of very nice pull requests coming in from a growing cadre of contributors over the last few months.
+Contributed goodness
+People have put in a lot of good work to boost Evennia, both by improving existing things and by adding new features. Thanks a lot everyone (below is just a small selection)!
+
+
+About that Evennia 0.7 ...
+So while PRs are popping up left and right in master I've been working in the devel branch towards what will be the Evennia 0.7 release. The branch is not ready for public consumption and testing yet But tentatively it's about halfway there as I am slowly progressing through the tickets. Most of the upcoming features were covered in the previous blog post so I'll leave it at that.
+I just want to end by saying that it's a very luxurious (and awesome) feeling for me to see master-branch Evennia expand with lots of new stuff "without me" so to speak. The power of Open Source indeed!
+
+
+
+
+
+
+
+ News items from the new year
+ ¶
+ - February 5, 2017
+
+
+The last few months have been mostly occupied with fixing bugs and straightening out usage quirks as more and more people take Evennia through its paces.
+Webclient progress
+One of our contributors, mewser/titeuf87 has put in work on implementing part of our roadmap for the webclient. In the first merged batch, the client now has an option window for adjusting and saving settings. This is an important first step towards expanding the client's functionality. Other features is showing help in an (optional) popup window and to report window activity by popup and/or sound.
+The goal for the future is to allow the user or developer to split the client window into panes to which they can then direct various output from the server as they please It's early days still but some of the example designs being discussed can be found in the wiki webclient brainstorm (see the title image of this blog for one of the mockups).
+New server stuff
+Last year saw the death of our old demo server on horizondark.com, luckily the new one at silvren.com has worked out fine with no hickups. As part of setting that up, we also got together a more proper list of recommended hosts for Evennia games. Evennia requires more memory than your average C code base so this is important information to have. It seems most of our users run Evennia on various cloud hosting services rather than from a traditional remote server login.
+Arx going strong
+The currently largest Evennia game, the mush Arx - After the Reckoning has helped a lot in stress testing. Their lead coder Tehom has also been active both in reporting issues and fixing them - kudos! There are however some lingering issues which appears rarely enough that they have not been possible to reproduce yet; we're working on those. Overall though I must say that considering how active Arx is, I would have expected to have seen even more "childhood diseases" than we have.
+Launch scripts and discussions
+It is always interesting with feedback, and some time back another discussion thread erupted over on musoapbox, here. The musoapbox regulars have strong opinions about many things and this time some were critical of Evennia's install process. They felt it was too elaborate with too many steps, especially if you are approaching the system with no knowledge about Python. Apparently the average MUSH server has a much shorter path to go (even though that does require C compiling). Whereas I don't necessarily agree with all notions in that thread, it's valuable feedback - I've long acknowledged that it's hard to know just what is hard or not for a beginner.
+Whereas we are planning to eventually move Evennia to pypi (so you can do pip install evennia), the instructions around getting virtualenv setup is not likely to change. So there is now unix shell scripts supplied with the system for installing on debian-derived systems (Debian, Ubuntu, Mint etc). I also made scripts for automating the setup and launch of Evennia and to use it with linux' initd within the scope of a virtualenv.
+So far these scripts are not tested by enough people to warrant them being generally recommended, but if you are on a supported OS and is interested to try they are found from the top of the Evennia repo, in bin/unix/. More info can be found on their documentation page.
+Docker
+Speaking of installing, Evennia now has an official Docker image, courtesy of the work of contributor and Ainneve dev feend78. The image is automatically kept up-to.date with the latest Evennia repo and allows Evennia to be easily deployed in a production environment (most cloud services supports this). See Docker wiki page for more info.
+Lots of new PRs
+There was a whole slew of contributions waiting for me when returning from Chistmas break, and this has not slowed since. Github makes it easy to contribute and I think we are really starting to see this effect (Google Code back in the day was not as simple in this regard). The best thing with many of these PRs is that they address common things that people need to do but which could be made simpler or more flexible. It's hard to plan for all possibilities, so many people using the system is the best way to find such solutions.
+Apart from the map-creation contribs from last year we also have a new Wildnerness system by mewser/titeuf87. This implements wilderness according to an old idea I had on the mailing list - instead of making a room per location, players get a single room. The room tracks its coordinate in the wildnerness and updates its description and exits dynamically every time you move. This way you could in principle have an infinite wilderness without it taking any space. It's great to see the idea turned into a practical implementation and that it seems to work so well. Will be fun to see what people can do with it in the future!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2018.html b/devblog/html/devblog2018.html
new file mode 100644
index 0000000000..1404b2252c
--- /dev/null
+++ b/devblog/html/devblog2018.html
@@ -0,0 +1,415 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Evennia 0.8 released
+ ¶
+ - September 30, 2018
+
+After about a year of work and almost 540 commits from close to 20 contributors, Evennia 0.8 is out! Evennia is a Python game server for creating text-based multiplayer games (MUDs, Mushes, etc) using Django and Twisted.
+Some of the upcoming improvements have been covered by previous dev blogs, such as the completely reworked server infrastructure:
+
+as well as the new Online Creation System that allows for editing in-game prototypes using a powerful menu system:
+
+Other improvements are in the web client, which supports split-panes out of the box. The user can split the output area in any number of panes, resize as desired and then assign different types of content to each pane. You can also have panes that absorb "all the rest" or "all" of the content.
+
+There are still some bits which are a bit shaky and there is still much to do with the web client (for example, not that many outgoing messages yet defaults to being tagged in a way that the webclient recognizes). But it's a step forward!
+There are many other improvements for developers, such as easier tools for running debuggers and a lot of new utilities and helper functions. The menu-creation tool (EvMenu) has seen a lot of improvements and also sport a few new decorators for quickly creating multi-page menus with full functionality to flip through and select large numbers of options.
+The community has also chipped in with a large number of optional contributions for developers to use for their own game, such as a full turn-based combat system (divided into convenient chunks for the dev to pick and choose support for everything from magic and potions to equipment and ranged attacks). There are also a range of helper functions for creating simpler menus and build commands as well as auditing tools and additions making better use of Django's very mature security features.
+The more detailed list of improvements and changes can be found in the announcement here. As usual, please report any issues to the issue tracker on github.
+Future
+In the immediate future, we'll focus on resolving any bugs that may have slipped through the cracks and also resolve some other issues in the pipeline.
+But beyond that, work on Evennia 0.9 will begin. And before you ask - yes Evennia 0.9 is the version where we'll move fully to Python3. Our dependencies have now reached a point where this is possible and there will be no intermediary Python2/3 version. There is no timeline for the 0.9 release but it should hopefully not be too tricky for the community to make the jump when the time comes.
+
+
+
+
+
+
+
+ Inline building in upcoming Evennia 0.8
+ ¶
+ - August 18, 2018
+
+
+Evennia, the Python MUD-server game development kit, is slowly creeping closer to its 0.8 release.
+In our development branch I've just pushed the first version of the new OLC (OnLine Creator) system. This is a system to allow builders (who may have limited coding knowledge) to customize and spawn new in-game objects more easily without code access. It's started with the olc command in-game. This is a visual system for manipulating Evennia Prototypes.
+Briefly on Prototypes
+The Prototype is an Evennia concept that has been around a good while. The prototype is a Python dictionary that holds specific keys with values representing properties on a game object. Here's an example of a simple prototype:
+
+ {"key": "My house",
+
+ "typeclass": "typeclasses.houses.MyHouse"}
+
+
+By passing this dict to the spawner, a new object named "My house" will be created. It will be set up with the given typeclass (a 'typeclass' is, in Evennia lingo, a Python class with a database backend). A prototype can specify all aspects of an in-game object - its attributes (like description and other game-specific properties), tags, aliases, location and so on. Prototypes also support inheritance - so you can expand on an existing template without having to add everything fresh every time.
+There are two main reasons for the Prototypes existing in Evennia:
+
+
+What's new
+As said, Prototypes have been around for a good while in Evennia. But in the past they were either manually entered directly as a dict on the command line, or created in code and read from a Python module. The former solution is cumbersome and requires that you know how to build a proper-syntax Python dictionary. The latter requires server code access, making them less useful to builders than they could be.
+Note: If you are visually impaired, each image is also a link to a text-only version.
+
+In Evennia 0.8, while you can still insert the Prototype as a raw dict, spawn/menu or the new olc command opens a new menu-driven interface.
+
+More importantly, builders can now create, save and load prototypes in the database for themselves and other builders to use. The prototypes can be tagged and searched as a joint resource. Builders can also lock prototypes if others are not to be able to read or use them to spawn things. Developers can still supply module-based "read-only" prototypes (for use as starting points or examples to their Builders, for example).
+
+You can now also use the menu to search for and create a new Prototype based on an existing object (if you have access to do so). This makes it quick to start up a new prototype and tweak it for spawning other similar objects. Of course you could spawn temporary objects without saving the prototype as well.
+
+Builders will likely not know which typeclasses are available in the code base. There are new a few ways to list them. The menu display makes use of Evennia 0.8's new EvMenu improvements, which allows for automatically creating multi-page listings (see example above).
+There is also a new switch to the typeclass command, /list, that will list all available typeclasses outside of the OLC.
+Protfuncs
+Another new feature are Protfuncs. Similarly to how Inlinefuncs allows for calling for the result of a function call inside a text string, Protfuncs allows for calling functions inside a prototype's values. It's given on the form $funcname(arguments), where arguments could themselves contain one or more nested Protfuncs.
+As with other such systems in Evennia, only Python functions in a specific module or modules (given by settings) are available for use as Protfuncs in-game. A bunch of default ones are included out of the box. Protfuncs are called at the time of spawning. So for example, you could set the Attribute
+
+Strength = $randint(5, 20)
+
+to automatically spawn objects with a random strength between 5 and 20.
+
+When spawning, the olc will validate the prototype and run tests on any Protfunc used. For convenience you can override the spawn-location if any is hard-coded in the prototype.
+
+The system will also allow you to try updating existing objects created from the same-named prototype earlier. It will sample the existing objects and calculate a 'diff' to apply. This is bit is still a bit iffy, with edge cases that still needs fixing.
+Current status
+The OLC is currently in the develop branch of Evennia - what will soon(ish) merge to become Evennia 0.8.
+It's a pretty big piece of code and as such it's still a bit unstable and there are edge cases and display issues to fix. But it would be great with more people trying it out and reporting errors so the childhood issues can be ironed out before release!
+
+
+
+
+
+
+
+ Kicking into gear from a distance
+ ¶
+ - January 27, 2018
+
+
+The last few weeks I have reworked the way Evennia's startup procedure works. This is now finished in the develop branch so I thought I'd mention a little what's going on.
+Evennia, being a server for creating and running text-games (MU*s), consists of two main processes:
+
+
+Since Evennia should be easy to set up and also run easily on Windows as well as on Linux/Mac, we have foregone using the linux process management services but instead offered our own solution. This is how the reload mechanism currently looks in master branch:
+
+Here I've excluded connections irrelevant to reloading, such as the Twisted AMP connection between Portal and Server. Dashed lines suggest a more "temporary" connection than a solid line.
+The Launcher is the evennia program one uses to interact with the Server in the terminal/console. You give it commands like evennia start/stop/reload.
+
+
+The original reason for this Server-Portal-Runner setup is that the Portal is also reloadable in the same way (it's not shown above). But over time I've found that having the Portal reloadable is not very useful - since players get disconnected when the Portal reloads one can just as well stop and start both processes. There are also a few issues with the setup, such as the .pid files going stale if the server is killed in some catastrophic way and various issues with reliably sending signals under Windows. Also, the interactive mode works a little strangely since closing the terminal will actually kill the Runner, not the Server/Portal - so they will keep on running except they can no longer reload ...
+It overall feels a little ... fiddly.
+In develop branch, this is now the new process management setup:
+
+The Portal is now a Twisted AMP server, while the Evennia Server and Launcher are AMP clients. The Runner is no more.
+
+
+So far I really like how this new setup works and while there were some initial issues on Windows (spawning new processes does not quite work they way you expect on that platform) I think this should conceptually be more OS-agnostic than sending kill-signals.
+This solution gives much more control over the processes. It's easy to start/stop the Server behind the portal at will. The Portal knows the Server state and stores the executable-string needed to start the Server. Thus the Server can also itself request to be reloaded by just mimicking the Launcher's instructions.
+The launcher is now only a client connecting to a port, so one difference with this setup is that there is no more 'interactive' mode - that is the Server/Portal will always run as daemons rather than giving log messages directly in the terminal/console. For that reason the Launcher instead has an in-built log-tailing mechanism now. With this the launcher will combine the server/portal logs and print them in real time to easily see errors etc during development.
+The merger of the develop branch is still a good bit off, but anyone may try it out already here: https://github.com/evennia/evennia/tree/develop . Report problems to the issue tracker as usual.
+
+
+
+
+
+
+
+ New year, new stuff
+ ¶
+ - January 5, 2018
+
+
+Happy 2018 everyone! Here's a little summary of the past Evennia year and what is brewing.
+(Evennia is a Python server- and toolbox for creating text-based multiplayer games (MU*)).
+The biggest challenge for me last year Evennia-wise was the release of Evennia 0.7. Especially designing the migration process for arbitrary users migrating the Django auth-user took a lot of thought to figure out as described in my blog post here. But now 0.7 is released and a few initial minor adjustments could be made after feedback from daring pilot testers. The final process of migrating from 0.6 to 0.7 is, while involved, a step-by-step copy&paste list that has worked fine for most to follow. I've gotten far fewer questions and complains about it than could be expected so that's a good sign.
+Working away on the boring but important behind-the-scenes stuff made me less able to keep up with more "mundane" issues and bugs popping up, or with adding new "fun" features to existing code. Luckily the Evennia community has really been thriving this year; It feels like new users pop up in the support channel all the time now. The number of pull requests both fixing issues and offering new features and contribs have really picked up. A bigger part of my time has been spent reviewing Pull Requests this year than any other I think. I would like to take the opportunity to thank everyone contributing, it's really awesome to see others donating their time and energy adding to Evennia. The Hacktoberfest participation was also surprisingly effective in getting people to create PRs - I have a feeling some were just happy to have an "excuse" for getting started to contribute. We should attend that next year too.
+One thing we added with 0.7 was a more formal branching structure: Evennia now uses fixed master and develop branches, where master is for bug-fixes and develop is for new features (things that will eventually become evennia 0.8). This is simple but enough for our needs; it also makes it easier to track new from old now that we are actually doing releases.
+Now that Twisted is at a point where this is possible for us to do, we also now have a sort-of plan for finally moving Evennia to Python 3. I won't personally be actively working on it until after 0.8 is out though. I don't expect both Evennia 0.8 and 0.9 (which will be pure py3) to get released this year, but we'll see - so far contributors have done all the work on the conversion.
+At any rate, this coming year will probably be dominated by catching up on issues and edge cases that are lining our Issue tracker. One side effect of more newcomers is more eyes on the code and finding the creaky-bits. At least for me, most of my Evennia-time will be spent resolving bugs and issues. The fun thing is that unlike previous years this is not only up to me anymore - hopefully others will keep helping to resolve issues/bugs to broaden our bandwidth when it comes to keeping Evennia stable. The faster we can handle the backlog of issues the faster we can focus on new shiny features after all.
+Finally, a continued great thank you to those of you contributing to the Patreon. Even small donations have a great encouraging value when working on something as niche as a Python MU* game server in 2018 - thanks a lot!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2019.html b/devblog/html/devblog2019.html
new file mode 100644
index 0000000000..838772a70b
--- /dev/null
+++ b/devblog/html/devblog2019.html
@@ -0,0 +1,725 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Blackifying and fixing bugs
+ ¶
+ - September 30, 2019
+
+
+Since version 0.9 of Evennia, the MU*-creation framework, was released, work has mainly been focused on bug fixing. But there few new features also already sneaked into master branch, despite technically being changes slated for Evennia 1.0.
+On Frontends
+Contributor friarzen has chipped away at improving Evennia's HTML5 web client. It already had the ability to structure and spawn any number of nested text panes. In the future we want to extend the user's ability to save an restore its layouts and allow developers to offer pre-prepared layouts for their games. Already now though, it has gotten plugins for handling both graphics, sounds and video:
+
+
+Inline image by me (deviantart.com/griatch-art)
+
+A related fun development is Castlelore Studios' development of an Unreal Engine Evennia plugin (this is unaffiliated with core Evennia development and I've not tried it, but it looks pretty nifty!):
+
+
+Image ©Castlelore Studios
+
+On Black
+Evennia's source code is extensively documented and was sort of adhering to the Python formatting standard PEP8. But many places were sort of hit-and-miss and others were formatted with slight variations due to who wrote the code.
+After pre-work and recommendation by Greg Taylor, Evennia has adopted the black autoformatter for its source code. I'm not really convinced that black produces the best output of all possible outputs every time, but as Greg puts it, it's at least consistent in style. We use a line width of 100.
+I have set it up so that whenever a new commit is added to the repo, the black formatter will run on it. It may still produce line widths >100 at times (especially for long strings), but otherwise this reduces the number of different PEP8 infractions in the code a lot.
+On Python3
+Overall the move to Python3 appears to have been pretty uneventful for most users. I've not heard almost any complaints or requests for help with converting an existing game.
+The purely Python2-to-Python3 related bugs have been very limited after launch; almost all have been with unicode/bytes when sending data over the wire.
+People have wholeheartedly adopted the new f-strings though, and some spontaneous PRs have already been made towards converting some of Evennia existing code into using them.
+Post-launch we moved to Django 2.2.2, but the Django 2+ upgrades have been pretty uneventful so far.Some people had issues installing Twisted on Windows since there was no py3.7 binary wheel (causing them to have to compile it from scratch). The rise of the Linux Subsystem on Windows have alleviated most of this though and I've not seen any Windows install issues in a while.
+On Future
+For now we'll stay in bug-fixing mode, with the ocational new feature popping up here and there. In the future we'll move to the develop branch again. I have a slew of things in mind for 1.0.
+Apart from bug fixing and cleaning up the API in several places, I plan to make use of the feedback received over the years to make Evennia a little more accessible for a new user. This means I'll also try reworking and consolidating the tutorials so one can follow them with a more coherent "red thread", as well as improving the documentation in various other ways to help newcomers with the common questions we hear a lot.
+The current project plan (subject to change) is found here. Lots of things to do!
+
+
+
+
+
+
+
+ Evennia 0.9 released
+ ¶
+ - July 4, 2019
+
+
+Last week we released Evennia 0.9, the next version of the open source Python MU* creation system.
+This release is the result of about 10 months of development, featuring 771 commits, 70 closed pull requests from the community and something like 80 issues and feature/requests closed. Thanks everyone!
+The main feature of Evennia 0.9 is that we have finally made the move to Python3. And we burn the bridges behind us; as announced in previous posts we completely drop Python2 support and move exclusively to only support the latest Python3.7.
+Overall the move to Python3 was not too bloody (and much work towards a never published py2+3 version was already done by Evennia contributors in a separate branch earlier). The main issues I ran into were mainly in the changes in how Python3 separates strings from bytes. This became crticial since Evennia implements several connection protocols; there were a lot of edge cases and weird errors appearing where data went to and from the wire.
+A regular user has it a lot easier though. So far people have not had too much trouble converting their games from 2.7 to 3.7. The biggest Linux distros don't all have Py3.7 out of the box though, so that may be a concern for some, we'll see.
+... but Py3 is nowhere all there is to find in this release though! There are a plethora of more features in the latest Evennia, all to make it easier to make the text-based multiplayer game of your dreams.
+You can see a summary of new features in the ML announcement and even more details in the actual CHANGELOG file.
+So what's up next?
+Now follows a period of bug-fixing and stabilizing. Maybe resolve some of those long-standing "tech-dept" issues and overall make Evennia more stable.
+Eventually work will then commence (in the develop branch) on version 1.0 of Evennia. For this next release I think I'll step back from new features a bit and focus on refactoring and cleanup of the API as well as other things around the library's distribution, documentation and presentation.
+But for now, onward to summer vacations.
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 2
+ ¶
+ - May 26, 2019
+
+
+
+
+This is part two of my post-mortem dev-blog about Evscaperoom, the multiplayer, text-based 'escape room' I wrote in Python and Evennia. You can read the first part of the dev blog here.
+This was a game-jam entry I created in a month for the Mud Coder's guild's Game Jam. The theme was One Room. You can play the game for free in your browser or with a traditional MUD client. There are no spoilers in these blog posts.
+Update: These days you can play the Evscaperoom by logging into the Evennia demo game at https://demo.evennia.com. It's just one of the exits you can get through when you enter.
+The first part dealt with the overall game-design aspects. This second, final part will go into details of the code and the systems I built to quickly create all the content. The code referenced here is released under the BSD license and is available on github.
+At the time of this post, players have played Evscaperoom for a little more than a week. At the end I'll share some observations and things I learned along the way.
+Ease of building
+Over the one-month game jam, I spent about four days making the game's 'engine' and toolset with Evennia. The rest of the time was spent using those tools to actually create game content (the story, puzzles etc).
+An important thing was that I didn't want to do any traditional in-game 'building'. That is - no logging into the game and running various commands to build objects and rooms. This is partly because I wanted rooms to be buildable on-demand, but also because I didn't want my game to only exist in the database but in actual version-controllable python modules.
+So all of the Evscaperoom is created in code (notably in the game states discussed below). This made it so that I could add unit tests to quickly find bugs and edge cases. It also made it easy to just clone the full game to an online server, init a database and run Evennia on it in a docker when time came to make it public.
+Overall game structure
+
+Main menu
+The game loop is simple: When you log in to the game, you get into a menu where you can create a new room to solve or join an existing one. Quitting a room brings you back to that menu. Quitting again leaves the game entirely. In between, you remain inside a single game location ('room').
+To make it easier for people to agree to meet up in a room, i made a little 'fantasy name generator' to make unique random names of the rooms. It felt more thematic than showing room id's. The generator combines phonemes together with some very simple logic. Not all comes out easy-to-pronounce, but the result is at least identifiable, like the Sheru and Uyoha above.
+I decided that I should not keep empty rooms around, so whenever a room has no more players in it, it's deleted from the database along with all its content. This means players can't really log off and come back to the same room unless a friend stays behind. I felt it was worth keeping things clean and avoid a growing backlog of empty, unsolved rooms. It is, unfortunately, quite common for players to log in, create a room and then immediately log off.
+I distribute Evscaperoom as an Evennia 'game dir'. Once you've installed Evennia you can just clone the evscaperoom repo and start a new multiplayer server with it. While the game dir has some Evennia templates in it by default, Almost all the custom logic for this game is in the evscaperoom/ folder. The only other modification I did was to make sure Evennia rerouted new players into the Evscaperoom menu when they connect.
+Room class
+Since all of the gameplay happens in a single room, it made sense to center all of the data-storage around a new, custom Evennia Room class. This "EvscapeRoom" class holds all resources for this room. Evennia makes sure to persist it all to the database for you.
+The Evennia API provides a lot of powerful but game-general functions. Since our use-case for this game is very strictly defined, I made a slew of helper functions to cut down on boiler plate and pre-set options I wanted to always use.
+For example, I added helper methods both for creating and finding objects in the room. On creation, all objects are tagged with the room's unique hash, meaning that one can be sure to never have any cross-over between rooms (like accidentally finding the object in another room (that of course has the exact same name). Since I also decided to never have more than one object with a given name per room, I could make these methods very simple.
+The room class also has helpers for finding all players in the room and for sending messages to them. It also catches players leaving so that eventual on-character variables can be cleaned.
+Importantly, the very action of deleting the room will automatically clean all resources tied to it, keeping things tidy.
+Commands and Objects
+
+The help screen, show all top-level commands
+As discussed in part one of this blog, the Evscaperoom, uses a 'focus' mode: The player must examine/focus on an object first in order to operate or use it.
+The basic command syntax is:
+> command [target]
+The parsing I made actually allows for a more complex syntax, but in the end this was all that was really needed, since the currently 'focused' object does not need to be specified. This is the process of using one object with another:
+> examine key
+
+~~ key (examining) ~~
+
+This is a brass key.
+
+
+
+(To unlock something with it, use insert into <target>)
+
+
+> insert into door
+You unlock the **door** with the **key**!
+
+(the into is optional). Here, we focus on the key. We get the key's description and a hint that you can insert it into things. We then insert it into the door, which is another object in the room. The insert command knows that we are focusing on the key already and that it should look into the room for an object door to use this with.
+Technically, these on-object 'actions' (like insert above), are dynamically generated. Here is an example of the key object:
+
+class Key(EvscaperoomObject):
+
+ def at_focus_insert(self, caller, **kwargs):
+
+ target = kwargs['args']
+
+ obj = caller.search(obj)
+
+ if not obj:
+
+ return
+
+ if obj.check_flag("can_use_key"):
+
+ obj.handle_insert(self)
+
+
+Not shown here is that I made a wrapper for the "no-match" command of Evennia. This command fires when no other commands match. I made this instead analyze the currently 'focused' object to see if it had a method at_focus_<command_name> on it. If so, I inject the supplied arguments into that method as a keyword argument args.
+So when you focus on the key and give the insert command, the at_focus_insert method on the key will be called with a target to insert the key into_._ We search for the target (the door in the example), check if it even accepts keys and then pass the key to that object to handle. It would then be up to the door to figure out if this particular key unlocks it.
+I created a library of base objects that I can just use as mixins for the object I want to create. Here's an example:
+
+from evscaperoom import objects
+
+
+
+class Box(objects.Openable,
+
+ objects.CodeInput,
+
+ objects.Movable):
+
+ # ...
+
+
+This class will offer actions to open, insert a code and move the object around. It will need some more configuration and addition of messages to show etc. But overall, this method-to-command solution ended up being very stable and extremely easy to use to make complex, interactive objects.
+Room states
+I think of the escape room as going through a series of states. A change of state could for example be that the user solved a puzzle to open a secret wall. That wall is now open, making new items and puzzles available. This means room description should change along with new objects being created or old ones deleted.
+I chose to represent states as Python modules in a folder. To be a state, each module needs to have a global-level class State inheriting from my new BaseState class. This class has methods for initializing and cleaning up the state, as well as was for figuring out which state to go to next. As the system initializes the new state, it gets the current room as argument, so it can modify it.
+This is a (simplified) example of a state module:
+
+# module `state_001_start.py`
+
+
+
+from evscaperoom.state import BaseState
+
+from evscaperoom import objects
+
+
+
+MUG_DESC = """
+
+A blue mug filled with a swirling liquid.
+
+On it is written "DRINK ME" with big letters.
+
+"""
+
+
+
+class Mug(objects.EvscapeRoomObject):
+
+ def at_focus_drink(self, caller, **kwargs):
+
+ caller.msg(f"You drink {self.key}.")
+
+ self.next_state() # trigger next state
+
+
+
+class State(BaseState):
+
+
+
+ hints = ["You are feeling a little thirsty...",
+
+ "Drink from the mug, dummy."]
+
+
+
+ next_state = "state_002_big_puzzle"
+
+
+
+ def init(self):
+
+ mug = self.create_object(
+
+ Mug, key="wooden mug", aliases=["mug"])
+
+ mug.db.desc = MUG_DESC.strip()
+
+
+In this simple state, a mug is created, and when you drink from it, the next state is triggered. The base object has a helper function to trigger the next state since I found that interactive with an object is almost always the reason for switching states.
+The state-class has a lot of useful properties to set, such as which the next state should be (this can be overridden in case of branching paths). You can also store
+a sequence of hints specific for that state.
+Informing the room
+I wrote the content in second-person perspective ("You open the door"). This is however a multiplayer game and I didn't intially appreciate how many texts must also exist in a third-party form for the rest of the room to see ("Griatch opens the door").
+As the amount of text grew (the Evscaperoom has close to 10 000 lines of code, a lot of which is content strings), it became clear that it would not be feasible to manually supply third-persion version strings as well.
+The solution was to add parsing and translation of pronouns and verbs (a concept I first saw on the game Armageddon).
+I write the string like this:
+
+ OPEN_TEXT = "~You ~open the *door."
+
+
+The ~ marks text that should be parsed for second/third-person use (I'll discuss the *door marking in the next section). This I then send to a helper method that either sends it only to you (which means it comes back pretty much the same, but without the special markers) or to you and to the room, in which it will look different depending on who receives it:
+I see
+You open the [door].
+
+
+
+Others see
+Griatch opens the [door].
+
+English is luckily pretty easy to use for this kind of automatic translation - in general you can just add an "s" to the end of the verb. I made a simple mapping for the few irregular verbs I ended up using.
+Overall, this made it quick to present multiple viewpoints with minimal extra text to write.
+
+
+The option menu
+
+The *door -style marking allowed me to generalize how target-able objects in the room were displayed. This meant that users can customize how objects are shown to them. The default is to mark them both with colors and square brackets (this makes it clear also for people with screen readers). But one can also use only colors or turn off the marking completely (hard mode).
+Bringing it online
+Evennia is both a mud framework and mudserver as well as a webserver based on Twisted. It runs the game's website (with the help of Django) and also provides its own HTML5 webclient. I tweaked the default website text and played a little with CSS but otherwise didn't spend too much time on this bit.
+I got a $5/month DigitalOcean droplet with Ubuntu. I made a new, unprivileged "evennia" user on it and cloned the evscaperoom repo to it. I then started a tmux session and ran the Evennia docker image in there. Getting the game online took maybe thirty minutes, most of which was me figuring out where to open the droplet and DigitalOcean firewalls.
+I then pointed http://experimental.evennia.com at the droplet's IP and that was it!
+Updating the online server is now only a matter of pushing changes to my github repo, pulling it to the server and reloading Evennia; Before release, I used a private github repo for this, afterwards I simply made it public. Pretty straightforward.
+Some lessons learned
+I have gotten pretty positive reviews on Evscaperoom so far. In the first two days people stumbled on some edge-case bugs, but after that it has been very stable. Mostly I've had to make small typos and grammar corrections as I (or players) spot them.
+There were nevertheless some things I learned, some of which led to more real improvements post-launch.
+No amount of help is too much help
+
+
+The header shows how to get out of focus mode
+
+Firstly, the focus-system (examine, then do stuff) is a little un-orthodox and needs to be explained. I saw people logging in, examining exactly one thing and then logging out. Eventually I found out (because a user told me), that this was likely because they could not figure out how to leave the focus mode. They'd just flounder about, think the game was buggy and log off.
+The answer (just run examine again) is found with the help command, but clearly this was not intuitive. The solution was to add an explicit help text to the top every time you examine something. After this, the confusion seems to have gone away.
+Make it easy to connect for all tastes
+Another example - a commenting user had pretty strong opinions about the fact that you used to have to supply a username and password to play the game. They suggested this was a 'huge hurdle'. Not sure if that's true. But unless you want to use a particular name, there is also no actual gameplay reason to formally authenticate for Evscaperoom.
+This was easy to fix. Evennia has guest-player support out of the box so I just activated that and supplied some more fantasy-sounding names than the default "Guest 1", "Guest 2" etc. Since then, maybe 40% of players connecting have chosen to do so as an anonymous guest. I don't know if those would have left completely if the option was not available, but it's at least a convenient shortcut for getting into the game.
+Everything takes longer than expected
+I already knew this one, but still I fell into the trap of thinking that things were going well and that there would be plenty of time to finish before deadline.
+Creating text content is a lot faster than creating graphical assets, but it's still a lot of work. Just the ending 'cinematics' took me almost two days to finish and clean up at the end.
+For once I did pick a reasonable scale for this project though. So while the last few days of the Jam was more intense than I would have liked, I never truly felt like I would not be able to finish in time.
+Building a MU* game in pure code is awesome
+Evennia tries to not instil and specific game type, hence its tools are very general. Wrapping these general tools as a highly opinionated and game-specific toolbox enforced to me just how easy it is to do things when you don't need to cover the general case.
+Using the tools and creating content purely in-code was great and ended up leading to a very fast content creation. Python works perfectly as a scripting language and I don't think there is a reason for using in-game building at all for your game, especially not when you are working on your own like this.
+I made a few admin-only commands to jump between states and to set flags, but otherwise most bugs were caught by a generic unit test that just looped over all founds states and tried to initialize them, one after another.
+Conclusions
+For all my work on the Evennia library/server, I've not actually used it for games of my own very much. This was a great opportunity for doing so. It also gave me the opportunity to test the Python3-development branch of Evennia in a production setting.
+I found a few edge-case library bugs which I fixed, but overall things worked very smoothly, also for this kind of game which is certainly far away from the normal MU*-mold that most use Evennia for. I am a bit biased, but overall I felt Evennia to be very mature for the use of making a game from scratch.
+In the future I will most likely break out the 'engine' and tools of the Evscaperoom into an Evennia contrib so that others can make similar games with it easily.
+Looking forward to future game jams now!
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 1
+ ¶
+ - May 18, 2019
+
+
+Over the last month (April-May 2019) I have taken part in the Mud Coder's Guild Game Jam "Enter the (Multi-User) Dungeon". This year the theme for the jam was One Room.
+The result was Evscaperoom, an text-based multi-player "escape-room" written in Python using the Evennia MU* creation system. You can play it from that link in your browser or MU*-client of choice. If you are so inclined, you can also vote for it here in the jam (well, no more).
+This little series of (likely two) dev-blog entries will try to recount the planning and technical aspects of the Evscaperoom. This is also for myself - I'd better write stuff down now while it's still fresh in my mind!
+Update: The Evscaperoom can these days be played by connecting to the Evennia game demo at https://demo.evennia.com.
+Inception
+When I first heard about the upcoming game-jam's theme of One Room, an 'escape room' was the first thing that came to mind, not the least because I just recently got to solve my my own first real-world escape-room as a gift on my birthday.
+If you are not familiar with escape-rooms, the premise is simple - you are locked into a room and have to figure out a way to get out of it by solving practical puzzles and finding hidden clues in the room.
+While you could create such a thing in your own bedroom (and there are also some one-use board game variants), most escape-rooms are managed by companies selling this as an experience for small groups. You usually have one hour to escape and if you get stuck you can press a button (or similar) to get a hint.
+I thought making a computer escape-room. Not only can you do things in the computer that you cannot do in the real world, restricting the game to a single room limits so that it's conceivable to actually finish the damned thing in a month.
+A concern I had was that everyone else in the jam surely must have went for the same obvious idea. In the end that was not an issue at all though.
+Basic premises
+I was pretty confident that I would technically be able to create the game in time (not only is Python and Evennia perfect for this kind of fast experimentation and prototyping, I know the engine very well). But that's not enough; I had to first decide on how the thing should actually play. Here are the questions I had to consider:
+Room State
+An escape room can be seen as going through multiple states as puzzles are solved. For example, you may open a cabinet and that may open up new puzzles to solve. This is fine in a single-player game, but how to handle it in a multi-player environment?
+My first thought was that each object may have multiple states and that players could co-exist in the same room, seeing different states at the same time. I really started planning for this. It would certainly be possible to implement.
+But in the end I considered how a real-world escape-room works - people in the same room solves it together. For there to be any meaning with multi-player, they must share the room state.
+So what I went with was a solution where players can create their own room or join an existing one. Each such room is generated on the fly (and filled with objects etc) and will change as players solve it. Once complete and/or everyone leaves, the room is deleted along with all objects in it. Clean and tidy.
+So how to describe these states? I pictured that these would be described as normal Python modules with a start- and end function that initialized each state and cleaned it up when a new state was started. In the beginning I pictured these states as being pretty small (like one state to change one thing in the room). In the end though, the entire Evscaperoom fits in 12 state modules. I'll describe them in more detail in the second part of this post.
+Accessibility and "pixel-hunting" in text
+When I first started writing descriptions I didn't always note which objects where interactive. It's a very simple and tempting puzzle to add - mention an object as part of a larger description and let the player figure out that it's something they can interact with. This practice is sort-of equivalent to pixel-hunting in graphical games - sweeping with the mouse across the screen until you find that little spot on the screen that you can do something with.
+Problem is, pixel-hunting's not really fun. You easily get stuck and when you eventually find out what was blocking you, you don't really feel clever but only frustrated. So I decided that I should clearly mark every object that people could interact with and focus puzzles on better things.
+In fact, in the end I made it an option:
+
+As part of this I had to remind myself never to use colors only when marking important information: Visually impaired people with screen readers will simply miss that. Not to mention that some just disable colors in their clients.
+So while I personally think option 2 above is the most visually pleasing, Evscaperoom defaults to the third option. It should should start everyone off on equal footing. Evennia has a screen-reader mode out of the box, but I moved it into the menu here for easy access.
+Inventory and collaboration
+In a puzzle-game, you often find objects and combine them with other things. Again, this is simple to do in a single-player game: Players just pick things up and use them later.
+But in a multi-player game this offers a huge risk: players that pick up something important and then log off. The remaining players in that room would then be stuck in an unsolvable room - and it would be very hard for them to know this.
+In principle you could try to 'clean' player inventories when they leave, but not only does it add complexity, there is another issue with players picking things up: It means that the person first to find/pick up the item is the only one that can use it and look at it. Others won't have access until the first player gives it up. Trusting that to anonymous players online is not a good idea.
+So in the end I arrived at the following conclusions:
+
+
+As a side-effect of this I also set a limit to the kind of puzzles I would allow:
+
+
+Focusing on objects
+So without inventory system, how do you interact with objects? A trademark of any puzzle is using one object with another and also to explore things closer to find clues. I turned to graphical adventure games for inspiration:
+
+Secret of Monkey Island ©1990 LucasArts. Image from old-games.com
+A common way to operate on an object in traditional adventure games is to hover the mouse over it and then select the action you want to apply to it. In later (3D) games you might even zoom in of the object and rotate it around with your mouse to see if there are some clues to be had.
+While Evennia and modern UI clients may allow you to use the mouse to select objects, I wanted this to work the traditional MUD-way, by inserting commands. So I decided that you as a player would be in one of two states:
+
+
+
+In the example above, the fireplace points out other objects you could also focus on, whereas the last parenthesis includes one or more "actions" that you can perform on the fireplace only when you have it focused.
+This ends up pretty different from most traditional MUD-style inputs. When I first released this to the public, I found people logged off after their first examine. It turned out that they couldn't figure out how to leave the focus mode. So they just assumed the thing was buggy and quit instead. Of course it's mentioned if you care to write help, but this is clearly one step too many for such an important UI concept.
+So I ended up adding the header above that always reminds you. And since then I've not seen any confusion over how the focus mode works.
+For making it easy to focus on things, I also decided that each room would only ever have one object named a particular thing. So there is for example only one single object in the game named "key" that you can focus on.
+Communication
+I wanted players to co-exist in the same room so that they could collaborate on solving it. This meant communication must be possible. I pictured people would want to point things out and talk to each other.
+In my first round of revisions I had a truckload of individual emotes; you could
+point at target
+for example. In the end I just limited it to
+say/shout/whisper
+and
+emote
+And seeing what people actually use, this is more than enough (say alone is probably 99% of what people need, really). I had a notion that the shout/whisper could be used in a puzzle later but in the end I decided that communication commands should be strictly between players and not have anything to do with the puzzles.
+I removed all other interaction: There is no fighting and without an inventory or requirement to collaborate on puzzles, there is no need for other interactions than to communicate.
+First version you didn't even see what the others did, but eventually I added so that you at least saw what other players were focusing on at the moment (and of course if some major thing was solved/found).
+In the end I don't even list characters as objects in the room (you have to use the who command to see who's in there with you).
+
+The main help command output.
+Story
+It's very common for this type of game to have a dangerous or scary theme. Things like "get out before the bomb explodes", "save the space ship before the engines overheat", "flee the axe murderer before he comes back" etc). I'm no stranger to dark themes, but for this I wanted something friendlier and brighter, maybe with a some dark undercurrents here and there.
+My Jester character is someone I've not only depicted in art, but she's also an old RP character and literary protagonist of mine. Who else would find it funny to lock someone into a room only to provide crazy puzzles and hints for them to get out again? So my flimsy 'premise' was this:
+The village Jester wants to win the pie eating contest. You are one of her most dangerous opponents. She tricked you to her cabin and now you are locked in! If you don't get out in time, she'll get to eat all those pies on her own and surely win!
+That's it - this became the premise from which the entire game flowed. I quickly decided that it to be a very "small-scale" story: no life-or-death situation, no saving of the world. The drama takes place in a small village with an "adversary" that doesn't really want to hurt you, but only to eat more pies than you.
+From this, the way to offer hints came naturally - just eat a slice of "hintberry pie" the jester made (she even encourage you to eat it). It gives you a hint but is also very filling. So if you eat too much, how will you beat her in the contest later, even if you do get out?
+To further the rustic and friendly tone I made sure the story took place on a warm summer day. Many descriptions describe sunshine, chirping birds and the smell of pie. I aimed at letting the text point out quirky and slightly comedic tone of the puzzles the Jester left behind. The player also sometimes gets teased by the game when doing things that does not make sense.
+I won't go into the story further here - it's best if you experience it yourself. Let's just say that the village has some old secrets. And and the Jester has her own ways of doing things and of telling a story. The game has multiple endings and so far people have drawn very different conclusions in the end.
+Scoring
+Most often in escape rooms, final score is determined by the time and the number of hints used. I do keep the latter - for every pie you eat, you get a penalty on your final score.
+As for time - this background story would fit very well with a time limit (get out in X time, after which the pie-eating contest will start!). But from experience with other online text-based games I decided against this. Not only should a player be able to take a break, they may also want to wait for a friend to leave and come back etc.
+But more importantly, I want players to explore and read all my carefully crafted descriptions! So I'd much rather prefer they take their time and reward them for being thorough.
+So in the end I give specific scores for actions throughout the game instead. Most points are for doing things that drive the story forward, such as using something or solving a puzzle. But a significant portion of the score comes from turning every stone and trying everything out. The nice side-effect of this is that even if you know exactly how to solve everything and rush through the game you will still not end up with a perfect score.
+The final score, adjusted by hints is then used to determine if you make it in time to the contest and how you fare. This means that if you explore carefully you have a "buffer" of points so eating a few pies may still land you a good result in the end.
+First sketch
+I really entered the game 'building' aspect with no real notion of how the Jester's cabin should look nor which puzzles should be in it. I tried to write things down beforehand but it didn't really work for me.
+So in the end I decided "let's just put a lot of interesting stuff in the room and then I'll figure out how they interact with each other". I'm sure this is different from game-maker to game-maker. But for me, this process worked perfectly.
+
+
+My first, very rough, sketch of the Jester's cabin
+
+The above, first sketch ended up being what I used, although many of the objects mentioned never ended up in the final game and some things switched places. I did some other sketches too, but they'd be spoilers so I won't show them here ...
+The actual game logic
+The Evscaperoom principles outlined above deviate quite a bit from the traditional MU* style of game play.
+While Evennia provides everything for database management, in-game objects, commands, networking and other resources, the specifics of your game is something you need to make yourself - and you have the full power of Python to do it!
+So for the first three days of the jam I used Evennia to build the custom game logic needed to provide the evscaperoom style of game play. I also made the tools I needed to quickly create the game content (which then took me the rest of the jam to make).
+In part 2 of this blog post I will cover the technical details of the Evscaperoom I built. I'll also go through some issues I ran into and conclusions I drew. I'll link to that from here when it's available!
+
+
+
+
+
+
+
+ Podcast about Evennia
+ ¶
+ - May 9, 2019
+
+
+I was interviewed on the (pretty grandiosely named) podcast Titans of Text the other day.
+In the interview, which are run by people from the MUD Coder's Guild (a great initiative!), I talk a bit about the history of Evennia, the text-based multiplayer game engine I'm working on, and go into some various technical aspects of the engine as well. Check it out and support the podcast!
+
+
+
+
+
+
+
+
+ Steaming on Eating Jam
+ ¶
+ - April 25, 2019
+
+
+In the last few months, development of the upcoming Evennia 0.9 has been steaming on. Evennia is, as you may know, a Python library for creating text-based multiplayer games (MUDs, MUSH etc).
+But it's not all backend work! There is also some sweet game-jamming going on, I get to that at the end.
+Evennia progress towards Python3
+The regular Evennia develop branch is now running completely in Python 3. Since we are using some new features of this Python release, we will be aiming for Python 3.7 as a minimum version once Evennia 0.9 goes stable. We will also use Django 2.1 and likely Twisted 19 - so we'll be pretty much up-to-date on all our main dependencies.
+Now, while the release of Evennia 0.9 is still some time away (there are a bunch of regular bug fixes and minor features that I want to get in there too (see the progress here on the github 0.9 project page), it's worth to consider how much work it'll be for you to migrate and if you should wait or jump in right now.
+If you are new, I still recommend you use regular master branch Evennia (using Python 2.7). This is for which all wiki articles and documentation online is currently written after all. Once we move to python3, you'll need to convert your code ... but syntactically the two are really not that different and conversion should not be much of an issue.
+Not only are there automatic converters for most stuff, you should only need to do one pass to make sure things work and then you'll be done. This article is pretty old but it serves well to identify the main differences. Later Py3 versions just adds new stuff which you would just not have had access to in Python2.7. Once 0.9 is released, we'll also make guides for how you go about converting existing code (apart from the wealth of info on this topic online).
+That said, if you are feeling more adventurous, or really want to use Python3 right away, many of the Evennia developer regulars have been running and testing develop branch for months now. It's overall been a pretty painless transition - as said, py3 is not that different from py2.
+However, develop branch has other features beyond the py3 jump. And those are not yet documented in the main docs. So you'll have to contend with that (but asking in chat/forum works of course). However while it works fine for development already, as a matter of principle I do not recommend ever using Evennia's develop branch for a production game - it can change quickly and may occationally be broken. You have been warned!
+Game Jam
+We are now a little more than a week into the Mud Coders Guild's second yearly Game Jam. This year's theme is "One Room".
+I really hope some more Evennia devs jump on this one because Evennia is perfect for this kind of experimental games. This is because Evennia is not imposing a game style on you - while there are default commands you are free to replace or customize the commands, objects and every aspect of your game to be as specific as you want to your game.
+For example, I have a small Game Jam contribution in the works, where I very quickly reworked the default Evennia setup to pretty much make it into a different genre of game.
+Usually the systems I make for Evennia are generic and intended for any game-type. By contrast, making somehing highly niched is super-fast to do: Building a whole new framework for game mechanisms along with build helpers for me to quickly make content took no more than three days.
+There will no doubt be some iteration, but I hope to spend the rest of the jam time on content and gameplay. I have some RL things happening in the coming weeks (including work on Evennia proper) but if I can get the time to tie my jam entry together, I'll likely make one or two blog posts about how it was developed and my reasons for making the choices i did. Most likely the code will appear as an Evennia contribution in case people want to do something similar for their own projects.
+So, busy days.
+
+
+
+
+
+
+
+ Into 2019
+ ¶
+ - January 2, 2019
+
+
+A new year has come around and it's time to both look back at the old and onward to the future of Evennia, the Python MUD creation system!
+Last year
+
+Last year saw the release of Evennia 0.8. This version of Evennia changes some fundamental aspects of the server infrastructure so that the server can truly run in daemon mode as you would expect (no more running it in a GnuScreen session if you want to see logging to the terminal). It also adds the new Online Creation System, which lets builders create and define prototypes using a menu system as well as big improvements in the web client, such as multiple window-panes (allows the user to assign text to different windows to keep their client uncluttered) as well as plenty of fixes and features to help ease life for the Evennia developer. Thanks again to everyone who helped out and contributed to the release of Evennia 0.8!
+On a personal note, I spoke about Evennia at PyCon Sweden this December, which was fun. I might put up my talk and make a more detailed blog post about that in the future, but my talk got a surprising amount of attention and positive feedback. Clearly many people have fond memories of MUDs and enjoy seeing they are not only still around but are possible to create in Python!
+This year
+
+Now we are steaming ahead towards Evennia 0.9! Already we have had a large number of contributions towards this release. A coming change is a much improved central way to make typeclass information available to a website as well as central ways to do various common operations like creating characters and linking them to Accounts. Much of this functionality is today hidden in the various default commands. In Evennia 0.9 they will be moved into more easily-findable locations as library functions everyone can just trigger without having to copy functionality.
+The biggest change for Evennia 0.9 is however that we will now finally move Evennia over to Python 3. This is now possible as all our dependencies are now sufficiently ported. As discussed in the community for a long time, this will be a clean break - we will not offer any mid-way solution of Python2/3 but will drop Python2 support entirely. We will at the same time move to Django 2.+. In Django 0.9 we will however probably not use any special Python3 features yet. It should hopefully not be too difficult for our users to upgrade, but we'll of course publish extensive instructions and help when that time comes.
+We will likely support a minimum of Python 3.6 and maybe 3.7. This work is currently happening in a separate branch develop-py3 which will soonish merge into the current Python2.7-based develop branch and become Evennia 0.9 when it merges into master branch at an unknown time later this year.
+There are a slew of other things planned for Evennia 0.9 and you can follow the progress from our project page. If you want to help out you are of course also very welcome. If you are new and are interested in getting your feet wet in helping out with Open-source development, we have a list of good first issues you could jump into.
+Onward into the new year!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2020.html b/devblog/html/devblog2020.html
index 22398fec04..19761fd282 100644
--- a/devblog/html/devblog2020.html
+++ b/devblog/html/devblog2020.html
@@ -35,23 +35,35 @@
-
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
-
- Initial-Blog
- ¶
- - May 2, 2020
+
+ Evennia 0.9.5 released
+ ¶
+ - November 14, 2020
-A way to do things
-
This is a test blog page for using markdown to write
-Evennia devblog posts.
-Starting out
-I'm experimenting with a new section of the docs containing these
-blog posts (obviously the blogs are CC anyway).
+
+As of today, Evennia 0.9.5 is out. Evennia is a Python based library and framework for creating text-based multiplayer games (MUD/MU*).
+This is a gradual improvement halfway between 0.9 and the upcoming 1.0. So if you have been keeping up-to-date with the master branch of Evennia over the last year you will not notice much difference from this release (time to upgrade if you haven't been keeping up though!).
+While an interim release, there are still a lot of things that has happened since v0.9:
+Webclient improvements
+
+
+EvMenu improvements
+EvMenu is a powerful system for creating in-game text menus.
+
+
+New settings
+
+
+Other improvements
+
+
+See the changelog here.
+New documentation system
+The bigger change with 0.9.5 is that we are moving to a new documentation system. The details of the long road to do this is documented in my previous post. The point is that we are stopping the use of the Github wiki in favor of statically generated documentation hosted on github pages. At the same time we also move the old evennia.com website from Google-sites to Github.
+Check it out:
+
+
+As for the docs, they will be maturing for a long time still. The old wiki will not be updated anymore, but it will also not be going anywhere in the short term. Version 0.9.5 of the docs is pretty much a copy of the wiki and I hope to not have to spend too much more work maintaining it since the wiki is still around.
+New updates and documentation features will primarily be happening in the 1.0-dev version of the documentation. This will include refactoring all pages as well as a new intro-tutorial and many other things.
+But that's for future blogs ...
+
+
+
+ On using Markdown with Sphinx
+ ¶
+ - October 20, 2020
+
+
+Last post I wrote about the upcoming v1.0 of Evennia, the Python MU* creation engine. We are not getting to that 1.0 version quite yet though: The next release will be 0.9.5, hopefully out relatively soon (TM).
+Evennia 0.9.5 is, as you may guess, an intermediary release. Apart from the 1.0 roadmap just not being done yet, there is one other big reason for this - we are introducing documentation versioning and for that a proper release is needed as a base to start from. Version 0.9.5 contains everything already in master branch, so if you have kept up-to-date you won't notice too much difference. Here are some highlights compared to version 0.9:
+
+
+Many contributors helped out along the way. See the changelog where contributors of the bigger new features are listed.
+The path to a new documentation
+For many years we've used the Github wiki as our documentation hub. It has served us well. But as mentioned in my previous post, it has its drawbacks, in particular when it comes to handling documentation for multiple Evennia versions in parallel.
+After considering a bunch of options, I eventually went with sphinx, because it has such a good autodoc functionality (parsing of the source-code docstrings). This is despite our wiki docs are all in markdown and I dislike restructured text quite a bit. Our code also uses friendly and in-code-readable Google-style docstrings instead of Sphinx' hideous and unreadable format.
+Luckily there are extensions for Sphinx to handle this:
+
+
+What could go wrong? Well, it's been quite a ride.
+Getting Markdown into reST
+Linking to things in recommonmark turned out to be very flaky. I ended up forking and merging a bunch of PRs from the project but that was not enough: Clearly this thing was not built to convert 200 pages of technical markdown from a github wiki.
+My custom fork of recommonmark had to be tweaked a bit for my needs, such as not having to specify the .md file ending in every link and make sure the url-resolver worked as I expected. There were a bunch of other things but I will probably not merge this back, the changes are pretty Evennia-specific.
+Even so, many of my wiki links just wouldn't work. This is not necessarily recommonmark's fault, but how sphinx works by grouping things into toctrees, something that the Evennia wiki doesn't have.
+Also, the recommonmark way to make a toctree in Markdown is to make a list of links - you can't have any descriptive text, making the listing quite useless (apparently people only want bland lists of link-names?). After trying to figure out a way to make this work I eventually capitulated - I make pretty lists in Markdown while using a "hidden" toctree to inform sphinx how the pages are related.
+Getting the wiki into the new doc site
+This required more custom code. I wrote a custom importer that reads the wiki and cleans/reformats it in places where recommonmark just dies on them. I also made a preprocessor that not only finds orphan pages but also builds a toctree and remaps all links in all documents to their actual location on compilation. The remapper makes it a lot easier to move things around. The drawback is that every page needs to be uniquely named. Since this was already the case in the wiki, this was a good tradeoff. So with a lot of custom code the wiki eventually could port automatically.
+The thing is, that even with all this processing, recommonmark doesn't support stuff like Markdown tables, so you still have to fall back to reST notation for those. And Napoleon, while doing a good job of parsing google docstrings, do not expect Markdown. So the end result is mostly markdown but we still have to fall back to reST for some things. It's probably as far as we get.
+Deploying the docs
+Figuring out how to build and deploy these components together was the next challenge. Sphinx' default Makefile was quite anemic and I also wanted something that regular contributors could use to test their documentation contributions easily. I ended up having to expand the Makefile quite a lot while also adding separate deploy scripts and interfaces to github actions (which we recently started using too).
+Finally, the versioning. The sphinx-multiversion plugin works by extracting the branches you choose from git and running the sphinx compiler in each branch. The plugin initially had a bug with how our docs are located (not at the root of the package) but after I reported it, it was quickly fixed. The result is a static document site where you can select between the available versions in the sidebar.
+I've not gotten down to trying to make LaTeX/PDF generation work yet. I'm dreading it quite a bit...
+Where we are
+The github wiki is now closed for external contributions. The v0.9.5 of the new documentation will pretty much be an import of the last state of the wiki with some minor cleanup (such as tables). While we'll fix outright errors in it, I don't plan to do many fixes of purely visual glitches from the conversion - the old wiki is still there should that be a problem.
+The main refactoring and cleanup of the documentation to fit its new home will instead happen in v1.0. While the rough structure of this is already in place, it's very much a work in progress at this point.
+Conclusions
+Evennia 0.9.5 has a lot of features, but the biggest things are 'meta' changes in the project itself. After it is out, it's onward towards 1.0 again!
+
+
+
+
+
+
+
+ Spring updates while trying to stay healthy
+ ¶
+ - April 14, 2020
+
+
+So, spring grows nearer for those of us on the Northern hemisphere. With everyone hopefully hunkered down and safe from the Covid-19 pandemic, I thought it overdue to make another dev blog for the progress of Evennia, the Python MU*-creation system.
+The last few months have seen primarily bug fixing on the Evennia front, but it also has seen an uptick of PRs from the community and the re-opening of the develop branch in earnest. There is still quite a lot of work to do before we can add that extra 0.1 and go from version 0.9 to 1.0.
+What's in a version?
+For me personally, I never put much stock in the notion of versions. Evennia didn't even have versions until a few years back: We used to just have a rolling git release. But eventually it became clear that our user base was big enough that we needed to more clearly separate major (and possibly breaking) updates from what came before. So I started versioning at Evennia 0.5 and have had roughly a new release every year since (not a plan or a promise, it just happened to turn out that way).
+Evennia has been useful (and been used) for game development for many years already. But there is no denying that a 1.x label tends to convey more confidence in a system than a 0.x label, that's just the way things are. So while the new version is still quite some way off, there are a bunch of changes and improvements that we want to do in this release to mark the version change in a good way.
+Documentation changes
+Our documentation will move away from our trusty Github wiki. Instead we will convert the wiki into a static github page built from sources inside evennia/docs/.
+The advantage of the wiki is that it is a very low entry for people to contribute and fix things using Github's editing system. We have had a lot of use of this over the years and the wiki has served us well. The drawbacks are starting to get ever more noticeable, however:
+
+
+The change so far planned is to switch to the Sphinx documentation build-system (same as Python/Django etc is using). We will use it with extensions that allows us to still use Markdown like in the old wiki. This also allows us to build a more comprehensive (and pretty) API documentation of the entire library. We have more options to add comprehensive online search functionality in this solution as well.
+Furthermore, will hopefully be able to set it up so that we can maintain and publish separate documentations for each forthcoming release. That is, you should be able to read the docs for 1.0, 1.1 or the latest master development as you like (similarly to how Django does it, although probably not as fancy from the onset).
+This means that contributions to the documentation will be done as PRs through GitHub, just like when contributing any other code. While this does add a little more of a hurdle to contributions, hopefully the benefits will far outweigh those. Building the docs locally will not require a running Evennia server (unless you want the api docs) and we will try to set everything up for to make it easy to contribute.
+Many of the details around the docs are still up in the air. This is still very much work-in-progress, like everything else.
+Work with this has started in the static-file-docs branch of Evennia. But we have not closed the wiki either - the two will exist in parallel for now.
+PyPi
+As mentioned before, we will finally start to distribute Evennia via PyPi (the Python Package Index) - that is, you will be able to run pip install evennia. Using GIT will no longer be a requirement to get started.
+Considering how quickly people in open-source throw up their three lines of code on PyPi these days, it may be surprising Evennia is not already on PyPi. I have however felt that reading and referencing the highly-commented code is a big part and requirement for getting the most out of the library.
+With the new documentation system, this would improve. And you can of course still use git and follow master branch like the good ol' days if you want!
+Web Admin improvements
+For the longest time, the Django-admin component has been somewhat on the back-burner. With the help of community contributors, this is improving so you will be able to do more work the Admin GUI related to creating and managing objects, tie puppets to Accounts etc.
+API improvements
+Whereas the last few months have been mostly spent fixing lingering bugs, one thing planned for version 1.0 is a general cleanup of legacy strangeness in the API. For example, certain methods can return a list or a single object depending situation, which makes it hard to generalize. There are a lot of small quirks like that which we hope to address and make more consistent.
+There has also been a recent flurry of contributor PRs intended to help decouple Evennia's systems and make them easier to replace for those inclined to do so. Many of this is still being worked on, but it's likely you'll be able to replace many more "core" components for 1.0 with your own variations without doing any hacking in upstream code at all.
+... Needless to say, this is an advanced feature that most developers will never need. But Evennia was always intended to be heavily customizable and having the option is a good thing!
+Another feature that will come for 1.0 is a REST-API, added by one of our contributors. This uses Django-REST-Framework and makes it easier for external programs to authenticate and fetch data out of the Evennia database (great both for external apps, websites or custom what-have-you).
+At this time you can only fetch database objects via this interface, you cannot perform Command-calls or "play the game" this way (REST is a stateless concept and Evennia Commands tend to retain state).
+Many other fixes and contributions
+There's a truckload of stuff already available in master branch, but with the latest contributions of bigger code changes, we have started to use the Evennia develop branch again in earnest again. For a summary of the changes so far, check out the Changelog.
+However, unless you want to contribute to Evennia itself (or really, really want to be on the bleeding edge), you are still recommended to use the master branch for now. A lot of work still to do, as said.
+
+
+
+
+ Birthday retrospective
+ ¶
+ - November 30, 2016
+
+
So, recently Evennia celebrated its ten-year anniversary. That is, it was on Nov 20, 2006, Greg Taylor made the first repo commit to what would eventually become the Evennia of today. Greg has said that Evennia started out as a "weird experiment" of building a MUD/MUX using Django. The strange name he got from a cheesy NPC in the Guild Wars MMORPG and Greg's first post to the mailing list also echoes the experimental intention of the codebase. The merger with Twisted came pretty early too, replacing the early asyncore hack he used and immediately seeing a massive speedup. Evennia got attention from the MUD community - clearly a Python-based MUD system sounded attractive.
+When I first joined the project I had been looking at doing something MUD-like in Python for a good while. I had looked over the various existing Python code bases at the time and found them all to be either abandoned or very limited. I had a few week's stunt working with pymoo before asking myself why I was going through the trouble of parsing a custom script language ... in Python ... Why not use Python throughout? This is when I came upon Evennia. I started making contributions and around 2010 I took over the development as real life commitments forced Greg to step down.
+Over the years we have gone through a series of changes. We have gone from using SVN to Mercurial and then to using GIT. We have transited from GoogleCode to GitHub - the main problem of which was converting the wiki documentation (Evennia has extensive documentation).
+For a long time we used Python's reload() function to add code to the running game. It worked ... sometimes, depending on what you changed. Eventually it turned out to be so unpredictable that we now use two processes, one to connect clients to and the other running the game, meaning we can completely restart one process without disconnecting anyone.
+Back in the day you were also expected to create your own game in a folder game/ inside the Evennia repo itself. It made it really hard for us to update that folder without creating merge conflicts all over. Now Evennia is a proper library and the code you write is properly separated from ours.
+So in summary, many things have happened over the years, much of it documented in this blog. With 3500 commits, 28 000 lines of code (+46% comments) and some 25 people contributing in the last year, Openhub lists us as
+++"A mature, well-established codebase with a stable commit history, a large development team and very well documented source code".
+
It's just words compiled by an algorithm, but they still feel kinda good!
+While Evennia was always meant to be used for any type of multiplayer text game, this general use have been expanded and cleaned up a lot over the years.
+This has been reflected in the width of people wanting to use it for different genres: Over time the MUSH people influenced us into adding the option to play the same character from many different clients at the same time (apparently, playing on the bus and then continuing on another device later is common for such games). Others have wanted to use Evennia for interactive fiction, for hack&slash, deep roleplay, strategy, education or just for learning Python.
+Since Evennia is a framework/library and tries to not impose any particular game systems, it means there is much work to do when building a game using Evennia. The result is that there are dozens of games "in production" using Evennia (and more we probably don't know about), but few public releases yet.
+The first active "game" may have been an Evennia game/chat supporting the Russian version of 4chan... The community driven Evennia demo-game Ainneve is also progressing, recently adding combat for testing. This is aimed at offering an example of more game-specific code people can build from (the way Diku does). There are similar projects meant for helping people create RPI (RolePlay Intensive) and MUSH-style games. That said, the Evennia-game Arx, After the Reckoning is progressing through beta at a good clip and is showing all signs of becoming the first full-fledged released Evennia game.
+So cheers, Evennia for turning 10. That's enough of the introspection and history. I'll get back to more technical aspects in the next post.
+ + ++
+ Season of fixes
+ ¶
+ - October 13, 2016
+
+
The last few months has been dominated by bug-fixing and testing in Evennia-land. A lot more new users appears to be starting to use Evennia, especially from the MUSH world where the Evennia-based Arx, After the Reckoning is, while still in alpha, currently leading the charge.
+With a new influx of users comes the application of all sorts of use- and edge-cases that stretch and exercise the framework in all the places where it matters. There is no better test of code than new users trying to use it unsupervised! Evennia is holding up well overall but there are always things that can be improved.
+-
+
A fun thing with a growing user base is that we are also starting to see a lot more Pull requests and contributions. Thanks a lot, keep 'em coming!
+-
+
The fixing and tightening of the nuts and bolts will likely continue the remainder of the year. I'm currently working on a refactoring of the way command sets are merged together (see the end of my blog post on Evennia in pictures for a brief summary of the command system). But with so much new blood in the community, who can tell where things will turn from here!
+ + ++
+ The art of sharing nicks and descriptions
+ ¶
+ - July 1, 2016
+
+
In the month or so since the merger of Evennia's development branch and all its web-client updates, we have been in bug-fixing mode as more people use and stress the code.
+There have been some new features as well though - I thought it could be interesting to those of you not slavishly following the mailing list.
+Shared web login
+When you are logged into the website you will now also auto-login to your account in the web client - no need to re-enter the login information! The inverse is also true. You still need to connect to game at least once to create the account, but after that you will stay connected while the browser session lasts.
+Behind the scenes the shared login uses cookies linked to server-side Django sessions which is a robust and safe way to manage access tokens. Obviously browser sessions are irrelevant to telnet- or ssh connections.
+Extended Nicks
+Evennia's nick(name) system is a way to create a personal alias for things in game - both to on-the-fly replacing text you input and for referring to in-game objects. In the old implementation this replacement was simply matched from the beginning of the input - if the string matched, it was replaced with the nick.
+In this new implementation, the matching part can be much more elaborate. For example you can catch arguments and put those arguments into the replacement nick in another order.
+Let's say we often use the @dig command this limited way:
+++@dig roomname;alias = exit;alias, backexit;alias
+
Let's say we find this syntax unintuitive. The new nick system allows to change this by catching the arguments in your nick and put it into the "real" command. Here is an example of a syntax putting the aliases in parentheses and separating all components with commas:
+> nick newroom $1($2), $3($4), $5($6) = @dig $1;$2 = $3;$4, $5;$6
+From here on you can now create your rooms with entries like this:
+> newroom The great castle(castle), to the castle(castle), back to the path(back)
+Multidescer contrib
+I have added a new "multidescer" to the contrib folder. A multidescer is (I think) a MUSH term for a mechanism managing more than one description. You can then combine any of these various descriptions into your "active" description.
+An example of usage:
+desc hat = a blue hat.
+desc basic = This is a tall man with narrow features.
+desc clothing = He is wearing black, flowing robes.
+These commands store the description on the Character and references them as unique keywords. Next we can combine these strings together in any order to build the actual current description:
+> desc/set basic + |/ + clothing + On his head he has + hat
+> look self
+This is a tall man with narrow features.
+He is wearing black, flowing robes. On his head he has a blue hat.
+This allows for both very flexible and easy-to-update descriptions but also a way to handle freeform equipment and clothing. And you can of course use the nick system to pre-format the output
+> nick setdesc $1 $2 $3 $4 = $1 + |/ + clothing + On his head he has a $4
+This way you can clothe yourself in different outfits easily using the same output format:
+> setdesc basic clothing hat
+The multidescer is a single, self-contained command that is easy to import and add to your game as needed.
+... There's also plenty of bug fixes, documentation work and other minor things or course.
+Anyway, summer is now upon us here in the northern hemisphere so things will calm down for a bit, at least from my end. Have a good 'un!
+ + ++
+ Evennia in Pictures
+ ¶
+ - May 31, 2016
+
+This article describes the MU* development system Evennia using pictures!
+This article was originally written for Optional Realities.
+Since it is no longer available to read on OR, I'm reposting it in full here.
+Figure 1: The parts of the Evennia library
+
Evennia is a game development library. What you see in Figure 1 is the part you download from us. This will not run on its own, we will soon initialize the missing “jigsaw puzzle” piece on the left. But first let’s look at what we’ve got.
+Looking at Figure 1 you will notice that Evennia internally has two components, the Portal and the Server. These will run as separate processes.
+The Portal tracks all connections to the outside world and understands Telnet protocols, websockets, SSH and so on. It knows nothing about the database or the game state. Data sent between the Portal and the Server is protocol-agnostic, meaning the Server sends/receives the same data regardless of how the user is connected. Hiding behind the Portal also means that the Server can be completely rebooted without anyone getting disconnected.
+The Server is the main “mud driver” and handles everything related to the game world and its database. It's asynchronous and uses Twisted. In the same process of the Server is also the Evennia web server component that serves the game’s website. That the Server and webserver are accessing the database in the same process allows for a consistent game state without any concerns for caching or race condition issues.
+Now, let’s get a game going. We’ll call it mygame. Original, isn’t it?
+Figure 2: The full setup for mygame
+
After installing evennia you will have the evennia command available. Using this you create a game directory - the darker grey piece in Figure 2 that was missing previously. This is where you will create your dream game!
+During initialization, Evennia will create Python module templates in mygame/ and link up all configurations to make mygame a fully functioning, if empty, game, ready to start extending. Two more commands will create your database and then start the server. From this point on, mygame is up and running and you can connect to your new game with telnet on localhost:4000 or by pointing your browser to http://localhost:4001.
+Now, our new mygame world needs Characters, locations, items and more! These we commonly refer to as game entities. Let’s see how Evennia handles those.
+Figure 3: The Database Abstraction of Evennia entities
+
Evennia is fully persistent and abstracts its database in Python using Django. The database tables are few and generic, each represented by a single Python class. As seen in Figure 3, the example ObjectDB Python class represents one database table. The properties on the class are the columns (fields) of the table. Each row is an instance of the class (one entity in the game).
+Among the example columns shown is the key (name) of the ObjectDB entity as well as a Foreign key-relationship for its current “location”. From the above we can see that Trigger is in the Dungeon, carrying his trusty crossbow Old Betsy!
+The db_typeclass_path is an important field. This is a python-style path and tells Evennia which subclass of ObjectDB is actually representing this entity.
+Figure 4: Inheriting classes to customize entities
+
In Figure 4 we see the (somewhat simplified) Python class inheritance tree that you as an Evennia developer will see, along with the three instanced entities.
+ObjectDB represents stuff you will actually see in-game and its child classes implement all the handlers, helper code and the hook methods that Evennia makes use of. In your mygame/ folder you just import these and overload the things you want to modify. In this way, the Crossbow is modified to do the stuff only crossbows can do and CastleRoom adds whatever it is that is special about rooms in the castle.
+When creating a new entity in-game, a new row will automatically be created in the database table and then “Trigger” will appear in-game! If we, in code, search the database for Trigger, we will get an instance of the Character class back - a Python object we can work with normally.
+Looking at this you may think that you will be making a lot of classes for every different object in the game. Your exact layout is up to you but Evennia also offers other ways to customize each individual object, as exemplified by Figure 5.
+Figure 5: Adding persistent Attributes to a game entity.
+
The Attribute is another class directly tied to the database behind the scenes. Each Attribute basically has a key, a value and a ForeignKey relation to another ObjectDB. An Attribute serializes Python constructs into the database, meaning you can store basically any valid Python, like the dictionary of skills seen in Figure 5. The “strength” and “skills” Attributes will henceforth be reachable directly from the Trigger object. This (and a few other resources) allow you to create individualized entities while only needing to create classes for those that really behave fundamentally different.
+Figure 6: Sessions, Players and Objects
+
Trigger is most likely played by a human. This human connects to the game via one or more Sessions, one for each client they connect with. Their account on mygame is represented by a PlayerDB entity. The PlayerDB holds the password and other account info but has no existence in the game world. Through the PlayerDB entity, Sessions can control (“puppet”) one or more ObjectDB entities in-game.
+In Figure 6, a user is connected to the game with three Sessions simultaneously. They are logged in to their Player account Richard. Through these Sessions they are simultaneously puppeting the in-game entities Trigger and Sir Hiss. Evennia can be configured to allow or disallow a range of different gaming styles like this.
+Now, for users to be able to control their game entities and actually play the game, they need to be able to send Commands.
+Figure 7: Commands are Python classes too
+
Commands represent anything a user can input actively to the game, such as the look command, get, quit, emote and so on.
+Each Command handles both argument parsing and execution. Since each Command is described with a normal Python class, it means that you can implement parsing once and then just have the rest of your commands inherit the effect. In Figure 7, the DIKUCommand parent class implements parsing of all the syntax common for all DIKU-style commands so CmdLook and others won’t have to.
+Figure 8: Commands are grouped together in sets and always associated with game entities.
+
Commands in Evennia are always joined together in Command Sets. These are containers that can hold many Command instances. A given Command class can contribute Command instances to any number of Command Sets. These sets are always associated with game entities. In Figure 8, Trigger has received a Command Set with a bunch of useful commands that he (and by extension his controlling Player) can now use.
+Figure 9: Command Sets can affect those around them
+
Trigger’s Command Set is only available to himself. In Figure 8 we put a Command Set with three commands on the Dungeon room. The room itself has no use for commands but we configure this set to affect those inside it instead. Note that we let these be different versions of these commands (hence the different color)! We’ll explain why below.
+Figure 10: The name Command “Set” is not just a name
+
Command Sets can be dynamically (and temporarily) merged together in a similar fashion as Set Theory, except the merge priority can be customized. In Figure 10 we see a Union-type merger where the Commands from Dungeon of the same name temporarily override the commands from Trigger. While in the Dungeon, Trigger will be using this version of those commands. When Trigger leaves, his own Command Set will be restored unharmed.
+Why would we want to do this? Consider for example that the dungeon is in darkness. We can then let the Dungeon’s version of the look command only show the contents of the room if Trigger is carrying a light source. You might also not be able to easily get things in the room without light - you might even be fumbling randomly in your inventory!
+Any number of Command Sets can be merged on the fly. This allows you to implement multiple overlapping states (like combat in a darkened room while intoxicated) without needing huge if statements for every possible combination. The merger is non-destructive, so you can remove cmdsets to get back previous states as needed.
+… And that’s how many illustrations I have the stamina to draw at this time. Hopefully this quick illustrated dive into Evennia helps to clarify some of the basic features of the system!
+ + ++
+ Evennia 0.6!
+ ¶
+ - May 22, 2016
+
+
As of today, I merged the development branch to make version 0.6 of the MU* development system and server Evennia.
+Evennia 0.6 comes with a lot of updates, mainly in the way Evennia talks to the outside world. All communication is now standardized, so there are no particular treatment of things like text - text is just one of any standardized commands being passed between the server the client (whether over telnet, ssh, websockets or ajax/comet).
+For example the user can now easily plug in "inputfuncs" to handle any data coming from the client. If you want your client to offer some particular functionality, you just need to plop in a python function to handle it, server-side. We also now offer a lot of utility functions for things like monitoring change (tell the client whenever your health status changes so it can update a health bar or flash the screen).
+The HTML5 webclient has itself updated considerably. Most is happening behind the scenes though. Notably the webclient's javascript component is split into two:
+
-
+
There are a truckload of more updates and features that are covered on the mailing list.
+ + ++
+ Technical stuff happening
+ ¶
+ - March 24, 2016
+
+
Hi folks, a bit more technical entry this time. These usually go onto the Evennia mailing list but I thought it would be interesting to put it in the dev-blog for once.
+So, I'm now halfway through the TODO list issue of the wclient development branch as alluded to in the last post. The wclient branch aims to rework and beef up the web client infrastructure of Evennia.
+The first steps, which has been done a while was converting the SSH/SSL and IRC input/output protocols to use the new protocol infrastructure (telnet and websockets was done since before). That's just under-the-hood stuff though. Today I finished the changes to the Monitor/TickerHandlers, which may be of more general interest.
+With the changes to the the way OOB (Out-Of-Band) messages are passing through Evennia (see this mailing list post for more details), the OOBHandler is no more. As discussed there, the handling of incoming data is becoming a lot freer and will be easily expandable to everyone wanting to make for a custom client experience. The idea is thus for Evennia to offer resources for various input commands to make use of, rather than prescribing such functionality in a monolothic way in the OOBHandler. There were three main functionalities the OOBHandler offered, and which will now be offered by separate components:
+-
+
The MonitorHandler
+evennia.MONITOR_HANDLER is the new singleton managing monitoring of on-object field/attribute changes. It is used like this:
+MONITOR_HANDLER.add(obj, field_or_attrname, callback, **kwargs)
+Here obj is a database entity, like a Character or another Object. The field_or_attrname is a string giving the name of a db_* database field (like "db_key", "db_location" etc). Any name not starting with db_ is assumed to be the name of an on-object Attribute (like "health"). Henceforth, whenever this field or attribute changes in any way (that is, whenever it is re-saved to the database), the callback will be called with the optional kwargs, as well as a way to easily get to the changed value. As all handlers you can also list and remove monitors using the standard MONITOR_HANDLER.remove(), .all() etc.
+The TickerHandler
+evennia.TICKER_HANDLER should be familiar to Evennia users from before - it's been around for a good while. It allows for creating arbitrary "tickers" that is being "subscribed" to - one ticker will call all subscribers rather than each object or function having its own timer.
+Before, the syntax for adding a new ticker required you specify a typeclassed entity and the name of the method on it to call every N seconds. This will now change. This is the new callsign for creating a new ticker:
+TICKER_HANDLER.add(interval, callback, idstring="", persistent=True, *args, **kwargs)
+Here**, interval,** like before, defines how often to call **callback(*args, kwargs).
+The big change here is that callback should be given as a valid, already imported callable, which can be either an on-entity method (like obj.func) or a global function in any module (like world.test.func) - the TickerHandler will analyze it and internally store it properly.
+idstring works as before, to separate tickers with the same intervals. Finally persistent=False means the ticker will behave the same way a Script with persistent=False does: it will survive a server reload but will not survive a server shutdown. This latter functionality is particularly useful for client-side commands since the client Session will also not survive a shutdown.
+... So this is a rather big API change to the TickerHandler, which will mean some conflicts for those of you relying heavily on tickers. Easiest will definitely be to simply stop the old and start new ones. It's not clear yet if we'll offer some automated way to convert old tickers to new ones. Chime in if this is something important to you.
+Happening Next
+The next steps involves making use of these new utilities to implement the basic OOB commands recommended by the MSDP and GMCP protocols along with some recommended functionality. We'll see how long that takes, but progress is being made. And if you are a web guy, do consider helping out.
+ + ++
+ Climbing up Branches
+ ¶
+ - February 14, 2016
+
+
Today I pushed the latest Evennia development branch "wclient". This has a bunch of updates to how Evennia's webclient infrastructure works, by making all exchanged data be treated equal (instead of treating text separately from other types of client instructions).
+It also reworks the javascript client into a library that should be a lot easier to expand on and customize. The actual client GUI is still pretty rudimentary though, so I hope a user with more web development experience can take upon themselves to look it over for best practices.
+A much more detailed description of what is currently going on (including how to check out the latest for yourself) is found in this mailing list post. Enjoy!
+ + +
+
+
Evennia
+The Python MU* Development Library
+-
+
+
-
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Getting a MUD RP scene going
+ ¶
+ - October 29, 2017
+
+This article is a little different from the normal more technical Evennia-specific content of this blog. It was originally published as a light-hearted addition to the Imaginary Realities e-zine many years ago. While IR is still online it has since dozed off. So I'm reposting it here to bring it to a new audience.
+In roleplay-heavy MUDs (and in other categories of text-based roleplaying games), the concept of scenes become important. A scene in this concept is simply a situation big or small that involves you and your fellow players in interesting role play. A scene can be as simple as two players meeting in the street and exchanging a few words to the dramatic conclusion to a staff-driven quest. Whenever role player-interested players meet, a scene may happen.
+But sometimes scenes won’t come naturally. Sometimes your favourite game has only a few people online, or most of them are hovering in private areas. It’s time to go proactive. Below I offer some archetypes, tropes and ideas for how to get a random Scene started and people interested. The list is based on one I did for a RP-heavy MUD I played some time back.
+Some terms used in the list:
+
+
+Scene starters
+Scene starters are for when you are alone in a room hoping for others to join you (we've all done it). It is considerably easier to run Scene starters if there is some OOC way for other players to know where to find you (such as a list showing who's interesting in roleplay and where they are in the game). If not, it’s best to prepare your starter in a commonly visited central location or hub. You normally trigger the starter whenever another Player enters.
+The Scene starters below are intended as ideas and suggestions, but are also examples of archetypical behaviour I’ve observed myself.
+The Barfly
+A role playing mud classic since time immemorial. The barfly is alone in a tavern and tends their drink, waiting for things to happen. A passive role, but trivial to setup and easy for other players to jump in on - they just slide up to the bar and ask what's up. Fun variations is the drunk barfly or really, really sad/happy barfly, states which immediately give other Players things to ask about and work with.
+The Strider
+This is the "dark stranger in the corner" variation of the barfly. It is simple to execute - just sit in a dark tavern corner looking glum and mysterious. Often used by newbie players unsure of the game’s commands. The problem is that unless they know the Strider from before it's hard for other Characters to include him/her in their roleplay in a realistic way. The whole IC point of this trope is after all to avoid attention.
+ The Busybody
+The busybody is keeping busy in this room. Most commonly they are performing their job. If they own a bar or run the shop, they tend it. If they are guardsmen they are standing on patrol. If they are wee jesters they are making fools out of themselves. And so on. This is a great starter since it is both natural, realistic and in-character all at once. The nature of their work may occasionally make it easier or harder for other Characters come up with reasons to interact with them though - it might be harder to motivate why some characters would strike up a conversation with a guardsman than they would with a street vendor.
+The Demagogue
+This more involved starter involves striking up a loud conversation with an NPC/vNPC. Whenever another Character enters, the Demagogue plays out a small scene where they are "arguing" with the NPC, playing both roles. The argument could be "continuing" or just starting as the new PC enters. It could be about anything from tavern prices to refuting a made-up insult. The advantage of this is that it gives immediate character to the demagogue and to the NPC both. It also makes it easy for the newcomer to get into the scene just by taking sides in the debate.
+
+The Damsel in Distress
+This starter, which of course works both for male and female Characters, sets up the damsel as being in a dependency situation to whomever enters the room next. It involves describing the damsel in a sort of precarious situation that clearly requires an extra hand to resolve. This could be anything: Having their hands full and nearly dropping stuff. Chasing a dog that is running off with their book. Being accosted by vNPC ruffians (which should bugger off quickly, unless roleplaying completely “virtual” combat is your cup of tea). Either way the newcomer has an ongoing scene to react to, and roleplay immediately ensues.
+The Organizer
+This starter requires that the game has a developed in-game message- or mailing system. If so - use it to explicitly and in-character invite people to a scene! If the organizer is in a position of in-game power, this could make good IC sense - like the lord calling on their vassals to attend some sort of function. But anything from calling in a favor to suggesting a business opportunity or looking for a job works. Throw a party. Get drunk and send an ill-advised love letter. This starter works exceptionally well in combination with Stage director or Aggravator for getting selected Players into a memorable scene.
+
+The Aggravator
+The aggravator starts off on the wrong foot with people. Maybe they lash out due to some perceived injustice or they are just grumpy. This starter does not fit all character concepts. The aggravator should accuse the newly arrived PC for something. It could be something from their common history or something made-up out of the blue. It is an active starter in that it leads the way and forces other PCs into roleplay - if nothing else in order to defend themselves. A simple example is to chide the newly arrived PC for not stopping the vNPC that just ran past them out the door. It's important not to take the aggravator trope too far, especially not when using vNPCs. The idea is to get a scene started with some tension, not to get the other (possibly random) PC into real trouble. No god-modding, remember. If the two Characters are actual enemies though, it may be another matter ...
+The Stage Director
+This is a more sophisticated starter that is halfway to improvised theater. It sets up a whole little scene involving some event with a number of semi-named vNPCs. The stage director could be directly involved or be a spectator (in which case other PCs can walk up to them and ask what's going on). The event could be anything from a trite bar brawl to a domestic dispute in progress. Or why not a marriage proposal between two vNPCs in the middle of the street! If the stage director is threatened in some way, this is a large-scale version of damsel in distress.
+The nice thing about staged scenes like this is that it gives depth and personality to the game and is often highly appreciated by other Players. If done well, the stage director could give everyone involved a true feeling of being in a living environment.
+The scene could continue to be played out around the PCs also as they interact, making this starter potentially demanding on the stage director. If the other Players are experienced they should pick up on this and maybe even contribute their own vNPCs to the scenario (or the stage director could actively invite other Players to do so). It's important to remember to avoid god-modding here - never dictate another PCs actions, let other Players react as they see fit.
+
+The Lazy Bum
+This is unfortunately the most common of starters and we've probably all done it one time or another. It does not involve anything but simply standing in a room. No action set, no nothing. Just being there, the Character staring blankly into space until something happens. Yeah.
+Scene entrances
+Here are some ideas on how to enter a scene/room with one or more other PCs already involved in role play. It should be noted that if other PCs already have a scene going they might be OOC annoyed if the newcomer muscles in with some room-changing entrance. So you as a Player have to show some consideration here. Check the land and eventual actions set on people in the room. If a great scene is already in progress you shouldn’t need to start your own - instead try to get in on the action!
+The Mouse
+The most common of entering schemes. The Mouse walks into the room/area not drawing attention to themselves. A simple, passive setup that fits many situations and Character concepts. The mouse is a useful way to enter an already running scene. It is a bit overused though, possibly being The lazy bum of entrances. It seem to imply that it is up to others to notice and respond to the mouse. If really aiming for anonymity, the mouse must emote explicitly that they are not drawing attention to themselves, making it clear to other characters they need not go out of their way to be courteous and notice the newcomer.
+The Ignoranti
+The ignoranti acts as if they do not notice the other Characters in the room. This entrance variant is useful for crowded or large locations. It is also realistic - just because the “chock-full” tavern has only two PCs in it, it doesn’t mean you would actually immediately notice them. vNPCs are everywhere. The ignoranti must emote their ignorance explicitly, with something like "S/he does not notice the others yet". This entrance makes for a nice variation by allowing the ignoranti and other PCs to "accidentally" bump into each other later in a very natural way.
+
+The Walker
+The walker is just "passing through" this area. This entrance is useful for outdoor areas or minor streets were many Character concepts probably have no real reason to be hanging about more than necessary. The walker is really heading somewhere else and just happens to stop to chat with people in this room. It's an effective entrance that allows for quick, logical exits as well (they just have to 'be on their way'). This is far better than the more common approach of just congesting onto a street room and start greeting people as if all you do is stand in the street all day.
+The Planned Visitor
+This is a variation on The busybody and the opposite of The walker. The planned visitor needs to come to this room, and that is not in order to chat with random PCs. The visitor will start to perform whatever they are here to do and interaction with others is mere a side effect. The classic take on this trope is to read message boards or to order food and drink. More imaginative ones could be to ask the NPC barkeep for a job, look for a vNPC (which turns out to not be here), repair something, do some sort of inspection or setup for an artistic performance. If done well, others will have plenty of opportunity to ask The Planned Visitor what they are up to. It also makes for a thematic way to exit the scene once you declare your business there done.
+The Wet Kitten
+A classic that involves entering a scene drenched to the bone, shivering from cold, gasping from heat or otherwise be dramatically and visually affected by whatever weather or situation reigns outside. Common to taverns everywhere. For some reason this entrance rarely instills as much sympathy as one would think - but at least it opens up for other Characters to comment on the weather. Taken to the extreme, this becomes a variation on Damsel in Distress.
+The Third Wheel
+This is an active, provocative entrance and a variant on the aggravator. It should directly interrupt and involve other PCs in the room entered. The trivial confrontational way to do this is for the intruder to muscle or elbow past other PCs in a rude way, maybe even (attempting to) give them a rough shove (remember to avoid god-modding). This is sure to start off a scene! The more common third-wheel approach is to walk up to another group of conversing PCs and simply jump into their conversation mid-sentence. How this is received depends on the situation and Characters involved.
+In both cases it's important to make it clear that your actions is a conscious RP choice - it’s your Character which is inconsiderate, not the Player behind it. In other words, emote something like “... He/She does not seem to notice or care that s/he is intruding...”
+The Theatrist
+This is an on-the-fly version of the Stage director or demagogue. Only use if it's clear the currently ongoing scene allows it (so its often a good idea to follow a few emotes in the room before setting this one off). Just like stage director, it starts some sort of background action in the room based on vNPCs. Maybe a brawl, an argument or some other event like a happy announcement. Maybe a vNPC starts hitting on a PC. Or, like the demagogue, the theatrist gets involved in a discussion with an NPC/vNPC. Bartender NPCs are classically useful targets for this. Again, the theatrist must be considerate here, and perceptive so as to not take over an already running scene. Some PCs might forcibly choose to ignore the events going on in order to focus on their ongoing RP, so don't shove it down their throats (no god-modding!)
+The Non-sequitur
+This, strangely rare, entrance involves running into a crowded room, shouting "Monkeeey!" and then run out again. This one will at least lead to roleplay for the confused people in the room you just visited. And no, don't do this unless you have a very specific and suitable character concept, kids.
+
+The Newbie
+The classic newbie entrance involves walking into a room and saying "Hello" to no one in particular. Bonus points if this is done while ignoring the fact that the room's on fire and the PCs within are all involved in mortal combat. Luckily this entrance trope screams newbie so clearly that players may be urged to pity and lenience. It may in fact be the trigger for getting a more experienced player to take the newbie under their wing and explain a thing or two.
+
+
+
+
+
+
+
+ Evennia in Hacktobergest 2017
+ ¶
+ - October 1, 2017
+
+
+Evennia, the Python MUD/MUSH/MU* creation library participates in the Hacktoberfest 2017 (sign up on that page)! Hacktoberfest is open for all open-source projects like ours. After registering, if you make at least four Pull Requests to a public repo on Github during October (need not just be to Evennia), you win a limited-edition T-shirt!
+The help Evennia out and get your T-Shirt, look at our Issue Tracker. I have marked some issues with "Hacktoberfest" but you could take on any issue you want. Take a look in particular at the Unit test issue if you are looking to get into contributing on a smaller scale while helping us tremendously.
+If you have any questions on contributing (or it's your first time making a Pull Request), don't be shy to drop into #evennia on irc.freenode.net or ask in our forum/mailing list. Have fun!
+
+
+
+
+
+
+
+ Evennia 0.7 released
+ ¶
+ - September 20, 2017
+
+Evennia 0.7 released
+
+As of today Evennia 0.7 is officially out! Evennia is a Python framework and -server for creating text-based multiplayer games (MU*).
+A big thank you to all collaborators that have helped with code and testing along the way!
+Here is the hefty forum post that details how you migrate to Evennia 0.7.
+Evennia 0.7 comes with a range of changes and updates (these are just the ones merged from the latest devel branch, a lot more has happened since 0.6 that were already in master):
+
+
+New contribs (optional plugins) (selection, new since 0.6 but many have been available on master branch for a while):
+
+
+A more technical list from the main announcement post:
+
+
+
+
+
+
+
+
+
+ Renaming Django's Auth User and App
+ ¶
+ - August 25, 2017
+
+
+Now that Evennia's devel branch (what will become Evennia 0.7) is slowly approaching completion, I thought I'd try to document an aspect of it that probably took me the longest to figure out. One change in Evennia 0.7 is that the Django model named "Player" changes name to "Account". Over time it has become clear that the old name didn't properly reflected the intention of the model. Sounds like a simple change, right? Well, it was not.
+Briefly on migrations
+First some background. A Django migration is a small Python file sitting in migrations/ sub folders throughout Evennia. A migration describes how our database schema changes over time, so as we change or update fields or add new features we add new migrations to describe how to go from the old to the new state. You apply them with the evennia migrate command we sometimes ask you to run. If we did not supply migrations, anyone with an existing Evennia database would have to either start from scratch or manually go in and tweak their database to match every upstream change we did.
+Each migration file has a sequential number, like migration_name.0002.py etc. Migrations will run in order but each migration can also "depend" on another. This means for example that a migration in the player/ folder (application) knows that it need to wait for the changes done by a migration in the typeclasses/ folder/app before it can run. Finally, Django stores a table in the database to know which migrations were already run so to not apply them more than once.
+For reference, Evennia is wrapping the django manage commands, so where I refer to evennia migrate below you would use manage.py migrate in most Django applications.
+Our problem
+So I wanted to migrate the database change "Rename the Player model to Account". We had to do this under a series of additional constraints however:
+
+
+Some false starts
+There is no lack of tutorials and help online for solving the problem of renaming a model. I think I tested most of them. But none I found actually ended up addressing these restraints. Especially point 2 in combination with point 3 above is a killer.
+
+
+In the end I concluded that I had to abandon the notion that users be able to just do a single migrate command. Some more work would be needed on the user's part.
+The solution
+In the end I needed to combine the power of migrations with the power of Git. Using Git resolved the Gordian knot about the player folder. Basically the process goes like this:
+
+
+
+ # ...
+
+
+
+ def forwards(apps, schema_editor):
+
+ try:
+
+ PlayerDB = apps.get_model("players", "PlayerDB")
+
+ except LookupError:
+
+ return
+
+
+
+ # copy data from player-tables to database tables here
+
+
+
+ class Migrations(migrations.Migration):
+
+ # ...
+
+ operations = [
+
+ migrations.RunPython(forwards, migrations.RunPython.noop)
+
+ ]
+
+
+
+
+
+ from django.db import connection
+
+
+
+ # ...
+
+
+
+ def _table_exists(db_cursor, tablename):
+
+ "Returns bool if table exists or not"
+
+ sql_check_exists = "SELECT * from %s;" % tablename
+
+ ### [Renaming Django's Auth User and App](https://evennia.blogspot.com/2017/08/renaming-djangos-auth-user-and-app.html)
+
+
+
+And with this, the migration's design was complete. Below is how to actually use it ...
+Running the final migration
+In brief, what our users will do after pulling the latest code is as follows:
+
+
+Conclusions
+And that's it. It's a bit more involved for the end user than I would have liked, and took me much longer than expected to figure out. But it's possible to reproduce and you only need to do it once - and only if you have a database to convert. Whereas this is necessarily specified for Evennia, I hope this might give a hint for other django users aiming to do something like this!
+
+
+
+
+
+
+
+ The luxury of a creative community
+ ¶
+ - April 23, 2017
+
+
+For this blog post I want to focus on the series of very nice pull requests coming in from a growing cadre of contributors over the last few months.
+Contributed goodness
+People have put in a lot of good work to boost Evennia, both by improving existing things and by adding new features. Thanks a lot everyone (below is just a small selection)!
+
+
+About that Evennia 0.7 ...
+So while PRs are popping up left and right in master I've been working in the devel branch towards what will be the Evennia 0.7 release. The branch is not ready for public consumption and testing yet But tentatively it's about halfway there as I am slowly progressing through the tickets. Most of the upcoming features were covered in the previous blog post so I'll leave it at that.
+I just want to end by saying that it's a very luxurious (and awesome) feeling for me to see master-branch Evennia expand with lots of new stuff "without me" so to speak. The power of Open Source indeed!
+
+
+
+
+
+
+
+ News items from the new year
+ ¶
+ - February 5, 2017
+
+
+The last few months have been mostly occupied with fixing bugs and straightening out usage quirks as more and more people take Evennia through its paces.
+Webclient progress
+One of our contributors, mewser/titeuf87 has put in work on implementing part of our roadmap for the webclient. In the first merged batch, the client now has an option window for adjusting and saving settings. This is an important first step towards expanding the client's functionality. Other features is showing help in an (optional) popup window and to report window activity by popup and/or sound.
+The goal for the future is to allow the user or developer to split the client window into panes to which they can then direct various output from the server as they please It's early days still but some of the example designs being discussed can be found in the wiki webclient brainstorm (see the title image of this blog for one of the mockups).
+New server stuff
+Last year saw the death of our old demo server on horizondark.com, luckily the new one at silvren.com has worked out fine with no hickups. As part of setting that up, we also got together a more proper list of recommended hosts for Evennia games. Evennia requires more memory than your average C code base so this is important information to have. It seems most of our users run Evennia on various cloud hosting services rather than from a traditional remote server login.
+Arx going strong
+The currently largest Evennia game, the mush Arx - After the Reckoning has helped a lot in stress testing. Their lead coder Tehom has also been active both in reporting issues and fixing them - kudos! There are however some lingering issues which appears rarely enough that they have not been possible to reproduce yet; we're working on those. Overall though I must say that considering how active Arx is, I would have expected to have seen even more "childhood diseases" than we have.
+Launch scripts and discussions
+It is always interesting with feedback, and some time back another discussion thread erupted over on musoapbox, here. The musoapbox regulars have strong opinions about many things and this time some were critical of Evennia's install process. They felt it was too elaborate with too many steps, especially if you are approaching the system with no knowledge about Python. Apparently the average MUSH server has a much shorter path to go (even though that does require C compiling). Whereas I don't necessarily agree with all notions in that thread, it's valuable feedback - I've long acknowledged that it's hard to know just what is hard or not for a beginner.
+Whereas we are planning to eventually move Evennia to pypi (so you can do pip install evennia), the instructions around getting virtualenv setup is not likely to change. So there is now unix shell scripts supplied with the system for installing on debian-derived systems (Debian, Ubuntu, Mint etc). I also made scripts for automating the setup and launch of Evennia and to use it with linux' initd within the scope of a virtualenv.
+So far these scripts are not tested by enough people to warrant them being generally recommended, but if you are on a supported OS and is interested to try they are found from the top of the Evennia repo, in bin/unix/. More info can be found on their documentation page.
+Docker
+Speaking of installing, Evennia now has an official Docker image, courtesy of the work of contributor and Ainneve dev feend78. The image is automatically kept up-to.date with the latest Evennia repo and allows Evennia to be easily deployed in a production environment (most cloud services supports this). See Docker wiki page for more info.
+Lots of new PRs
+There was a whole slew of contributions waiting for me when returning from Chistmas break, and this has not slowed since. Github makes it easy to contribute and I think we are really starting to see this effect (Google Code back in the day was not as simple in this regard). The best thing with many of these PRs is that they address common things that people need to do but which could be made simpler or more flexible. It's hard to plan for all possibilities, so many people using the system is the best way to find such solutions.
+Apart from the map-creation contribs from last year we also have a new Wildnerness system by mewser/titeuf87. This implements wilderness according to an old idea I had on the mailing list - instead of making a room per location, players get a single room. The room tracks its coordinate in the wildnerness and updates its description and exits dynamically every time you move. This way you could in principle have an infinite wilderness without it taking any space. It's great to see the idea turned into a practical implementation and that it seems to work so well. Will be fun to see what people can do with it in the future!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2018.html b/devblog/html/devblog2018.html
new file mode 100644
index 0000000000..1404b2252c
--- /dev/null
+++ b/devblog/html/devblog2018.html
@@ -0,0 +1,415 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Evennia 0.8 released
+ ¶
+ - September 30, 2018
+
+After about a year of work and almost 540 commits from close to 20 contributors, Evennia 0.8 is out! Evennia is a Python game server for creating text-based multiplayer games (MUDs, Mushes, etc) using Django and Twisted.
+Some of the upcoming improvements have been covered by previous dev blogs, such as the completely reworked server infrastructure:
+
+as well as the new Online Creation System that allows for editing in-game prototypes using a powerful menu system:
+
+Other improvements are in the web client, which supports split-panes out of the box. The user can split the output area in any number of panes, resize as desired and then assign different types of content to each pane. You can also have panes that absorb "all the rest" or "all" of the content.
+
+There are still some bits which are a bit shaky and there is still much to do with the web client (for example, not that many outgoing messages yet defaults to being tagged in a way that the webclient recognizes). But it's a step forward!
+There are many other improvements for developers, such as easier tools for running debuggers and a lot of new utilities and helper functions. The menu-creation tool (EvMenu) has seen a lot of improvements and also sport a few new decorators for quickly creating multi-page menus with full functionality to flip through and select large numbers of options.
+The community has also chipped in with a large number of optional contributions for developers to use for their own game, such as a full turn-based combat system (divided into convenient chunks for the dev to pick and choose support for everything from magic and potions to equipment and ranged attacks). There are also a range of helper functions for creating simpler menus and build commands as well as auditing tools and additions making better use of Django's very mature security features.
+The more detailed list of improvements and changes can be found in the announcement here. As usual, please report any issues to the issue tracker on github.
+Future
+In the immediate future, we'll focus on resolving any bugs that may have slipped through the cracks and also resolve some other issues in the pipeline.
+But beyond that, work on Evennia 0.9 will begin. And before you ask - yes Evennia 0.9 is the version where we'll move fully to Python3. Our dependencies have now reached a point where this is possible and there will be no intermediary Python2/3 version. There is no timeline for the 0.9 release but it should hopefully not be too tricky for the community to make the jump when the time comes.
+
+
+
+
+
+
+
+ Inline building in upcoming Evennia 0.8
+ ¶
+ - August 18, 2018
+
+
+Evennia, the Python MUD-server game development kit, is slowly creeping closer to its 0.8 release.
+In our development branch I've just pushed the first version of the new OLC (OnLine Creator) system. This is a system to allow builders (who may have limited coding knowledge) to customize and spawn new in-game objects more easily without code access. It's started with the olc command in-game. This is a visual system for manipulating Evennia Prototypes.
+Briefly on Prototypes
+The Prototype is an Evennia concept that has been around a good while. The prototype is a Python dictionary that holds specific keys with values representing properties on a game object. Here's an example of a simple prototype:
+
+ {"key": "My house",
+
+ "typeclass": "typeclasses.houses.MyHouse"}
+
+
+By passing this dict to the spawner, a new object named "My house" will be created. It will be set up with the given typeclass (a 'typeclass' is, in Evennia lingo, a Python class with a database backend). A prototype can specify all aspects of an in-game object - its attributes (like description and other game-specific properties), tags, aliases, location and so on. Prototypes also support inheritance - so you can expand on an existing template without having to add everything fresh every time.
+There are two main reasons for the Prototypes existing in Evennia:
+
+
+What's new
+As said, Prototypes have been around for a good while in Evennia. But in the past they were either manually entered directly as a dict on the command line, or created in code and read from a Python module. The former solution is cumbersome and requires that you know how to build a proper-syntax Python dictionary. The latter requires server code access, making them less useful to builders than they could be.
+Note: If you are visually impaired, each image is also a link to a text-only version.
+
+In Evennia 0.8, while you can still insert the Prototype as a raw dict, spawn/menu or the new olc command opens a new menu-driven interface.
+
+More importantly, builders can now create, save and load prototypes in the database for themselves and other builders to use. The prototypes can be tagged and searched as a joint resource. Builders can also lock prototypes if others are not to be able to read or use them to spawn things. Developers can still supply module-based "read-only" prototypes (for use as starting points or examples to their Builders, for example).
+
+You can now also use the menu to search for and create a new Prototype based on an existing object (if you have access to do so). This makes it quick to start up a new prototype and tweak it for spawning other similar objects. Of course you could spawn temporary objects without saving the prototype as well.
+
+Builders will likely not know which typeclasses are available in the code base. There are new a few ways to list them. The menu display makes use of Evennia 0.8's new EvMenu improvements, which allows for automatically creating multi-page listings (see example above).
+There is also a new switch to the typeclass command, /list, that will list all available typeclasses outside of the OLC.
+Protfuncs
+Another new feature are Protfuncs. Similarly to how Inlinefuncs allows for calling for the result of a function call inside a text string, Protfuncs allows for calling functions inside a prototype's values. It's given on the form $funcname(arguments), where arguments could themselves contain one or more nested Protfuncs.
+As with other such systems in Evennia, only Python functions in a specific module or modules (given by settings) are available for use as Protfuncs in-game. A bunch of default ones are included out of the box. Protfuncs are called at the time of spawning. So for example, you could set the Attribute
+
+Strength = $randint(5, 20)
+
+to automatically spawn objects with a random strength between 5 and 20.
+
+When spawning, the olc will validate the prototype and run tests on any Protfunc used. For convenience you can override the spawn-location if any is hard-coded in the prototype.
+
+The system will also allow you to try updating existing objects created from the same-named prototype earlier. It will sample the existing objects and calculate a 'diff' to apply. This is bit is still a bit iffy, with edge cases that still needs fixing.
+Current status
+The OLC is currently in the develop branch of Evennia - what will soon(ish) merge to become Evennia 0.8.
+It's a pretty big piece of code and as such it's still a bit unstable and there are edge cases and display issues to fix. But it would be great with more people trying it out and reporting errors so the childhood issues can be ironed out before release!
+
+
+
+
+
+
+
+ Kicking into gear from a distance
+ ¶
+ - January 27, 2018
+
+
+The last few weeks I have reworked the way Evennia's startup procedure works. This is now finished in the develop branch so I thought I'd mention a little what's going on.
+Evennia, being a server for creating and running text-games (MU*s), consists of two main processes:
+
+
+Since Evennia should be easy to set up and also run easily on Windows as well as on Linux/Mac, we have foregone using the linux process management services but instead offered our own solution. This is how the reload mechanism currently looks in master branch:
+
+Here I've excluded connections irrelevant to reloading, such as the Twisted AMP connection between Portal and Server. Dashed lines suggest a more "temporary" connection than a solid line.
+The Launcher is the evennia program one uses to interact with the Server in the terminal/console. You give it commands like evennia start/stop/reload.
+
+
+The original reason for this Server-Portal-Runner setup is that the Portal is also reloadable in the same way (it's not shown above). But over time I've found that having the Portal reloadable is not very useful - since players get disconnected when the Portal reloads one can just as well stop and start both processes. There are also a few issues with the setup, such as the .pid files going stale if the server is killed in some catastrophic way and various issues with reliably sending signals under Windows. Also, the interactive mode works a little strangely since closing the terminal will actually kill the Runner, not the Server/Portal - so they will keep on running except they can no longer reload ...
+It overall feels a little ... fiddly.
+In develop branch, this is now the new process management setup:
+
+The Portal is now a Twisted AMP server, while the Evennia Server and Launcher are AMP clients. The Runner is no more.
+
+
+So far I really like how this new setup works and while there were some initial issues on Windows (spawning new processes does not quite work they way you expect on that platform) I think this should conceptually be more OS-agnostic than sending kill-signals.
+This solution gives much more control over the processes. It's easy to start/stop the Server behind the portal at will. The Portal knows the Server state and stores the executable-string needed to start the Server. Thus the Server can also itself request to be reloaded by just mimicking the Launcher's instructions.
+The launcher is now only a client connecting to a port, so one difference with this setup is that there is no more 'interactive' mode - that is the Server/Portal will always run as daemons rather than giving log messages directly in the terminal/console. For that reason the Launcher instead has an in-built log-tailing mechanism now. With this the launcher will combine the server/portal logs and print them in real time to easily see errors etc during development.
+The merger of the develop branch is still a good bit off, but anyone may try it out already here: https://github.com/evennia/evennia/tree/develop . Report problems to the issue tracker as usual.
+
+
+
+
+
+
+
+ New year, new stuff
+ ¶
+ - January 5, 2018
+
+
+Happy 2018 everyone! Here's a little summary of the past Evennia year and what is brewing.
+(Evennia is a Python server- and toolbox for creating text-based multiplayer games (MU*)).
+The biggest challenge for me last year Evennia-wise was the release of Evennia 0.7. Especially designing the migration process for arbitrary users migrating the Django auth-user took a lot of thought to figure out as described in my blog post here. But now 0.7 is released and a few initial minor adjustments could be made after feedback from daring pilot testers. The final process of migrating from 0.6 to 0.7 is, while involved, a step-by-step copy&paste list that has worked fine for most to follow. I've gotten far fewer questions and complains about it than could be expected so that's a good sign.
+Working away on the boring but important behind-the-scenes stuff made me less able to keep up with more "mundane" issues and bugs popping up, or with adding new "fun" features to existing code. Luckily the Evennia community has really been thriving this year; It feels like new users pop up in the support channel all the time now. The number of pull requests both fixing issues and offering new features and contribs have really picked up. A bigger part of my time has been spent reviewing Pull Requests this year than any other I think. I would like to take the opportunity to thank everyone contributing, it's really awesome to see others donating their time and energy adding to Evennia. The Hacktoberfest participation was also surprisingly effective in getting people to create PRs - I have a feeling some were just happy to have an "excuse" for getting started to contribute. We should attend that next year too.
+One thing we added with 0.7 was a more formal branching structure: Evennia now uses fixed master and develop branches, where master is for bug-fixes and develop is for new features (things that will eventually become evennia 0.8). This is simple but enough for our needs; it also makes it easier to track new from old now that we are actually doing releases.
+Now that Twisted is at a point where this is possible for us to do, we also now have a sort-of plan for finally moving Evennia to Python 3. I won't personally be actively working on it until after 0.8 is out though. I don't expect both Evennia 0.8 and 0.9 (which will be pure py3) to get released this year, but we'll see - so far contributors have done all the work on the conversion.
+At any rate, this coming year will probably be dominated by catching up on issues and edge cases that are lining our Issue tracker. One side effect of more newcomers is more eyes on the code and finding the creaky-bits. At least for me, most of my Evennia-time will be spent resolving bugs and issues. The fun thing is that unlike previous years this is not only up to me anymore - hopefully others will keep helping to resolve issues/bugs to broaden our bandwidth when it comes to keeping Evennia stable. The faster we can handle the backlog of issues the faster we can focus on new shiny features after all.
+Finally, a continued great thank you to those of you contributing to the Patreon. Even small donations have a great encouraging value when working on something as niche as a Python MU* game server in 2018 - thanks a lot!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2019.html b/devblog/html/devblog2019.html
new file mode 100644
index 0000000000..838772a70b
--- /dev/null
+++ b/devblog/html/devblog2019.html
@@ -0,0 +1,725 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Blackifying and fixing bugs
+ ¶
+ - September 30, 2019
+
+
+Since version 0.9 of Evennia, the MU*-creation framework, was released, work has mainly been focused on bug fixing. But there few new features also already sneaked into master branch, despite technically being changes slated for Evennia 1.0.
+On Frontends
+Contributor friarzen has chipped away at improving Evennia's HTML5 web client. It already had the ability to structure and spawn any number of nested text panes. In the future we want to extend the user's ability to save an restore its layouts and allow developers to offer pre-prepared layouts for their games. Already now though, it has gotten plugins for handling both graphics, sounds and video:
+
+
+Inline image by me (deviantart.com/griatch-art)
+
+A related fun development is Castlelore Studios' development of an Unreal Engine Evennia plugin (this is unaffiliated with core Evennia development and I've not tried it, but it looks pretty nifty!):
+
+
+Image ©Castlelore Studios
+
+On Black
+Evennia's source code is extensively documented and was sort of adhering to the Python formatting standard PEP8. But many places were sort of hit-and-miss and others were formatted with slight variations due to who wrote the code.
+After pre-work and recommendation by Greg Taylor, Evennia has adopted the black autoformatter for its source code. I'm not really convinced that black produces the best output of all possible outputs every time, but as Greg puts it, it's at least consistent in style. We use a line width of 100.
+I have set it up so that whenever a new commit is added to the repo, the black formatter will run on it. It may still produce line widths >100 at times (especially for long strings), but otherwise this reduces the number of different PEP8 infractions in the code a lot.
+On Python3
+Overall the move to Python3 appears to have been pretty uneventful for most users. I've not heard almost any complaints or requests for help with converting an existing game.
+The purely Python2-to-Python3 related bugs have been very limited after launch; almost all have been with unicode/bytes when sending data over the wire.
+People have wholeheartedly adopted the new f-strings though, and some spontaneous PRs have already been made towards converting some of Evennia existing code into using them.
+Post-launch we moved to Django 2.2.2, but the Django 2+ upgrades have been pretty uneventful so far.Some people had issues installing Twisted on Windows since there was no py3.7 binary wheel (causing them to have to compile it from scratch). The rise of the Linux Subsystem on Windows have alleviated most of this though and I've not seen any Windows install issues in a while.
+On Future
+For now we'll stay in bug-fixing mode, with the ocational new feature popping up here and there. In the future we'll move to the develop branch again. I have a slew of things in mind for 1.0.
+Apart from bug fixing and cleaning up the API in several places, I plan to make use of the feedback received over the years to make Evennia a little more accessible for a new user. This means I'll also try reworking and consolidating the tutorials so one can follow them with a more coherent "red thread", as well as improving the documentation in various other ways to help newcomers with the common questions we hear a lot.
+The current project plan (subject to change) is found here. Lots of things to do!
+
+
+
+
+
+
+
+ Evennia 0.9 released
+ ¶
+ - July 4, 2019
+
+
+Last week we released Evennia 0.9, the next version of the open source Python MU* creation system.
+This release is the result of about 10 months of development, featuring 771 commits, 70 closed pull requests from the community and something like 80 issues and feature/requests closed. Thanks everyone!
+The main feature of Evennia 0.9 is that we have finally made the move to Python3. And we burn the bridges behind us; as announced in previous posts we completely drop Python2 support and move exclusively to only support the latest Python3.7.
+Overall the move to Python3 was not too bloody (and much work towards a never published py2+3 version was already done by Evennia contributors in a separate branch earlier). The main issues I ran into were mainly in the changes in how Python3 separates strings from bytes. This became crticial since Evennia implements several connection protocols; there were a lot of edge cases and weird errors appearing where data went to and from the wire.
+A regular user has it a lot easier though. So far people have not had too much trouble converting their games from 2.7 to 3.7. The biggest Linux distros don't all have Py3.7 out of the box though, so that may be a concern for some, we'll see.
+... but Py3 is nowhere all there is to find in this release though! There are a plethora of more features in the latest Evennia, all to make it easier to make the text-based multiplayer game of your dreams.
+You can see a summary of new features in the ML announcement and even more details in the actual CHANGELOG file.
+So what's up next?
+Now follows a period of bug-fixing and stabilizing. Maybe resolve some of those long-standing "tech-dept" issues and overall make Evennia more stable.
+Eventually work will then commence (in the develop branch) on version 1.0 of Evennia. For this next release I think I'll step back from new features a bit and focus on refactoring and cleanup of the API as well as other things around the library's distribution, documentation and presentation.
+But for now, onward to summer vacations.
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 2
+ ¶
+ - May 26, 2019
+
+
+
+
+This is part two of my post-mortem dev-blog about Evscaperoom, the multiplayer, text-based 'escape room' I wrote in Python and Evennia. You can read the first part of the dev blog here.
+This was a game-jam entry I created in a month for the Mud Coder's guild's Game Jam. The theme was One Room. You can play the game for free in your browser or with a traditional MUD client. There are no spoilers in these blog posts.
+Update: These days you can play the Evscaperoom by logging into the Evennia demo game at https://demo.evennia.com. It's just one of the exits you can get through when you enter.
+The first part dealt with the overall game-design aspects. This second, final part will go into details of the code and the systems I built to quickly create all the content. The code referenced here is released under the BSD license and is available on github.
+At the time of this post, players have played Evscaperoom for a little more than a week. At the end I'll share some observations and things I learned along the way.
+Ease of building
+Over the one-month game jam, I spent about four days making the game's 'engine' and toolset with Evennia. The rest of the time was spent using those tools to actually create game content (the story, puzzles etc).
+An important thing was that I didn't want to do any traditional in-game 'building'. That is - no logging into the game and running various commands to build objects and rooms. This is partly because I wanted rooms to be buildable on-demand, but also because I didn't want my game to only exist in the database but in actual version-controllable python modules.
+So all of the Evscaperoom is created in code (notably in the game states discussed below). This made it so that I could add unit tests to quickly find bugs and edge cases. It also made it easy to just clone the full game to an online server, init a database and run Evennia on it in a docker when time came to make it public.
+Overall game structure
+
+Main menu
+The game loop is simple: When you log in to the game, you get into a menu where you can create a new room to solve or join an existing one. Quitting a room brings you back to that menu. Quitting again leaves the game entirely. In between, you remain inside a single game location ('room').
+To make it easier for people to agree to meet up in a room, i made a little 'fantasy name generator' to make unique random names of the rooms. It felt more thematic than showing room id's. The generator combines phonemes together with some very simple logic. Not all comes out easy-to-pronounce, but the result is at least identifiable, like the Sheru and Uyoha above.
+I decided that I should not keep empty rooms around, so whenever a room has no more players in it, it's deleted from the database along with all its content. This means players can't really log off and come back to the same room unless a friend stays behind. I felt it was worth keeping things clean and avoid a growing backlog of empty, unsolved rooms. It is, unfortunately, quite common for players to log in, create a room and then immediately log off.
+I distribute Evscaperoom as an Evennia 'game dir'. Once you've installed Evennia you can just clone the evscaperoom repo and start a new multiplayer server with it. While the game dir has some Evennia templates in it by default, Almost all the custom logic for this game is in the evscaperoom/ folder. The only other modification I did was to make sure Evennia rerouted new players into the Evscaperoom menu when they connect.
+Room class
+Since all of the gameplay happens in a single room, it made sense to center all of the data-storage around a new, custom Evennia Room class. This "EvscapeRoom" class holds all resources for this room. Evennia makes sure to persist it all to the database for you.
+The Evennia API provides a lot of powerful but game-general functions. Since our use-case for this game is very strictly defined, I made a slew of helper functions to cut down on boiler plate and pre-set options I wanted to always use.
+For example, I added helper methods both for creating and finding objects in the room. On creation, all objects are tagged with the room's unique hash, meaning that one can be sure to never have any cross-over between rooms (like accidentally finding the object in another room (that of course has the exact same name). Since I also decided to never have more than one object with a given name per room, I could make these methods very simple.
+The room class also has helpers for finding all players in the room and for sending messages to them. It also catches players leaving so that eventual on-character variables can be cleaned.
+Importantly, the very action of deleting the room will automatically clean all resources tied to it, keeping things tidy.
+Commands and Objects
+
+The help screen, show all top-level commands
+As discussed in part one of this blog, the Evscaperoom, uses a 'focus' mode: The player must examine/focus on an object first in order to operate or use it.
+The basic command syntax is:
+> command [target]
+The parsing I made actually allows for a more complex syntax, but in the end this was all that was really needed, since the currently 'focused' object does not need to be specified. This is the process of using one object with another:
+> examine key
+
+~~ key (examining) ~~
+
+This is a brass key.
+
+
+
+(To unlock something with it, use insert into <target>)
+
+
+> insert into door
+You unlock the **door** with the **key**!
+
+(the into is optional). Here, we focus on the key. We get the key's description and a hint that you can insert it into things. We then insert it into the door, which is another object in the room. The insert command knows that we are focusing on the key already and that it should look into the room for an object door to use this with.
+Technically, these on-object 'actions' (like insert above), are dynamically generated. Here is an example of the key object:
+
+class Key(EvscaperoomObject):
+
+ def at_focus_insert(self, caller, **kwargs):
+
+ target = kwargs['args']
+
+ obj = caller.search(obj)
+
+ if not obj:
+
+ return
+
+ if obj.check_flag("can_use_key"):
+
+ obj.handle_insert(self)
+
+
+Not shown here is that I made a wrapper for the "no-match" command of Evennia. This command fires when no other commands match. I made this instead analyze the currently 'focused' object to see if it had a method at_focus_<command_name> on it. If so, I inject the supplied arguments into that method as a keyword argument args.
+So when you focus on the key and give the insert command, the at_focus_insert method on the key will be called with a target to insert the key into_._ We search for the target (the door in the example), check if it even accepts keys and then pass the key to that object to handle. It would then be up to the door to figure out if this particular key unlocks it.
+I created a library of base objects that I can just use as mixins for the object I want to create. Here's an example:
+
+from evscaperoom import objects
+
+
+
+class Box(objects.Openable,
+
+ objects.CodeInput,
+
+ objects.Movable):
+
+ # ...
+
+
+This class will offer actions to open, insert a code and move the object around. It will need some more configuration and addition of messages to show etc. But overall, this method-to-command solution ended up being very stable and extremely easy to use to make complex, interactive objects.
+Room states
+I think of the escape room as going through a series of states. A change of state could for example be that the user solved a puzzle to open a secret wall. That wall is now open, making new items and puzzles available. This means room description should change along with new objects being created or old ones deleted.
+I chose to represent states as Python modules in a folder. To be a state, each module needs to have a global-level class State inheriting from my new BaseState class. This class has methods for initializing and cleaning up the state, as well as was for figuring out which state to go to next. As the system initializes the new state, it gets the current room as argument, so it can modify it.
+This is a (simplified) example of a state module:
+
+# module `state_001_start.py`
+
+
+
+from evscaperoom.state import BaseState
+
+from evscaperoom import objects
+
+
+
+MUG_DESC = """
+
+A blue mug filled with a swirling liquid.
+
+On it is written "DRINK ME" with big letters.
+
+"""
+
+
+
+class Mug(objects.EvscapeRoomObject):
+
+ def at_focus_drink(self, caller, **kwargs):
+
+ caller.msg(f"You drink {self.key}.")
+
+ self.next_state() # trigger next state
+
+
+
+class State(BaseState):
+
+
+
+ hints = ["You are feeling a little thirsty...",
+
+ "Drink from the mug, dummy."]
+
+
+
+ next_state = "state_002_big_puzzle"
+
+
+
+ def init(self):
+
+ mug = self.create_object(
+
+ Mug, key="wooden mug", aliases=["mug"])
+
+ mug.db.desc = MUG_DESC.strip()
+
+
+In this simple state, a mug is created, and when you drink from it, the next state is triggered. The base object has a helper function to trigger the next state since I found that interactive with an object is almost always the reason for switching states.
+The state-class has a lot of useful properties to set, such as which the next state should be (this can be overridden in case of branching paths). You can also store
+a sequence of hints specific for that state.
+Informing the room
+I wrote the content in second-person perspective ("You open the door"). This is however a multiplayer game and I didn't intially appreciate how many texts must also exist in a third-party form for the rest of the room to see ("Griatch opens the door").
+As the amount of text grew (the Evscaperoom has close to 10 000 lines of code, a lot of which is content strings), it became clear that it would not be feasible to manually supply third-persion version strings as well.
+The solution was to add parsing and translation of pronouns and verbs (a concept I first saw on the game Armageddon).
+I write the string like this:
+
+ OPEN_TEXT = "~You ~open the *door."
+
+
+The ~ marks text that should be parsed for second/third-person use (I'll discuss the *door marking in the next section). This I then send to a helper method that either sends it only to you (which means it comes back pretty much the same, but without the special markers) or to you and to the room, in which it will look different depending on who receives it:
+I see
+You open the [door].
+
+
+
+Others see
+Griatch opens the [door].
+
+English is luckily pretty easy to use for this kind of automatic translation - in general you can just add an "s" to the end of the verb. I made a simple mapping for the few irregular verbs I ended up using.
+Overall, this made it quick to present multiple viewpoints with minimal extra text to write.
+
+
+The option menu
+
+The *door -style marking allowed me to generalize how target-able objects in the room were displayed. This meant that users can customize how objects are shown to them. The default is to mark them both with colors and square brackets (this makes it clear also for people with screen readers). But one can also use only colors or turn off the marking completely (hard mode).
+Bringing it online
+Evennia is both a mud framework and mudserver as well as a webserver based on Twisted. It runs the game's website (with the help of Django) and also provides its own HTML5 webclient. I tweaked the default website text and played a little with CSS but otherwise didn't spend too much time on this bit.
+I got a $5/month DigitalOcean droplet with Ubuntu. I made a new, unprivileged "evennia" user on it and cloned the evscaperoom repo to it. I then started a tmux session and ran the Evennia docker image in there. Getting the game online took maybe thirty minutes, most of which was me figuring out where to open the droplet and DigitalOcean firewalls.
+I then pointed http://experimental.evennia.com at the droplet's IP and that was it!
+Updating the online server is now only a matter of pushing changes to my github repo, pulling it to the server and reloading Evennia; Before release, I used a private github repo for this, afterwards I simply made it public. Pretty straightforward.
+Some lessons learned
+I have gotten pretty positive reviews on Evscaperoom so far. In the first two days people stumbled on some edge-case bugs, but after that it has been very stable. Mostly I've had to make small typos and grammar corrections as I (or players) spot them.
+There were nevertheless some things I learned, some of which led to more real improvements post-launch.
+No amount of help is too much help
+
+
+The header shows how to get out of focus mode
+
+Firstly, the focus-system (examine, then do stuff) is a little un-orthodox and needs to be explained. I saw people logging in, examining exactly one thing and then logging out. Eventually I found out (because a user told me), that this was likely because they could not figure out how to leave the focus mode. They'd just flounder about, think the game was buggy and log off.
+The answer (just run examine again) is found with the help command, but clearly this was not intuitive. The solution was to add an explicit help text to the top every time you examine something. After this, the confusion seems to have gone away.
+Make it easy to connect for all tastes
+Another example - a commenting user had pretty strong opinions about the fact that you used to have to supply a username and password to play the game. They suggested this was a 'huge hurdle'. Not sure if that's true. But unless you want to use a particular name, there is also no actual gameplay reason to formally authenticate for Evscaperoom.
+This was easy to fix. Evennia has guest-player support out of the box so I just activated that and supplied some more fantasy-sounding names than the default "Guest 1", "Guest 2" etc. Since then, maybe 40% of players connecting have chosen to do so as an anonymous guest. I don't know if those would have left completely if the option was not available, but it's at least a convenient shortcut for getting into the game.
+Everything takes longer than expected
+I already knew this one, but still I fell into the trap of thinking that things were going well and that there would be plenty of time to finish before deadline.
+Creating text content is a lot faster than creating graphical assets, but it's still a lot of work. Just the ending 'cinematics' took me almost two days to finish and clean up at the end.
+For once I did pick a reasonable scale for this project though. So while the last few days of the Jam was more intense than I would have liked, I never truly felt like I would not be able to finish in time.
+Building a MU* game in pure code is awesome
+Evennia tries to not instil and specific game type, hence its tools are very general. Wrapping these general tools as a highly opinionated and game-specific toolbox enforced to me just how easy it is to do things when you don't need to cover the general case.
+Using the tools and creating content purely in-code was great and ended up leading to a very fast content creation. Python works perfectly as a scripting language and I don't think there is a reason for using in-game building at all for your game, especially not when you are working on your own like this.
+I made a few admin-only commands to jump between states and to set flags, but otherwise most bugs were caught by a generic unit test that just looped over all founds states and tried to initialize them, one after another.
+Conclusions
+For all my work on the Evennia library/server, I've not actually used it for games of my own very much. This was a great opportunity for doing so. It also gave me the opportunity to test the Python3-development branch of Evennia in a production setting.
+I found a few edge-case library bugs which I fixed, but overall things worked very smoothly, also for this kind of game which is certainly far away from the normal MU*-mold that most use Evennia for. I am a bit biased, but overall I felt Evennia to be very mature for the use of making a game from scratch.
+In the future I will most likely break out the 'engine' and tools of the Evscaperoom into an Evennia contrib so that others can make similar games with it easily.
+Looking forward to future game jams now!
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 1
+ ¶
+ - May 18, 2019
+
+
+Over the last month (April-May 2019) I have taken part in the Mud Coder's Guild Game Jam "Enter the (Multi-User) Dungeon". This year the theme for the jam was One Room.
+The result was Evscaperoom, an text-based multi-player "escape-room" written in Python using the Evennia MU* creation system. You can play it from that link in your browser or MU*-client of choice. If you are so inclined, you can also vote for it here in the jam (well, no more).
+This little series of (likely two) dev-blog entries will try to recount the planning and technical aspects of the Evscaperoom. This is also for myself - I'd better write stuff down now while it's still fresh in my mind!
+Update: The Evscaperoom can these days be played by connecting to the Evennia game demo at https://demo.evennia.com.
+Inception
+When I first heard about the upcoming game-jam's theme of One Room, an 'escape room' was the first thing that came to mind, not the least because I just recently got to solve my my own first real-world escape-room as a gift on my birthday.
+If you are not familiar with escape-rooms, the premise is simple - you are locked into a room and have to figure out a way to get out of it by solving practical puzzles and finding hidden clues in the room.
+While you could create such a thing in your own bedroom (and there are also some one-use board game variants), most escape-rooms are managed by companies selling this as an experience for small groups. You usually have one hour to escape and if you get stuck you can press a button (or similar) to get a hint.
+I thought making a computer escape-room. Not only can you do things in the computer that you cannot do in the real world, restricting the game to a single room limits so that it's conceivable to actually finish the damned thing in a month.
+A concern I had was that everyone else in the jam surely must have went for the same obvious idea. In the end that was not an issue at all though.
+Basic premises
+I was pretty confident that I would technically be able to create the game in time (not only is Python and Evennia perfect for this kind of fast experimentation and prototyping, I know the engine very well). But that's not enough; I had to first decide on how the thing should actually play. Here are the questions I had to consider:
+Room State
+An escape room can be seen as going through multiple states as puzzles are solved. For example, you may open a cabinet and that may open up new puzzles to solve. This is fine in a single-player game, but how to handle it in a multi-player environment?
+My first thought was that each object may have multiple states and that players could co-exist in the same room, seeing different states at the same time. I really started planning for this. It would certainly be possible to implement.
+But in the end I considered how a real-world escape-room works - people in the same room solves it together. For there to be any meaning with multi-player, they must share the room state.
+So what I went with was a solution where players can create their own room or join an existing one. Each such room is generated on the fly (and filled with objects etc) and will change as players solve it. Once complete and/or everyone leaves, the room is deleted along with all objects in it. Clean and tidy.
+So how to describe these states? I pictured that these would be described as normal Python modules with a start- and end function that initialized each state and cleaned it up when a new state was started. In the beginning I pictured these states as being pretty small (like one state to change one thing in the room). In the end though, the entire Evscaperoom fits in 12 state modules. I'll describe them in more detail in the second part of this post.
+Accessibility and "pixel-hunting" in text
+When I first started writing descriptions I didn't always note which objects where interactive. It's a very simple and tempting puzzle to add - mention an object as part of a larger description and let the player figure out that it's something they can interact with. This practice is sort-of equivalent to pixel-hunting in graphical games - sweeping with the mouse across the screen until you find that little spot on the screen that you can do something with.
+Problem is, pixel-hunting's not really fun. You easily get stuck and when you eventually find out what was blocking you, you don't really feel clever but only frustrated. So I decided that I should clearly mark every object that people could interact with and focus puzzles on better things.
+In fact, in the end I made it an option:
+
+As part of this I had to remind myself never to use colors only when marking important information: Visually impaired people with screen readers will simply miss that. Not to mention that some just disable colors in their clients.
+So while I personally think option 2 above is the most visually pleasing, Evscaperoom defaults to the third option. It should should start everyone off on equal footing. Evennia has a screen-reader mode out of the box, but I moved it into the menu here for easy access.
+Inventory and collaboration
+In a puzzle-game, you often find objects and combine them with other things. Again, this is simple to do in a single-player game: Players just pick things up and use them later.
+But in a multi-player game this offers a huge risk: players that pick up something important and then log off. The remaining players in that room would then be stuck in an unsolvable room - and it would be very hard for them to know this.
+In principle you could try to 'clean' player inventories when they leave, but not only does it add complexity, there is another issue with players picking things up: It means that the person first to find/pick up the item is the only one that can use it and look at it. Others won't have access until the first player gives it up. Trusting that to anonymous players online is not a good idea.
+So in the end I arrived at the following conclusions:
+
+
+As a side-effect of this I also set a limit to the kind of puzzles I would allow:
+
+
+Focusing on objects
+So without inventory system, how do you interact with objects? A trademark of any puzzle is using one object with another and also to explore things closer to find clues. I turned to graphical adventure games for inspiration:
+
+Secret of Monkey Island ©1990 LucasArts. Image from old-games.com
+A common way to operate on an object in traditional adventure games is to hover the mouse over it and then select the action you want to apply to it. In later (3D) games you might even zoom in of the object and rotate it around with your mouse to see if there are some clues to be had.
+While Evennia and modern UI clients may allow you to use the mouse to select objects, I wanted this to work the traditional MUD-way, by inserting commands. So I decided that you as a player would be in one of two states:
+
+
+
+In the example above, the fireplace points out other objects you could also focus on, whereas the last parenthesis includes one or more "actions" that you can perform on the fireplace only when you have it focused.
+This ends up pretty different from most traditional MUD-style inputs. When I first released this to the public, I found people logged off after their first examine. It turned out that they couldn't figure out how to leave the focus mode. So they just assumed the thing was buggy and quit instead. Of course it's mentioned if you care to write help, but this is clearly one step too many for such an important UI concept.
+So I ended up adding the header above that always reminds you. And since then I've not seen any confusion over how the focus mode works.
+For making it easy to focus on things, I also decided that each room would only ever have one object named a particular thing. So there is for example only one single object in the game named "key" that you can focus on.
+Communication
+I wanted players to co-exist in the same room so that they could collaborate on solving it. This meant communication must be possible. I pictured people would want to point things out and talk to each other.
+In my first round of revisions I had a truckload of individual emotes; you could
+point at target
+for example. In the end I just limited it to
+say/shout/whisper
+and
+emote
+And seeing what people actually use, this is more than enough (say alone is probably 99% of what people need, really). I had a notion that the shout/whisper could be used in a puzzle later but in the end I decided that communication commands should be strictly between players and not have anything to do with the puzzles.
+I removed all other interaction: There is no fighting and without an inventory or requirement to collaborate on puzzles, there is no need for other interactions than to communicate.
+First version you didn't even see what the others did, but eventually I added so that you at least saw what other players were focusing on at the moment (and of course if some major thing was solved/found).
+In the end I don't even list characters as objects in the room (you have to use the who command to see who's in there with you).
+
+The main help command output.
+Story
+It's very common for this type of game to have a dangerous or scary theme. Things like "get out before the bomb explodes", "save the space ship before the engines overheat", "flee the axe murderer before he comes back" etc). I'm no stranger to dark themes, but for this I wanted something friendlier and brighter, maybe with a some dark undercurrents here and there.
+My Jester character is someone I've not only depicted in art, but she's also an old RP character and literary protagonist of mine. Who else would find it funny to lock someone into a room only to provide crazy puzzles and hints for them to get out again? So my flimsy 'premise' was this:
+The village Jester wants to win the pie eating contest. You are one of her most dangerous opponents. She tricked you to her cabin and now you are locked in! If you don't get out in time, she'll get to eat all those pies on her own and surely win!
+That's it - this became the premise from which the entire game flowed. I quickly decided that it to be a very "small-scale" story: no life-or-death situation, no saving of the world. The drama takes place in a small village with an "adversary" that doesn't really want to hurt you, but only to eat more pies than you.
+From this, the way to offer hints came naturally - just eat a slice of "hintberry pie" the jester made (she even encourage you to eat it). It gives you a hint but is also very filling. So if you eat too much, how will you beat her in the contest later, even if you do get out?
+To further the rustic and friendly tone I made sure the story took place on a warm summer day. Many descriptions describe sunshine, chirping birds and the smell of pie. I aimed at letting the text point out quirky and slightly comedic tone of the puzzles the Jester left behind. The player also sometimes gets teased by the game when doing things that does not make sense.
+I won't go into the story further here - it's best if you experience it yourself. Let's just say that the village has some old secrets. And and the Jester has her own ways of doing things and of telling a story. The game has multiple endings and so far people have drawn very different conclusions in the end.
+Scoring
+Most often in escape rooms, final score is determined by the time and the number of hints used. I do keep the latter - for every pie you eat, you get a penalty on your final score.
+As for time - this background story would fit very well with a time limit (get out in X time, after which the pie-eating contest will start!). But from experience with other online text-based games I decided against this. Not only should a player be able to take a break, they may also want to wait for a friend to leave and come back etc.
+But more importantly, I want players to explore and read all my carefully crafted descriptions! So I'd much rather prefer they take their time and reward them for being thorough.
+So in the end I give specific scores for actions throughout the game instead. Most points are for doing things that drive the story forward, such as using something or solving a puzzle. But a significant portion of the score comes from turning every stone and trying everything out. The nice side-effect of this is that even if you know exactly how to solve everything and rush through the game you will still not end up with a perfect score.
+The final score, adjusted by hints is then used to determine if you make it in time to the contest and how you fare. This means that if you explore carefully you have a "buffer" of points so eating a few pies may still land you a good result in the end.
+First sketch
+I really entered the game 'building' aspect with no real notion of how the Jester's cabin should look nor which puzzles should be in it. I tried to write things down beforehand but it didn't really work for me.
+So in the end I decided "let's just put a lot of interesting stuff in the room and then I'll figure out how they interact with each other". I'm sure this is different from game-maker to game-maker. But for me, this process worked perfectly.
+
+
+My first, very rough, sketch of the Jester's cabin
+
+The above, first sketch ended up being what I used, although many of the objects mentioned never ended up in the final game and some things switched places. I did some other sketches too, but they'd be spoilers so I won't show them here ...
+The actual game logic
+The Evscaperoom principles outlined above deviate quite a bit from the traditional MU* style of game play.
+While Evennia provides everything for database management, in-game objects, commands, networking and other resources, the specifics of your game is something you need to make yourself - and you have the full power of Python to do it!
+So for the first three days of the jam I used Evennia to build the custom game logic needed to provide the evscaperoom style of game play. I also made the tools I needed to quickly create the game content (which then took me the rest of the jam to make).
+In part 2 of this blog post I will cover the technical details of the Evscaperoom I built. I'll also go through some issues I ran into and conclusions I drew. I'll link to that from here when it's available!
+
+
+
+
+
+
+
+ Podcast about Evennia
+ ¶
+ - May 9, 2019
+
+
+I was interviewed on the (pretty grandiosely named) podcast Titans of Text the other day.
+In the interview, which are run by people from the MUD Coder's Guild (a great initiative!), I talk a bit about the history of Evennia, the text-based multiplayer game engine I'm working on, and go into some various technical aspects of the engine as well. Check it out and support the podcast!
+
+
+
+
+
+
+
+
+ Steaming on Eating Jam
+ ¶
+ - April 25, 2019
+
+
+In the last few months, development of the upcoming Evennia 0.9 has been steaming on. Evennia is, as you may know, a Python library for creating text-based multiplayer games (MUDs, MUSH etc).
+But it's not all backend work! There is also some sweet game-jamming going on, I get to that at the end.
+Evennia progress towards Python3
+The regular Evennia develop branch is now running completely in Python 3. Since we are using some new features of this Python release, we will be aiming for Python 3.7 as a minimum version once Evennia 0.9 goes stable. We will also use Django 2.1 and likely Twisted 19 - so we'll be pretty much up-to-date on all our main dependencies.
+Now, while the release of Evennia 0.9 is still some time away (there are a bunch of regular bug fixes and minor features that I want to get in there too (see the progress here on the github 0.9 project page), it's worth to consider how much work it'll be for you to migrate and if you should wait or jump in right now.
+If you are new, I still recommend you use regular master branch Evennia (using Python 2.7). This is for which all wiki articles and documentation online is currently written after all. Once we move to python3, you'll need to convert your code ... but syntactically the two are really not that different and conversion should not be much of an issue.
+Not only are there automatic converters for most stuff, you should only need to do one pass to make sure things work and then you'll be done. This article is pretty old but it serves well to identify the main differences. Later Py3 versions just adds new stuff which you would just not have had access to in Python2.7. Once 0.9 is released, we'll also make guides for how you go about converting existing code (apart from the wealth of info on this topic online).
+That said, if you are feeling more adventurous, or really want to use Python3 right away, many of the Evennia developer regulars have been running and testing develop branch for months now. It's overall been a pretty painless transition - as said, py3 is not that different from py2.
+However, develop branch has other features beyond the py3 jump. And those are not yet documented in the main docs. So you'll have to contend with that (but asking in chat/forum works of course). However while it works fine for development already, as a matter of principle I do not recommend ever using Evennia's develop branch for a production game - it can change quickly and may occationally be broken. You have been warned!
+Game Jam
+We are now a little more than a week into the Mud Coders Guild's second yearly Game Jam. This year's theme is "One Room".
+I really hope some more Evennia devs jump on this one because Evennia is perfect for this kind of experimental games. This is because Evennia is not imposing a game style on you - while there are default commands you are free to replace or customize the commands, objects and every aspect of your game to be as specific as you want to your game.
+For example, I have a small Game Jam contribution in the works, where I very quickly reworked the default Evennia setup to pretty much make it into a different genre of game.
+Usually the systems I make for Evennia are generic and intended for any game-type. By contrast, making somehing highly niched is super-fast to do: Building a whole new framework for game mechanisms along with build helpers for me to quickly make content took no more than three days.
+There will no doubt be some iteration, but I hope to spend the rest of the jam time on content and gameplay. I have some RL things happening in the coming weeks (including work on Evennia proper) but if I can get the time to tie my jam entry together, I'll likely make one or two blog posts about how it was developed and my reasons for making the choices i did. Most likely the code will appear as an Evennia contribution in case people want to do something similar for their own projects.
+So, busy days.
+
+
+
+
+
+
+
+ Into 2019
+ ¶
+ - January 2, 2019
+
+
+A new year has come around and it's time to both look back at the old and onward to the future of Evennia, the Python MUD creation system!
+Last year
+
+Last year saw the release of Evennia 0.8. This version of Evennia changes some fundamental aspects of the server infrastructure so that the server can truly run in daemon mode as you would expect (no more running it in a GnuScreen session if you want to see logging to the terminal). It also adds the new Online Creation System, which lets builders create and define prototypes using a menu system as well as big improvements in the web client, such as multiple window-panes (allows the user to assign text to different windows to keep their client uncluttered) as well as plenty of fixes and features to help ease life for the Evennia developer. Thanks again to everyone who helped out and contributed to the release of Evennia 0.8!
+On a personal note, I spoke about Evennia at PyCon Sweden this December, which was fun. I might put up my talk and make a more detailed blog post about that in the future, but my talk got a surprising amount of attention and positive feedback. Clearly many people have fond memories of MUDs and enjoy seeing they are not only still around but are possible to create in Python!
+This year
+
+Now we are steaming ahead towards Evennia 0.9! Already we have had a large number of contributions towards this release. A coming change is a much improved central way to make typeclass information available to a website as well as central ways to do various common operations like creating characters and linking them to Accounts. Much of this functionality is today hidden in the various default commands. In Evennia 0.9 they will be moved into more easily-findable locations as library functions everyone can just trigger without having to copy functionality.
+The biggest change for Evennia 0.9 is however that we will now finally move Evennia over to Python 3. This is now possible as all our dependencies are now sufficiently ported. As discussed in the community for a long time, this will be a clean break - we will not offer any mid-way solution of Python2/3 but will drop Python2 support entirely. We will at the same time move to Django 2.+. In Django 0.9 we will however probably not use any special Python3 features yet. It should hopefully not be too difficult for our users to upgrade, but we'll of course publish extensive instructions and help when that time comes.
+We will likely support a minimum of Python 3.6 and maybe 3.7. This work is currently happening in a separate branch develop-py3 which will soonish merge into the current Python2.7-based develop branch and become Evennia 0.9 when it merges into master branch at an unknown time later this year.
+There are a slew of other things planned for Evennia 0.9 and you can follow the progress from our project page. If you want to help out you are of course also very welcome. If you are new and are interested in getting your feet wet in helping out with Open-source development, we have a list of good first issues you could jump into.
+Onward into the new year!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2020.html b/devblog/html/devblog2020.html
index 22398fec04..19761fd282 100644
--- a/devblog/html/devblog2020.html
+++ b/devblog/html/devblog2020.html
@@ -35,23 +35,35 @@
-
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
-
- Initial-Blog
- ¶
- - May 2, 2020
+
+ Evennia 0.9.5 released
+ ¶
+ - November 14, 2020
-A way to do things
-
This is a test blog page for using markdown to write
-Evennia devblog posts.
-Starting out
-I'm experimenting with a new section of the docs containing these
-blog posts (obviously the blogs are CC anyway).
+
+As of today, Evennia 0.9.5 is out. Evennia is a Python based library and framework for creating text-based multiplayer games (MUD/MU*).
+This is a gradual improvement halfway between 0.9 and the upcoming 1.0. So if you have been keeping up-to-date with the master branch of Evennia over the last year you will not notice much difference from this release (time to upgrade if you haven't been keeping up though!).
+While an interim release, there are still a lot of things that has happened since v0.9:
+Webclient improvements
+
+
+EvMenu improvements
+EvMenu is a powerful system for creating in-game text menus.
+
+
+New settings
+
+
+Other improvements
+
+
+See the changelog here.
+New documentation system
+The bigger change with 0.9.5 is that we are moving to a new documentation system. The details of the long road to do this is documented in my previous post. The point is that we are stopping the use of the Github wiki in favor of statically generated documentation hosted on github pages. At the same time we also move the old evennia.com website from Google-sites to Github.
+Check it out:
+
+
+As for the docs, they will be maturing for a long time still. The old wiki will not be updated anymore, but it will also not be going anywhere in the short term. Version 0.9.5 of the docs is pretty much a copy of the wiki and I hope to not have to spend too much more work maintaining it since the wiki is still around.
+New updates and documentation features will primarily be happening in the 1.0-dev version of the documentation. This will include refactoring all pages as well as a new intro-tutorial and many other things.
+But that's for future blogs ...
+
+
+
+ On using Markdown with Sphinx
+ ¶
+ - October 20, 2020
+
+
+Last post I wrote about the upcoming v1.0 of Evennia, the Python MU* creation engine. We are not getting to that 1.0 version quite yet though: The next release will be 0.9.5, hopefully out relatively soon (TM).
+Evennia 0.9.5 is, as you may guess, an intermediary release. Apart from the 1.0 roadmap just not being done yet, there is one other big reason for this - we are introducing documentation versioning and for that a proper release is needed as a base to start from. Version 0.9.5 contains everything already in master branch, so if you have kept up-to-date you won't notice too much difference. Here are some highlights compared to version 0.9:
+
+
+Many contributors helped out along the way. See the changelog where contributors of the bigger new features are listed.
+The path to a new documentation
+For many years we've used the Github wiki as our documentation hub. It has served us well. But as mentioned in my previous post, it has its drawbacks, in particular when it comes to handling documentation for multiple Evennia versions in parallel.
+After considering a bunch of options, I eventually went with sphinx, because it has such a good autodoc functionality (parsing of the source-code docstrings). This is despite our wiki docs are all in markdown and I dislike restructured text quite a bit. Our code also uses friendly and in-code-readable Google-style docstrings instead of Sphinx' hideous and unreadable format.
+Luckily there are extensions for Sphinx to handle this:
+
+
+What could go wrong? Well, it's been quite a ride.
+Getting Markdown into reST
+Linking to things in recommonmark turned out to be very flaky. I ended up forking and merging a bunch of PRs from the project but that was not enough: Clearly this thing was not built to convert 200 pages of technical markdown from a github wiki.
+My custom fork of recommonmark had to be tweaked a bit for my needs, such as not having to specify the .md file ending in every link and make sure the url-resolver worked as I expected. There were a bunch of other things but I will probably not merge this back, the changes are pretty Evennia-specific.
+Even so, many of my wiki links just wouldn't work. This is not necessarily recommonmark's fault, but how sphinx works by grouping things into toctrees, something that the Evennia wiki doesn't have.
+Also, the recommonmark way to make a toctree in Markdown is to make a list of links - you can't have any descriptive text, making the listing quite useless (apparently people only want bland lists of link-names?). After trying to figure out a way to make this work I eventually capitulated - I make pretty lists in Markdown while using a "hidden" toctree to inform sphinx how the pages are related.
+Getting the wiki into the new doc site
+This required more custom code. I wrote a custom importer that reads the wiki and cleans/reformats it in places where recommonmark just dies on them. I also made a preprocessor that not only finds orphan pages but also builds a toctree and remaps all links in all documents to their actual location on compilation. The remapper makes it a lot easier to move things around. The drawback is that every page needs to be uniquely named. Since this was already the case in the wiki, this was a good tradeoff. So with a lot of custom code the wiki eventually could port automatically.
+The thing is, that even with all this processing, recommonmark doesn't support stuff like Markdown tables, so you still have to fall back to reST notation for those. And Napoleon, while doing a good job of parsing google docstrings, do not expect Markdown. So the end result is mostly markdown but we still have to fall back to reST for some things. It's probably as far as we get.
+Deploying the docs
+Figuring out how to build and deploy these components together was the next challenge. Sphinx' default Makefile was quite anemic and I also wanted something that regular contributors could use to test their documentation contributions easily. I ended up having to expand the Makefile quite a lot while also adding separate deploy scripts and interfaces to github actions (which we recently started using too).
+Finally, the versioning. The sphinx-multiversion plugin works by extracting the branches you choose from git and running the sphinx compiler in each branch. The plugin initially had a bug with how our docs are located (not at the root of the package) but after I reported it, it was quickly fixed. The result is a static document site where you can select between the available versions in the sidebar.
+I've not gotten down to trying to make LaTeX/PDF generation work yet. I'm dreading it quite a bit...
+Where we are
+The github wiki is now closed for external contributions. The v0.9.5 of the new documentation will pretty much be an import of the last state of the wiki with some minor cleanup (such as tables). While we'll fix outright errors in it, I don't plan to do many fixes of purely visual glitches from the conversion - the old wiki is still there should that be a problem.
+The main refactoring and cleanup of the documentation to fit its new home will instead happen in v1.0. While the rough structure of this is already in place, it's very much a work in progress at this point.
+Conclusions
+Evennia 0.9.5 has a lot of features, but the biggest things are 'meta' changes in the project itself. After it is out, it's onward towards 1.0 again!
+
+
+
+
+
+
+
+ Spring updates while trying to stay healthy
+ ¶
+ - April 14, 2020
+
+
+So, spring grows nearer for those of us on the Northern hemisphere. With everyone hopefully hunkered down and safe from the Covid-19 pandemic, I thought it overdue to make another dev blog for the progress of Evennia, the Python MU*-creation system.
+The last few months have seen primarily bug fixing on the Evennia front, but it also has seen an uptick of PRs from the community and the re-opening of the develop branch in earnest. There is still quite a lot of work to do before we can add that extra 0.1 and go from version 0.9 to 1.0.
+What's in a version?
+For me personally, I never put much stock in the notion of versions. Evennia didn't even have versions until a few years back: We used to just have a rolling git release. But eventually it became clear that our user base was big enough that we needed to more clearly separate major (and possibly breaking) updates from what came before. So I started versioning at Evennia 0.5 and have had roughly a new release every year since (not a plan or a promise, it just happened to turn out that way).
+Evennia has been useful (and been used) for game development for many years already. But there is no denying that a 1.x label tends to convey more confidence in a system than a 0.x label, that's just the way things are. So while the new version is still quite some way off, there are a bunch of changes and improvements that we want to do in this release to mark the version change in a good way.
+Documentation changes
+Our documentation will move away from our trusty Github wiki. Instead we will convert the wiki into a static github page built from sources inside evennia/docs/.
+The advantage of the wiki is that it is a very low entry for people to contribute and fix things using Github's editing system. We have had a lot of use of this over the years and the wiki has served us well. The drawbacks are starting to get ever more noticeable, however:
+
+
+The change so far planned is to switch to the Sphinx documentation build-system (same as Python/Django etc is using). We will use it with extensions that allows us to still use Markdown like in the old wiki. This also allows us to build a more comprehensive (and pretty) API documentation of the entire library. We have more options to add comprehensive online search functionality in this solution as well.
+Furthermore, will hopefully be able to set it up so that we can maintain and publish separate documentations for each forthcoming release. That is, you should be able to read the docs for 1.0, 1.1 or the latest master development as you like (similarly to how Django does it, although probably not as fancy from the onset).
+This means that contributions to the documentation will be done as PRs through GitHub, just like when contributing any other code. While this does add a little more of a hurdle to contributions, hopefully the benefits will far outweigh those. Building the docs locally will not require a running Evennia server (unless you want the api docs) and we will try to set everything up for to make it easy to contribute.
+Many of the details around the docs are still up in the air. This is still very much work-in-progress, like everything else.
+Work with this has started in the static-file-docs branch of Evennia. But we have not closed the wiki either - the two will exist in parallel for now.
+PyPi
+As mentioned before, we will finally start to distribute Evennia via PyPi (the Python Package Index) - that is, you will be able to run pip install evennia. Using GIT will no longer be a requirement to get started.
+Considering how quickly people in open-source throw up their three lines of code on PyPi these days, it may be surprising Evennia is not already on PyPi. I have however felt that reading and referencing the highly-commented code is a big part and requirement for getting the most out of the library.
+With the new documentation system, this would improve. And you can of course still use git and follow master branch like the good ol' days if you want!
+Web Admin improvements
+For the longest time, the Django-admin component has been somewhat on the back-burner. With the help of community contributors, this is improving so you will be able to do more work the Admin GUI related to creating and managing objects, tie puppets to Accounts etc.
+API improvements
+Whereas the last few months have been mostly spent fixing lingering bugs, one thing planned for version 1.0 is a general cleanup of legacy strangeness in the API. For example, certain methods can return a list or a single object depending situation, which makes it hard to generalize. There are a lot of small quirks like that which we hope to address and make more consistent.
+There has also been a recent flurry of contributor PRs intended to help decouple Evennia's systems and make them easier to replace for those inclined to do so. Many of this is still being worked on, but it's likely you'll be able to replace many more "core" components for 1.0 with your own variations without doing any hacking in upstream code at all.
+... Needless to say, this is an advanced feature that most developers will never need. But Evennia was always intended to be heavily customizable and having the option is a good thing!
+Another feature that will come for 1.0 is a REST-API, added by one of our contributors. This uses Django-REST-Framework and makes it easier for external programs to authenticate and fetch data out of the Evennia database (great both for external apps, websites or custom what-have-you).
+At this time you can only fetch database objects via this interface, you cannot perform Command-calls or "play the game" this way (REST is a stateless concept and Evennia Commands tend to retain state).
+Many other fixes and contributions
+There's a truckload of stuff already available in master branch, but with the latest contributions of bigger code changes, we have started to use the Evennia develop branch again in earnest again. For a summary of the changes so far, check out the Changelog.
+However, unless you want to contribute to Evennia itself (or really, really want to be on the bleeding edge), you are still recommended to use the master branch for now. A lot of work still to do, as said.
+
+
+
+
+ Getting a MUD RP scene going
+ ¶
+ - October 29, 2017
+
+This article is a little different from the normal more technical Evennia-specific content of this blog. It was originally published as a light-hearted addition to the Imaginary Realities e-zine many years ago. While IR is still online it has since dozed off. So I'm reposting it here to bring it to a new audience.
+In roleplay-heavy MUDs (and in other categories of text-based roleplaying games), the concept of scenes become important. A scene in this concept is simply a situation big or small that involves you and your fellow players in interesting role play. A scene can be as simple as two players meeting in the street and exchanging a few words to the dramatic conclusion to a staff-driven quest. Whenever role player-interested players meet, a scene may happen.
+But sometimes scenes won’t come naturally. Sometimes your favourite game has only a few people online, or most of them are hovering in private areas. It’s time to go proactive. Below I offer some archetypes, tropes and ideas for how to get a random Scene started and people interested. The list is based on one I did for a RP-heavy MUD I played some time back.
+Some terms used in the list:
+-
+
Scene starters
+Scene starters are for when you are alone in a room hoping for others to join you (we've all done it). It is considerably easier to run Scene starters if there is some OOC way for other players to know where to find you (such as a list showing who's interesting in roleplay and where they are in the game). If not, it’s best to prepare your starter in a commonly visited central location or hub. You normally trigger the starter whenever another Player enters.
+The Scene starters below are intended as ideas and suggestions, but are also examples of archetypical behaviour I’ve observed myself.
+The Barfly
+A role playing mud classic since time immemorial. The barfly is alone in a tavern and tends their drink, waiting for things to happen. A passive role, but trivial to setup and easy for other players to jump in on - they just slide up to the bar and ask what's up. Fun variations is the drunk barfly or really, really sad/happy barfly, states which immediately give other Players things to ask about and work with.
+The Strider
+This is the "dark stranger in the corner" variation of the barfly. It is simple to execute - just sit in a dark tavern corner looking glum and mysterious. Often used by newbie players unsure of the game’s commands. The problem is that unless they know the Strider from before it's hard for other Characters to include him/her in their roleplay in a realistic way. The whole IC point of this trope is after all to avoid attention.
+ The Busybody
+The busybody is keeping busy in this room. Most commonly they are performing their job. If they own a bar or run the shop, they tend it. If they are guardsmen they are standing on patrol. If they are wee jesters they are making fools out of themselves. And so on. This is a great starter since it is both natural, realistic and in-character all at once. The nature of their work may occasionally make it easier or harder for other Characters come up with reasons to interact with them though - it might be harder to motivate why some characters would strike up a conversation with a guardsman than they would with a street vendor.
+The Demagogue
+
The Damsel in Distress
+This starter, which of course works both for male and female Characters, sets up the damsel as being in a dependency situation to whomever enters the room next. It involves describing the damsel in a sort of precarious situation that clearly requires an extra hand to resolve. This could be anything: Having their hands full and nearly dropping stuff. Chasing a dog that is running off with their book. Being accosted by vNPC ruffians (which should bugger off quickly, unless roleplaying completely “virtual” combat is your cup of tea). Either way the newcomer has an ongoing scene to react to, and roleplay immediately ensues.
+The Organizer
+
The Aggravator
+The aggravator starts off on the wrong foot with people. Maybe they lash out due to some perceived injustice or they are just grumpy. This starter does not fit all character concepts. The aggravator should accuse the newly arrived PC for something. It could be something from their common history or something made-up out of the blue. It is an active starter in that it leads the way and forces other PCs into roleplay - if nothing else in order to defend themselves. A simple example is to chide the newly arrived PC for not stopping the vNPC that just ran past them out the door. It's important not to take the aggravator trope too far, especially not when using vNPCs. The idea is to get a scene started with some tension, not to get the other (possibly random) PC into real trouble. No god-modding, remember. If the two Characters are actual enemies though, it may be another matter ...
+The Stage Director
+
The nice thing about staged scenes like this is that it gives depth and personality to the game and is often highly appreciated by other Players. If done well, the stage director could give everyone involved a true feeling of being in a living environment.
+The scene could continue to be played out around the PCs also as they interact, making this starter potentially demanding on the stage director. If the other Players are experienced they should pick up on this and maybe even contribute their own vNPCs to the scenario (or the stage director could actively invite other Players to do so). It's important to remember to avoid god-modding here - never dictate another PCs actions, let other Players react as they see fit.
+The Lazy Bum
+This is unfortunately the most common of starters and we've probably all done it one time or another. It does not involve anything but simply standing in a room. No action set, no nothing. Just being there, the Character staring blankly into space until something happens. Yeah.
+Scene entrances
+Here are some ideas on how to enter a scene/room with one or more other PCs already involved in role play. It should be noted that if other PCs already have a scene going they might be OOC annoyed if the newcomer muscles in with some room-changing entrance. So you as a Player have to show some consideration here. Check the land and eventual actions set on people in the room. If a great scene is already in progress you shouldn’t need to start your own - instead try to get in on the action!
+The Mouse
+The most common of entering schemes. The Mouse walks into the room/area not drawing attention to themselves. A simple, passive setup that fits many situations and Character concepts. The mouse is a useful way to enter an already running scene. It is a bit overused though, possibly being The lazy bum of entrances. It seem to imply that it is up to others to notice and respond to the mouse. If really aiming for anonymity, the mouse must emote explicitly that they are not drawing attention to themselves, making it clear to other characters they need not go out of their way to be courteous and notice the newcomer.
+The Ignoranti
+
The Walker
+The walker is just "passing through" this area. This entrance is useful for outdoor areas or minor streets were many Character concepts probably have no real reason to be hanging about more than necessary. The walker is really heading somewhere else and just happens to stop to chat with people in this room. It's an effective entrance that allows for quick, logical exits as well (they just have to 'be on their way'). This is far better than the more common approach of just congesting onto a street room and start greeting people as if all you do is stand in the street all day.
+The Planned Visitor
+
The Wet Kitten
+A classic that involves entering a scene drenched to the bone, shivering from cold, gasping from heat or otherwise be dramatically and visually affected by whatever weather or situation reigns outside. Common to taverns everywhere. For some reason this entrance rarely instills as much sympathy as one would think - but at least it opens up for other Characters to comment on the weather. Taken to the extreme, this becomes a variation on Damsel in Distress.
+The Third Wheel
+
In both cases it's important to make it clear that your actions is a conscious RP choice - it’s your Character which is inconsiderate, not the Player behind it. In other words, emote something like “... He/She does not seem to notice or care that s/he is intruding...”
+The Theatrist
+This is an on-the-fly version of the Stage director or demagogue. Only use if it's clear the currently ongoing scene allows it (so its often a good idea to follow a few emotes in the room before setting this one off). Just like stage director, it starts some sort of background action in the room based on vNPCs. Maybe a brawl, an argument or some other event like a happy announcement. Maybe a vNPC starts hitting on a PC. Or, like the demagogue, the theatrist gets involved in a discussion with an NPC/vNPC. Bartender NPCs are classically useful targets for this. Again, the theatrist must be considerate here, and perceptive so as to not take over an already running scene. Some PCs might forcibly choose to ignore the events going on in order to focus on their ongoing RP, so don't shove it down their throats (no god-modding!)
+The Non-sequitur
+This, strangely rare, entrance involves running into a crowded room, shouting "Monkeeey!" and then run out again. This one will at least lead to roleplay for the confused people in the room you just visited. And no, don't do this unless you have a very specific and suitable character concept, kids.
+The Newbie
+The classic newbie entrance involves walking into a room and saying "Hello" to no one in particular. Bonus points if this is done while ignoring the fact that the room's on fire and the PCs within are all involved in mortal combat. Luckily this entrance trope screams newbie so clearly that players may be urged to pity and lenience. It may in fact be the trigger for getting a more experienced player to take the newbie under their wing and explain a thing or two.
+ + ++
+ Evennia in Hacktobergest 2017
+ ¶
+ - October 1, 2017
+
+
Evennia, the Python MUD/MUSH/MU* creation library participates in the Hacktoberfest 2017 (sign up on that page)! Hacktoberfest is open for all open-source projects like ours. After registering, if you make at least four Pull Requests to a public repo on Github during October (need not just be to Evennia), you win a limited-edition T-shirt!
+The help Evennia out and get your T-Shirt, look at our Issue Tracker. I have marked some issues with "Hacktoberfest" but you could take on any issue you want. Take a look in particular at the Unit test issue if you are looking to get into contributing on a smaller scale while helping us tremendously.
+If you have any questions on contributing (or it's your first time making a Pull Request), don't be shy to drop into #evennia on irc.freenode.net or ask in our forum/mailing list. Have fun!
+ + ++
+ Evennia 0.7 released
+ ¶
+ - September 20, 2017
+
+Evennia 0.7 released
+
As of today Evennia 0.7 is officially out! Evennia is a Python framework and -server for creating text-based multiplayer games (MU*).
+A big thank you to all collaborators that have helped with code and testing along the way!
+Here is the hefty forum post that details how you migrate to Evennia 0.7.
+Evennia 0.7 comes with a range of changes and updates (these are just the ones merged from the latest devel branch, a lot more has happened since 0.6 that were already in master):
+-
+
New contribs (optional plugins) (selection, new since 0.6 but many have been available on master branch for a while):
-
+
A more technical list from the main announcement post:
+-
+
+
+ Renaming Django's Auth User and App
+ ¶
+ - August 25, 2017
+
+
Now that Evennia's devel branch (what will become Evennia 0.7) is slowly approaching completion, I thought I'd try to document an aspect of it that probably took me the longest to figure out. One change in Evennia 0.7 is that the Django model named "Player" changes name to "Account". Over time it has become clear that the old name didn't properly reflected the intention of the model. Sounds like a simple change, right? Well, it was not.
+Briefly on migrations
+First some background. A Django migration is a small Python file sitting in migrations/ sub folders throughout Evennia. A migration describes how our database schema changes over time, so as we change or update fields or add new features we add new migrations to describe how to go from the old to the new state. You apply them with the evennia migrate command we sometimes ask you to run. If we did not supply migrations, anyone with an existing Evennia database would have to either start from scratch or manually go in and tweak their database to match every upstream change we did.
Each migration file has a sequential number, like migration_name.0002.py etc. Migrations will run in order but each migration can also "depend" on another. This means for example that a migration in the player/ folder (application) knows that it need to wait for the changes done by a migration in the typeclasses/ folder/app before it can run. Finally, Django stores a table in the database to know which migrations were already run so to not apply them more than once.
+For reference, Evennia is wrapping the django manage commands, so where I refer to evennia migrate below you would use manage.py migrate in most Django applications.
+Our problem
+So I wanted to migrate the database change "Rename the Player model to Account". We had to do this under a series of additional constraints however:
+-
+
Some false starts
+There is no lack of tutorials and help online for solving the problem of renaming a model. I think I tested most of them. But none I found actually ended up addressing these restraints. Especially point 2 in combination with point 3 above is a killer.
+-
+
In the end I concluded that I had to abandon the notion that users be able to just do a single migrate command. Some more work would be needed on the user's part.
+The solution
+In the end I needed to combine the power of migrations with the power of Git. Using Git resolved the Gordian knot about the player folder. Basically the process goes like this:
+-
+
+ # ...
+
+
+
+ def forwards(apps, schema_editor):
+
+ try:
+
+ PlayerDB = apps.get_model("players", "PlayerDB")
+
+ except LookupError:
+
+ return
+
+
+
+ # copy data from player-tables to database tables here
+
+
+
+ class Migrations(migrations.Migration):
+
+ # ...
+
+ operations = [
+
+ migrations.RunPython(forwards, migrations.RunPython.noop)
+
+ ]
+
+-
+
+ from django.db import connection
+
+
+
+ # ...
+
+
+
+ def _table_exists(db_cursor, tablename):
+
+ "Returns bool if table exists or not"
+
+ sql_check_exists = "SELECT * from %s;" % tablename
+
+ ### [Renaming Django's Auth User and App](https://evennia.blogspot.com/2017/08/renaming-djangos-auth-user-and-app.html)
+
+
And with this, the migration's design was complete. Below is how to actually use it ...
+Running the final migration
+In brief, what our users will do after pulling the latest code is as follows:
+-
+
Conclusions
+And that's it. It's a bit more involved for the end user than I would have liked, and took me much longer than expected to figure out. But it's possible to reproduce and you only need to do it once - and only if you have a database to convert. Whereas this is necessarily specified for Evennia, I hope this might give a hint for other django users aiming to do something like this!
+ + ++
+ The luxury of a creative community
+ ¶
+ - April 23, 2017
+
+
For this blog post I want to focus on the series of very nice pull requests coming in from a growing cadre of contributors over the last few months.
+Contributed goodness
+People have put in a lot of good work to boost Evennia, both by improving existing things and by adding new features. Thanks a lot everyone (below is just a small selection)!
+-
+
About that Evennia 0.7 ...
+So while PRs are popping up left and right in master I've been working in the devel branch towards what will be the Evennia 0.7 release. The branch is not ready for public consumption and testing yet But tentatively it's about halfway there as I am slowly progressing through the tickets. Most of the upcoming features were covered in the previous blog post so I'll leave it at that.
+I just want to end by saying that it's a very luxurious (and awesome) feeling for me to see master-branch Evennia expand with lots of new stuff "without me" so to speak. The power of Open Source indeed!
+ + ++
+ News items from the new year
+ ¶
+ - February 5, 2017
+
+
The last few months have been mostly occupied with fixing bugs and straightening out usage quirks as more and more people take Evennia through its paces.
+Webclient progress
+One of our contributors, mewser/titeuf87 has put in work on implementing part of our roadmap for the webclient. In the first merged batch, the client now has an option window for adjusting and saving settings. This is an important first step towards expanding the client's functionality. Other features is showing help in an (optional) popup window and to report window activity by popup and/or sound.
+The goal for the future is to allow the user or developer to split the client window into panes to which they can then direct various output from the server as they please It's early days still but some of the example designs being discussed can be found in the wiki webclient brainstorm (see the title image of this blog for one of the mockups).
+New server stuff
+Last year saw the death of our old demo server on horizondark.com, luckily the new one at silvren.com has worked out fine with no hickups. As part of setting that up, we also got together a more proper list of recommended hosts for Evennia games. Evennia requires more memory than your average C code base so this is important information to have. It seems most of our users run Evennia on various cloud hosting services rather than from a traditional remote server login.
+Arx going strong
+The currently largest Evennia game, the mush Arx - After the Reckoning has helped a lot in stress testing. Their lead coder Tehom has also been active both in reporting issues and fixing them - kudos! There are however some lingering issues which appears rarely enough that they have not been possible to reproduce yet; we're working on those. Overall though I must say that considering how active Arx is, I would have expected to have seen even more "childhood diseases" than we have.
+Launch scripts and discussions
+It is always interesting with feedback, and some time back another discussion thread erupted over on musoapbox, here. The musoapbox regulars have strong opinions about many things and this time some were critical of Evennia's install process. They felt it was too elaborate with too many steps, especially if you are approaching the system with no knowledge about Python. Apparently the average MUSH server has a much shorter path to go (even though that does require C compiling). Whereas I don't necessarily agree with all notions in that thread, it's valuable feedback - I've long acknowledged that it's hard to know just what is hard or not for a beginner.
+Whereas we are planning to eventually move Evennia to pypi (so you can do pip install evennia), the instructions around getting virtualenv setup is not likely to change. So there is now unix shell scripts supplied with the system for installing on debian-derived systems (Debian, Ubuntu, Mint etc). I also made scripts for automating the setup and launch of Evennia and to use it with linux' initd within the scope of a virtualenv.
+So far these scripts are not tested by enough people to warrant them being generally recommended, but if you are on a supported OS and is interested to try they are found from the top of the Evennia repo, in bin/unix/. More info can be found on their documentation page.
+Docker
+Speaking of installing, Evennia now has an official Docker image, courtesy of the work of contributor and Ainneve dev feend78. The image is automatically kept up-to.date with the latest Evennia repo and allows Evennia to be easily deployed in a production environment (most cloud services supports this). See Docker wiki page for more info.
+Lots of new PRs
+There was a whole slew of contributions waiting for me when returning from Chistmas break, and this has not slowed since. Github makes it easy to contribute and I think we are really starting to see this effect (Google Code back in the day was not as simple in this regard). The best thing with many of these PRs is that they address common things that people need to do but which could be made simpler or more flexible. It's hard to plan for all possibilities, so many people using the system is the best way to find such solutions.
+Apart from the map-creation contribs from last year we also have a new Wildnerness system by mewser/titeuf87. This implements wilderness according to an old idea I had on the mailing list - instead of making a room per location, players get a single room. The room tracks its coordinate in the wildnerness and updates its description and exits dynamically every time you move. This way you could in principle have an infinite wilderness without it taking any space. It's great to see the idea turned into a practical implementation and that it seems to work so well. Will be fun to see what people can do with it in the future!
+ + +
+
+
Evennia
+The Python MU* Development Library
+-
+
+
-
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Evennia 0.8 released
+ ¶
+ - September 30, 2018
+
+After about a year of work and almost 540 commits from close to 20 contributors, Evennia 0.8 is out! Evennia is a Python game server for creating text-based multiplayer games (MUDs, Mushes, etc) using Django and Twisted.
+Some of the upcoming improvements have been covered by previous dev blogs, such as the completely reworked server infrastructure:
+
+as well as the new Online Creation System that allows for editing in-game prototypes using a powerful menu system:
+
+Other improvements are in the web client, which supports split-panes out of the box. The user can split the output area in any number of panes, resize as desired and then assign different types of content to each pane. You can also have panes that absorb "all the rest" or "all" of the content.
+
+There are still some bits which are a bit shaky and there is still much to do with the web client (for example, not that many outgoing messages yet defaults to being tagged in a way that the webclient recognizes). But it's a step forward!
+There are many other improvements for developers, such as easier tools for running debuggers and a lot of new utilities and helper functions. The menu-creation tool (EvMenu) has seen a lot of improvements and also sport a few new decorators for quickly creating multi-page menus with full functionality to flip through and select large numbers of options.
+The community has also chipped in with a large number of optional contributions for developers to use for their own game, such as a full turn-based combat system (divided into convenient chunks for the dev to pick and choose support for everything from magic and potions to equipment and ranged attacks). There are also a range of helper functions for creating simpler menus and build commands as well as auditing tools and additions making better use of Django's very mature security features.
+The more detailed list of improvements and changes can be found in the announcement here. As usual, please report any issues to the issue tracker on github.
+Future
+In the immediate future, we'll focus on resolving any bugs that may have slipped through the cracks and also resolve some other issues in the pipeline.
+But beyond that, work on Evennia 0.9 will begin. And before you ask - yes Evennia 0.9 is the version where we'll move fully to Python3. Our dependencies have now reached a point where this is possible and there will be no intermediary Python2/3 version. There is no timeline for the 0.9 release but it should hopefully not be too tricky for the community to make the jump when the time comes.
+
+
+
+
+
+
+
+ Inline building in upcoming Evennia 0.8
+ ¶
+ - August 18, 2018
+
+
+Evennia, the Python MUD-server game development kit, is slowly creeping closer to its 0.8 release.
+In our development branch I've just pushed the first version of the new OLC (OnLine Creator) system. This is a system to allow builders (who may have limited coding knowledge) to customize and spawn new in-game objects more easily without code access. It's started with the olc command in-game. This is a visual system for manipulating Evennia Prototypes.
+Briefly on Prototypes
+The Prototype is an Evennia concept that has been around a good while. The prototype is a Python dictionary that holds specific keys with values representing properties on a game object. Here's an example of a simple prototype:
+
+ {"key": "My house",
+
+ "typeclass": "typeclasses.houses.MyHouse"}
+
+
+By passing this dict to the spawner, a new object named "My house" will be created. It will be set up with the given typeclass (a 'typeclass' is, in Evennia lingo, a Python class with a database backend). A prototype can specify all aspects of an in-game object - its attributes (like description and other game-specific properties), tags, aliases, location and so on. Prototypes also support inheritance - so you can expand on an existing template without having to add everything fresh every time.
+There are two main reasons for the Prototypes existing in Evennia:
+
+
+What's new
+As said, Prototypes have been around for a good while in Evennia. But in the past they were either manually entered directly as a dict on the command line, or created in code and read from a Python module. The former solution is cumbersome and requires that you know how to build a proper-syntax Python dictionary. The latter requires server code access, making them less useful to builders than they could be.
+Note: If you are visually impaired, each image is also a link to a text-only version.
+
+In Evennia 0.8, while you can still insert the Prototype as a raw dict, spawn/menu or the new olc command opens a new menu-driven interface.
+
+More importantly, builders can now create, save and load prototypes in the database for themselves and other builders to use. The prototypes can be tagged and searched as a joint resource. Builders can also lock prototypes if others are not to be able to read or use them to spawn things. Developers can still supply module-based "read-only" prototypes (for use as starting points or examples to their Builders, for example).
+
+You can now also use the menu to search for and create a new Prototype based on an existing object (if you have access to do so). This makes it quick to start up a new prototype and tweak it for spawning other similar objects. Of course you could spawn temporary objects without saving the prototype as well.
+
+Builders will likely not know which typeclasses are available in the code base. There are new a few ways to list them. The menu display makes use of Evennia 0.8's new EvMenu improvements, which allows for automatically creating multi-page listings (see example above).
+There is also a new switch to the typeclass command, /list, that will list all available typeclasses outside of the OLC.
+Protfuncs
+Another new feature are Protfuncs. Similarly to how Inlinefuncs allows for calling for the result of a function call inside a text string, Protfuncs allows for calling functions inside a prototype's values. It's given on the form $funcname(arguments), where arguments could themselves contain one or more nested Protfuncs.
+As with other such systems in Evennia, only Python functions in a specific module or modules (given by settings) are available for use as Protfuncs in-game. A bunch of default ones are included out of the box. Protfuncs are called at the time of spawning. So for example, you could set the Attribute
+
+Strength = $randint(5, 20)
+
+to automatically spawn objects with a random strength between 5 and 20.
+
+When spawning, the olc will validate the prototype and run tests on any Protfunc used. For convenience you can override the spawn-location if any is hard-coded in the prototype.
+
+The system will also allow you to try updating existing objects created from the same-named prototype earlier. It will sample the existing objects and calculate a 'diff' to apply. This is bit is still a bit iffy, with edge cases that still needs fixing.
+Current status
+The OLC is currently in the develop branch of Evennia - what will soon(ish) merge to become Evennia 0.8.
+It's a pretty big piece of code and as such it's still a bit unstable and there are edge cases and display issues to fix. But it would be great with more people trying it out and reporting errors so the childhood issues can be ironed out before release!
+
+
+
+
+
+
+
+ Kicking into gear from a distance
+ ¶
+ - January 27, 2018
+
+
+The last few weeks I have reworked the way Evennia's startup procedure works. This is now finished in the develop branch so I thought I'd mention a little what's going on.
+Evennia, being a server for creating and running text-games (MU*s), consists of two main processes:
+
+
+Since Evennia should be easy to set up and also run easily on Windows as well as on Linux/Mac, we have foregone using the linux process management services but instead offered our own solution. This is how the reload mechanism currently looks in master branch:
+
+Here I've excluded connections irrelevant to reloading, such as the Twisted AMP connection between Portal and Server. Dashed lines suggest a more "temporary" connection than a solid line.
+The Launcher is the evennia program one uses to interact with the Server in the terminal/console. You give it commands like evennia start/stop/reload.
+
+
+The original reason for this Server-Portal-Runner setup is that the Portal is also reloadable in the same way (it's not shown above). But over time I've found that having the Portal reloadable is not very useful - since players get disconnected when the Portal reloads one can just as well stop and start both processes. There are also a few issues with the setup, such as the .pid files going stale if the server is killed in some catastrophic way and various issues with reliably sending signals under Windows. Also, the interactive mode works a little strangely since closing the terminal will actually kill the Runner, not the Server/Portal - so they will keep on running except they can no longer reload ...
+It overall feels a little ... fiddly.
+In develop branch, this is now the new process management setup:
+
+The Portal is now a Twisted AMP server, while the Evennia Server and Launcher are AMP clients. The Runner is no more.
+
+
+So far I really like how this new setup works and while there were some initial issues on Windows (spawning new processes does not quite work they way you expect on that platform) I think this should conceptually be more OS-agnostic than sending kill-signals.
+This solution gives much more control over the processes. It's easy to start/stop the Server behind the portal at will. The Portal knows the Server state and stores the executable-string needed to start the Server. Thus the Server can also itself request to be reloaded by just mimicking the Launcher's instructions.
+The launcher is now only a client connecting to a port, so one difference with this setup is that there is no more 'interactive' mode - that is the Server/Portal will always run as daemons rather than giving log messages directly in the terminal/console. For that reason the Launcher instead has an in-built log-tailing mechanism now. With this the launcher will combine the server/portal logs and print them in real time to easily see errors etc during development.
+The merger of the develop branch is still a good bit off, but anyone may try it out already here: https://github.com/evennia/evennia/tree/develop . Report problems to the issue tracker as usual.
+
+
+
+
+
+
+
+ New year, new stuff
+ ¶
+ - January 5, 2018
+
+
+Happy 2018 everyone! Here's a little summary of the past Evennia year and what is brewing.
+(Evennia is a Python server- and toolbox for creating text-based multiplayer games (MU*)).
+The biggest challenge for me last year Evennia-wise was the release of Evennia 0.7. Especially designing the migration process for arbitrary users migrating the Django auth-user took a lot of thought to figure out as described in my blog post here. But now 0.7 is released and a few initial minor adjustments could be made after feedback from daring pilot testers. The final process of migrating from 0.6 to 0.7 is, while involved, a step-by-step copy&paste list that has worked fine for most to follow. I've gotten far fewer questions and complains about it than could be expected so that's a good sign.
+Working away on the boring but important behind-the-scenes stuff made me less able to keep up with more "mundane" issues and bugs popping up, or with adding new "fun" features to existing code. Luckily the Evennia community has really been thriving this year; It feels like new users pop up in the support channel all the time now. The number of pull requests both fixing issues and offering new features and contribs have really picked up. A bigger part of my time has been spent reviewing Pull Requests this year than any other I think. I would like to take the opportunity to thank everyone contributing, it's really awesome to see others donating their time and energy adding to Evennia. The Hacktoberfest participation was also surprisingly effective in getting people to create PRs - I have a feeling some were just happy to have an "excuse" for getting started to contribute. We should attend that next year too.
+One thing we added with 0.7 was a more formal branching structure: Evennia now uses fixed master and develop branches, where master is for bug-fixes and develop is for new features (things that will eventually become evennia 0.8). This is simple but enough for our needs; it also makes it easier to track new from old now that we are actually doing releases.
+Now that Twisted is at a point where this is possible for us to do, we also now have a sort-of plan for finally moving Evennia to Python 3. I won't personally be actively working on it until after 0.8 is out though. I don't expect both Evennia 0.8 and 0.9 (which will be pure py3) to get released this year, but we'll see - so far contributors have done all the work on the conversion.
+At any rate, this coming year will probably be dominated by catching up on issues and edge cases that are lining our Issue tracker. One side effect of more newcomers is more eyes on the code and finding the creaky-bits. At least for me, most of my Evennia-time will be spent resolving bugs and issues. The fun thing is that unlike previous years this is not only up to me anymore - hopefully others will keep helping to resolve issues/bugs to broaden our bandwidth when it comes to keeping Evennia stable. The faster we can handle the backlog of issues the faster we can focus on new shiny features after all.
+Finally, a continued great thank you to those of you contributing to the Patreon. Even small donations have a great encouraging value when working on something as niche as a Python MU* game server in 2018 - thanks a lot!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2019.html b/devblog/html/devblog2019.html
new file mode 100644
index 0000000000..838772a70b
--- /dev/null
+++ b/devblog/html/devblog2019.html
@@ -0,0 +1,725 @@
+
+
+
+
+
+ Devblog: Evennia Python MUD/MU creation system
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia
+ The Python MU* Development Library
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Blackifying and fixing bugs
+ ¶
+ - September 30, 2019
+
+
+Since version 0.9 of Evennia, the MU*-creation framework, was released, work has mainly been focused on bug fixing. But there few new features also already sneaked into master branch, despite technically being changes slated for Evennia 1.0.
+On Frontends
+Contributor friarzen has chipped away at improving Evennia's HTML5 web client. It already had the ability to structure and spawn any number of nested text panes. In the future we want to extend the user's ability to save an restore its layouts and allow developers to offer pre-prepared layouts for their games. Already now though, it has gotten plugins for handling both graphics, sounds and video:
+
+
+Inline image by me (deviantart.com/griatch-art)
+
+A related fun development is Castlelore Studios' development of an Unreal Engine Evennia plugin (this is unaffiliated with core Evennia development and I've not tried it, but it looks pretty nifty!):
+
+
+Image ©Castlelore Studios
+
+On Black
+Evennia's source code is extensively documented and was sort of adhering to the Python formatting standard PEP8. But many places were sort of hit-and-miss and others were formatted with slight variations due to who wrote the code.
+After pre-work and recommendation by Greg Taylor, Evennia has adopted the black autoformatter for its source code. I'm not really convinced that black produces the best output of all possible outputs every time, but as Greg puts it, it's at least consistent in style. We use a line width of 100.
+I have set it up so that whenever a new commit is added to the repo, the black formatter will run on it. It may still produce line widths >100 at times (especially for long strings), but otherwise this reduces the number of different PEP8 infractions in the code a lot.
+On Python3
+Overall the move to Python3 appears to have been pretty uneventful for most users. I've not heard almost any complaints or requests for help with converting an existing game.
+The purely Python2-to-Python3 related bugs have been very limited after launch; almost all have been with unicode/bytes when sending data over the wire.
+People have wholeheartedly adopted the new f-strings though, and some spontaneous PRs have already been made towards converting some of Evennia existing code into using them.
+Post-launch we moved to Django 2.2.2, but the Django 2+ upgrades have been pretty uneventful so far.Some people had issues installing Twisted on Windows since there was no py3.7 binary wheel (causing them to have to compile it from scratch). The rise of the Linux Subsystem on Windows have alleviated most of this though and I've not seen any Windows install issues in a while.
+On Future
+For now we'll stay in bug-fixing mode, with the ocational new feature popping up here and there. In the future we'll move to the develop branch again. I have a slew of things in mind for 1.0.
+Apart from bug fixing and cleaning up the API in several places, I plan to make use of the feedback received over the years to make Evennia a little more accessible for a new user. This means I'll also try reworking and consolidating the tutorials so one can follow them with a more coherent "red thread", as well as improving the documentation in various other ways to help newcomers with the common questions we hear a lot.
+The current project plan (subject to change) is found here. Lots of things to do!
+
+
+
+
+
+
+
+ Evennia 0.9 released
+ ¶
+ - July 4, 2019
+
+
+Last week we released Evennia 0.9, the next version of the open source Python MU* creation system.
+This release is the result of about 10 months of development, featuring 771 commits, 70 closed pull requests from the community and something like 80 issues and feature/requests closed. Thanks everyone!
+The main feature of Evennia 0.9 is that we have finally made the move to Python3. And we burn the bridges behind us; as announced in previous posts we completely drop Python2 support and move exclusively to only support the latest Python3.7.
+Overall the move to Python3 was not too bloody (and much work towards a never published py2+3 version was already done by Evennia contributors in a separate branch earlier). The main issues I ran into were mainly in the changes in how Python3 separates strings from bytes. This became crticial since Evennia implements several connection protocols; there were a lot of edge cases and weird errors appearing where data went to and from the wire.
+A regular user has it a lot easier though. So far people have not had too much trouble converting their games from 2.7 to 3.7. The biggest Linux distros don't all have Py3.7 out of the box though, so that may be a concern for some, we'll see.
+... but Py3 is nowhere all there is to find in this release though! There are a plethora of more features in the latest Evennia, all to make it easier to make the text-based multiplayer game of your dreams.
+You can see a summary of new features in the ML announcement and even more details in the actual CHANGELOG file.
+So what's up next?
+Now follows a period of bug-fixing and stabilizing. Maybe resolve some of those long-standing "tech-dept" issues and overall make Evennia more stable.
+Eventually work will then commence (in the develop branch) on version 1.0 of Evennia. For this next release I think I'll step back from new features a bit and focus on refactoring and cleanup of the API as well as other things around the library's distribution, documentation and presentation.
+But for now, onward to summer vacations.
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 2
+ ¶
+ - May 26, 2019
+
+
+
+
+This is part two of my post-mortem dev-blog about Evscaperoom, the multiplayer, text-based 'escape room' I wrote in Python and Evennia. You can read the first part of the dev blog here.
+This was a game-jam entry I created in a month for the Mud Coder's guild's Game Jam. The theme was One Room. You can play the game for free in your browser or with a traditional MUD client. There are no spoilers in these blog posts.
+Update: These days you can play the Evscaperoom by logging into the Evennia demo game at https://demo.evennia.com. It's just one of the exits you can get through when you enter.
+The first part dealt with the overall game-design aspects. This second, final part will go into details of the code and the systems I built to quickly create all the content. The code referenced here is released under the BSD license and is available on github.
+At the time of this post, players have played Evscaperoom for a little more than a week. At the end I'll share some observations and things I learned along the way.
+Ease of building
+Over the one-month game jam, I spent about four days making the game's 'engine' and toolset with Evennia. The rest of the time was spent using those tools to actually create game content (the story, puzzles etc).
+An important thing was that I didn't want to do any traditional in-game 'building'. That is - no logging into the game and running various commands to build objects and rooms. This is partly because I wanted rooms to be buildable on-demand, but also because I didn't want my game to only exist in the database but in actual version-controllable python modules.
+So all of the Evscaperoom is created in code (notably in the game states discussed below). This made it so that I could add unit tests to quickly find bugs and edge cases. It also made it easy to just clone the full game to an online server, init a database and run Evennia on it in a docker when time came to make it public.
+Overall game structure
+
+Main menu
+The game loop is simple: When you log in to the game, you get into a menu where you can create a new room to solve or join an existing one. Quitting a room brings you back to that menu. Quitting again leaves the game entirely. In between, you remain inside a single game location ('room').
+To make it easier for people to agree to meet up in a room, i made a little 'fantasy name generator' to make unique random names of the rooms. It felt more thematic than showing room id's. The generator combines phonemes together with some very simple logic. Not all comes out easy-to-pronounce, but the result is at least identifiable, like the Sheru and Uyoha above.
+I decided that I should not keep empty rooms around, so whenever a room has no more players in it, it's deleted from the database along with all its content. This means players can't really log off and come back to the same room unless a friend stays behind. I felt it was worth keeping things clean and avoid a growing backlog of empty, unsolved rooms. It is, unfortunately, quite common for players to log in, create a room and then immediately log off.
+I distribute Evscaperoom as an Evennia 'game dir'. Once you've installed Evennia you can just clone the evscaperoom repo and start a new multiplayer server with it. While the game dir has some Evennia templates in it by default, Almost all the custom logic for this game is in the evscaperoom/ folder. The only other modification I did was to make sure Evennia rerouted new players into the Evscaperoom menu when they connect.
+Room class
+Since all of the gameplay happens in a single room, it made sense to center all of the data-storage around a new, custom Evennia Room class. This "EvscapeRoom" class holds all resources for this room. Evennia makes sure to persist it all to the database for you.
+The Evennia API provides a lot of powerful but game-general functions. Since our use-case for this game is very strictly defined, I made a slew of helper functions to cut down on boiler plate and pre-set options I wanted to always use.
+For example, I added helper methods both for creating and finding objects in the room. On creation, all objects are tagged with the room's unique hash, meaning that one can be sure to never have any cross-over between rooms (like accidentally finding the object in another room (that of course has the exact same name). Since I also decided to never have more than one object with a given name per room, I could make these methods very simple.
+The room class also has helpers for finding all players in the room and for sending messages to them. It also catches players leaving so that eventual on-character variables can be cleaned.
+Importantly, the very action of deleting the room will automatically clean all resources tied to it, keeping things tidy.
+Commands and Objects
+
+The help screen, show all top-level commands
+As discussed in part one of this blog, the Evscaperoom, uses a 'focus' mode: The player must examine/focus on an object first in order to operate or use it.
+The basic command syntax is:
+> command [target]
+The parsing I made actually allows for a more complex syntax, but in the end this was all that was really needed, since the currently 'focused' object does not need to be specified. This is the process of using one object with another:
+> examine key
+
+~~ key (examining) ~~
+
+This is a brass key.
+
+
+
+(To unlock something with it, use insert into <target>)
+
+
+> insert into door
+You unlock the **door** with the **key**!
+
+(the into is optional). Here, we focus on the key. We get the key's description and a hint that you can insert it into things. We then insert it into the door, which is another object in the room. The insert command knows that we are focusing on the key already and that it should look into the room for an object door to use this with.
+Technically, these on-object 'actions' (like insert above), are dynamically generated. Here is an example of the key object:
+
+class Key(EvscaperoomObject):
+
+ def at_focus_insert(self, caller, **kwargs):
+
+ target = kwargs['args']
+
+ obj = caller.search(obj)
+
+ if not obj:
+
+ return
+
+ if obj.check_flag("can_use_key"):
+
+ obj.handle_insert(self)
+
+
+Not shown here is that I made a wrapper for the "no-match" command of Evennia. This command fires when no other commands match. I made this instead analyze the currently 'focused' object to see if it had a method at_focus_<command_name> on it. If so, I inject the supplied arguments into that method as a keyword argument args.
+So when you focus on the key and give the insert command, the at_focus_insert method on the key will be called with a target to insert the key into_._ We search for the target (the door in the example), check if it even accepts keys and then pass the key to that object to handle. It would then be up to the door to figure out if this particular key unlocks it.
+I created a library of base objects that I can just use as mixins for the object I want to create. Here's an example:
+
+from evscaperoom import objects
+
+
+
+class Box(objects.Openable,
+
+ objects.CodeInput,
+
+ objects.Movable):
+
+ # ...
+
+
+This class will offer actions to open, insert a code and move the object around. It will need some more configuration and addition of messages to show etc. But overall, this method-to-command solution ended up being very stable and extremely easy to use to make complex, interactive objects.
+Room states
+I think of the escape room as going through a series of states. A change of state could for example be that the user solved a puzzle to open a secret wall. That wall is now open, making new items and puzzles available. This means room description should change along with new objects being created or old ones deleted.
+I chose to represent states as Python modules in a folder. To be a state, each module needs to have a global-level class State inheriting from my new BaseState class. This class has methods for initializing and cleaning up the state, as well as was for figuring out which state to go to next. As the system initializes the new state, it gets the current room as argument, so it can modify it.
+This is a (simplified) example of a state module:
+
+# module `state_001_start.py`
+
+
+
+from evscaperoom.state import BaseState
+
+from evscaperoom import objects
+
+
+
+MUG_DESC = """
+
+A blue mug filled with a swirling liquid.
+
+On it is written "DRINK ME" with big letters.
+
+"""
+
+
+
+class Mug(objects.EvscapeRoomObject):
+
+ def at_focus_drink(self, caller, **kwargs):
+
+ caller.msg(f"You drink {self.key}.")
+
+ self.next_state() # trigger next state
+
+
+
+class State(BaseState):
+
+
+
+ hints = ["You are feeling a little thirsty...",
+
+ "Drink from the mug, dummy."]
+
+
+
+ next_state = "state_002_big_puzzle"
+
+
+
+ def init(self):
+
+ mug = self.create_object(
+
+ Mug, key="wooden mug", aliases=["mug"])
+
+ mug.db.desc = MUG_DESC.strip()
+
+
+In this simple state, a mug is created, and when you drink from it, the next state is triggered. The base object has a helper function to trigger the next state since I found that interactive with an object is almost always the reason for switching states.
+The state-class has a lot of useful properties to set, such as which the next state should be (this can be overridden in case of branching paths). You can also store
+a sequence of hints specific for that state.
+Informing the room
+I wrote the content in second-person perspective ("You open the door"). This is however a multiplayer game and I didn't intially appreciate how many texts must also exist in a third-party form for the rest of the room to see ("Griatch opens the door").
+As the amount of text grew (the Evscaperoom has close to 10 000 lines of code, a lot of which is content strings), it became clear that it would not be feasible to manually supply third-persion version strings as well.
+The solution was to add parsing and translation of pronouns and verbs (a concept I first saw on the game Armageddon).
+I write the string like this:
+
+ OPEN_TEXT = "~You ~open the *door."
+
+
+The ~ marks text that should be parsed for second/third-person use (I'll discuss the *door marking in the next section). This I then send to a helper method that either sends it only to you (which means it comes back pretty much the same, but without the special markers) or to you and to the room, in which it will look different depending on who receives it:
+I see
+You open the [door].
+
+
+
+Others see
+Griatch opens the [door].
+
+English is luckily pretty easy to use for this kind of automatic translation - in general you can just add an "s" to the end of the verb. I made a simple mapping for the few irregular verbs I ended up using.
+Overall, this made it quick to present multiple viewpoints with minimal extra text to write.
+
+
+The option menu
+
+The *door -style marking allowed me to generalize how target-able objects in the room were displayed. This meant that users can customize how objects are shown to them. The default is to mark them both with colors and square brackets (this makes it clear also for people with screen readers). But one can also use only colors or turn off the marking completely (hard mode).
+Bringing it online
+Evennia is both a mud framework and mudserver as well as a webserver based on Twisted. It runs the game's website (with the help of Django) and also provides its own HTML5 webclient. I tweaked the default website text and played a little with CSS but otherwise didn't spend too much time on this bit.
+I got a $5/month DigitalOcean droplet with Ubuntu. I made a new, unprivileged "evennia" user on it and cloned the evscaperoom repo to it. I then started a tmux session and ran the Evennia docker image in there. Getting the game online took maybe thirty minutes, most of which was me figuring out where to open the droplet and DigitalOcean firewalls.
+I then pointed http://experimental.evennia.com at the droplet's IP and that was it!
+Updating the online server is now only a matter of pushing changes to my github repo, pulling it to the server and reloading Evennia; Before release, I used a private github repo for this, afterwards I simply made it public. Pretty straightforward.
+Some lessons learned
+I have gotten pretty positive reviews on Evscaperoom so far. In the first two days people stumbled on some edge-case bugs, but after that it has been very stable. Mostly I've had to make small typos and grammar corrections as I (or players) spot them.
+There were nevertheless some things I learned, some of which led to more real improvements post-launch.
+No amount of help is too much help
+
+
+The header shows how to get out of focus mode
+
+Firstly, the focus-system (examine, then do stuff) is a little un-orthodox and needs to be explained. I saw people logging in, examining exactly one thing and then logging out. Eventually I found out (because a user told me), that this was likely because they could not figure out how to leave the focus mode. They'd just flounder about, think the game was buggy and log off.
+The answer (just run examine again) is found with the help command, but clearly this was not intuitive. The solution was to add an explicit help text to the top every time you examine something. After this, the confusion seems to have gone away.
+Make it easy to connect for all tastes
+Another example - a commenting user had pretty strong opinions about the fact that you used to have to supply a username and password to play the game. They suggested this was a 'huge hurdle'. Not sure if that's true. But unless you want to use a particular name, there is also no actual gameplay reason to formally authenticate for Evscaperoom.
+This was easy to fix. Evennia has guest-player support out of the box so I just activated that and supplied some more fantasy-sounding names than the default "Guest 1", "Guest 2" etc. Since then, maybe 40% of players connecting have chosen to do so as an anonymous guest. I don't know if those would have left completely if the option was not available, but it's at least a convenient shortcut for getting into the game.
+Everything takes longer than expected
+I already knew this one, but still I fell into the trap of thinking that things were going well and that there would be plenty of time to finish before deadline.
+Creating text content is a lot faster than creating graphical assets, but it's still a lot of work. Just the ending 'cinematics' took me almost two days to finish and clean up at the end.
+For once I did pick a reasonable scale for this project though. So while the last few days of the Jam was more intense than I would have liked, I never truly felt like I would not be able to finish in time.
+Building a MU* game in pure code is awesome
+Evennia tries to not instil and specific game type, hence its tools are very general. Wrapping these general tools as a highly opinionated and game-specific toolbox enforced to me just how easy it is to do things when you don't need to cover the general case.
+Using the tools and creating content purely in-code was great and ended up leading to a very fast content creation. Python works perfectly as a scripting language and I don't think there is a reason for using in-game building at all for your game, especially not when you are working on your own like this.
+I made a few admin-only commands to jump between states and to set flags, but otherwise most bugs were caught by a generic unit test that just looped over all founds states and tried to initialize them, one after another.
+Conclusions
+For all my work on the Evennia library/server, I've not actually used it for games of my own very much. This was a great opportunity for doing so. It also gave me the opportunity to test the Python3-development branch of Evennia in a production setting.
+I found a few edge-case library bugs which I fixed, but overall things worked very smoothly, also for this kind of game which is certainly far away from the normal MU*-mold that most use Evennia for. I am a bit biased, but overall I felt Evennia to be very mature for the use of making a game from scratch.
+In the future I will most likely break out the 'engine' and tools of the Evscaperoom into an Evennia contrib so that others can make similar games with it easily.
+Looking forward to future game jams now!
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 1
+ ¶
+ - May 18, 2019
+
+
+Over the last month (April-May 2019) I have taken part in the Mud Coder's Guild Game Jam "Enter the (Multi-User) Dungeon". This year the theme for the jam was One Room.
+The result was Evscaperoom, an text-based multi-player "escape-room" written in Python using the Evennia MU* creation system. You can play it from that link in your browser or MU*-client of choice. If you are so inclined, you can also vote for it here in the jam (well, no more).
+This little series of (likely two) dev-blog entries will try to recount the planning and technical aspects of the Evscaperoom. This is also for myself - I'd better write stuff down now while it's still fresh in my mind!
+Update: The Evscaperoom can these days be played by connecting to the Evennia game demo at https://demo.evennia.com.
+Inception
+When I first heard about the upcoming game-jam's theme of One Room, an 'escape room' was the first thing that came to mind, not the least because I just recently got to solve my my own first real-world escape-room as a gift on my birthday.
+If you are not familiar with escape-rooms, the premise is simple - you are locked into a room and have to figure out a way to get out of it by solving practical puzzles and finding hidden clues in the room.
+While you could create such a thing in your own bedroom (and there are also some one-use board game variants), most escape-rooms are managed by companies selling this as an experience for small groups. You usually have one hour to escape and if you get stuck you can press a button (or similar) to get a hint.
+I thought making a computer escape-room. Not only can you do things in the computer that you cannot do in the real world, restricting the game to a single room limits so that it's conceivable to actually finish the damned thing in a month.
+A concern I had was that everyone else in the jam surely must have went for the same obvious idea. In the end that was not an issue at all though.
+Basic premises
+I was pretty confident that I would technically be able to create the game in time (not only is Python and Evennia perfect for this kind of fast experimentation and prototyping, I know the engine very well). But that's not enough; I had to first decide on how the thing should actually play. Here are the questions I had to consider:
+Room State
+An escape room can be seen as going through multiple states as puzzles are solved. For example, you may open a cabinet and that may open up new puzzles to solve. This is fine in a single-player game, but how to handle it in a multi-player environment?
+My first thought was that each object may have multiple states and that players could co-exist in the same room, seeing different states at the same time. I really started planning for this. It would certainly be possible to implement.
+But in the end I considered how a real-world escape-room works - people in the same room solves it together. For there to be any meaning with multi-player, they must share the room state.
+So what I went with was a solution where players can create their own room or join an existing one. Each such room is generated on the fly (and filled with objects etc) and will change as players solve it. Once complete and/or everyone leaves, the room is deleted along with all objects in it. Clean and tidy.
+So how to describe these states? I pictured that these would be described as normal Python modules with a start- and end function that initialized each state and cleaned it up when a new state was started. In the beginning I pictured these states as being pretty small (like one state to change one thing in the room). In the end though, the entire Evscaperoom fits in 12 state modules. I'll describe them in more detail in the second part of this post.
+Accessibility and "pixel-hunting" in text
+When I first started writing descriptions I didn't always note which objects where interactive. It's a very simple and tempting puzzle to add - mention an object as part of a larger description and let the player figure out that it's something they can interact with. This practice is sort-of equivalent to pixel-hunting in graphical games - sweeping with the mouse across the screen until you find that little spot on the screen that you can do something with.
+Problem is, pixel-hunting's not really fun. You easily get stuck and when you eventually find out what was blocking you, you don't really feel clever but only frustrated. So I decided that I should clearly mark every object that people could interact with and focus puzzles on better things.
+In fact, in the end I made it an option:
+
+As part of this I had to remind myself never to use colors only when marking important information: Visually impaired people with screen readers will simply miss that. Not to mention that some just disable colors in their clients.
+So while I personally think option 2 above is the most visually pleasing, Evscaperoom defaults to the third option. It should should start everyone off on equal footing. Evennia has a screen-reader mode out of the box, but I moved it into the menu here for easy access.
+Inventory and collaboration
+In a puzzle-game, you often find objects and combine them with other things. Again, this is simple to do in a single-player game: Players just pick things up and use them later.
+But in a multi-player game this offers a huge risk: players that pick up something important and then log off. The remaining players in that room would then be stuck in an unsolvable room - and it would be very hard for them to know this.
+In principle you could try to 'clean' player inventories when they leave, but not only does it add complexity, there is another issue with players picking things up: It means that the person first to find/pick up the item is the only one that can use it and look at it. Others won't have access until the first player gives it up. Trusting that to anonymous players online is not a good idea.
+So in the end I arrived at the following conclusions:
+
+
+As a side-effect of this I also set a limit to the kind of puzzles I would allow:
+
+
+Focusing on objects
+So without inventory system, how do you interact with objects? A trademark of any puzzle is using one object with another and also to explore things closer to find clues. I turned to graphical adventure games for inspiration:
+
+Secret of Monkey Island ©1990 LucasArts. Image from old-games.com
+A common way to operate on an object in traditional adventure games is to hover the mouse over it and then select the action you want to apply to it. In later (3D) games you might even zoom in of the object and rotate it around with your mouse to see if there are some clues to be had.
+While Evennia and modern UI clients may allow you to use the mouse to select objects, I wanted this to work the traditional MUD-way, by inserting commands. So I decided that you as a player would be in one of two states:
+
+
+
+In the example above, the fireplace points out other objects you could also focus on, whereas the last parenthesis includes one or more "actions" that you can perform on the fireplace only when you have it focused.
+This ends up pretty different from most traditional MUD-style inputs. When I first released this to the public, I found people logged off after their first examine. It turned out that they couldn't figure out how to leave the focus mode. So they just assumed the thing was buggy and quit instead. Of course it's mentioned if you care to write help, but this is clearly one step too many for such an important UI concept.
+So I ended up adding the header above that always reminds you. And since then I've not seen any confusion over how the focus mode works.
+For making it easy to focus on things, I also decided that each room would only ever have one object named a particular thing. So there is for example only one single object in the game named "key" that you can focus on.
+Communication
+I wanted players to co-exist in the same room so that they could collaborate on solving it. This meant communication must be possible. I pictured people would want to point things out and talk to each other.
+In my first round of revisions I had a truckload of individual emotes; you could
+point at target
+for example. In the end I just limited it to
+say/shout/whisper
+and
+emote
+And seeing what people actually use, this is more than enough (say alone is probably 99% of what people need, really). I had a notion that the shout/whisper could be used in a puzzle later but in the end I decided that communication commands should be strictly between players and not have anything to do with the puzzles.
+I removed all other interaction: There is no fighting and without an inventory or requirement to collaborate on puzzles, there is no need for other interactions than to communicate.
+First version you didn't even see what the others did, but eventually I added so that you at least saw what other players were focusing on at the moment (and of course if some major thing was solved/found).
+In the end I don't even list characters as objects in the room (you have to use the who command to see who's in there with you).
+
+The main help command output.
+Story
+It's very common for this type of game to have a dangerous or scary theme. Things like "get out before the bomb explodes", "save the space ship before the engines overheat", "flee the axe murderer before he comes back" etc). I'm no stranger to dark themes, but for this I wanted something friendlier and brighter, maybe with a some dark undercurrents here and there.
+My Jester character is someone I've not only depicted in art, but she's also an old RP character and literary protagonist of mine. Who else would find it funny to lock someone into a room only to provide crazy puzzles and hints for them to get out again? So my flimsy 'premise' was this:
+The village Jester wants to win the pie eating contest. You are one of her most dangerous opponents. She tricked you to her cabin and now you are locked in! If you don't get out in time, she'll get to eat all those pies on her own and surely win!
+That's it - this became the premise from which the entire game flowed. I quickly decided that it to be a very "small-scale" story: no life-or-death situation, no saving of the world. The drama takes place in a small village with an "adversary" that doesn't really want to hurt you, but only to eat more pies than you.
+From this, the way to offer hints came naturally - just eat a slice of "hintberry pie" the jester made (she even encourage you to eat it). It gives you a hint but is also very filling. So if you eat too much, how will you beat her in the contest later, even if you do get out?
+To further the rustic and friendly tone I made sure the story took place on a warm summer day. Many descriptions describe sunshine, chirping birds and the smell of pie. I aimed at letting the text point out quirky and slightly comedic tone of the puzzles the Jester left behind. The player also sometimes gets teased by the game when doing things that does not make sense.
+I won't go into the story further here - it's best if you experience it yourself. Let's just say that the village has some old secrets. And and the Jester has her own ways of doing things and of telling a story. The game has multiple endings and so far people have drawn very different conclusions in the end.
+Scoring
+Most often in escape rooms, final score is determined by the time and the number of hints used. I do keep the latter - for every pie you eat, you get a penalty on your final score.
+As for time - this background story would fit very well with a time limit (get out in X time, after which the pie-eating contest will start!). But from experience with other online text-based games I decided against this. Not only should a player be able to take a break, they may also want to wait for a friend to leave and come back etc.
+But more importantly, I want players to explore and read all my carefully crafted descriptions! So I'd much rather prefer they take their time and reward them for being thorough.
+So in the end I give specific scores for actions throughout the game instead. Most points are for doing things that drive the story forward, such as using something or solving a puzzle. But a significant portion of the score comes from turning every stone and trying everything out. The nice side-effect of this is that even if you know exactly how to solve everything and rush through the game you will still not end up with a perfect score.
+The final score, adjusted by hints is then used to determine if you make it in time to the contest and how you fare. This means that if you explore carefully you have a "buffer" of points so eating a few pies may still land you a good result in the end.
+First sketch
+I really entered the game 'building' aspect with no real notion of how the Jester's cabin should look nor which puzzles should be in it. I tried to write things down beforehand but it didn't really work for me.
+So in the end I decided "let's just put a lot of interesting stuff in the room and then I'll figure out how they interact with each other". I'm sure this is different from game-maker to game-maker. But for me, this process worked perfectly.
+
+
+My first, very rough, sketch of the Jester's cabin
+
+The above, first sketch ended up being what I used, although many of the objects mentioned never ended up in the final game and some things switched places. I did some other sketches too, but they'd be spoilers so I won't show them here ...
+The actual game logic
+The Evscaperoom principles outlined above deviate quite a bit from the traditional MU* style of game play.
+While Evennia provides everything for database management, in-game objects, commands, networking and other resources, the specifics of your game is something you need to make yourself - and you have the full power of Python to do it!
+So for the first three days of the jam I used Evennia to build the custom game logic needed to provide the evscaperoom style of game play. I also made the tools I needed to quickly create the game content (which then took me the rest of the jam to make).
+In part 2 of this blog post I will cover the technical details of the Evscaperoom I built. I'll also go through some issues I ran into and conclusions I drew. I'll link to that from here when it's available!
+
+
+
+
+
+
+
+ Podcast about Evennia
+ ¶
+ - May 9, 2019
+
+
+I was interviewed on the (pretty grandiosely named) podcast Titans of Text the other day.
+In the interview, which are run by people from the MUD Coder's Guild (a great initiative!), I talk a bit about the history of Evennia, the text-based multiplayer game engine I'm working on, and go into some various technical aspects of the engine as well. Check it out and support the podcast!
+
+
+
+
+
+
+
+
+ Steaming on Eating Jam
+ ¶
+ - April 25, 2019
+
+
+In the last few months, development of the upcoming Evennia 0.9 has been steaming on. Evennia is, as you may know, a Python library for creating text-based multiplayer games (MUDs, MUSH etc).
+But it's not all backend work! There is also some sweet game-jamming going on, I get to that at the end.
+Evennia progress towards Python3
+The regular Evennia develop branch is now running completely in Python 3. Since we are using some new features of this Python release, we will be aiming for Python 3.7 as a minimum version once Evennia 0.9 goes stable. We will also use Django 2.1 and likely Twisted 19 - so we'll be pretty much up-to-date on all our main dependencies.
+Now, while the release of Evennia 0.9 is still some time away (there are a bunch of regular bug fixes and minor features that I want to get in there too (see the progress here on the github 0.9 project page), it's worth to consider how much work it'll be for you to migrate and if you should wait or jump in right now.
+If you are new, I still recommend you use regular master branch Evennia (using Python 2.7). This is for which all wiki articles and documentation online is currently written after all. Once we move to python3, you'll need to convert your code ... but syntactically the two are really not that different and conversion should not be much of an issue.
+Not only are there automatic converters for most stuff, you should only need to do one pass to make sure things work and then you'll be done. This article is pretty old but it serves well to identify the main differences. Later Py3 versions just adds new stuff which you would just not have had access to in Python2.7. Once 0.9 is released, we'll also make guides for how you go about converting existing code (apart from the wealth of info on this topic online).
+That said, if you are feeling more adventurous, or really want to use Python3 right away, many of the Evennia developer regulars have been running and testing develop branch for months now. It's overall been a pretty painless transition - as said, py3 is not that different from py2.
+However, develop branch has other features beyond the py3 jump. And those are not yet documented in the main docs. So you'll have to contend with that (but asking in chat/forum works of course). However while it works fine for development already, as a matter of principle I do not recommend ever using Evennia's develop branch for a production game - it can change quickly and may occationally be broken. You have been warned!
+Game Jam
+We are now a little more than a week into the Mud Coders Guild's second yearly Game Jam. This year's theme is "One Room".
+I really hope some more Evennia devs jump on this one because Evennia is perfect for this kind of experimental games. This is because Evennia is not imposing a game style on you - while there are default commands you are free to replace or customize the commands, objects and every aspect of your game to be as specific as you want to your game.
+For example, I have a small Game Jam contribution in the works, where I very quickly reworked the default Evennia setup to pretty much make it into a different genre of game.
+Usually the systems I make for Evennia are generic and intended for any game-type. By contrast, making somehing highly niched is super-fast to do: Building a whole new framework for game mechanisms along with build helpers for me to quickly make content took no more than three days.
+There will no doubt be some iteration, but I hope to spend the rest of the jam time on content and gameplay. I have some RL things happening in the coming weeks (including work on Evennia proper) but if I can get the time to tie my jam entry together, I'll likely make one or two blog posts about how it was developed and my reasons for making the choices i did. Most likely the code will appear as an Evennia contribution in case people want to do something similar for their own projects.
+So, busy days.
+
+
+
+
+
+
+
+ Into 2019
+ ¶
+ - January 2, 2019
+
+
+A new year has come around and it's time to both look back at the old and onward to the future of Evennia, the Python MUD creation system!
+Last year
+
+Last year saw the release of Evennia 0.8. This version of Evennia changes some fundamental aspects of the server infrastructure so that the server can truly run in daemon mode as you would expect (no more running it in a GnuScreen session if you want to see logging to the terminal). It also adds the new Online Creation System, which lets builders create and define prototypes using a menu system as well as big improvements in the web client, such as multiple window-panes (allows the user to assign text to different windows to keep their client uncluttered) as well as plenty of fixes and features to help ease life for the Evennia developer. Thanks again to everyone who helped out and contributed to the release of Evennia 0.8!
+On a personal note, I spoke about Evennia at PyCon Sweden this December, which was fun. I might put up my talk and make a more detailed blog post about that in the future, but my talk got a surprising amount of attention and positive feedback. Clearly many people have fond memories of MUDs and enjoy seeing they are not only still around but are possible to create in Python!
+This year
+
+Now we are steaming ahead towards Evennia 0.9! Already we have had a large number of contributions towards this release. A coming change is a much improved central way to make typeclass information available to a website as well as central ways to do various common operations like creating characters and linking them to Accounts. Much of this functionality is today hidden in the various default commands. In Evennia 0.9 they will be moved into more easily-findable locations as library functions everyone can just trigger without having to copy functionality.
+The biggest change for Evennia 0.9 is however that we will now finally move Evennia over to Python 3. This is now possible as all our dependencies are now sufficiently ported. As discussed in the community for a long time, this will be a clean break - we will not offer any mid-way solution of Python2/3 but will drop Python2 support entirely. We will at the same time move to Django 2.+. In Django 0.9 we will however probably not use any special Python3 features yet. It should hopefully not be too difficult for our users to upgrade, but we'll of course publish extensive instructions and help when that time comes.
+We will likely support a minimum of Python 3.6 and maybe 3.7. This work is currently happening in a separate branch develop-py3 which will soonish merge into the current Python2.7-based develop branch and become Evennia 0.9 when it merges into master branch at an unknown time later this year.
+There are a slew of other things planned for Evennia 0.9 and you can follow the progress from our project page. If you want to help out you are of course also very welcome. If you are new and are interested in getting your feet wet in helping out with Open-source development, we have a list of good first issues you could jump into.
+Onward into the new year!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2020.html b/devblog/html/devblog2020.html
index 22398fec04..19761fd282 100644
--- a/devblog/html/devblog2020.html
+++ b/devblog/html/devblog2020.html
@@ -35,23 +35,35 @@
-
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
-
- Initial-Blog
- ¶
- - May 2, 2020
+
+ Evennia 0.9.5 released
+ ¶
+ - November 14, 2020
-A way to do things
-
This is a test blog page for using markdown to write
-Evennia devblog posts.
-Starting out
-I'm experimenting with a new section of the docs containing these
-blog posts (obviously the blogs are CC anyway).
+
+As of today, Evennia 0.9.5 is out. Evennia is a Python based library and framework for creating text-based multiplayer games (MUD/MU*).
+This is a gradual improvement halfway between 0.9 and the upcoming 1.0. So if you have been keeping up-to-date with the master branch of Evennia over the last year you will not notice much difference from this release (time to upgrade if you haven't been keeping up though!).
+While an interim release, there are still a lot of things that has happened since v0.9:
+Webclient improvements
+
+
+EvMenu improvements
+EvMenu is a powerful system for creating in-game text menus.
+
+
+New settings
+
+
+Other improvements
+
+
+See the changelog here.
+New documentation system
+The bigger change with 0.9.5 is that we are moving to a new documentation system. The details of the long road to do this is documented in my previous post. The point is that we are stopping the use of the Github wiki in favor of statically generated documentation hosted on github pages. At the same time we also move the old evennia.com website from Google-sites to Github.
+Check it out:
+
+
+As for the docs, they will be maturing for a long time still. The old wiki will not be updated anymore, but it will also not be going anywhere in the short term. Version 0.9.5 of the docs is pretty much a copy of the wiki and I hope to not have to spend too much more work maintaining it since the wiki is still around.
+New updates and documentation features will primarily be happening in the 1.0-dev version of the documentation. This will include refactoring all pages as well as a new intro-tutorial and many other things.
+But that's for future blogs ...
+
+
+
+ On using Markdown with Sphinx
+ ¶
+ - October 20, 2020
+
+
+Last post I wrote about the upcoming v1.0 of Evennia, the Python MU* creation engine. We are not getting to that 1.0 version quite yet though: The next release will be 0.9.5, hopefully out relatively soon (TM).
+Evennia 0.9.5 is, as you may guess, an intermediary release. Apart from the 1.0 roadmap just not being done yet, there is one other big reason for this - we are introducing documentation versioning and for that a proper release is needed as a base to start from. Version 0.9.5 contains everything already in master branch, so if you have kept up-to-date you won't notice too much difference. Here are some highlights compared to version 0.9:
+
+
+Many contributors helped out along the way. See the changelog where contributors of the bigger new features are listed.
+The path to a new documentation
+For many years we've used the Github wiki as our documentation hub. It has served us well. But as mentioned in my previous post, it has its drawbacks, in particular when it comes to handling documentation for multiple Evennia versions in parallel.
+After considering a bunch of options, I eventually went with sphinx, because it has such a good autodoc functionality (parsing of the source-code docstrings). This is despite our wiki docs are all in markdown and I dislike restructured text quite a bit. Our code also uses friendly and in-code-readable Google-style docstrings instead of Sphinx' hideous and unreadable format.
+Luckily there are extensions for Sphinx to handle this:
+
+
+What could go wrong? Well, it's been quite a ride.
+Getting Markdown into reST
+Linking to things in recommonmark turned out to be very flaky. I ended up forking and merging a bunch of PRs from the project but that was not enough: Clearly this thing was not built to convert 200 pages of technical markdown from a github wiki.
+My custom fork of recommonmark had to be tweaked a bit for my needs, such as not having to specify the .md file ending in every link and make sure the url-resolver worked as I expected. There were a bunch of other things but I will probably not merge this back, the changes are pretty Evennia-specific.
+Even so, many of my wiki links just wouldn't work. This is not necessarily recommonmark's fault, but how sphinx works by grouping things into toctrees, something that the Evennia wiki doesn't have.
+Also, the recommonmark way to make a toctree in Markdown is to make a list of links - you can't have any descriptive text, making the listing quite useless (apparently people only want bland lists of link-names?). After trying to figure out a way to make this work I eventually capitulated - I make pretty lists in Markdown while using a "hidden" toctree to inform sphinx how the pages are related.
+Getting the wiki into the new doc site
+This required more custom code. I wrote a custom importer that reads the wiki and cleans/reformats it in places where recommonmark just dies on them. I also made a preprocessor that not only finds orphan pages but also builds a toctree and remaps all links in all documents to their actual location on compilation. The remapper makes it a lot easier to move things around. The drawback is that every page needs to be uniquely named. Since this was already the case in the wiki, this was a good tradeoff. So with a lot of custom code the wiki eventually could port automatically.
+The thing is, that even with all this processing, recommonmark doesn't support stuff like Markdown tables, so you still have to fall back to reST notation for those. And Napoleon, while doing a good job of parsing google docstrings, do not expect Markdown. So the end result is mostly markdown but we still have to fall back to reST for some things. It's probably as far as we get.
+Deploying the docs
+Figuring out how to build and deploy these components together was the next challenge. Sphinx' default Makefile was quite anemic and I also wanted something that regular contributors could use to test their documentation contributions easily. I ended up having to expand the Makefile quite a lot while also adding separate deploy scripts and interfaces to github actions (which we recently started using too).
+Finally, the versioning. The sphinx-multiversion plugin works by extracting the branches you choose from git and running the sphinx compiler in each branch. The plugin initially had a bug with how our docs are located (not at the root of the package) but after I reported it, it was quickly fixed. The result is a static document site where you can select between the available versions in the sidebar.
+I've not gotten down to trying to make LaTeX/PDF generation work yet. I'm dreading it quite a bit...
+Where we are
+The github wiki is now closed for external contributions. The v0.9.5 of the new documentation will pretty much be an import of the last state of the wiki with some minor cleanup (such as tables). While we'll fix outright errors in it, I don't plan to do many fixes of purely visual glitches from the conversion - the old wiki is still there should that be a problem.
+The main refactoring and cleanup of the documentation to fit its new home will instead happen in v1.0. While the rough structure of this is already in place, it's very much a work in progress at this point.
+Conclusions
+Evennia 0.9.5 has a lot of features, but the biggest things are 'meta' changes in the project itself. After it is out, it's onward towards 1.0 again!
+
+
+
+
+
+
+
+ Spring updates while trying to stay healthy
+ ¶
+ - April 14, 2020
+
+
+So, spring grows nearer for those of us on the Northern hemisphere. With everyone hopefully hunkered down and safe from the Covid-19 pandemic, I thought it overdue to make another dev blog for the progress of Evennia, the Python MU*-creation system.
+The last few months have seen primarily bug fixing on the Evennia front, but it also has seen an uptick of PRs from the community and the re-opening of the develop branch in earnest. There is still quite a lot of work to do before we can add that extra 0.1 and go from version 0.9 to 1.0.
+What's in a version?
+For me personally, I never put much stock in the notion of versions. Evennia didn't even have versions until a few years back: We used to just have a rolling git release. But eventually it became clear that our user base was big enough that we needed to more clearly separate major (and possibly breaking) updates from what came before. So I started versioning at Evennia 0.5 and have had roughly a new release every year since (not a plan or a promise, it just happened to turn out that way).
+Evennia has been useful (and been used) for game development for many years already. But there is no denying that a 1.x label tends to convey more confidence in a system than a 0.x label, that's just the way things are. So while the new version is still quite some way off, there are a bunch of changes and improvements that we want to do in this release to mark the version change in a good way.
+Documentation changes
+Our documentation will move away from our trusty Github wiki. Instead we will convert the wiki into a static github page built from sources inside evennia/docs/.
+The advantage of the wiki is that it is a very low entry for people to contribute and fix things using Github's editing system. We have had a lot of use of this over the years and the wiki has served us well. The drawbacks are starting to get ever more noticeable, however:
+
+
+The change so far planned is to switch to the Sphinx documentation build-system (same as Python/Django etc is using). We will use it with extensions that allows us to still use Markdown like in the old wiki. This also allows us to build a more comprehensive (and pretty) API documentation of the entire library. We have more options to add comprehensive online search functionality in this solution as well.
+Furthermore, will hopefully be able to set it up so that we can maintain and publish separate documentations for each forthcoming release. That is, you should be able to read the docs for 1.0, 1.1 or the latest master development as you like (similarly to how Django does it, although probably not as fancy from the onset).
+This means that contributions to the documentation will be done as PRs through GitHub, just like when contributing any other code. While this does add a little more of a hurdle to contributions, hopefully the benefits will far outweigh those. Building the docs locally will not require a running Evennia server (unless you want the api docs) and we will try to set everything up for to make it easy to contribute.
+Many of the details around the docs are still up in the air. This is still very much work-in-progress, like everything else.
+Work with this has started in the static-file-docs branch of Evennia. But we have not closed the wiki either - the two will exist in parallel for now.
+PyPi
+As mentioned before, we will finally start to distribute Evennia via PyPi (the Python Package Index) - that is, you will be able to run pip install evennia. Using GIT will no longer be a requirement to get started.
+Considering how quickly people in open-source throw up their three lines of code on PyPi these days, it may be surprising Evennia is not already on PyPi. I have however felt that reading and referencing the highly-commented code is a big part and requirement for getting the most out of the library.
+With the new documentation system, this would improve. And you can of course still use git and follow master branch like the good ol' days if you want!
+Web Admin improvements
+For the longest time, the Django-admin component has been somewhat on the back-burner. With the help of community contributors, this is improving so you will be able to do more work the Admin GUI related to creating and managing objects, tie puppets to Accounts etc.
+API improvements
+Whereas the last few months have been mostly spent fixing lingering bugs, one thing planned for version 1.0 is a general cleanup of legacy strangeness in the API. For example, certain methods can return a list or a single object depending situation, which makes it hard to generalize. There are a lot of small quirks like that which we hope to address and make more consistent.
+There has also been a recent flurry of contributor PRs intended to help decouple Evennia's systems and make them easier to replace for those inclined to do so. Many of this is still being worked on, but it's likely you'll be able to replace many more "core" components for 1.0 with your own variations without doing any hacking in upstream code at all.
+... Needless to say, this is an advanced feature that most developers will never need. But Evennia was always intended to be heavily customizable and having the option is a good thing!
+Another feature that will come for 1.0 is a REST-API, added by one of our contributors. This uses Django-REST-Framework and makes it easier for external programs to authenticate and fetch data out of the Evennia database (great both for external apps, websites or custom what-have-you).
+At this time you can only fetch database objects via this interface, you cannot perform Command-calls or "play the game" this way (REST is a stateless concept and Evennia Commands tend to retain state).
+Many other fixes and contributions
+There's a truckload of stuff already available in master branch, but with the latest contributions of bigger code changes, we have started to use the Evennia develop branch again in earnest again. For a summary of the changes so far, check out the Changelog.
+However, unless you want to contribute to Evennia itself (or really, really want to be on the bleeding edge), you are still recommended to use the master branch for now. A lot of work still to do, as said.
+
+
+
+
+ Evennia 0.8 released
+ ¶
+ - September 30, 2018
+
+After about a year of work and almost 540 commits from close to 20 contributors, Evennia 0.8 is out! Evennia is a Python game server for creating text-based multiplayer games (MUDs, Mushes, etc) using Django and Twisted.
Some of the upcoming improvements have been covered by previous dev blogs, such as the completely reworked server infrastructure:
+
as well as the new Online Creation System that allows for editing in-game prototypes using a powerful menu system:
+
Other improvements are in the web client, which supports split-panes out of the box. The user can split the output area in any number of panes, resize as desired and then assign different types of content to each pane. You can also have panes that absorb "all the rest" or "all" of the content.
+
There are still some bits which are a bit shaky and there is still much to do with the web client (for example, not that many outgoing messages yet defaults to being tagged in a way that the webclient recognizes). But it's a step forward!
+There are many other improvements for developers, such as easier tools for running debuggers and a lot of new utilities and helper functions. The menu-creation tool (EvMenu) has seen a lot of improvements and also sport a few new decorators for quickly creating multi-page menus with full functionality to flip through and select large numbers of options.
+The community has also chipped in with a large number of optional contributions for developers to use for their own game, such as a full turn-based combat system (divided into convenient chunks for the dev to pick and choose support for everything from magic and potions to equipment and ranged attacks). There are also a range of helper functions for creating simpler menus and build commands as well as auditing tools and additions making better use of Django's very mature security features.
+The more detailed list of improvements and changes can be found in the announcement here. As usual, please report any issues to the issue tracker on github.
+Future
+In the immediate future, we'll focus on resolving any bugs that may have slipped through the cracks and also resolve some other issues in the pipeline.
+But beyond that, work on Evennia 0.9 will begin. And before you ask - yes Evennia 0.9 is the version where we'll move fully to Python3. Our dependencies have now reached a point where this is possible and there will be no intermediary Python2/3 version. There is no timeline for the 0.9 release but it should hopefully not be too tricky for the community to make the jump when the time comes.
+ + ++
+ Inline building in upcoming Evennia 0.8
+ ¶
+ - August 18, 2018
+
+
Evennia, the Python MUD-server game development kit, is slowly creeping closer to its 0.8 release.
+In our development branch I've just pushed the first version of the new OLC (OnLine Creator) system. This is a system to allow builders (who may have limited coding knowledge) to customize and spawn new in-game objects more easily without code access. It's started with the olc command in-game. This is a visual system for manipulating Evennia Prototypes.
+Briefly on Prototypes
+The Prototype is an Evennia concept that has been around a good while. The prototype is a Python dictionary that holds specific keys with values representing properties on a game object. Here's an example of a simple prototype:
+
+ {"key": "My house",
+
+ "typeclass": "typeclasses.houses.MyHouse"}
+
+By passing this dict to the spawner, a new object named "My house" will be created. It will be set up with the given typeclass (a 'typeclass' is, in Evennia lingo, a Python class with a database backend). A prototype can specify all aspects of an in-game object - its attributes (like description and other game-specific properties), tags, aliases, location and so on. Prototypes also support inheritance - so you can expand on an existing template without having to add everything fresh every time.
+There are two main reasons for the Prototypes existing in Evennia:
+-
+
What's new
+As said, Prototypes have been around for a good while in Evennia. But in the past they were either manually entered directly as a dict on the command line, or created in code and read from a Python module. The former solution is cumbersome and requires that you know how to build a proper-syntax Python dictionary. The latter requires server code access, making them less useful to builders than they could be.
+Note: If you are visually impaired, each image is also a link to a text-only version.
+
In Evennia 0.8, while you can still insert the Prototype as a raw dict, spawn/menu or the new olc command opens a new menu-driven interface.
+
More importantly, builders can now create, save and load prototypes in the database for themselves and other builders to use. The prototypes can be tagged and searched as a joint resource. Builders can also lock prototypes if others are not to be able to read or use them to spawn things. Developers can still supply module-based "read-only" prototypes (for use as starting points or examples to their Builders, for example).
+
You can now also use the menu to search for and create a new Prototype based on an existing object (if you have access to do so). This makes it quick to start up a new prototype and tweak it for spawning other similar objects. Of course you could spawn temporary objects without saving the prototype as well.
+
Builders will likely not know which typeclasses are available in the code base. There are new a few ways to list them. The menu display makes use of Evennia 0.8's new EvMenu improvements, which allows for automatically creating multi-page listings (see example above).
+There is also a new switch to the typeclass command, /list, that will list all available typeclasses outside of the OLC.
+Protfuncs
+Another new feature are Protfuncs. Similarly to how Inlinefuncs allows for calling for the result of a function call inside a text string, Protfuncs allows for calling functions inside a prototype's values. It's given on the form $funcname(arguments), where arguments could themselves contain one or more nested Protfuncs.
+As with other such systems in Evennia, only Python functions in a specific module or modules (given by settings) are available for use as Protfuncs in-game. A bunch of default ones are included out of the box. Protfuncs are called at the time of spawning. So for example, you could set the Attribute
+++Strength = $randint(5, 20)
+
to automatically spawn objects with a random strength between 5 and 20.
+
When spawning, the olc will validate the prototype and run tests on any Protfunc used. For convenience you can override the spawn-location if any is hard-coded in the prototype.
+
The system will also allow you to try updating existing objects created from the same-named prototype earlier. It will sample the existing objects and calculate a 'diff' to apply. This is bit is still a bit iffy, with edge cases that still needs fixing.
+Current status
+The OLC is currently in the develop branch of Evennia - what will soon(ish) merge to become Evennia 0.8.
+It's a pretty big piece of code and as such it's still a bit unstable and there are edge cases and display issues to fix. But it would be great with more people trying it out and reporting errors so the childhood issues can be ironed out before release!
+ + ++
+ Kicking into gear from a distance
+ ¶
+ - January 27, 2018
+
+
The last few weeks I have reworked the way Evennia's startup procedure works. This is now finished in the develop branch so I thought I'd mention a little what's going on.
+Evennia, being a server for creating and running text-games (MU*s), consists of two main processes:
+-
+
Since Evennia should be easy to set up and also run easily on Windows as well as on Linux/Mac, we have foregone using the linux process management services but instead offered our own solution. This is how the reload mechanism currently looks in master branch:
+
Here I've excluded connections irrelevant to reloading, such as the Twisted AMP connection between Portal and Server. Dashed lines suggest a more "temporary" connection than a solid line.
+The Launcher is the evennia program one uses to interact with the Server in the terminal/console. You give it commands like evennia start/stop/reload.
+-
+
The original reason for this Server-Portal-Runner setup is that the Portal is also reloadable in the same way (it's not shown above). But over time I've found that having the Portal reloadable is not very useful - since players get disconnected when the Portal reloads one can just as well stop and start both processes. There are also a few issues with the setup, such as the .pid files going stale if the server is killed in some catastrophic way and various issues with reliably sending signals under Windows. Also, the interactive mode works a little strangely since closing the terminal will actually kill the Runner, not the Server/Portal - so they will keep on running except they can no longer reload ...
+It overall feels a little ... fiddly.
+In develop branch, this is now the new process management setup:
+
The Portal is now a Twisted AMP server, while the Evennia Server and Launcher are AMP clients. The Runner is no more.
+-
+
So far I really like how this new setup works and while there were some initial issues on Windows (spawning new processes does not quite work they way you expect on that platform) I think this should conceptually be more OS-agnostic than sending kill-signals.
+This solution gives much more control over the processes. It's easy to start/stop the Server behind the portal at will. The Portal knows the Server state and stores the executable-string needed to start the Server. Thus the Server can also itself request to be reloaded by just mimicking the Launcher's instructions.
+The launcher is now only a client connecting to a port, so one difference with this setup is that there is no more 'interactive' mode - that is the Server/Portal will always run as daemons rather than giving log messages directly in the terminal/console. For that reason the Launcher instead has an in-built log-tailing mechanism now. With this the launcher will combine the server/portal logs and print them in real time to easily see errors etc during development.
+The merger of the develop branch is still a good bit off, but anyone may try it out already here: https://github.com/evennia/evennia/tree/develop . Report problems to the issue tracker as usual.
+ + ++
+ New year, new stuff
+ ¶
+ - January 5, 2018
+
+
Happy 2018 everyone! Here's a little summary of the past Evennia year and what is brewing.
+(Evennia is a Python server- and toolbox for creating text-based multiplayer games (MU*)).
+The biggest challenge for me last year Evennia-wise was the release of Evennia 0.7. Especially designing the migration process for arbitrary users migrating the Django auth-user took a lot of thought to figure out as described in my blog post here. But now 0.7 is released and a few initial minor adjustments could be made after feedback from daring pilot testers. The final process of migrating from 0.6 to 0.7 is, while involved, a step-by-step copy&paste list that has worked fine for most to follow. I've gotten far fewer questions and complains about it than could be expected so that's a good sign.
+Working away on the boring but important behind-the-scenes stuff made me less able to keep up with more "mundane" issues and bugs popping up, or with adding new "fun" features to existing code. Luckily the Evennia community has really been thriving this year; It feels like new users pop up in the support channel all the time now. The number of pull requests both fixing issues and offering new features and contribs have really picked up. A bigger part of my time has been spent reviewing Pull Requests this year than any other I think. I would like to take the opportunity to thank everyone contributing, it's really awesome to see others donating their time and energy adding to Evennia. The Hacktoberfest participation was also surprisingly effective in getting people to create PRs - I have a feeling some were just happy to have an "excuse" for getting started to contribute. We should attend that next year too.
+One thing we added with 0.7 was a more formal branching structure: Evennia now uses fixed master and develop branches, where master is for bug-fixes and develop is for new features (things that will eventually become evennia 0.8). This is simple but enough for our needs; it also makes it easier to track new from old now that we are actually doing releases.
+Now that Twisted is at a point where this is possible for us to do, we also now have a sort-of plan for finally moving Evennia to Python 3. I won't personally be actively working on it until after 0.8 is out though. I don't expect both Evennia 0.8 and 0.9 (which will be pure py3) to get released this year, but we'll see - so far contributors have done all the work on the conversion.
+At any rate, this coming year will probably be dominated by catching up on issues and edge cases that are lining our Issue tracker. One side effect of more newcomers is more eyes on the code and finding the creaky-bits. At least for me, most of my Evennia-time will be spent resolving bugs and issues. The fun thing is that unlike previous years this is not only up to me anymore - hopefully others will keep helping to resolve issues/bugs to broaden our bandwidth when it comes to keeping Evennia stable. The faster we can handle the backlog of issues the faster we can focus on new shiny features after all.
+Finally, a continued great thank you to those of you contributing to the Patreon. Even small donations have a great encouraging value when working on something as niche as a Python MU* game server in 2018 - thanks a lot!
+ + +
+
+
Evennia
+The Python MU* Development Library
+-
+
+
-
+
+
+
+
+
+ Evennia Dev Blog
+
+
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
+
+
+
+
+ Blackifying and fixing bugs
+ ¶
+ - September 30, 2019
+
+
+Since version 0.9 of Evennia, the MU*-creation framework, was released, work has mainly been focused on bug fixing. But there few new features also already sneaked into master branch, despite technically being changes slated for Evennia 1.0.
+On Frontends
+Contributor friarzen has chipped away at improving Evennia's HTML5 web client. It already had the ability to structure and spawn any number of nested text panes. In the future we want to extend the user's ability to save an restore its layouts and allow developers to offer pre-prepared layouts for their games. Already now though, it has gotten plugins for handling both graphics, sounds and video:
+
+
+Inline image by me (deviantart.com/griatch-art)
+
+A related fun development is Castlelore Studios' development of an Unreal Engine Evennia plugin (this is unaffiliated with core Evennia development and I've not tried it, but it looks pretty nifty!):
+
+
+Image ©Castlelore Studios
+
+On Black
+Evennia's source code is extensively documented and was sort of adhering to the Python formatting standard PEP8. But many places were sort of hit-and-miss and others were formatted with slight variations due to who wrote the code.
+After pre-work and recommendation by Greg Taylor, Evennia has adopted the black autoformatter for its source code. I'm not really convinced that black produces the best output of all possible outputs every time, but as Greg puts it, it's at least consistent in style. We use a line width of 100.
+I have set it up so that whenever a new commit is added to the repo, the black formatter will run on it. It may still produce line widths >100 at times (especially for long strings), but otherwise this reduces the number of different PEP8 infractions in the code a lot.
+On Python3
+Overall the move to Python3 appears to have been pretty uneventful for most users. I've not heard almost any complaints or requests for help with converting an existing game.
+The purely Python2-to-Python3 related bugs have been very limited after launch; almost all have been with unicode/bytes when sending data over the wire.
+People have wholeheartedly adopted the new f-strings though, and some spontaneous PRs have already been made towards converting some of Evennia existing code into using them.
+Post-launch we moved to Django 2.2.2, but the Django 2+ upgrades have been pretty uneventful so far.Some people had issues installing Twisted on Windows since there was no py3.7 binary wheel (causing them to have to compile it from scratch). The rise of the Linux Subsystem on Windows have alleviated most of this though and I've not seen any Windows install issues in a while.
+On Future
+For now we'll stay in bug-fixing mode, with the ocational new feature popping up here and there. In the future we'll move to the develop branch again. I have a slew of things in mind for 1.0.
+Apart from bug fixing and cleaning up the API in several places, I plan to make use of the feedback received over the years to make Evennia a little more accessible for a new user. This means I'll also try reworking and consolidating the tutorials so one can follow them with a more coherent "red thread", as well as improving the documentation in various other ways to help newcomers with the common questions we hear a lot.
+The current project plan (subject to change) is found here. Lots of things to do!
+
+
+
+
+
+
+
+ Evennia 0.9 released
+ ¶
+ - July 4, 2019
+
+
+Last week we released Evennia 0.9, the next version of the open source Python MU* creation system.
+This release is the result of about 10 months of development, featuring 771 commits, 70 closed pull requests from the community and something like 80 issues and feature/requests closed. Thanks everyone!
+The main feature of Evennia 0.9 is that we have finally made the move to Python3. And we burn the bridges behind us; as announced in previous posts we completely drop Python2 support and move exclusively to only support the latest Python3.7.
+Overall the move to Python3 was not too bloody (and much work towards a never published py2+3 version was already done by Evennia contributors in a separate branch earlier). The main issues I ran into were mainly in the changes in how Python3 separates strings from bytes. This became crticial since Evennia implements several connection protocols; there were a lot of edge cases and weird errors appearing where data went to and from the wire.
+A regular user has it a lot easier though. So far people have not had too much trouble converting their games from 2.7 to 3.7. The biggest Linux distros don't all have Py3.7 out of the box though, so that may be a concern for some, we'll see.
+... but Py3 is nowhere all there is to find in this release though! There are a plethora of more features in the latest Evennia, all to make it easier to make the text-based multiplayer game of your dreams.
+You can see a summary of new features in the ML announcement and even more details in the actual CHANGELOG file.
+So what's up next?
+Now follows a period of bug-fixing and stabilizing. Maybe resolve some of those long-standing "tech-dept" issues and overall make Evennia more stable.
+Eventually work will then commence (in the develop branch) on version 1.0 of Evennia. For this next release I think I'll step back from new features a bit and focus on refactoring and cleanup of the API as well as other things around the library's distribution, documentation and presentation.
+But for now, onward to summer vacations.
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 2
+ ¶
+ - May 26, 2019
+
+
+
+
+This is part two of my post-mortem dev-blog about Evscaperoom, the multiplayer, text-based 'escape room' I wrote in Python and Evennia. You can read the first part of the dev blog here.
+This was a game-jam entry I created in a month for the Mud Coder's guild's Game Jam. The theme was One Room. You can play the game for free in your browser or with a traditional MUD client. There are no spoilers in these blog posts.
+Update: These days you can play the Evscaperoom by logging into the Evennia demo game at https://demo.evennia.com. It's just one of the exits you can get through when you enter.
+The first part dealt with the overall game-design aspects. This second, final part will go into details of the code and the systems I built to quickly create all the content. The code referenced here is released under the BSD license and is available on github.
+At the time of this post, players have played Evscaperoom for a little more than a week. At the end I'll share some observations and things I learned along the way.
+Ease of building
+Over the one-month game jam, I spent about four days making the game's 'engine' and toolset with Evennia. The rest of the time was spent using those tools to actually create game content (the story, puzzles etc).
+An important thing was that I didn't want to do any traditional in-game 'building'. That is - no logging into the game and running various commands to build objects and rooms. This is partly because I wanted rooms to be buildable on-demand, but also because I didn't want my game to only exist in the database but in actual version-controllable python modules.
+So all of the Evscaperoom is created in code (notably in the game states discussed below). This made it so that I could add unit tests to quickly find bugs and edge cases. It also made it easy to just clone the full game to an online server, init a database and run Evennia on it in a docker when time came to make it public.
+Overall game structure
+
+Main menu
+The game loop is simple: When you log in to the game, you get into a menu where you can create a new room to solve or join an existing one. Quitting a room brings you back to that menu. Quitting again leaves the game entirely. In between, you remain inside a single game location ('room').
+To make it easier for people to agree to meet up in a room, i made a little 'fantasy name generator' to make unique random names of the rooms. It felt more thematic than showing room id's. The generator combines phonemes together with some very simple logic. Not all comes out easy-to-pronounce, but the result is at least identifiable, like the Sheru and Uyoha above.
+I decided that I should not keep empty rooms around, so whenever a room has no more players in it, it's deleted from the database along with all its content. This means players can't really log off and come back to the same room unless a friend stays behind. I felt it was worth keeping things clean and avoid a growing backlog of empty, unsolved rooms. It is, unfortunately, quite common for players to log in, create a room and then immediately log off.
+I distribute Evscaperoom as an Evennia 'game dir'. Once you've installed Evennia you can just clone the evscaperoom repo and start a new multiplayer server with it. While the game dir has some Evennia templates in it by default, Almost all the custom logic for this game is in the evscaperoom/ folder. The only other modification I did was to make sure Evennia rerouted new players into the Evscaperoom menu when they connect.
+Room class
+Since all of the gameplay happens in a single room, it made sense to center all of the data-storage around a new, custom Evennia Room class. This "EvscapeRoom" class holds all resources for this room. Evennia makes sure to persist it all to the database for you.
+The Evennia API provides a lot of powerful but game-general functions. Since our use-case for this game is very strictly defined, I made a slew of helper functions to cut down on boiler plate and pre-set options I wanted to always use.
+For example, I added helper methods both for creating and finding objects in the room. On creation, all objects are tagged with the room's unique hash, meaning that one can be sure to never have any cross-over between rooms (like accidentally finding the object in another room (that of course has the exact same name). Since I also decided to never have more than one object with a given name per room, I could make these methods very simple.
+The room class also has helpers for finding all players in the room and for sending messages to them. It also catches players leaving so that eventual on-character variables can be cleaned.
+Importantly, the very action of deleting the room will automatically clean all resources tied to it, keeping things tidy.
+Commands and Objects
+
+The help screen, show all top-level commands
+As discussed in part one of this blog, the Evscaperoom, uses a 'focus' mode: The player must examine/focus on an object first in order to operate or use it.
+The basic command syntax is:
+> command [target]
+The parsing I made actually allows for a more complex syntax, but in the end this was all that was really needed, since the currently 'focused' object does not need to be specified. This is the process of using one object with another:
+> examine key
+
+~~ key (examining) ~~
+
+This is a brass key.
+
+
+
+(To unlock something with it, use insert into <target>)
+
+
+> insert into door
+You unlock the **door** with the **key**!
+
+(the into is optional). Here, we focus on the key. We get the key's description and a hint that you can insert it into things. We then insert it into the door, which is another object in the room. The insert command knows that we are focusing on the key already and that it should look into the room for an object door to use this with.
+Technically, these on-object 'actions' (like insert above), are dynamically generated. Here is an example of the key object:
+
+class Key(EvscaperoomObject):
+
+ def at_focus_insert(self, caller, **kwargs):
+
+ target = kwargs['args']
+
+ obj = caller.search(obj)
+
+ if not obj:
+
+ return
+
+ if obj.check_flag("can_use_key"):
+
+ obj.handle_insert(self)
+
+
+Not shown here is that I made a wrapper for the "no-match" command of Evennia. This command fires when no other commands match. I made this instead analyze the currently 'focused' object to see if it had a method at_focus_<command_name> on it. If so, I inject the supplied arguments into that method as a keyword argument args.
+So when you focus on the key and give the insert command, the at_focus_insert method on the key will be called with a target to insert the key into_._ We search for the target (the door in the example), check if it even accepts keys and then pass the key to that object to handle. It would then be up to the door to figure out if this particular key unlocks it.
+I created a library of base objects that I can just use as mixins for the object I want to create. Here's an example:
+
+from evscaperoom import objects
+
+
+
+class Box(objects.Openable,
+
+ objects.CodeInput,
+
+ objects.Movable):
+
+ # ...
+
+
+This class will offer actions to open, insert a code and move the object around. It will need some more configuration and addition of messages to show etc. But overall, this method-to-command solution ended up being very stable and extremely easy to use to make complex, interactive objects.
+Room states
+I think of the escape room as going through a series of states. A change of state could for example be that the user solved a puzzle to open a secret wall. That wall is now open, making new items and puzzles available. This means room description should change along with new objects being created or old ones deleted.
+I chose to represent states as Python modules in a folder. To be a state, each module needs to have a global-level class State inheriting from my new BaseState class. This class has methods for initializing and cleaning up the state, as well as was for figuring out which state to go to next. As the system initializes the new state, it gets the current room as argument, so it can modify it.
+This is a (simplified) example of a state module:
+
+# module `state_001_start.py`
+
+
+
+from evscaperoom.state import BaseState
+
+from evscaperoom import objects
+
+
+
+MUG_DESC = """
+
+A blue mug filled with a swirling liquid.
+
+On it is written "DRINK ME" with big letters.
+
+"""
+
+
+
+class Mug(objects.EvscapeRoomObject):
+
+ def at_focus_drink(self, caller, **kwargs):
+
+ caller.msg(f"You drink {self.key}.")
+
+ self.next_state() # trigger next state
+
+
+
+class State(BaseState):
+
+
+
+ hints = ["You are feeling a little thirsty...",
+
+ "Drink from the mug, dummy."]
+
+
+
+ next_state = "state_002_big_puzzle"
+
+
+
+ def init(self):
+
+ mug = self.create_object(
+
+ Mug, key="wooden mug", aliases=["mug"])
+
+ mug.db.desc = MUG_DESC.strip()
+
+
+In this simple state, a mug is created, and when you drink from it, the next state is triggered. The base object has a helper function to trigger the next state since I found that interactive with an object is almost always the reason for switching states.
+The state-class has a lot of useful properties to set, such as which the next state should be (this can be overridden in case of branching paths). You can also store
+a sequence of hints specific for that state.
+Informing the room
+I wrote the content in second-person perspective ("You open the door"). This is however a multiplayer game and I didn't intially appreciate how many texts must also exist in a third-party form for the rest of the room to see ("Griatch opens the door").
+As the amount of text grew (the Evscaperoom has close to 10 000 lines of code, a lot of which is content strings), it became clear that it would not be feasible to manually supply third-persion version strings as well.
+The solution was to add parsing and translation of pronouns and verbs (a concept I first saw on the game Armageddon).
+I write the string like this:
+
+ OPEN_TEXT = "~You ~open the *door."
+
+
+The ~ marks text that should be parsed for second/third-person use (I'll discuss the *door marking in the next section). This I then send to a helper method that either sends it only to you (which means it comes back pretty much the same, but without the special markers) or to you and to the room, in which it will look different depending on who receives it:
+I see
+You open the [door].
+
+
+
+Others see
+Griatch opens the [door].
+
+English is luckily pretty easy to use for this kind of automatic translation - in general you can just add an "s" to the end of the verb. I made a simple mapping for the few irregular verbs I ended up using.
+Overall, this made it quick to present multiple viewpoints with minimal extra text to write.
+
+
+The option menu
+
+The *door -style marking allowed me to generalize how target-able objects in the room were displayed. This meant that users can customize how objects are shown to them. The default is to mark them both with colors and square brackets (this makes it clear also for people with screen readers). But one can also use only colors or turn off the marking completely (hard mode).
+Bringing it online
+Evennia is both a mud framework and mudserver as well as a webserver based on Twisted. It runs the game's website (with the help of Django) and also provides its own HTML5 webclient. I tweaked the default website text and played a little with CSS but otherwise didn't spend too much time on this bit.
+I got a $5/month DigitalOcean droplet with Ubuntu. I made a new, unprivileged "evennia" user on it and cloned the evscaperoom repo to it. I then started a tmux session and ran the Evennia docker image in there. Getting the game online took maybe thirty minutes, most of which was me figuring out where to open the droplet and DigitalOcean firewalls.
+I then pointed http://experimental.evennia.com at the droplet's IP and that was it!
+Updating the online server is now only a matter of pushing changes to my github repo, pulling it to the server and reloading Evennia; Before release, I used a private github repo for this, afterwards I simply made it public. Pretty straightforward.
+Some lessons learned
+I have gotten pretty positive reviews on Evscaperoom so far. In the first two days people stumbled on some edge-case bugs, but after that it has been very stable. Mostly I've had to make small typos and grammar corrections as I (or players) spot them.
+There were nevertheless some things I learned, some of which led to more real improvements post-launch.
+No amount of help is too much help
+
+
+The header shows how to get out of focus mode
+
+Firstly, the focus-system (examine, then do stuff) is a little un-orthodox and needs to be explained. I saw people logging in, examining exactly one thing and then logging out. Eventually I found out (because a user told me), that this was likely because they could not figure out how to leave the focus mode. They'd just flounder about, think the game was buggy and log off.
+The answer (just run examine again) is found with the help command, but clearly this was not intuitive. The solution was to add an explicit help text to the top every time you examine something. After this, the confusion seems to have gone away.
+Make it easy to connect for all tastes
+Another example - a commenting user had pretty strong opinions about the fact that you used to have to supply a username and password to play the game. They suggested this was a 'huge hurdle'. Not sure if that's true. But unless you want to use a particular name, there is also no actual gameplay reason to formally authenticate for Evscaperoom.
+This was easy to fix. Evennia has guest-player support out of the box so I just activated that and supplied some more fantasy-sounding names than the default "Guest 1", "Guest 2" etc. Since then, maybe 40% of players connecting have chosen to do so as an anonymous guest. I don't know if those would have left completely if the option was not available, but it's at least a convenient shortcut for getting into the game.
+Everything takes longer than expected
+I already knew this one, but still I fell into the trap of thinking that things were going well and that there would be plenty of time to finish before deadline.
+Creating text content is a lot faster than creating graphical assets, but it's still a lot of work. Just the ending 'cinematics' took me almost two days to finish and clean up at the end.
+For once I did pick a reasonable scale for this project though. So while the last few days of the Jam was more intense than I would have liked, I never truly felt like I would not be able to finish in time.
+Building a MU* game in pure code is awesome
+Evennia tries to not instil and specific game type, hence its tools are very general. Wrapping these general tools as a highly opinionated and game-specific toolbox enforced to me just how easy it is to do things when you don't need to cover the general case.
+Using the tools and creating content purely in-code was great and ended up leading to a very fast content creation. Python works perfectly as a scripting language and I don't think there is a reason for using in-game building at all for your game, especially not when you are working on your own like this.
+I made a few admin-only commands to jump between states and to set flags, but otherwise most bugs were caught by a generic unit test that just looped over all founds states and tried to initialize them, one after another.
+Conclusions
+For all my work on the Evennia library/server, I've not actually used it for games of my own very much. This was a great opportunity for doing so. It also gave me the opportunity to test the Python3-development branch of Evennia in a production setting.
+I found a few edge-case library bugs which I fixed, but overall things worked very smoothly, also for this kind of game which is certainly far away from the normal MU*-mold that most use Evennia for. I am a bit biased, but overall I felt Evennia to be very mature for the use of making a game from scratch.
+In the future I will most likely break out the 'engine' and tools of the Evscaperoom into an Evennia contrib so that others can make similar games with it easily.
+Looking forward to future game jams now!
+
+
+
+
+
+
+
+ Creating Evscaperoom Part 1
+ ¶
+ - May 18, 2019
+
+
+Over the last month (April-May 2019) I have taken part in the Mud Coder's Guild Game Jam "Enter the (Multi-User) Dungeon". This year the theme for the jam was One Room.
+The result was Evscaperoom, an text-based multi-player "escape-room" written in Python using the Evennia MU* creation system. You can play it from that link in your browser or MU*-client of choice. If you are so inclined, you can also vote for it here in the jam (well, no more).
+This little series of (likely two) dev-blog entries will try to recount the planning and technical aspects of the Evscaperoom. This is also for myself - I'd better write stuff down now while it's still fresh in my mind!
+Update: The Evscaperoom can these days be played by connecting to the Evennia game demo at https://demo.evennia.com.
+Inception
+When I first heard about the upcoming game-jam's theme of One Room, an 'escape room' was the first thing that came to mind, not the least because I just recently got to solve my my own first real-world escape-room as a gift on my birthday.
+If you are not familiar with escape-rooms, the premise is simple - you are locked into a room and have to figure out a way to get out of it by solving practical puzzles and finding hidden clues in the room.
+While you could create such a thing in your own bedroom (and there are also some one-use board game variants), most escape-rooms are managed by companies selling this as an experience for small groups. You usually have one hour to escape and if you get stuck you can press a button (or similar) to get a hint.
+I thought making a computer escape-room. Not only can you do things in the computer that you cannot do in the real world, restricting the game to a single room limits so that it's conceivable to actually finish the damned thing in a month.
+A concern I had was that everyone else in the jam surely must have went for the same obvious idea. In the end that was not an issue at all though.
+Basic premises
+I was pretty confident that I would technically be able to create the game in time (not only is Python and Evennia perfect for this kind of fast experimentation and prototyping, I know the engine very well). But that's not enough; I had to first decide on how the thing should actually play. Here are the questions I had to consider:
+Room State
+An escape room can be seen as going through multiple states as puzzles are solved. For example, you may open a cabinet and that may open up new puzzles to solve. This is fine in a single-player game, but how to handle it in a multi-player environment?
+My first thought was that each object may have multiple states and that players could co-exist in the same room, seeing different states at the same time. I really started planning for this. It would certainly be possible to implement.
+But in the end I considered how a real-world escape-room works - people in the same room solves it together. For there to be any meaning with multi-player, they must share the room state.
+So what I went with was a solution where players can create their own room or join an existing one. Each such room is generated on the fly (and filled with objects etc) and will change as players solve it. Once complete and/or everyone leaves, the room is deleted along with all objects in it. Clean and tidy.
+So how to describe these states? I pictured that these would be described as normal Python modules with a start- and end function that initialized each state and cleaned it up when a new state was started. In the beginning I pictured these states as being pretty small (like one state to change one thing in the room). In the end though, the entire Evscaperoom fits in 12 state modules. I'll describe them in more detail in the second part of this post.
+Accessibility and "pixel-hunting" in text
+When I first started writing descriptions I didn't always note which objects where interactive. It's a very simple and tempting puzzle to add - mention an object as part of a larger description and let the player figure out that it's something they can interact with. This practice is sort-of equivalent to pixel-hunting in graphical games - sweeping with the mouse across the screen until you find that little spot on the screen that you can do something with.
+Problem is, pixel-hunting's not really fun. You easily get stuck and when you eventually find out what was blocking you, you don't really feel clever but only frustrated. So I decided that I should clearly mark every object that people could interact with and focus puzzles on better things.
+In fact, in the end I made it an option:
+
+As part of this I had to remind myself never to use colors only when marking important information: Visually impaired people with screen readers will simply miss that. Not to mention that some just disable colors in their clients.
+So while I personally think option 2 above is the most visually pleasing, Evscaperoom defaults to the third option. It should should start everyone off on equal footing. Evennia has a screen-reader mode out of the box, but I moved it into the menu here for easy access.
+Inventory and collaboration
+In a puzzle-game, you often find objects and combine them with other things. Again, this is simple to do in a single-player game: Players just pick things up and use them later.
+But in a multi-player game this offers a huge risk: players that pick up something important and then log off. The remaining players in that room would then be stuck in an unsolvable room - and it would be very hard for them to know this.
+In principle you could try to 'clean' player inventories when they leave, but not only does it add complexity, there is another issue with players picking things up: It means that the person first to find/pick up the item is the only one that can use it and look at it. Others won't have access until the first player gives it up. Trusting that to anonymous players online is not a good idea.
+So in the end I arrived at the following conclusions:
+
+
+As a side-effect of this I also set a limit to the kind of puzzles I would allow:
+
+
+Focusing on objects
+So without inventory system, how do you interact with objects? A trademark of any puzzle is using one object with another and also to explore things closer to find clues. I turned to graphical adventure games for inspiration:
+
+Secret of Monkey Island ©1990 LucasArts. Image from old-games.com
+A common way to operate on an object in traditional adventure games is to hover the mouse over it and then select the action you want to apply to it. In later (3D) games you might even zoom in of the object and rotate it around with your mouse to see if there are some clues to be had.
+While Evennia and modern UI clients may allow you to use the mouse to select objects, I wanted this to work the traditional MUD-way, by inserting commands. So I decided that you as a player would be in one of two states:
+
+
+
+In the example above, the fireplace points out other objects you could also focus on, whereas the last parenthesis includes one or more "actions" that you can perform on the fireplace only when you have it focused.
+This ends up pretty different from most traditional MUD-style inputs. When I first released this to the public, I found people logged off after their first examine. It turned out that they couldn't figure out how to leave the focus mode. So they just assumed the thing was buggy and quit instead. Of course it's mentioned if you care to write help, but this is clearly one step too many for such an important UI concept.
+So I ended up adding the header above that always reminds you. And since then I've not seen any confusion over how the focus mode works.
+For making it easy to focus on things, I also decided that each room would only ever have one object named a particular thing. So there is for example only one single object in the game named "key" that you can focus on.
+Communication
+I wanted players to co-exist in the same room so that they could collaborate on solving it. This meant communication must be possible. I pictured people would want to point things out and talk to each other.
+In my first round of revisions I had a truckload of individual emotes; you could
+point at target
+for example. In the end I just limited it to
+say/shout/whisper
+and
+emote
+And seeing what people actually use, this is more than enough (say alone is probably 99% of what people need, really). I had a notion that the shout/whisper could be used in a puzzle later but in the end I decided that communication commands should be strictly between players and not have anything to do with the puzzles.
+I removed all other interaction: There is no fighting and without an inventory or requirement to collaborate on puzzles, there is no need for other interactions than to communicate.
+First version you didn't even see what the others did, but eventually I added so that you at least saw what other players were focusing on at the moment (and of course if some major thing was solved/found).
+In the end I don't even list characters as objects in the room (you have to use the who command to see who's in there with you).
+
+The main help command output.
+Story
+It's very common for this type of game to have a dangerous or scary theme. Things like "get out before the bomb explodes", "save the space ship before the engines overheat", "flee the axe murderer before he comes back" etc). I'm no stranger to dark themes, but for this I wanted something friendlier and brighter, maybe with a some dark undercurrents here and there.
+My Jester character is someone I've not only depicted in art, but she's also an old RP character and literary protagonist of mine. Who else would find it funny to lock someone into a room only to provide crazy puzzles and hints for them to get out again? So my flimsy 'premise' was this:
+The village Jester wants to win the pie eating contest. You are one of her most dangerous opponents. She tricked you to her cabin and now you are locked in! If you don't get out in time, she'll get to eat all those pies on her own and surely win!
+That's it - this became the premise from which the entire game flowed. I quickly decided that it to be a very "small-scale" story: no life-or-death situation, no saving of the world. The drama takes place in a small village with an "adversary" that doesn't really want to hurt you, but only to eat more pies than you.
+From this, the way to offer hints came naturally - just eat a slice of "hintberry pie" the jester made (she even encourage you to eat it). It gives you a hint but is also very filling. So if you eat too much, how will you beat her in the contest later, even if you do get out?
+To further the rustic and friendly tone I made sure the story took place on a warm summer day. Many descriptions describe sunshine, chirping birds and the smell of pie. I aimed at letting the text point out quirky and slightly comedic tone of the puzzles the Jester left behind. The player also sometimes gets teased by the game when doing things that does not make sense.
+I won't go into the story further here - it's best if you experience it yourself. Let's just say that the village has some old secrets. And and the Jester has her own ways of doing things and of telling a story. The game has multiple endings and so far people have drawn very different conclusions in the end.
+Scoring
+Most often in escape rooms, final score is determined by the time and the number of hints used. I do keep the latter - for every pie you eat, you get a penalty on your final score.
+As for time - this background story would fit very well with a time limit (get out in X time, after which the pie-eating contest will start!). But from experience with other online text-based games I decided against this. Not only should a player be able to take a break, they may also want to wait for a friend to leave and come back etc.
+But more importantly, I want players to explore and read all my carefully crafted descriptions! So I'd much rather prefer they take their time and reward them for being thorough.
+So in the end I give specific scores for actions throughout the game instead. Most points are for doing things that drive the story forward, such as using something or solving a puzzle. But a significant portion of the score comes from turning every stone and trying everything out. The nice side-effect of this is that even if you know exactly how to solve everything and rush through the game you will still not end up with a perfect score.
+The final score, adjusted by hints is then used to determine if you make it in time to the contest and how you fare. This means that if you explore carefully you have a "buffer" of points so eating a few pies may still land you a good result in the end.
+First sketch
+I really entered the game 'building' aspect with no real notion of how the Jester's cabin should look nor which puzzles should be in it. I tried to write things down beforehand but it didn't really work for me.
+So in the end I decided "let's just put a lot of interesting stuff in the room and then I'll figure out how they interact with each other". I'm sure this is different from game-maker to game-maker. But for me, this process worked perfectly.
+
+
+My first, very rough, sketch of the Jester's cabin
+
+The above, first sketch ended up being what I used, although many of the objects mentioned never ended up in the final game and some things switched places. I did some other sketches too, but they'd be spoilers so I won't show them here ...
+The actual game logic
+The Evscaperoom principles outlined above deviate quite a bit from the traditional MU* style of game play.
+While Evennia provides everything for database management, in-game objects, commands, networking and other resources, the specifics of your game is something you need to make yourself - and you have the full power of Python to do it!
+So for the first three days of the jam I used Evennia to build the custom game logic needed to provide the evscaperoom style of game play. I also made the tools I needed to quickly create the game content (which then took me the rest of the jam to make).
+In part 2 of this blog post I will cover the technical details of the Evscaperoom I built. I'll also go through some issues I ran into and conclusions I drew. I'll link to that from here when it's available!
+
+
+
+
+
+
+
+ Podcast about Evennia
+ ¶
+ - May 9, 2019
+
+
+I was interviewed on the (pretty grandiosely named) podcast Titans of Text the other day.
+In the interview, which are run by people from the MUD Coder's Guild (a great initiative!), I talk a bit about the history of Evennia, the text-based multiplayer game engine I'm working on, and go into some various technical aspects of the engine as well. Check it out and support the podcast!
+
+
+
+
+
+
+
+
+ Steaming on Eating Jam
+ ¶
+ - April 25, 2019
+
+
+In the last few months, development of the upcoming Evennia 0.9 has been steaming on. Evennia is, as you may know, a Python library for creating text-based multiplayer games (MUDs, MUSH etc).
+But it's not all backend work! There is also some sweet game-jamming going on, I get to that at the end.
+Evennia progress towards Python3
+The regular Evennia develop branch is now running completely in Python 3. Since we are using some new features of this Python release, we will be aiming for Python 3.7 as a minimum version once Evennia 0.9 goes stable. We will also use Django 2.1 and likely Twisted 19 - so we'll be pretty much up-to-date on all our main dependencies.
+Now, while the release of Evennia 0.9 is still some time away (there are a bunch of regular bug fixes and minor features that I want to get in there too (see the progress here on the github 0.9 project page), it's worth to consider how much work it'll be for you to migrate and if you should wait or jump in right now.
+If you are new, I still recommend you use regular master branch Evennia (using Python 2.7). This is for which all wiki articles and documentation online is currently written after all. Once we move to python3, you'll need to convert your code ... but syntactically the two are really not that different and conversion should not be much of an issue.
+Not only are there automatic converters for most stuff, you should only need to do one pass to make sure things work and then you'll be done. This article is pretty old but it serves well to identify the main differences. Later Py3 versions just adds new stuff which you would just not have had access to in Python2.7. Once 0.9 is released, we'll also make guides for how you go about converting existing code (apart from the wealth of info on this topic online).
+That said, if you are feeling more adventurous, or really want to use Python3 right away, many of the Evennia developer regulars have been running and testing develop branch for months now. It's overall been a pretty painless transition - as said, py3 is not that different from py2.
+However, develop branch has other features beyond the py3 jump. And those are not yet documented in the main docs. So you'll have to contend with that (but asking in chat/forum works of course). However while it works fine for development already, as a matter of principle I do not recommend ever using Evennia's develop branch for a production game - it can change quickly and may occationally be broken. You have been warned!
+Game Jam
+We are now a little more than a week into the Mud Coders Guild's second yearly Game Jam. This year's theme is "One Room".
+I really hope some more Evennia devs jump on this one because Evennia is perfect for this kind of experimental games. This is because Evennia is not imposing a game style on you - while there are default commands you are free to replace or customize the commands, objects and every aspect of your game to be as specific as you want to your game.
+For example, I have a small Game Jam contribution in the works, where I very quickly reworked the default Evennia setup to pretty much make it into a different genre of game.
+Usually the systems I make for Evennia are generic and intended for any game-type. By contrast, making somehing highly niched is super-fast to do: Building a whole new framework for game mechanisms along with build helpers for me to quickly make content took no more than three days.
+There will no doubt be some iteration, but I hope to spend the rest of the jam time on content and gameplay. I have some RL things happening in the coming weeks (including work on Evennia proper) but if I can get the time to tie my jam entry together, I'll likely make one or two blog posts about how it was developed and my reasons for making the choices i did. Most likely the code will appear as an Evennia contribution in case people want to do something similar for their own projects.
+So, busy days.
+
+
+
+
+
+
+
+ Into 2019
+ ¶
+ - January 2, 2019
+
+
+A new year has come around and it's time to both look back at the old and onward to the future of Evennia, the Python MUD creation system!
+Last year
+
+Last year saw the release of Evennia 0.8. This version of Evennia changes some fundamental aspects of the server infrastructure so that the server can truly run in daemon mode as you would expect (no more running it in a GnuScreen session if you want to see logging to the terminal). It also adds the new Online Creation System, which lets builders create and define prototypes using a menu system as well as big improvements in the web client, such as multiple window-panes (allows the user to assign text to different windows to keep their client uncluttered) as well as plenty of fixes and features to help ease life for the Evennia developer. Thanks again to everyone who helped out and contributed to the release of Evennia 0.8!
+On a personal note, I spoke about Evennia at PyCon Sweden this December, which was fun. I might put up my talk and make a more detailed blog post about that in the future, but my talk got a surprising amount of attention and positive feedback. Clearly many people have fond memories of MUDs and enjoy seeing they are not only still around but are possible to create in Python!
+This year
+
+Now we are steaming ahead towards Evennia 0.9! Already we have had a large number of contributions towards this release. A coming change is a much improved central way to make typeclass information available to a website as well as central ways to do various common operations like creating characters and linking them to Accounts. Much of this functionality is today hidden in the various default commands. In Evennia 0.9 they will be moved into more easily-findable locations as library functions everyone can just trigger without having to copy functionality.
+The biggest change for Evennia 0.9 is however that we will now finally move Evennia over to Python 3. This is now possible as all our dependencies are now sufficiently ported. As discussed in the community for a long time, this will be a clean break - we will not offer any mid-way solution of Python2/3 but will drop Python2 support entirely. We will at the same time move to Django 2.+. In Django 0.9 we will however probably not use any special Python3 features yet. It should hopefully not be too difficult for our users to upgrade, but we'll of course publish extensive instructions and help when that time comes.
+We will likely support a minimum of Python 3.6 and maybe 3.7. This work is currently happening in a separate branch develop-py3 which will soonish merge into the current Python2.7-based develop branch and become Evennia 0.9 when it merges into master branch at an unknown time later this year.
+There are a slew of other things planned for Evennia 0.9 and you can follow the progress from our project page. If you want to help out you are of course also very welcome. If you are new and are interested in getting your feet wet in helping out with Open-source development, we have a list of good first issues you could jump into.
+Onward into the new year!
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/devblog/html/devblog2020.html b/devblog/html/devblog2020.html
index 22398fec04..19761fd282 100644
--- a/devblog/html/devblog2020.html
+++ b/devblog/html/devblog2020.html
@@ -35,23 +35,35 @@
-
+
+ Random Evennia- and MUD-related musings of Griatch, the Evennia lead developer.
+
-
- Initial-Blog
- ¶
- - May 2, 2020
+
+ Evennia 0.9.5 released
+ ¶
+ - November 14, 2020
-A way to do things
-
This is a test blog page for using markdown to write
-Evennia devblog posts.
-Starting out
-I'm experimenting with a new section of the docs containing these
-blog posts (obviously the blogs are CC anyway).
+
+As of today, Evennia 0.9.5 is out. Evennia is a Python based library and framework for creating text-based multiplayer games (MUD/MU*).
+This is a gradual improvement halfway between 0.9 and the upcoming 1.0. So if you have been keeping up-to-date with the master branch of Evennia over the last year you will not notice much difference from this release (time to upgrade if you haven't been keeping up though!).
+While an interim release, there are still a lot of things that has happened since v0.9:
+Webclient improvements
+
+
+EvMenu improvements
+EvMenu is a powerful system for creating in-game text menus.
+
+
+New settings
+
+
+Other improvements
+
+
+See the changelog here.
+New documentation system
+The bigger change with 0.9.5 is that we are moving to a new documentation system. The details of the long road to do this is documented in my previous post. The point is that we are stopping the use of the Github wiki in favor of statically generated documentation hosted on github pages. At the same time we also move the old evennia.com website from Google-sites to Github.
+Check it out:
+
+
+As for the docs, they will be maturing for a long time still. The old wiki will not be updated anymore, but it will also not be going anywhere in the short term. Version 0.9.5 of the docs is pretty much a copy of the wiki and I hope to not have to spend too much more work maintaining it since the wiki is still around.
+New updates and documentation features will primarily be happening in the 1.0-dev version of the documentation. This will include refactoring all pages as well as a new intro-tutorial and many other things.
+But that's for future blogs ...
+
+
+
+ On using Markdown with Sphinx
+ ¶
+ - October 20, 2020
+
+
+Last post I wrote about the upcoming v1.0 of Evennia, the Python MU* creation engine. We are not getting to that 1.0 version quite yet though: The next release will be 0.9.5, hopefully out relatively soon (TM).
+Evennia 0.9.5 is, as you may guess, an intermediary release. Apart from the 1.0 roadmap just not being done yet, there is one other big reason for this - we are introducing documentation versioning and for that a proper release is needed as a base to start from. Version 0.9.5 contains everything already in master branch, so if you have kept up-to-date you won't notice too much difference. Here are some highlights compared to version 0.9:
+
+
+Many contributors helped out along the way. See the changelog where contributors of the bigger new features are listed.
+The path to a new documentation
+For many years we've used the Github wiki as our documentation hub. It has served us well. But as mentioned in my previous post, it has its drawbacks, in particular when it comes to handling documentation for multiple Evennia versions in parallel.
+After considering a bunch of options, I eventually went with sphinx, because it has such a good autodoc functionality (parsing of the source-code docstrings). This is despite our wiki docs are all in markdown and I dislike restructured text quite a bit. Our code also uses friendly and in-code-readable Google-style docstrings instead of Sphinx' hideous and unreadable format.
+Luckily there are extensions for Sphinx to handle this:
+
+
+What could go wrong? Well, it's been quite a ride.
+Getting Markdown into reST
+Linking to things in recommonmark turned out to be very flaky. I ended up forking and merging a bunch of PRs from the project but that was not enough: Clearly this thing was not built to convert 200 pages of technical markdown from a github wiki.
+My custom fork of recommonmark had to be tweaked a bit for my needs, such as not having to specify the .md file ending in every link and make sure the url-resolver worked as I expected. There were a bunch of other things but I will probably not merge this back, the changes are pretty Evennia-specific.
+Even so, many of my wiki links just wouldn't work. This is not necessarily recommonmark's fault, but how sphinx works by grouping things into toctrees, something that the Evennia wiki doesn't have.
+Also, the recommonmark way to make a toctree in Markdown is to make a list of links - you can't have any descriptive text, making the listing quite useless (apparently people only want bland lists of link-names?). After trying to figure out a way to make this work I eventually capitulated - I make pretty lists in Markdown while using a "hidden" toctree to inform sphinx how the pages are related.
+Getting the wiki into the new doc site
+This required more custom code. I wrote a custom importer that reads the wiki and cleans/reformats it in places where recommonmark just dies on them. I also made a preprocessor that not only finds orphan pages but also builds a toctree and remaps all links in all documents to their actual location on compilation. The remapper makes it a lot easier to move things around. The drawback is that every page needs to be uniquely named. Since this was already the case in the wiki, this was a good tradeoff. So with a lot of custom code the wiki eventually could port automatically.
+The thing is, that even with all this processing, recommonmark doesn't support stuff like Markdown tables, so you still have to fall back to reST notation for those. And Napoleon, while doing a good job of parsing google docstrings, do not expect Markdown. So the end result is mostly markdown but we still have to fall back to reST for some things. It's probably as far as we get.
+Deploying the docs
+Figuring out how to build and deploy these components together was the next challenge. Sphinx' default Makefile was quite anemic and I also wanted something that regular contributors could use to test their documentation contributions easily. I ended up having to expand the Makefile quite a lot while also adding separate deploy scripts and interfaces to github actions (which we recently started using too).
+Finally, the versioning. The sphinx-multiversion plugin works by extracting the branches you choose from git and running the sphinx compiler in each branch. The plugin initially had a bug with how our docs are located (not at the root of the package) but after I reported it, it was quickly fixed. The result is a static document site where you can select between the available versions in the sidebar.
+I've not gotten down to trying to make LaTeX/PDF generation work yet. I'm dreading it quite a bit...
+Where we are
+The github wiki is now closed for external contributions. The v0.9.5 of the new documentation will pretty much be an import of the last state of the wiki with some minor cleanup (such as tables). While we'll fix outright errors in it, I don't plan to do many fixes of purely visual glitches from the conversion - the old wiki is still there should that be a problem.
+The main refactoring and cleanup of the documentation to fit its new home will instead happen in v1.0. While the rough structure of this is already in place, it's very much a work in progress at this point.
+Conclusions
+Evennia 0.9.5 has a lot of features, but the biggest things are 'meta' changes in the project itself. After it is out, it's onward towards 1.0 again!
+
+
+
+
+
+
+
+ Spring updates while trying to stay healthy
+ ¶
+ - April 14, 2020
+
+
+So, spring grows nearer for those of us on the Northern hemisphere. With everyone hopefully hunkered down and safe from the Covid-19 pandemic, I thought it overdue to make another dev blog for the progress of Evennia, the Python MU*-creation system.
+The last few months have seen primarily bug fixing on the Evennia front, but it also has seen an uptick of PRs from the community and the re-opening of the develop branch in earnest. There is still quite a lot of work to do before we can add that extra 0.1 and go from version 0.9 to 1.0.
+What's in a version?
+For me personally, I never put much stock in the notion of versions. Evennia didn't even have versions until a few years back: We used to just have a rolling git release. But eventually it became clear that our user base was big enough that we needed to more clearly separate major (and possibly breaking) updates from what came before. So I started versioning at Evennia 0.5 and have had roughly a new release every year since (not a plan or a promise, it just happened to turn out that way).
+Evennia has been useful (and been used) for game development for many years already. But there is no denying that a 1.x label tends to convey more confidence in a system than a 0.x label, that's just the way things are. So while the new version is still quite some way off, there are a bunch of changes and improvements that we want to do in this release to mark the version change in a good way.
+Documentation changes
+Our documentation will move away from our trusty Github wiki. Instead we will convert the wiki into a static github page built from sources inside evennia/docs/.
+The advantage of the wiki is that it is a very low entry for people to contribute and fix things using Github's editing system. We have had a lot of use of this over the years and the wiki has served us well. The drawbacks are starting to get ever more noticeable, however:
+
+
+The change so far planned is to switch to the Sphinx documentation build-system (same as Python/Django etc is using). We will use it with extensions that allows us to still use Markdown like in the old wiki. This also allows us to build a more comprehensive (and pretty) API documentation of the entire library. We have more options to add comprehensive online search functionality in this solution as well.
+Furthermore, will hopefully be able to set it up so that we can maintain and publish separate documentations for each forthcoming release. That is, you should be able to read the docs for 1.0, 1.1 or the latest master development as you like (similarly to how Django does it, although probably not as fancy from the onset).
+This means that contributions to the documentation will be done as PRs through GitHub, just like when contributing any other code. While this does add a little more of a hurdle to contributions, hopefully the benefits will far outweigh those. Building the docs locally will not require a running Evennia server (unless you want the api docs) and we will try to set everything up for to make it easy to contribute.
+Many of the details around the docs are still up in the air. This is still very much work-in-progress, like everything else.
+Work with this has started in the static-file-docs branch of Evennia. But we have not closed the wiki either - the two will exist in parallel for now.
+PyPi
+As mentioned before, we will finally start to distribute Evennia via PyPi (the Python Package Index) - that is, you will be able to run pip install evennia. Using GIT will no longer be a requirement to get started.
+Considering how quickly people in open-source throw up their three lines of code on PyPi these days, it may be surprising Evennia is not already on PyPi. I have however felt that reading and referencing the highly-commented code is a big part and requirement for getting the most out of the library.
+With the new documentation system, this would improve. And you can of course still use git and follow master branch like the good ol' days if you want!
+Web Admin improvements
+For the longest time, the Django-admin component has been somewhat on the back-burner. With the help of community contributors, this is improving so you will be able to do more work the Admin GUI related to creating and managing objects, tie puppets to Accounts etc.
+API improvements
+Whereas the last few months have been mostly spent fixing lingering bugs, one thing planned for version 1.0 is a general cleanup of legacy strangeness in the API. For example, certain methods can return a list or a single object depending situation, which makes it hard to generalize. There are a lot of small quirks like that which we hope to address and make more consistent.
+There has also been a recent flurry of contributor PRs intended to help decouple Evennia's systems and make them easier to replace for those inclined to do so. Many of this is still being worked on, but it's likely you'll be able to replace many more "core" components for 1.0 with your own variations without doing any hacking in upstream code at all.
+... Needless to say, this is an advanced feature that most developers will never need. But Evennia was always intended to be heavily customizable and having the option is a good thing!
+Another feature that will come for 1.0 is a REST-API, added by one of our contributors. This uses Django-REST-Framework and makes it easier for external programs to authenticate and fetch data out of the Evennia database (great both for external apps, websites or custom what-have-you).
+At this time you can only fetch database objects via this interface, you cannot perform Command-calls or "play the game" this way (REST is a stateless concept and Evennia Commands tend to retain state).
+Many other fixes and contributions
+There's a truckload of stuff already available in master branch, but with the latest contributions of bigger code changes, we have started to use the Evennia develop branch again in earnest again. For a summary of the changes so far, check out the Changelog.
+However, unless you want to contribute to Evennia itself (or really, really want to be on the bleeding edge), you are still recommended to use the master branch for now. A lot of work still to do, as said.
+
+
+
+
+ Blackifying and fixing bugs
+ ¶
+ - September 30, 2019
+
+
Since version 0.9 of Evennia, the MU*-creation framework, was released, work has mainly been focused on bug fixing. But there few new features also already sneaked into master branch, despite technically being changes slated for Evennia 1.0.
+On Frontends
+Contributor friarzen has chipped away at improving Evennia's HTML5 web client. It already had the ability to structure and spawn any number of nested text panes. In the future we want to extend the user's ability to save an restore its layouts and allow developers to offer pre-prepared layouts for their games. Already now though, it has gotten plugins for handling both graphics, sounds and video:
+
++Inline image by me (deviantart.com/griatch-art)
+
A related fun development is Castlelore Studios' development of an Unreal Engine Evennia plugin (this is unaffiliated with core Evennia development and I've not tried it, but it looks pretty nifty!):
+
++Image ©Castlelore Studios
+
On Black
+Evennia's source code is extensively documented and was sort of adhering to the Python formatting standard PEP8. But many places were sort of hit-and-miss and others were formatted with slight variations due to who wrote the code.
+After pre-work and recommendation by Greg Taylor, Evennia has adopted the black autoformatter for its source code. I'm not really convinced that black produces the best output of all possible outputs every time, but as Greg puts it, it's at least consistent in style. We use a line width of 100.
+I have set it up so that whenever a new commit is added to the repo, the black formatter will run on it. It may still produce line widths >100 at times (especially for long strings), but otherwise this reduces the number of different PEP8 infractions in the code a lot.
+On Python3
+Overall the move to Python3 appears to have been pretty uneventful for most users. I've not heard almost any complaints or requests for help with converting an existing game.
+The purely Python2-to-Python3 related bugs have been very limited after launch; almost all have been with unicode/bytes when sending data over the wire.
+People have wholeheartedly adopted the new f-strings though, and some spontaneous PRs have already been made towards converting some of Evennia existing code into using them.
+Post-launch we moved to Django 2.2.2, but the Django 2+ upgrades have been pretty uneventful so far.Some people had issues installing Twisted on Windows since there was no py3.7 binary wheel (causing them to have to compile it from scratch). The rise of the Linux Subsystem on Windows have alleviated most of this though and I've not seen any Windows install issues in a while.
+On Future
+For now we'll stay in bug-fixing mode, with the ocational new feature popping up here and there. In the future we'll move to the develop branch again. I have a slew of things in mind for 1.0.
+Apart from bug fixing and cleaning up the API in several places, I plan to make use of the feedback received over the years to make Evennia a little more accessible for a new user. This means I'll also try reworking and consolidating the tutorials so one can follow them with a more coherent "red thread", as well as improving the documentation in various other ways to help newcomers with the common questions we hear a lot.
+The current project plan (subject to change) is found here. Lots of things to do!
+ + ++
+ Evennia 0.9 released
+ ¶
+ - July 4, 2019
+
+
Last week we released Evennia 0.9, the next version of the open source Python MU* creation system.
+This release is the result of about 10 months of development, featuring 771 commits, 70 closed pull requests from the community and something like 80 issues and feature/requests closed. Thanks everyone!
+The main feature of Evennia 0.9 is that we have finally made the move to Python3. And we burn the bridges behind us; as announced in previous posts we completely drop Python2 support and move exclusively to only support the latest Python3.7.
+Overall the move to Python3 was not too bloody (and much work towards a never published py2+3 version was already done by Evennia contributors in a separate branch earlier). The main issues I ran into were mainly in the changes in how Python3 separates strings from bytes. This became crticial since Evennia implements several connection protocols; there were a lot of edge cases and weird errors appearing where data went to and from the wire.
+A regular user has it a lot easier though. So far people have not had too much trouble converting their games from 2.7 to 3.7. The biggest Linux distros don't all have Py3.7 out of the box though, so that may be a concern for some, we'll see.
+... but Py3 is nowhere all there is to find in this release though! There are a plethora of more features in the latest Evennia, all to make it easier to make the text-based multiplayer game of your dreams.
+You can see a summary of new features in the ML announcement and even more details in the actual CHANGELOG file.
+So what's up next?
+Now follows a period of bug-fixing and stabilizing. Maybe resolve some of those long-standing "tech-dept" issues and overall make Evennia more stable.
+Eventually work will then commence (in the develop branch) on version 1.0 of Evennia. For this next release I think I'll step back from new features a bit and focus on refactoring and cleanup of the API as well as other things around the library's distribution, documentation and presentation.
+But for now, onward to summer vacations.
+ + ++
+ Creating Evscaperoom Part 2
+ ¶
+ - May 26, 2019
+
+
This is part two of my post-mortem dev-blog about Evscaperoom, the multiplayer, text-based 'escape room' I wrote in Python and Evennia. You can read the first part of the dev blog here.
+This was a game-jam entry I created in a month for the Mud Coder's guild's Game Jam. The theme was One Room. You can play the game for free in your browser or with a traditional MUD client. There are no spoilers in these blog posts.
+Update: These days you can play the Evscaperoom by logging into the Evennia demo game at https://demo.evennia.com. It's just one of the exits you can get through when you enter.
+The first part dealt with the overall game-design aspects. This second, final part will go into details of the code and the systems I built to quickly create all the content. The code referenced here is released under the BSD license and is available on github.
+At the time of this post, players have played Evscaperoom for a little more than a week. At the end I'll share some observations and things I learned along the way.
+Ease of building
+Over the one-month game jam, I spent about four days making the game's 'engine' and toolset with Evennia. The rest of the time was spent using those tools to actually create game content (the story, puzzles etc).
+An important thing was that I didn't want to do any traditional in-game 'building'. That is - no logging into the game and running various commands to build objects and rooms. This is partly because I wanted rooms to be buildable on-demand, but also because I didn't want my game to only exist in the database but in actual version-controllable python modules.
+So all of the Evscaperoom is created in code (notably in the game states discussed below). This made it so that I could add unit tests to quickly find bugs and edge cases. It also made it easy to just clone the full game to an online server, init a database and run Evennia on it in a docker when time came to make it public.
+Overall game structure
+
Main menu
+The game loop is simple: When you log in to the game, you get into a menu where you can create a new room to solve or join an existing one. Quitting a room brings you back to that menu. Quitting again leaves the game entirely. In between, you remain inside a single game location ('room').
+To make it easier for people to agree to meet up in a room, i made a little 'fantasy name generator' to make unique random names of the rooms. It felt more thematic than showing room id's. The generator combines phonemes together with some very simple logic. Not all comes out easy-to-pronounce, but the result is at least identifiable, like the Sheru and Uyoha above.
+I decided that I should not keep empty rooms around, so whenever a room has no more players in it, it's deleted from the database along with all its content. This means players can't really log off and come back to the same room unless a friend stays behind. I felt it was worth keeping things clean and avoid a growing backlog of empty, unsolved rooms. It is, unfortunately, quite common for players to log in, create a room and then immediately log off.
+I distribute Evscaperoom as an Evennia 'game dir'. Once you've installed Evennia you can just clone the evscaperoom repo and start a new multiplayer server with it. While the game dir has some Evennia templates in it by default, Almost all the custom logic for this game is in the evscaperoom/ folder. The only other modification I did was to make sure Evennia rerouted new players into the Evscaperoom menu when they connect.
+Room class
+Since all of the gameplay happens in a single room, it made sense to center all of the data-storage around a new, custom Evennia Room class. This "EvscapeRoom" class holds all resources for this room. Evennia makes sure to persist it all to the database for you.
+The Evennia API provides a lot of powerful but game-general functions. Since our use-case for this game is very strictly defined, I made a slew of helper functions to cut down on boiler plate and pre-set options I wanted to always use.
+For example, I added helper methods both for creating and finding objects in the room. On creation, all objects are tagged with the room's unique hash, meaning that one can be sure to never have any cross-over between rooms (like accidentally finding the object in another room (that of course has the exact same name). Since I also decided to never have more than one object with a given name per room, I could make these methods very simple.
+The room class also has helpers for finding all players in the room and for sending messages to them. It also catches players leaving so that eventual on-character variables can be cleaned.
+Importantly, the very action of deleting the room will automatically clean all resources tied to it, keeping things tidy.
+Commands and Objects
+
The help screen, show all top-level commands
+As discussed in part one of this blog, the Evscaperoom, uses a 'focus' mode: The player must examine/focus on an object first in order to operate or use it.
+The basic command syntax is:
+> command [target]
+The parsing I made actually allows for a more complex syntax, but in the end this was all that was really needed, since the currently 'focused' object does not need to be specified. This is the process of using one object with another:
+> examine key
+
+~~ key (examining) ~~
+
+This is a brass key.
+
+
+
+(To unlock something with it, use insert into <target>)
+
+> insert into door
+You unlock the **door** with the **key**!
+(the into is optional). Here, we focus on the key. We get the key's description and a hint that you can insert it into things. We then insert it into the door, which is another object in the room. The insert command knows that we are focusing on the key already and that it should look into the room for an object door to use this with.
+Technically, these on-object 'actions' (like insert above), are dynamically generated. Here is an example of the key object:
+
+class Key(EvscaperoomObject):
+
+ def at_focus_insert(self, caller, **kwargs):
+
+ target = kwargs['args']
+
+ obj = caller.search(obj)
+
+ if not obj:
+
+ return
+
+ if obj.check_flag("can_use_key"):
+
+ obj.handle_insert(self)
+
+Not shown here is that I made a wrapper for the "no-match" command of Evennia. This command fires when no other commands match. I made this instead analyze the currently 'focused' object to see if it had a method at_focus_<command_name> on it. If so, I inject the supplied arguments into that method as a keyword argument args.
+So when you focus on the key and give the insert command, the at_focus_insert method on the key will be called with a target to insert the key into_._ We search for the target (the door in the example), check if it even accepts keys and then pass the key to that object to handle. It would then be up to the door to figure out if this particular key unlocks it.
+I created a library of base objects that I can just use as mixins for the object I want to create. Here's an example:
+
+from evscaperoom import objects
+
+
+
+class Box(objects.Openable,
+
+ objects.CodeInput,
+
+ objects.Movable):
+
+ # ...
+
+This class will offer actions to open, insert a code and move the object around. It will need some more configuration and addition of messages to show etc. But overall, this method-to-command solution ended up being very stable and extremely easy to use to make complex, interactive objects.
+Room states
+I think of the escape room as going through a series of states. A change of state could for example be that the user solved a puzzle to open a secret wall. That wall is now open, making new items and puzzles available. This means room description should change along with new objects being created or old ones deleted.
+I chose to represent states as Python modules in a folder. To be a state, each module needs to have a global-level class State inheriting from my new BaseState class. This class has methods for initializing and cleaning up the state, as well as was for figuring out which state to go to next. As the system initializes the new state, it gets the current room as argument, so it can modify it.
+This is a (simplified) example of a state module:
+
+# module `state_001_start.py`
+
+
+
+from evscaperoom.state import BaseState
+
+from evscaperoom import objects
+
+
+
+MUG_DESC = """
+
+A blue mug filled with a swirling liquid.
+
+On it is written "DRINK ME" with big letters.
+
+"""
+
+
+
+class Mug(objects.EvscapeRoomObject):
+
+ def at_focus_drink(self, caller, **kwargs):
+
+ caller.msg(f"You drink {self.key}.")
+
+ self.next_state() # trigger next state
+
+
+
+class State(BaseState):
+
+
+
+ hints = ["You are feeling a little thirsty...",
+
+ "Drink from the mug, dummy."]
+
+
+
+ next_state = "state_002_big_puzzle"
+
+
+
+ def init(self):
+
+ mug = self.create_object(
+
+ Mug, key="wooden mug", aliases=["mug"])
+
+ mug.db.desc = MUG_DESC.strip()
+
+In this simple state, a mug is created, and when you drink from it, the next state is triggered. The base object has a helper function to trigger the next state since I found that interactive with an object is almost always the reason for switching states.
+The state-class has a lot of useful properties to set, such as which the next state should be (this can be overridden in case of branching paths). You can also store
+a sequence of hints specific for that state.
+Informing the room
+I wrote the content in second-person perspective ("You open the door"). This is however a multiplayer game and I didn't intially appreciate how many texts must also exist in a third-party form for the rest of the room to see ("Griatch opens the door").
+As the amount of text grew (the Evscaperoom has close to 10 000 lines of code, a lot of which is content strings), it became clear that it would not be feasible to manually supply third-persion version strings as well.
+The solution was to add parsing and translation of pronouns and verbs (a concept I first saw on the game Armageddon).
+I write the string like this:
+
+ OPEN_TEXT = "~You ~open the *door."
+
+The ~ marks text that should be parsed for second/third-person use (I'll discuss the *door marking in the next section). This I then send to a helper method that either sends it only to you (which means it comes back pretty much the same, but without the special markers) or to you and to the room, in which it will look different depending on who receives it:
+I see
+You open the [door].
+
+
+Others see
+Griatch opens the [door].
+English is luckily pretty easy to use for this kind of automatic translation - in general you can just add an "s" to the end of the verb. I made a simple mapping for the few irregular verbs I ended up using.
+Overall, this made it quick to present multiple viewpoints with minimal extra text to write.
+
++The option menu
+
The *door -style marking allowed me to generalize how target-able objects in the room were displayed. This meant that users can customize how objects are shown to them. The default is to mark them both with colors and square brackets (this makes it clear also for people with screen readers). But one can also use only colors or turn off the marking completely (hard mode).
+Bringing it online
+Evennia is both a mud framework and mudserver as well as a webserver based on Twisted. It runs the game's website (with the help of Django) and also provides its own HTML5 webclient. I tweaked the default website text and played a little with CSS but otherwise didn't spend too much time on this bit.
+I got a $5/month DigitalOcean droplet with Ubuntu. I made a new, unprivileged "evennia" user on it and cloned the evscaperoom repo to it. I then started a tmux session and ran the Evennia docker image in there. Getting the game online took maybe thirty minutes, most of which was me figuring out where to open the droplet and DigitalOcean firewalls.
+I then pointed http://experimental.evennia.com at the droplet's IP and that was it!
+Updating the online server is now only a matter of pushing changes to my github repo, pulling it to the server and reloading Evennia; Before release, I used a private github repo for this, afterwards I simply made it public. Pretty straightforward.
+Some lessons learned
+I have gotten pretty positive reviews on Evscaperoom so far. In the first two days people stumbled on some edge-case bugs, but after that it has been very stable. Mostly I've had to make small typos and grammar corrections as I (or players) spot them.
+There were nevertheless some things I learned, some of which led to more real improvements post-launch.
+No amount of help is too much help
+
++The header shows how to get out of focus mode
+
Firstly, the focus-system (examine, then do stuff) is a little un-orthodox and needs to be explained. I saw people logging in, examining exactly one thing and then logging out. Eventually I found out (because a user told me), that this was likely because they could not figure out how to leave the focus mode. They'd just flounder about, think the game was buggy and log off.
+The answer (just run examine again) is found with the help command, but clearly this was not intuitive. The solution was to add an explicit help text to the top every time you examine something. After this, the confusion seems to have gone away.
+Make it easy to connect for all tastes
+Another example - a commenting user had pretty strong opinions about the fact that you used to have to supply a username and password to play the game. They suggested this was a 'huge hurdle'. Not sure if that's true. But unless you want to use a particular name, there is also no actual gameplay reason to formally authenticate for Evscaperoom.
+This was easy to fix. Evennia has guest-player support out of the box so I just activated that and supplied some more fantasy-sounding names than the default "Guest 1", "Guest 2" etc. Since then, maybe 40% of players connecting have chosen to do so as an anonymous guest. I don't know if those would have left completely if the option was not available, but it's at least a convenient shortcut for getting into the game.
+Everything takes longer than expected
+I already knew this one, but still I fell into the trap of thinking that things were going well and that there would be plenty of time to finish before deadline.
+Creating text content is a lot faster than creating graphical assets, but it's still a lot of work. Just the ending 'cinematics' took me almost two days to finish and clean up at the end.
+For once I did pick a reasonable scale for this project though. So while the last few days of the Jam was more intense than I would have liked, I never truly felt like I would not be able to finish in time.
+Building a MU* game in pure code is awesome
+Evennia tries to not instil and specific game type, hence its tools are very general. Wrapping these general tools as a highly opinionated and game-specific toolbox enforced to me just how easy it is to do things when you don't need to cover the general case.
+Using the tools and creating content purely in-code was great and ended up leading to a very fast content creation. Python works perfectly as a scripting language and I don't think there is a reason for using in-game building at all for your game, especially not when you are working on your own like this.
+I made a few admin-only commands to jump between states and to set flags, but otherwise most bugs were caught by a generic unit test that just looped over all founds states and tried to initialize them, one after another.
+Conclusions
+For all my work on the Evennia library/server, I've not actually used it for games of my own very much. This was a great opportunity for doing so. It also gave me the opportunity to test the Python3-development branch of Evennia in a production setting.
+I found a few edge-case library bugs which I fixed, but overall things worked very smoothly, also for this kind of game which is certainly far away from the normal MU*-mold that most use Evennia for. I am a bit biased, but overall I felt Evennia to be very mature for the use of making a game from scratch.
+In the future I will most likely break out the 'engine' and tools of the Evscaperoom into an Evennia contrib so that others can make similar games with it easily.
+Looking forward to future game jams now!
+ + ++
+ Creating Evscaperoom Part 1
+ ¶
+ - May 18, 2019
+
+
Over the last month (April-May 2019) I have taken part in the Mud Coder's Guild Game Jam "Enter the (Multi-User) Dungeon". This year the theme for the jam was One Room.
+The result was Evscaperoom, an text-based multi-player "escape-room" written in Python using the Evennia MU* creation system. You can play it from that link in your browser or MU*-client of choice. If you are so inclined, you can also vote for it here in the jam (well, no more).
+This little series of (likely two) dev-blog entries will try to recount the planning and technical aspects of the Evscaperoom. This is also for myself - I'd better write stuff down now while it's still fresh in my mind!
+Update: The Evscaperoom can these days be played by connecting to the Evennia game demo at https://demo.evennia.com.
+Inception
+When I first heard about the upcoming game-jam's theme of One Room, an 'escape room' was the first thing that came to mind, not the least because I just recently got to solve my my own first real-world escape-room as a gift on my birthday.
+If you are not familiar with escape-rooms, the premise is simple - you are locked into a room and have to figure out a way to get out of it by solving practical puzzles and finding hidden clues in the room.
+While you could create such a thing in your own bedroom (and there are also some one-use board game variants), most escape-rooms are managed by companies selling this as an experience for small groups. You usually have one hour to escape and if you get stuck you can press a button (or similar) to get a hint.
+I thought making a computer escape-room. Not only can you do things in the computer that you cannot do in the real world, restricting the game to a single room limits so that it's conceivable to actually finish the damned thing in a month.
+A concern I had was that everyone else in the jam surely must have went for the same obvious idea. In the end that was not an issue at all though.
+Basic premises
+I was pretty confident that I would technically be able to create the game in time (not only is Python and Evennia perfect for this kind of fast experimentation and prototyping, I know the engine very well). But that's not enough; I had to first decide on how the thing should actually play. Here are the questions I had to consider:
+Room State
+An escape room can be seen as going through multiple states as puzzles are solved. For example, you may open a cabinet and that may open up new puzzles to solve. This is fine in a single-player game, but how to handle it in a multi-player environment?
+My first thought was that each object may have multiple states and that players could co-exist in the same room, seeing different states at the same time. I really started planning for this. It would certainly be possible to implement.
+But in the end I considered how a real-world escape-room works - people in the same room solves it together. For there to be any meaning with multi-player, they must share the room state.
+So what I went with was a solution where players can create their own room or join an existing one. Each such room is generated on the fly (and filled with objects etc) and will change as players solve it. Once complete and/or everyone leaves, the room is deleted along with all objects in it. Clean and tidy.
+So how to describe these states? I pictured that these would be described as normal Python modules with a start- and end function that initialized each state and cleaned it up when a new state was started. In the beginning I pictured these states as being pretty small (like one state to change one thing in the room). In the end though, the entire Evscaperoom fits in 12 state modules. I'll describe them in more detail in the second part of this post.
+Accessibility and "pixel-hunting" in text
+When I first started writing descriptions I didn't always note which objects where interactive. It's a very simple and tempting puzzle to add - mention an object as part of a larger description and let the player figure out that it's something they can interact with. This practice is sort-of equivalent to pixel-hunting in graphical games - sweeping with the mouse across the screen until you find that little spot on the screen that you can do something with.
+Problem is, pixel-hunting's not really fun. You easily get stuck and when you eventually find out what was blocking you, you don't really feel clever but only frustrated. So I decided that I should clearly mark every object that people could interact with and focus puzzles on better things.
+In fact, in the end I made it an option:
+![Option menu ('quit' to return) 1: ( ) No item markings (hard mode) 2: ( ) Items marked as item (with color) 3: (*) Items are marked as [item] (screenreader friendly) 4: ( ) Screenreader mode](https://3.bp.blogspot.com/-HdLAfVl8P5A/XOAWjd_zoDI/AAAAAAAAKek/GBrnsZDvck0rkeBW2WVLZHXNG6ePqKEjgCEwYBhgL/s1600/Screenshot%2Bfrom%2B2019-05-17%2B11-49-20.png "In-game option menu")
As part of this I had to remind myself never to use colors only when marking important information: Visually impaired people with screen readers will simply miss that. Not to mention that some just disable colors in their clients.
+So while I personally think option 2 above is the most visually pleasing, Evscaperoom defaults to the third option. It should should start everyone off on equal footing. Evennia has a screen-reader mode out of the box, but I moved it into the menu here for easy access.
+Inventory and collaboration
+In a puzzle-game, you often find objects and combine them with other things. Again, this is simple to do in a single-player game: Players just pick things up and use them later.
+But in a multi-player game this offers a huge risk: players that pick up something important and then log off. The remaining players in that room would then be stuck in an unsolvable room - and it would be very hard for them to know this.
+In principle you could try to 'clean' player inventories when they leave, but not only does it add complexity, there is another issue with players picking things up: It means that the person first to find/pick up the item is the only one that can use it and look at it. Others won't have access until the first player gives it up. Trusting that to anonymous players online is not a good idea.
+So in the end I arrived at the following conclusions:
+-
+
As a side-effect of this I also set a limit to the kind of puzzles I would allow:
+-
+
Focusing on objects
+So without inventory system, how do you interact with objects? A trademark of any puzzle is using one object with another and also to explore things closer to find clues. I turned to graphical adventure games for inspiration:
+
Secret of Monkey Island ©1990 LucasArts. Image from old-games.com
+A common way to operate on an object in traditional adventure games is to hover the mouse over it and then select the action you want to apply to it. In later (3D) games you might even zoom in of the object and rotate it around with your mouse to see if there are some clues to be had.
+While Evennia and modern UI clients may allow you to use the mouse to select objects, I wanted this to work the traditional MUD-way, by inserting commands. So I decided that you as a player would be in one of two states:
+-
+
![A small stone fireplace sits in the middle of the wall opposite the [door]. On the chimney hangs a small oil [painting] of a man. Hanging over the hearth is a black [cauldron]. The piles of [ashes] below are cold. (It looks like fireplace may be suitable to [climb].)](https://2.bp.blogspot.com/-E-J-PZZ2KbY/XOAWidK1Y_I/AAAAAAAAKek/mcWbgVNkvVkBBZEUpOuaaWyBVkNoE7K9gCEwYBhgL/s1600/Screenshot%2Bfrom%2B2019-05-17%2B11-41-50.png "Examining a fireplace")
In the example above, the fireplace points out other objects you could also focus on, whereas the last parenthesis includes one or more "actions" that you can perform on the fireplace only when you have it focused.
+This ends up pretty different from most traditional MUD-style inputs. When I first released this to the public, I found people logged off after their first examine. It turned out that they couldn't figure out how to leave the focus mode. So they just assumed the thing was buggy and quit instead. Of course it's mentioned if you care to write help, but this is clearly one step too many for such an important UI concept.
+So I ended up adding the header above that always reminds you. And since then I've not seen any confusion over how the focus mode works.
+For making it easy to focus on things, I also decided that each room would only ever have one object named a particular thing. So there is for example only one single object in the game named "key" that you can focus on.
+Communication
+I wanted players to co-exist in the same room so that they could collaborate on solving it. This meant communication must be possible. I pictured people would want to point things out and talk to each other.
+In my first round of revisions I had a truckload of individual emotes; you could
+point at target
+for example. In the end I just limited it to
+say/shout/whisper
and
+emote
And seeing what people actually use, this is more than enough (say alone is probably 99% of what people need, really). I had a notion that the shout/whisper could be used in a puzzle later but in the end I decided that communication commands should be strictly between players and not have anything to do with the puzzles.
+I removed all other interaction: There is no fighting and without an inventory or requirement to collaborate on puzzles, there is no need for other interactions than to communicate.
+First version you didn't even see what the others did, but eventually I added so that you at least saw what other players were focusing on at the moment (and of course if some major thing was solved/found).
+In the end I don't even list characters as objects in the room (you have to use the who command to see who's in there with you).
+
The main help command output.
+Story
+It's very common for this type of game to have a dangerous or scary theme. Things like "get out before the bomb explodes", "save the space ship before the engines overheat", "flee the axe murderer before he comes back" etc). I'm no stranger to dark themes, but for this I wanted something friendlier and brighter, maybe with a some dark undercurrents here and there.
+My Jester character is someone I've not only depicted in art, but she's also an old RP character and literary protagonist of mine. Who else would find it funny to lock someone into a room only to provide crazy puzzles and hints for them to get out again? So my flimsy 'premise' was this:
+The village Jester wants to win the pie eating contest. You are one of her most dangerous opponents. She tricked you to her cabin and now you are locked in! If you don't get out in time, she'll get to eat all those pies on her own and surely win!
+That's it - this became the premise from which the entire game flowed. I quickly decided that it to be a very "small-scale" story: no life-or-death situation, no saving of the world. The drama takes place in a small village with an "adversary" that doesn't really want to hurt you, but only to eat more pies than you.
+From this, the way to offer hints came naturally - just eat a slice of "hintberry pie" the jester made (she even encourage you to eat it). It gives you a hint but is also very filling. So if you eat too much, how will you beat her in the contest later, even if you do get out?
+To further the rustic and friendly tone I made sure the story took place on a warm summer day. Many descriptions describe sunshine, chirping birds and the smell of pie. I aimed at letting the text point out quirky and slightly comedic tone of the puzzles the Jester left behind. The player also sometimes gets teased by the game when doing things that does not make sense.
+I won't go into the story further here - it's best if you experience it yourself. Let's just say that the village has some old secrets. And and the Jester has her own ways of doing things and of telling a story. The game has multiple endings and so far people have drawn very different conclusions in the end.
+Scoring
+Most often in escape rooms, final score is determined by the time and the number of hints used. I do keep the latter - for every pie you eat, you get a penalty on your final score.
+As for time - this background story would fit very well with a time limit (get out in X time, after which the pie-eating contest will start!). But from experience with other online text-based games I decided against this. Not only should a player be able to take a break, they may also want to wait for a friend to leave and come back etc.
+But more importantly, I want players to explore and read all my carefully crafted descriptions! So I'd much rather prefer they take their time and reward them for being thorough.
+So in the end I give specific scores for actions throughout the game instead. Most points are for doing things that drive the story forward, such as using something or solving a puzzle. But a significant portion of the score comes from turning every stone and trying everything out. The nice side-effect of this is that even if you know exactly how to solve everything and rush through the game you will still not end up with a perfect score.
+The final score, adjusted by hints is then used to determine if you make it in time to the contest and how you fare. This means that if you explore carefully you have a "buffer" of points so eating a few pies may still land you a good result in the end.
+First sketch
+I really entered the game 'building' aspect with no real notion of how the Jester's cabin should look nor which puzzles should be in it. I tried to write things down beforehand but it didn't really work for me.
+So in the end I decided "let's just put a lot of interesting stuff in the room and then I'll figure out how they interact with each other". I'm sure this is different from game-maker to game-maker. But for me, this process worked perfectly.
+
++My first, very rough, sketch of the Jester's cabin
+
The above, first sketch ended up being what I used, although many of the objects mentioned never ended up in the final game and some things switched places. I did some other sketches too, but they'd be spoilers so I won't show them here ...
+The actual game logic
+The Evscaperoom principles outlined above deviate quite a bit from the traditional MU* style of game play.
+While Evennia provides everything for database management, in-game objects, commands, networking and other resources, the specifics of your game is something you need to make yourself - and you have the full power of Python to do it!
+So for the first three days of the jam I used Evennia to build the custom game logic needed to provide the evscaperoom style of game play. I also made the tools I needed to quickly create the game content (which then took me the rest of the jam to make).
+In part 2 of this blog post I will cover the technical details of the Evscaperoom I built. I'll also go through some issues I ran into and conclusions I drew. I'll link to that from here when it's available!
+ + ++
+ Podcast about Evennia
+ ¶
+ - May 9, 2019
+
+
I was interviewed on the (pretty grandiosely named) podcast Titans of Text the other day.
+In the interview, which are run by people from the MUD Coder's Guild (a great initiative!), I talk a bit about the history of Evennia, the text-based multiplayer game engine I'm working on, and go into some various technical aspects of the engine as well. Check it out and support the podcast!
+ + + ++
+ Steaming on Eating Jam
+ ¶
+ - April 25, 2019
+
+
In the last few months, development of the upcoming Evennia 0.9 has been steaming on. Evennia is, as you may know, a Python library for creating text-based multiplayer games (MUDs, MUSH etc).
+But it's not all backend work! There is also some sweet game-jamming going on, I get to that at the end.
+Evennia progress towards Python3
+The regular Evennia develop branch is now running completely in Python 3. Since we are using some new features of this Python release, we will be aiming for Python 3.7 as a minimum version once Evennia 0.9 goes stable. We will also use Django 2.1 and likely Twisted 19 - so we'll be pretty much up-to-date on all our main dependencies.
+Now, while the release of Evennia 0.9 is still some time away (there are a bunch of regular bug fixes and minor features that I want to get in there too (see the progress here on the github 0.9 project page), it's worth to consider how much work it'll be for you to migrate and if you should wait or jump in right now.
+If you are new, I still recommend you use regular master branch Evennia (using Python 2.7). This is for which all wiki articles and documentation online is currently written after all. Once we move to python3, you'll need to convert your code ... but syntactically the two are really not that different and conversion should not be much of an issue.
+Not only are there automatic converters for most stuff, you should only need to do one pass to make sure things work and then you'll be done. This article is pretty old but it serves well to identify the main differences. Later Py3 versions just adds new stuff which you would just not have had access to in Python2.7. Once 0.9 is released, we'll also make guides for how you go about converting existing code (apart from the wealth of info on this topic online).
+That said, if you are feeling more adventurous, or really want to use Python3 right away, many of the Evennia developer regulars have been running and testing develop branch for months now. It's overall been a pretty painless transition - as said, py3 is not that different from py2.
+However, develop branch has other features beyond the py3 jump. And those are not yet documented in the main docs. So you'll have to contend with that (but asking in chat/forum works of course). However while it works fine for development already, as a matter of principle I do not recommend ever using Evennia's develop branch for a production game - it can change quickly and may occationally be broken. You have been warned!
+Game Jam
+We are now a little more than a week into the Mud Coders Guild's second yearly Game Jam. This year's theme is "One Room".
+I really hope some more Evennia devs jump on this one because Evennia is perfect for this kind of experimental games. This is because Evennia is not imposing a game style on you - while there are default commands you are free to replace or customize the commands, objects and every aspect of your game to be as specific as you want to your game.
+For example, I have a small Game Jam contribution in the works, where I very quickly reworked the default Evennia setup to pretty much make it into a different genre of game.
+Usually the systems I make for Evennia are generic and intended for any game-type. By contrast, making somehing highly niched is super-fast to do: Building a whole new framework for game mechanisms along with build helpers for me to quickly make content took no more than three days.
+There will no doubt be some iteration, but I hope to spend the rest of the jam time on content and gameplay. I have some RL things happening in the coming weeks (including work on Evennia proper) but if I can get the time to tie my jam entry together, I'll likely make one or two blog posts about how it was developed and my reasons for making the choices i did. Most likely the code will appear as an Evennia contribution in case people want to do something similar for their own projects.
+So, busy days.
+ + ++
+ Into 2019
+ ¶
+ - January 2, 2019
+
+
A new year has come around and it's time to both look back at the old and onward to the future of Evennia, the Python MUD creation system!
+Last year
+
Last year saw the release of Evennia 0.8. This version of Evennia changes some fundamental aspects of the server infrastructure so that the server can truly run in daemon mode as you would expect (no more running it in a GnuScreen session if you want to see logging to the terminal). It also adds the new Online Creation System, which lets builders create and define prototypes using a menu system as well as big improvements in the web client, such as multiple window-panes (allows the user to assign text to different windows to keep their client uncluttered) as well as plenty of fixes and features to help ease life for the Evennia developer. Thanks again to everyone who helped out and contributed to the release of Evennia 0.8!
+On a personal note, I spoke about Evennia at PyCon Sweden this December, which was fun. I might put up my talk and make a more detailed blog post about that in the future, but my talk got a surprising amount of attention and positive feedback. Clearly many people have fond memories of MUDs and enjoy seeing they are not only still around but are possible to create in Python!
+This year
+
Now we are steaming ahead towards Evennia 0.9! Already we have had a large number of contributions towards this release. A coming change is a much improved central way to make typeclass information available to a website as well as central ways to do various common operations like creating characters and linking them to Accounts. Much of this functionality is today hidden in the various default commands. In Evennia 0.9 they will be moved into more easily-findable locations as library functions everyone can just trigger without having to copy functionality.
+The biggest change for Evennia 0.9 is however that we will now finally move Evennia over to Python 3. This is now possible as all our dependencies are now sufficiently ported. As discussed in the community for a long time, this will be a clean break - we will not offer any mid-way solution of Python2/3 but will drop Python2 support entirely. We will at the same time move to Django 2.+. In Django 0.9 we will however probably not use any special Python3 features yet. It should hopefully not be too difficult for our users to upgrade, but we'll of course publish extensive instructions and help when that time comes.
+We will likely support a minimum of Python 3.6 and maybe 3.7. This work is currently happening in a separate branch develop-py3 which will soonish merge into the current Python2.7-based develop branch and become Evennia 0.9 when it merges into master branch at an unknown time later this year.
+There are a slew of other things planned for Evennia 0.9 and you can follow the progress from our project page. If you want to help out you are of course also very welcome. If you are new and are interested in getting your feet wet in helping out with Open-source development, we have a list of good first issues you could jump into.
+Onward into the new year!
+ + +-
-
- Initial-Blog
- ¶
- - May 2, 2020
+
+ Evennia 0.9.5 released
+ ¶
+ - November 14, 2020
-A way to do things
-
This is a test blog page for using markdown to write
-Evennia devblog posts.
-Starting out
-I'm experimenting with a new section of the docs containing these
-blog posts (obviously the blogs are CC anyway).
+
As of today, Evennia 0.9.5 is out. Evennia is a Python based library and framework for creating text-based multiplayer games (MUD/MU*).
+This is a gradual improvement halfway between 0.9 and the upcoming 1.0. So if you have been keeping up-to-date with the master branch of Evennia over the last year you will not notice much difference from this release (time to upgrade if you haven't been keeping up though!).
+While an interim release, there are still a lot of things that has happened since v0.9:
+Webclient improvements
+-
+
EvMenu improvements
+EvMenu is a powerful system for creating in-game text menus.
+-
+
New settings
+-
+
Other improvements
+-
+
See the changelog here.
+New documentation system
+The bigger change with 0.9.5 is that we are moving to a new documentation system. The details of the long road to do this is documented in my previous post. The point is that we are stopping the use of the Github wiki in favor of statically generated documentation hosted on github pages. At the same time we also move the old evennia.com website from Google-sites to Github.
+Check it out:
+-
+
As for the docs, they will be maturing for a long time still. The old wiki will not be updated anymore, but it will also not be going anywhere in the short term. Version 0.9.5 of the docs is pretty much a copy of the wiki and I hope to not have to spend too much more work maintaining it since the wiki is still around.
+New updates and documentation features will primarily be happening in the 1.0-dev version of the documentation. This will include refactoring all pages as well as a new intro-tutorial and many other things.
+But that's for future blogs ...
+
+ On using Markdown with Sphinx
+ ¶
+ - October 20, 2020
+
+
Last post I wrote about the upcoming v1.0 of Evennia, the Python MU* creation engine. We are not getting to that 1.0 version quite yet though: The next release will be 0.9.5, hopefully out relatively soon (TM).
+Evennia 0.9.5 is, as you may guess, an intermediary release. Apart from the 1.0 roadmap just not being done yet, there is one other big reason for this - we are introducing documentation versioning and for that a proper release is needed as a base to start from. Version 0.9.5 contains everything already in master branch, so if you have kept up-to-date you won't notice too much difference. Here are some highlights compared to version 0.9:
+-
+
Many contributors helped out along the way. See the changelog where contributors of the bigger new features are listed.
+The path to a new documentation
+For many years we've used the Github wiki as our documentation hub. It has served us well. But as mentioned in my previous post, it has its drawbacks, in particular when it comes to handling documentation for multiple Evennia versions in parallel.
+After considering a bunch of options, I eventually went with sphinx, because it has such a good autodoc functionality (parsing of the source-code docstrings). This is despite our wiki docs are all in markdown and I dislike restructured text quite a bit. Our code also uses friendly and in-code-readable Google-style docstrings instead of Sphinx' hideous and unreadable format.
+Luckily there are extensions for Sphinx to handle this:
+-
+
What could go wrong? Well, it's been quite a ride.
+Getting Markdown into reST
+Linking to things in recommonmark turned out to be very flaky. I ended up forking and merging a bunch of PRs from the project but that was not enough: Clearly this thing was not built to convert 200 pages of technical markdown from a github wiki.
+My custom fork of recommonmark had to be tweaked a bit for my needs, such as not having to specify the .md file ending in every link and make sure the url-resolver worked as I expected. There were a bunch of other things but I will probably not merge this back, the changes are pretty Evennia-specific.
+Even so, many of my wiki links just wouldn't work. This is not necessarily recommonmark's fault, but how sphinx works by grouping things into toctrees, something that the Evennia wiki doesn't have.
+Also, the recommonmark way to make a toctree in Markdown is to make a list of links - you can't have any descriptive text, making the listing quite useless (apparently people only want bland lists of link-names?). After trying to figure out a way to make this work I eventually capitulated - I make pretty lists in Markdown while using a "hidden" toctree to inform sphinx how the pages are related.
+Getting the wiki into the new doc site
+This required more custom code. I wrote a custom importer that reads the wiki and cleans/reformats it in places where recommonmark just dies on them. I also made a preprocessor that not only finds orphan pages but also builds a toctree and remaps all links in all documents to their actual location on compilation. The remapper makes it a lot easier to move things around. The drawback is that every page needs to be uniquely named. Since this was already the case in the wiki, this was a good tradeoff. So with a lot of custom code the wiki eventually could port automatically.
+The thing is, that even with all this processing, recommonmark doesn't support stuff like Markdown tables, so you still have to fall back to reST notation for those. And Napoleon, while doing a good job of parsing google docstrings, do not expect Markdown. So the end result is mostly markdown but we still have to fall back to reST for some things. It's probably as far as we get.
+Deploying the docs
+Figuring out how to build and deploy these components together was the next challenge. Sphinx' default Makefile was quite anemic and I also wanted something that regular contributors could use to test their documentation contributions easily. I ended up having to expand the Makefile quite a lot while also adding separate deploy scripts and interfaces to github actions (which we recently started using too).
+Finally, the versioning. The sphinx-multiversion plugin works by extracting the branches you choose from git and running the sphinx compiler in each branch. The plugin initially had a bug with how our docs are located (not at the root of the package) but after I reported it, it was quickly fixed. The result is a static document site where you can select between the available versions in the sidebar.
+I've not gotten down to trying to make LaTeX/PDF generation work yet. I'm dreading it quite a bit...
+Where we are
+The github wiki is now closed for external contributions. The v0.9.5 of the new documentation will pretty much be an import of the last state of the wiki with some minor cleanup (such as tables). While we'll fix outright errors in it, I don't plan to do many fixes of purely visual glitches from the conversion - the old wiki is still there should that be a problem.
+The main refactoring and cleanup of the documentation to fit its new home will instead happen in v1.0. While the rough structure of this is already in place, it's very much a work in progress at this point.
+Conclusions
+Evennia 0.9.5 has a lot of features, but the biggest things are 'meta' changes in the project itself. After it is out, it's onward towards 1.0 again!
+ + ++
+ Spring updates while trying to stay healthy
+ ¶
+ - April 14, 2020
+
+
So, spring grows nearer for those of us on the Northern hemisphere. With everyone hopefully hunkered down and safe from the Covid-19 pandemic, I thought it overdue to make another dev blog for the progress of Evennia, the Python MU*-creation system.
+The last few months have seen primarily bug fixing on the Evennia front, but it also has seen an uptick of PRs from the community and the re-opening of the develop branch in earnest. There is still quite a lot of work to do before we can add that extra 0.1 and go from version 0.9 to 1.0.
+What's in a version?
+For me personally, I never put much stock in the notion of versions. Evennia didn't even have versions until a few years back: We used to just have a rolling git release. But eventually it became clear that our user base was big enough that we needed to more clearly separate major (and possibly breaking) updates from what came before. So I started versioning at Evennia 0.5 and have had roughly a new release every year since (not a plan or a promise, it just happened to turn out that way).
+Evennia has been useful (and been used) for game development for many years already. But there is no denying that a 1.x label tends to convey more confidence in a system than a 0.x label, that's just the way things are. So while the new version is still quite some way off, there are a bunch of changes and improvements that we want to do in this release to mark the version change in a good way.
+Documentation changes
+Our documentation will move away from our trusty Github wiki. Instead we will convert the wiki into a static github page built from sources inside evennia/docs/.
+The advantage of the wiki is that it is a very low entry for people to contribute and fix things using Github's editing system. We have had a lot of use of this over the years and the wiki has served us well. The drawbacks are starting to get ever more noticeable, however:
+-
+
The change so far planned is to switch to the Sphinx documentation build-system (same as Python/Django etc is using). We will use it with extensions that allows us to still use Markdown like in the old wiki. This also allows us to build a more comprehensive (and pretty) API documentation of the entire library. We have more options to add comprehensive online search functionality in this solution as well.
+Furthermore, will hopefully be able to set it up so that we can maintain and publish separate documentations for each forthcoming release. That is, you should be able to read the docs for 1.0, 1.1 or the latest master development as you like (similarly to how Django does it, although probably not as fancy from the onset).
+This means that contributions to the documentation will be done as PRs through GitHub, just like when contributing any other code. While this does add a little more of a hurdle to contributions, hopefully the benefits will far outweigh those. Building the docs locally will not require a running Evennia server (unless you want the api docs) and we will try to set everything up for to make it easy to contribute.
+Many of the details around the docs are still up in the air. This is still very much work-in-progress, like everything else.
+Work with this has started in the static-file-docs branch of Evennia. But we have not closed the wiki either - the two will exist in parallel for now.
+PyPi
+As mentioned before, we will finally start to distribute Evennia via PyPi (the Python Package Index) - that is, you will be able to run pip install evennia. Using GIT will no longer be a requirement to get started.
Considering how quickly people in open-source throw up their three lines of code on PyPi these days, it may be surprising Evennia is not already on PyPi. I have however felt that reading and referencing the highly-commented code is a big part and requirement for getting the most out of the library.
+With the new documentation system, this would improve. And you can of course still use git and follow master branch like the good ol' days if you want!
+Web Admin improvements
+For the longest time, the Django-admin component has been somewhat on the back-burner. With the help of community contributors, this is improving so you will be able to do more work the Admin GUI related to creating and managing objects, tie puppets to Accounts etc.
+API improvements
+Whereas the last few months have been mostly spent fixing lingering bugs, one thing planned for version 1.0 is a general cleanup of legacy strangeness in the API. For example, certain methods can return a list or a single object depending situation, which makes it hard to generalize. There are a lot of small quirks like that which we hope to address and make more consistent.
+There has also been a recent flurry of contributor PRs intended to help decouple Evennia's systems and make them easier to replace for those inclined to do so. Many of this is still being worked on, but it's likely you'll be able to replace many more "core" components for 1.0 with your own variations without doing any hacking in upstream code at all.
+... Needless to say, this is an advanced feature that most developers will never need. But Evennia was always intended to be heavily customizable and having the option is a good thing!
+Another feature that will come for 1.0 is a REST-API, added by one of our contributors. This uses Django-REST-Framework and makes it easier for external programs to authenticate and fetch data out of the Evennia database (great both for external apps, websites or custom what-have-you).
+At this time you can only fetch database objects via this interface, you cannot perform Command-calls or "play the game" this way (REST is a stateless concept and Evennia Commands tend to retain state).
+Many other fixes and contributions
+There's a truckload of stuff already available in master branch, but with the latest contributions of bigger code changes, we have started to use the Evennia develop branch again in earnest again. For a summary of the changes so far, check out the Changelog.
+However, unless you want to contribute to Evennia itself (or really, really want to be on the bleeding edge), you are still recommended to use the master branch for now. A lot of work still to do, as said.
+ + +