The blog moved! ¶

- November 18, 2021

If you are reading this, you may notice that this blog has moved from its old home over on blogspot. I had no issues with blogspot except for the fact that writing the blog itself was done in a rather clunky editor with limited support for code.

Every other text in Evennia (docs, comments etc) is written in markdown and I figured it would be nice to be able to use that also for my dev blog.

So I put together my own little blog platform.

Making a little blog platform

I have rather small requirements - I don't publish a crazy amount of Evennia devblogs and I'm fine with making a git commit to do so.

I already use github pages for the Evennia homepage and documentation. These are simply html pages located in a gh-pages branch of the main evennia repo. So I decided I would just post my blog posts in a folder and then run a markdown parser to turn it into publisheable HTML pages.

The tools

Markdown was originally made to be converted to HTML and there is a plethora of markdown parsers for Python. I also wanted an easy way to insert my text into HTML template; this is also a well-solved problem. So these are the tools I used:

• mistletoe is a pure-Python markdown->HTML parser. I had never used it before but it was easy to use and very fast. It also supports the CommonMark Markdown spec (same as github). I could also easily have it use pygments to add code-highlighting to code snippets.
• jinja2 is a way to embed special tags in HTML "templates" that can then be programmatically filled with content. It's very similar to the Django templating language.

The posts

I then decided that each blog post should be one markdown file with a file name YYYY-MM-DD-The-post-name.md. So this current devblog has a file name of 2021-11-18-The-blog-moved.md.

In its simplest form, the date and name of the blog is just parsed from the filename (also makes it easy to find in the file system). But I also decided that each post could have a little optional meta-header for customizing things:

