Evennia 1.0 released! ¶

- December 3, 2022

As of today, Evennia 1.0 released! This has been a long time coming. Not only were there a lot of fixes and features to add, we also moved to a completely new documentation system. With many moving parts and my wish to get as much as possible into this release, it took a while to get things aligned.

This release is also the first one where we distribute Evennia on Pypi, so you can install with pip install evennia. This also led to a lot of new work and documentation to write.

That said, it would have taken even longer if I had been alone - and I was not. The Evennia community is growing ever more active, and we now have a regular influx of PRs. I even get help fixing bugs at times! Not to mention a bunch of very sweet new contribs and implemented features. It feels super-luxurious to wake up and find a bug has been fixed for me!

Thanks a lot, everyone!

Moving forward

The linked announcement above covers the new features of 1.0. Check it out - there's a lot of fun stuff. In this dev-blog, I wanted to talk a little bit about the future instead.

Main is where it's at

As usual when the develop branch merges, activity shifts. So moving forward, the main branch (which is now what we use instead of master) will be the 'active' branch.

All new PRs and features should now be made against main. The develop branch will likely make its return as the bleeding-edge, but I hope that it will be mainly for testing individual complex features rather than for a huge new version like in the past.

Versioning

In the past we have made big version changes: 0.5->0.6->0.7->0.8->0.9. Then we got sort of stuck preparing for 1.0, and there was an interim 0.9.5 release just to hold us over. In the end, 1.0 took almost two years to complete.

Having the develop branch open for this long is not good. Users of 0.9.5 were stuck with the old docs (just a plain import from the github wiki) since I couldn't maintain both. It meant stagnation for people downloading master branch. And while people in the know eventually switched to use develop branch (helping a lot of with testing!) it's still not an ideal state of affairs. I don't want something similar to happen leading up to 2.0.

So for that reason I plan to move Evennia to semantic versioning going forward. Semantic versioning means that we'll use Major.Minor.Patch versioning. For you as a developer of an Evennia game (using pip install - if you follow main on git, it's less relevant, you'll have bleeding edge), this versioning means

• 1.0.x - changes (1.0.1, 1.0.2 etc) are patches. Bug fixes. Security fixes. Should always be safe to upgrade to without anything breaking.
• 1.x.0 - changes (1.1.0, 1.2.0 etc) are minor version changes. This can introduce new functionality that is backwards compatible. So a new default command, a new contrib, stuff like that. Maybe bigger bug fixes and refactoring that don't change existing functionality. So Minor versions are also usually worthwhile to update to.
• x.0.0 - changes (2.0.0, 3.0.0 etc) are major version changes. These versions include changes that are backwards-incompatible. The change may still be small! The gist of it is that they are changes that require you to take some action.

With semantic versioning, Evennia 2.0, 3.0 etc may happen sooner than you may think - even changing how a setting should be written is technically a backwards-incompatible change. I think this will help make those major versions be less daunting too - meaning we won't get stuck at 1.9.5 again.

Finishing the beginner tutorial

The new Beginner Tutorial is not ready yet.

As mentioned in my previous devblog, I had to pause work on it or 1.0 wouldn't get out this year. That said, I think the first two parts that are finished are already useful to newcomers. In the coming months I will continue with the tutorial-game and finish all the code. In the end I aim to have the reader make a complete little MUD from scratch if they follow the tutorial from beginning to end.

Onward!

After the 1.0 release we are now officially in the 'bug fix and cleanup' phase. So report all the issues you find - especially with the new docs!

So moving forward, I expect to mainly do patches and minor versions for a while. I don't intend to start any major work until after the beginner-tutorial is complete.

For now though, let's just be happy that 1.0 is out! :D

Project plans and Splitting a Setting in two ¶

- September 17, 2022

As those following Evennia development should be aware of for now, we are approaching the 1.0 release of Evennia, the MU*-building framework.

Thing is, that release has been coming 'soon' for quite a while now. Since some time you can already test Evennia 1.0-dev by checking out the Evennia develop branch (here for help on how). Evennia 1.0-dev is still changing, but it's already stable enough that It's gotten to the point that people in chat now recommend new users to start fresh with 1.0-dev rather than the 'stable' version 0.9.5, which is now 1.5 years old and is not seeing more updates.

Changes to 1.0 release plans

In short:

I plan to pause the work on the new beginner tutorial and release 1.0 with that piece of the documentation unfinished. It still has a large swathes of useful info, but the new from-scratch game will not be ready.

Longer:

One of the reasons for 1.0 not being released is that I have been working on a new beginner-tutorial to go with the new system. This involves making a full little MUD game from scratch, and I'm making a full system you can both follow lesson-per-lesson as well as implementing it for those that prefer to pull apart code.

Writing good code as well as full tutorial lessons is however a big, full-time job (next to my actual real-life full-time job) and thus I expect it will take a good while longer before the new tutorial is done. Worse, in the meantime I can't spend much time resolving the 1.0-dev bugs that has been reported by community testers and also block release.

So I will map out the remaining pieces of the tutorial with informational "Work in progress" markers, merge what I have, and stop work on it for now.

I'll continue finishing the tutorial in smaller sub-releases after the main 1.0 release.

What's left for 1.0-dev

So, with the main bulk of work (the beginner tutorial) on hold, what's left to do?

• Cleanup the rest of the docs! There's still much to do there, including removing old tutorials that are now covered in the parts of the beginner-tutorial already finished. Also need to connect all pages and structure the docs better.
• Get into the bug backlog of Evennia 1.0-dev that people have reported. Also work to merge some outstanding PRs. I'll need to triage issues more, but hopefully I can get some help fixing simpler bugs during October's Hacktoberfest.

MULTISESSION_MODE changes (this will affect your current game!)

That said, now to some recent changes in 1.0-dev. This one is important since it affects your existing game.

In short:

The functionality of MULTISESSION_MODE has been broken into smaller sub-settings. This makes it a lot more flexible, but if you used the 'side-effects' of a higher MULTISESSION_MODE in your game, you now need to set a few other settings to get that back.

Longer:

The MULTISESSION_MODE is a long-standing Evennia setting. It controls how many sessions you can connect to the game at a time. In other words, how many game clients you can open against the same accoung login at the same time.

• Mode 0: A single session. Connecting a new one will disconnect the previous one.
• Mode 1: Multiple sessions can be connected. When you puppet a Character, each session will see the same output.
• Mode 2: Multiple sessions can be connected. Each session can puppet one Character each.
• Mode 3: Multiple sessions can be connected. Multiple sessions can puppet a Character, each session will see the same output.

Thing is that for the longest time, this setting has also controlled other things:

• Mode 0,1: A Character of the same name as the Account is auto-created when first connecting.
• Mode 0,1: You auto-connect to your last character whenever you log in.
• Mode 2,3: You don't get an auto-created character and end up in and OOC 'character' select screen when logging in.

These things don't really belong together. For example, if you want players to be able to choose between multiple characters (a character selection screen) but only play one at a time (MULTISESSION_MODE 0 or 1), you'd need to work around Evennia's default.

As of today, I've merged a change to Evennia 1.0-dev (develop branch) which changes this.

• MULTISESSION_MODE now only controls how sessions connect and how they can puppet characters.
• MAX_NR_SIMULTANEOUS_PUPPETS is a new setting that controls how many puppets you can control for MULTISESSION_MODE 2 and 3. This will not change anything for modes 0 and 1 (always acts as 1 due to how those modes work).
• AUTO_CREATE_CHARACTERS_WITH_ACCOUNT allows you to turn off the auto-creation of a character with the same name as the Account when you register. This used to be enforced as a part of MULTISESSION_MODE 0 or 1.
• AUTO_PUPPET_ON_LOGIN controls if you will auto-connect to the last thing you puppet when you login, of if you'll end up OOC (by default at a character selection screen). Again, this used to be enforced by MULTISESSION_MODE 0 or 1.
• MAX_NR_CHARACTERS existed before. It controls how many characters the default charcreate command will allow you to create.

By default these settings are all setup to mimic the old MULTISESSION_MODE 0, so you should not notice any difference in a fresh game.

The drawback is that if you use a higher MULTISESSION_MODE in your existing game, you will need to tweak these settings to get back what you had before. Also, if you overrode Account or the default login commands, you may need to tweak things to match the new upstream default.

Tutorial-writing and Attributes galore ¶

- July 5, 2022

It has been a while since I wrote anything for the dev blog of Evennia, the MU creation system - so it's about time!