title: The blog moved!
date: 2021-10-11
copyrights: Image: [©Griatch](https://deviantart.com/griatch-art)

---

Here the blog starts...

The title is mainly to be able to add characters like ! or ? that I don't want to add to the file name. I've not used the date yet, but I guess one could use it to publish a text at a different date than the filename (not sure why one would want that ...). The copyrights is to properly credit any resources (mostly images) used.

I wrote my own build_devblog.py program that simple reads all .md files from a directory. It figures out the date and title (from file name or meta-header) and runs mistletoe on it. I create a dataclass with all the post-relevant properties on it. So far so good. Now we need to inject this into an HTML structure.

The html

Next I prepared a little post.html Jinja template:

<h1 id={{ blogpost.anchor }}>
     {{ blogpost.title }}
     <a class="devblog-headerlink" href="{{ blogpost.permalink }}" title="Permalink to this blog post">¶</a>
    <div class="devblog-title-date">- {{ blogpost.date_pretty }}</div>
</h1>
{{ blogpost.html }}
<footer class="devblog-footer">
    <span class="devblog-copyrights">
        {{ blogpost.image_copyrights }}
    </span>
    <a class="devblog-to-toplink" href="{{ blogpost.permalink }}" title="Link to top of post">⇬(top)</a>
</footer>

Above, the blogpost is a dataclass made available to Jinja, from which it reads and inserts data into the HTML using the {{ ... }} templating fields. I wanted each individual blog post to have a permalink, so that you could refer to it. I also decided that I would group all blog posts from a year into one HTML page, so 2021.html, 2020.html etc. Within each page, the blog post is just an anchor. So the link to this post is

 https://www.evennia.com/devblog/2021.html#2021-11-18-The-blog-moved

which seems quite clear.

For the entire year of devblogs, I stole the template used by the main evennia.com page, and also used the same CSS file (it's all in the same repo after all). Jinja allows you to do simple for loops within the template so it's easy to add all posts into a page.

The CSS

The final bit was to clean up the CSS and make a little 'calendar' in the sidebar to make it easy to navigate to older devblogs. In the wide-page view you can hover over the blog dates to see their names for easy lookup.

Converting the old blog

Google (which owns blogspot (formar Blogger) has an export feature but the result of this is a very dense XML file. It's mainly intended to be imported by Wordpress or some other existing blog platform. In the end I gave up on trying to parse it.

Instead I went the dumb route and just copy&pasted each of my old blogs from the old blog into Obsidian, which I use for markdown editing. Luckily this worked very well - all layout was retained and converted automatically to markdown syntax, including links to images etc. I only needed to add some nicer markup for code strings (since that was not a thing on blogspot).

I don't know if I have Obsidian to thank for this or if blogspot uses some standardized format, but manually converti of all my devblogs since 2012 thus ended up being a lot less painful than I thought (for once).

Things lost in move

There are a few things that were possible on blogspot that my simple little custom platform cannot do.

• Online editing: I'm not posting things on the fly so I'm fine with making a commit. Writing in a proper text editor is more confortable anyway. And the posts are under version control too!
• Comments: Few people every commented directly in the old blog though - and lately it has mostly been spam. To comment, people'll need to use our forums on github or the support channel.
• Notifications: I haven't added an RSS feed for this page and there is thus no automatic reporting of new posts in chat etc. I think the amount of posts I do is low enough that I can advertise them manually. I'll probably just make a dedicated announcement thread in Github discussions. Update: I added an RSS feed now, see the little icon on the top-right of this page.

Onward

So, with this new blog platform in place (this post is the first one I write using the new system), I won't update the old one anymore. The old one's not going anywhere though, and I will point here from it.

The new Evennia site ecosystem is getting a little more compact. These are services hosted on github/github pages:

• Homepage - https://www.evennia.com
• Docs - https://www.evennia.com/docs
• Devblog - https://www.evennia.com/devblog
• Forums - https://github.com/evennia/evennia/discussions
• Code - [https://github.com/evennia/evennia](https://github.com/evennia/evennia

At this point, the only things running elsewhere (and which will continue doing so) are:

• https://games.evennia.com - runs on Google App Engine
• https://demo.evennia.com - Digital Ocean droplet
• https://discord.gg/AJJpcRUhtF - Discord server (duh)

There is also an old version of the docs on ReadTheDocs. This is out of date and should be removed ...

But overall, the Evennia ecosystem is getting more and more cleaned up as we (slowly) approach the release of Evennia 1.0 ...

Where do I begin? ¶

- March 21, 2021

This is a repost of an article I originally wrote for the Imaginary Realities e-zine, Volume 7, issue 3 back in 2015. It's not Evennia-specific but meant for a wider audience interested in making a text-based multiplayer game (MUD/MU*). Since IR is no longer active, I repost it here with only some minor cleanup.

When a new user has everything installed and drops into Evennia’s IRC support chat or mailing list, there is one question that we regularly get in various variations:

“Where do I begin?”
How to actually start down that long road towards your own game is an important question. Unfortunately it has no one-size-fits-all answer. So it usually leads to a series of counter-questions. In this article I will try to (without being Evennia-specific) pose those questions in a way that would not fit in a chat window.

What is your motivation for doing this?

So you want to make a game. First you need to make a few things clear to yourself.

Making a multiplayer online game is a big undertaking. You will (if you are like most of us) be doing it as a hobby, without getting paid. And you’ll be doing it for a long time.

So the very first thing you should ask yourself (and your team, if you have any) is why am I doing this? Do some soul-searching here. Here are some possible answers:

• I want to earn recognition and fame from my online community and/or among my friends.
• I want to build the game so I can play and enjoy it myself.
• I want to build the same game I already play but without the bad people.
• I want to create a game so that I can control it and be the head honcho.
• A friend or online acquaintance talked me into working on it.
• I work on this because I’m paid to (wow!)
• I only build this for my own benefit or to see if I can pull it off.
• I want to create something to give back to the community I love.
• I want to use this project as a stepping-stone towards other projects (like a career in game design or programming).
• I am interested in coding or server and network architectures, making a MUD just seems to be a good way to teach myself.
• I want to build a commercial game and earn money.
• I want to fulfill a life-long dream of game making.

There are many other possibilities. How “solid” your answer is for a long-term development project is up to you. The important point is that you ask yourself the question.

Answering this question you may find that you should not start a new project - maybe it’s better to build on or help improve something that already exists. Maybe you find you are more of a game engine developer than a game designer. Some answers may also suggest that you are driven by emotions of revenge or disconcert - emotions that may have abated later when the project most needs your enthusiasm and motivation.

If your aim is to earn money your design goals may well be very different from those of a person who only builds for their own benefit.

Whichever your motivation, you should at least have it clear in your own mind. It’s worth to make sure your eventual team is on the same page too.

What are your skills?

Once you have your motivations straight you need to take stock of your own skills and the skills available in your team, if you have one.

Your game will have two principal components and you will need skills to cater for both:

• The game engine (“the code base”)
• The assets created for using the game engine (“the game world”)

The game engine

The game engine is maintained and modified by programmers (coders). It represents the infrastructure that runs the game - the network code, the protocol support, the handling of commands, scripting and data storage.

Creating your game engine from scratch can be a worthwhile and rewarding endeavour. It is however not a small one and if your main goal is to create a running game I would recommend building on an existing engine. It’s worth to take your time and do your research here. Searching the net and various MUD sites will bring you a slew of options. I will give some things to look for here.

Whereas some engines/code bases offer a lot of pre-existing coded systems, there is no denying that your team will always need someone who either already knows some basic programming or is willing to learn it.

When judging which engine you want to use, consider:

• The engine’s community - hang out in the community/forums/chat surrounding the respective engine. Expect to need to ask a lot of “stupid” questions as you start developing (hint: no question is stupid). Is this a community in which you would feel comfortable doing so?
• Active development - is the code base actively maintained? If there are bugs in the engine, does it seem likely they will be fixed upstream or will you be patching bugs yourself? Or alternatively, are there many active users that can help you out with known quirks?
• Other available documentation - does the engine come with a manual? Are there online tutorials or other help resources to read?
• Which language is the engine coded in? What is it scripted in? Do you or your team already know this language or are you willing to learn it?
• If you don’t know the language, do a few beginner tutorial so that you can at least vaguely recognize the syntax. Does the engine’s code seem easy to read and well documented? If the engine is poorly documented, the time of development may rise dramatically.
• Something to remember here is that computers of today are very powerful. And while scaling may be interesting if your game really takes off, a text game is, for the most part, not very demanding. So I’d recommend you pick your language and engine not primarily based on performance but on what you feel comfortable and productive working with.
• What is the engine’s license? This is mainly important if you plan to ever earn money with your game. Some common engines explicitly forbid commercial use.

Asset creation

Compared to the level of work needed to produce professional graphics for an MMORPG, detailed text assets for a mud are cheap to create. This is one of the many reasons muds are so well suited for a small team.

This is not to say that making “professional” text content is easy though. Knowing how to write imaginative and grammatically correct prose is only the minimal starting requirement. A good asset-creator (traditionally called a “builder”) must also be able to utilize the tools of the game engine to its fullest in order to script events, make quests, triggers and interactive, interesting environments.

Some game engines will offer generic online building tools while others will depend on the coders to create tools specific for their game. What you go for may be influenced by just how technically savvy your builders are and what skills they are willing to pick up along the way.

Your team’s in-house builders will be the first ones to actually “use” your game framework and build tools. They will stumble on all the bugs. This means that you need people who are just not “artsy” or “good with words”. Assuming coders and builders are not the same people, builders need to be able to collaborate well and give clear and concise feedback.

So, where do I begin?

Right, after all this soul-searching and skill-inventory-checking, let’s go back to the original question. And maybe you’ll find that you have a better feeling for the answer yourself already:

• If you are learning a new programming language, you should follow basic tutorials so that you can read, understand and replicate example code without being completely in the dark.
• If you have decided on your game engine you should dive into its manual and basic tutorials. Also make sure to introduce yourself to its community so you can get as much help as possible.
• If the game engine offers tutorials on making some small example game, do that carefully. Even if the resulting demo game has nothing to do with what you aim to build. If there are no tutorials maybe you can instead find a full example code that you can examine in the same way. Not only will this give you a better understanding of how parts of the engine hangs together, it will also give you ideas for what you can do with it. If something is surprisingly easy to do, you might even be able to expand your plans!
• If your game engine comes with pre-made game tools or building commands, the builders can start getting familiar with it. But keep in mind that these will not reflect the full capabilities of the game - your game is not yet built! So don’t set builders off to build large zone projects at this point. If they are building anything at all, it should be small test areas in order to agree on a homogenous form, mood and literary style.

With a few tutorials and game examples under your belt you are ready to start some preliminary coding-tests of your own. You won’t be making a full game yet! Working without a step-by-step tutorial will give you an idea of just how easy or hard this stuff is to figure out in practice at your current skill level, chosen game engine and language. Make ample use of any manuals, help channels or other resources you can find - anything you will also have access to when you code the real thing. This allows you to judge the quality and usefulness of those resources at the same time.

You or any builders may also get some building exercise here, using the commands and objects you create for simple testing. Here is a list of things to try out (you should be able to do these in any game engine worth its salt):

• Change some phrasing in the output of an already existing command.
• Make a new command and add it to the game engine. Make it just echo back whatever argument you give it.
• Code an object that echoes “tick” to everyone at its location every 20 seconds.
• Make a new command that creates new ticking objects where you are, but with a name given by you.
• Make a room whose description changes every time you enter it.
• Make an object that deletes itself when its “health” property is changed to zero.
• Make an “attack” command that randomly reduces the “health” property of a target object until it deletes itself.
• These are all simple things but it should give you an idea of what your chosen game engine is capable of and, most importantly, where to find help when you get stuck. If you can’t get past this step even with help you might need to go back and read up on the programming bit some more. Or maybe you should consider an easier game engine.

What is your scope?

We are now past the “things to do first”. Welcome to the things you do later.

To reiterate, at this point you should have pondered why you are doing this and made an inventory of your available skills. You have gotten a first taste of the kind of coding work you will need to do and what that entails. You have built a few things to see how that works. Maybe you even changed game engine somewhere in the middle. Still ready to roll? Excellent.

You should now hopefully have enough information to be able to realistically set the scope of your game.

Everyone wants to make the best game ever. You want a whole world simulated in minute detail with next-generation artificial intelligence. You want instant action that puts Hollywood to shame and emergent storytelling worthy of Shakespeare.

It’s okay to dream big, but your first goal now is to get something out. Something that players can actually connect to and give feedback on. Having players enjoying an early version of your game is a great motivational boost in itself, you should try to reach that stage quickly. You are aiming for a first version, not the ultimate version. All online mmo:s keep improving the game after release, that’s the name of the game.

So keep your grand plans in mind but limit your scope for your first release. For a group of hobbyist developers (which is, frankly what almost all MU* development teams are) your motivational time is precious. You are likely not getting paid during development which means that it’s imperative that you set out to create something you are capable of finishing while still having fun. Adjust the scope to fit this time. If you run out of steam before this time you’ll know you went for too big a scope.

How to continue from here?

How to progress is depending on your preference. Some prefer to just jump straight into coding and figure out things as they go. It's not a bad idea to to sit down and plan a little first though - and remember that you want a first version of your game at this point, not the final, ultimate version.

This is beyond the first question asked in this article (which is long enough as it is) but I have written about this process in Evennia’s game planning documentation. This reiterates some aspects of this article while expanding on others.

… But in the end, remember that what kills a hobby game project will usually be your own lack of motivation. So do whatever you can to keep that motivation burning strong! Even if it means deviating from what you read in articles like this one. Just get that game out there, whichever way works best for you.

Happy New Years 2021! ¶

- January 1, 2021

Another year passed with Evennia, the Python MU* creation system. The past year saw a lot of bug fixing and more gradual additions and in September we released version 0.9.5. This was an intermediary version on our way to 1.0. Time to look forward to next year.

On my development horizon for 2021 are the main new features planned for v1.0. Some of these are rather big things I've wanted to get around to for a while. They are all happening in the develop branch of Evennia, which is currently not recommended for general use.

• SessionDB: In the current Evennia, Sessions (the representation of a single client connection) is an in-memory entity. This is changing to be a database-backed entity instead. One will be able to typeclass Sessions like other entities for easier overriding. This change also means that there will be one single point of session-id (the django-session), alleviating some reported issues where the Portal- and Server-side sessions have drifted out of sync. It will also make it a lot easier to support auto-logins, also across server reboots. Db-backed Sessions will also simplify the Portal-Session interaction a lot.
• Script refactor: The Scripts will see some refactoring, mainly because they are used more as general-storage entities compared to the timers they were originally meant to be. These days Evennia also offers a range of other timer-mechanisms (tickers, delays, Events etc), so it's less important to rely on Scripts for this functionality. The most important change will be that the timer will required to be explicitly started (instead of always starting on script-creation). It will also be possible to stop the timer without the script getting deleted (so separating the timer from the Script's life-cycle).
• Channel refactor: The Channels will also see changes; notably to make it considerably easier to override and customize them per-caller. Today the Channel typeclass has a maze of different hooks being called, but it's harder for devs wanting users to customize their channel output. So one of the changes will be new hooks on the account/object level for allowing to format the channel output per-user. There will also be a cleanup of the existing hooks to make things clearer.
• New starting tutorial: As part of the new documentation, I'm writing a new starting-tutorial. This will consolidate many of the existing beginner tutorials in a consistent sequence and if following it to the end, the reader will have created a small beginner game with everything in place. I plan to make a few new contribs to support this.
• Contrib restructure: Our contrib/ folder is getting a little cluttered. I'm investigating organizing things a little differently by at least moving things into categorized folders. This will lead to people having to change their imports, but we'll see just how it goes.
• Documentation cleanup: There are a lot of small changes, cleanup and restructuring needed in the docs overall - many of the existing pages are auto-translated from the old wiki and need rewriting both in style and content. The whole idea of moving to the new doc-system is to be able to update the docs alongside the code changes. So hopefully the changes to Sessions, Scripts and Channels etc will all be covered properly from the onset rather than after release (as was the case with the wiki).
• Unittest coverage: Our current test coverate is 64%, we need to expand this. I hope to get to at least 70% before v1.0 but that is less of a strict goal.
• Evennia PYPI package: This will be one of the last things before the release of 1.0 - Evennia will be put onto PYPI  so you can install with pip install evennia. Once we do it will simplify the install instructions dramatically for those not interested in contributing to Evennia proper.

We also have some pull-requests in the making that will be interesting to have in the system, such as Volund's plugin system, making it easier to inject custom settings on the fly (good for contribs wanting to add their own database tables, for example).

A lot of work to do as usual!

Thanks for the past year, everyone - thanks to all of you that contributed to Evennia with code or by reporting issues or coming with feedback. Thanks particularly to those of you willing (and able) to chip in with some financial support for Evennia development - that's very encouraging!

And finally, a big thanks to all of you taking part in community discussions, both you asking questions and you helping to answer them tirelessly and with good cheer - you make the Evennia community the friendly, inviting place it is!

May all our game development move forward and our hard drives stay healthy for another year.

Cheers and a Happy new year,

Griatch