It's been a busy spring and early summer for me, with lots of real-life work going on away from Evennia land. But that hasn't meant activity on the Evennia code base has slowed!

Many eyes on Evennia 1.0-dev

Earlier this year I invited people to try the Evennia develop branch - what will become Evennia 1.0. A lot of bold beta-testers have since swapped to using the 1.0 branch. While there are plenty of issues being reported, most seem pretty happy about it so far. As mentioned in earlier dev blogs, Evennia 1.0 has a lot of improvements and new features!

As part of this, the amount of PRs being made against develop branch has increased a lot, with awesome community members stepping up to fix bugs and even address long-standing annoyances. This includes everything from big improvements in ANSI parsing, fixes to the 1.0 FuncParser, RPSystem contrib optimizations and much more - the list of closed PRs is long.

Another big part are everyone helping to answer questions in chat and suggesting improvements to the community in general. Thanks everyone!

The upcoming beginner tutorial

On my end, I'm working on the Beginner Tutorial for the new 1.0 documentation. This will be a multi-part tutorial where you get to make a little MUD game from scratch. It goes through the basics of Evennia all the way to releasing your little game and I hope it will help people get started. This will also lead to a new contrib - the evadventure package, which should (I plan) have everything the tutorial needs to run. This is useful for those that prefer picking apart existing code over reading about it.

The tutorial game itself is based on Knave, an light Old-School-Renaissance (OSR) tabletop roleplaying ruleset inspired by early editions Dungeons & Dragons. It's simple enough to fit in a tutorial but with enough wrinkles to showcase how to create some basic rpg systems in Evennia:

• Using Attributes (STR, DEX etc)
• Rules (dice rolls, advantage, contested rolls etc)
• Character generation (Knave chargen is mostly random, but it still showcases Evennia's menu system EvMenu).
• Inventory management and equipment (including limited storage as well as items worn or wielded).
• Turn-based combat system (menu based)
• • Attacking with wielded weapons (or spell rune)
• • Stunts to give you advantages for later turns or give enemies disadvantage for later turns
• • Using items for healing or other effects
• • Fleeing and chasing
• Alternative Twitch-based combat system (might be a stretch goal)
• NPCs with very simple AI, Death and respawn
• Simple Questing system with NPC quest givers and quest states
• A small example world (tech-demo)

I won't include how to make a Crafting system, since I've added a full Crafting contrib to Evennia 1.0 for devs to be inspired by or tear apart.

Some nice new things about Attributes

In general news, Evennia 1.0 will see two big improvements when it comes to Attributes.

AttributeProperty

This is a new way to write - and particularly initialize - Attributes. Traditionally in Evennia you need to initialize your object's Attributes something like this:

from evennia import DefaultCharacter

class Character(DefaultCharacter):
    def at_object_creation(self):
        self.db.strength = 10
        self.db.mana = 12

This still works. But with the new AttributeProperty you can now write it like this instead:

from evennia import DefaultCharacter
from evennia.typeclasses.attributes import AttributeProperty

class Character(DefaultCharacter):
    strength = AttributeProperty(10)
    mana = AttributeProperty(10)

This makes Attributes look more like Django fields, sitting directly on the class. They can also have category and all other values you'd expect. You can still access those Attributes like normal:

strength = char.db.strength
mana = char.attributes.get("mana")

But you can now also do just

strength = char.strength
mana = char.mana

directly (you'll need to be careful to not override any existing properties on objects this way of course).

An interesting feature of using an AttributeProperty is that you can choose to not actually create the Attribute under the hood unless the default changed:

class Character(DefaultCharacter):
    strength = AttributeProperty(10, autocreate=False)
    mana = AttributeProperty(10, autocreate=False)

When you now access char.strength you will get 10 back but you won't actually be hitting the database to load anything - it's just giving you the default. Not until you change the default will the actual Attribute be created. While this can be very powerful for optimization, note that you can of course not access such data via char.db or char.attributes.get either (because no Attribute yet exists). So this functionality can be confusing unless you know what you are doing. Hence autocreate defaults to True.

Saving Attributes with hidden database objects

This is one of those classical quirks of Evennia that many have encountered. While Evennia can save a lot of things in an Attribute, including database objects, it cannot do so if it doesnt know those database objects are there. This is fine if you are saving a list or a dict with objects in it - Evennia will go through it and make sure to serialize each db-object in turn.

But if you "hide away" your db-object you will be in trouble:

class MyStore:
    def __init__(self, dbobj):
        self.dbobj = dbjobj

char = Character.objects.get(id=1)
obj.db.mystore = MyStore(char)   # leads to Traceback!

This fails because we store char inside MyStore and there is no way for Evennia to know it's there and to handle it properly.

For the longest time, this was just a limitation you had to accept. But with Evennia 1.0-dev you can now help Evennia out:

from evennia.utils.dbserialize import dbserialize, dbunserialize

class MyStore:
    def __init__(self, dbobj):
        self.dbobj = dbobj
    def __serialize_dbobjs__(self):
        self.dbobj = dbserialize(self.dbobj)
    def __deserialize_dbobjs__(self):
        self.dbobj = dbunserialize(self.dbobj)

char = Character.objects.get(id=1)
obj.db.mystore = MyStore(char)   # now OK!

With the new __serialize_dbobjs__ and __deserialize_dbobjs__, Evennia is told how to properly stow away the db-object (using the tools from evennia.utils) before trying to serialize the entire MyStore. And later, when loading it up, Evennia is helped to know how to restore the db-object back to normal again after the rest of MyStore was already loaded up.

Moving forward ...

For Evennia 1.0, the tutorial-writing is the single biggest project that remains - that and the general documentation cleanup of our entirely rewritten documentation.

After that I will dive back in with the issues that has popped up during beta-testing of 1.0-dev and try to wrap up the most serious ones before release. Still some time away, but it's getting there ... slowly!

Into 2022 with thanks and plans ¶

- January 6, 2022

I didn't write an end-of-the year summary for 2021, so this first devblog of 2022 will also look back a bit at the past year. It also helps me get used to using this new blog platform I wrote about in the previous post.

On Evennia 1.0

Speaking of 2021, you may have noticed that there was no new versioned Evennia release last year. Last one was 0.9.5 back in 2020. This may make it seem like little is happening in Evennia-land ... but the fact is that while little has happened in master branch over the past year, all the more has been going on in Evennia's develop branch - the branch which will become Evennia 1.0.

Now, it's not really so good to have a development branch run so long. This is because in the interim people report errors in master branch that has since been resolved in develop. It's becoming more and more cumbersome to backport which means that master is not getting updated all that much right now.

Post 1.0, I'll likely switch to a faster release cycle, but at least for now, it has been hard to avoid, this is because I'm reworking the entire documentation site alongside the code, with new autodocs and tutorials. Releasing an intermediary version with some sort of mid-way documentation version is just not practical for me. So I hope you can be patient a bit further!

Soonish™, I hope to have finished the code changes needed for 1.0 and then I'll invite adventurous folks to use the branch more extensively while the docs are still in flux.

So what's still to do for Evennia 1.0?

This is the current TODO list.

The big one I'm currently doing is to refactor the contrib/ folder to have more structure (it has grown organically until now). After this, there are a series of bugs and minor features to do. I will also go back and address the low-hanging master branch bugs that haven't already been resolved in develop. Most remaining points are then documentation fixes. Those will be handled in one go as the docs are finalized.

So ...

I won't/can't commit to a deadline for Evennia 1.0, but I'll keep chipping away at it as fast as I can. If you want things to move quicker you are more than welcome to join the other contributors that have chipped in with PRs over the past year. Check out the TODO list and consider investigating a bug or implementing a feature - some may be pretty straight forward.

... some thanks!

A big thanks to those that dropped an encouraing buck in my hat (aka patreon or with a one-time paypal donation) over the year. Everyone has different economical situations and I hope I've been very clear that noone should feel obligated to pay anything. But those of you that could and did - know that you have my thanks - it's very encouraging.

But - just as big thanks go out to everyone that contributed to Evennia in 2021! "Contribution" means so many things - we have the troopers that contributed code and made PRs (best Hacktoberfest yet!), but also those that dilligently reported bugs and pointed out problems as well as (and this is just as important) were active and helpful in the support chat and github discussion!

You guys make the community, that's all there is to it. Thanks a lot.

Now onward into this new, fresh year and towards that elusive Evennia 1.0 ...