<h1>Evennia in pictures<aclass="headerlink"href="#evennia-in-pictures"title="Permalink to this headline">¶</a></h1>
<asideclass="sidebar">
<p>This is <em>not</em> an exhaustive overview. Think of it as a snapshot of some interesting things to start looking into.</p>
</aside>
<p>This article tries to give a high-level overview of the Evennia server and some of its moving parts. It should hopefully give a better understanding of how everything hangs together.</p>
<divstyle="clear: right;"></div>
<sectionid="the-two-main-evennia-pieces">
<h2>The two main Evennia pieces<aclass="headerlink"href="#the-two-main-evennia-pieces"title="Permalink to this headline">¶</a></h2>
<p><imgalt="evennia portal and server"src="https://2.bp.blogspot.com/-0-oir21e76k/W3kaUuGrg3I/AAAAAAAAJLU/qlQWmXlAiGUz_eKG_oYYVRf0yP6KVDdmQCEwYBhgL/s1600/Evennia_illustrated_fig1.png"/></p>
<p>What you see in this figure is the part of Evennia that you download from us. It will <em>not</em> start a game on its own. We’ll soon create the missing ‘jigsaw puzzle piece’. But first, let’s see what we have.</p>
<p>First, you’ll notice that Evennia has two main components - the <aclass="reference internal"href="Components/Portal-And-Server.html"><spanclass="doc std std-doc">Portal and Server</span></a>. These are separate processes.</p>
<p>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.</p>
<p>The Server is the main “mud driver” and handles everything related to the game world and its database. It’s asynchronous and uses<aclass="reference external"href="http://twistedmatrix.com/trac/">Twisted</a>.</p>
<p>In the same process of the Server is also the Evennia <aclass="reference internal"href="Components/Webserver.html"><spanclass="doc std std-doc">Web Server</span></a> . This serves the game’s website.</p>
<divstyle="clear: right;"></div>
<sectionid="initializing-the-game-folder">
<h3>Initializing the game folder<aclass="headerlink"href="#initializing-the-game-folder"title="Permalink to this headline">¶</a></h3>
<p><imgalt="creating the game folder"src="https://4.bp.blogspot.com/-TuLk-PIVyK8/W3kaUi-e-MI/AAAAAAAAJLc/DA9oMA6m5ooObZlf0Ao6ywW1jHqsPQZAQCEwYBhgL/s1600/Evennia_illustrated_fig2.png"/></p>
<p>After <aclass="reference internal"href="Setup/Installation.html"><spanclass="doc std std-doc">installing evennia</span></a> you will have the <codeclass="docutils literal notranslate"><spanclass="pre">evennia</span></code> command available. Using this you create a game directory (let’s call it <codeclass="docutils literal notranslate"><spanclass="pre">mygame</span></code>). This is the darker grey piece in this figure. It was missing previously. This is where you will create your dream game!</p>
<p>During initialization, Evennia will create Python module templates in <codeclass="docutils literal notranslate"><spanclass="pre">mygame/</span></code> and link up all configurations to make mygame a fully functioning, if empty, game, ready to start extending.</p>
<p>As part of the intialization, you’ll create the database and then start the server. From this point on, your new game is up and running and you can connect to your new game with telnet on localhost:4000 or by pointing your browser to <aclass="reference external"href="http://localhost:4001">http://localhost:4001</a>.</p>
<p>Now, our new mygame world needs Characters, locations, items and more!</p>
</section>
</section>
<sectionid="the-database">
<h2>The database<aclass="headerlink"href="#the-database"title="Permalink to this headline">¶</a></h2>
<p>Evennia is fully persistent and abstracts its database in Python using <aclass="reference external"href="https://www.djangoproject.com/">Django</a>. The database tables are few and generic, each represented by a single Python class. As seen in this figure, the example <codeclass="docutils literal notranslate"><spanclass="pre">ObjectDB</span></code> 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).</p>
<p>Among the example columns shown is the key (name) of the <codeclass="docutils literal notranslate"><spanclass="pre">ObjectDB</span></code> entity as well as a <aclass="reference external"href="https://en.wikipedia.org/wiki/Foreign_key">Foreign key</a>-relationship for its current “location”.</p>
<p>From the figure we can see that <em>Trigger</em> is in the <em>Dungeon</em>, carrying his trusty crossbow <em>Old Betsy</em>!</p>
<p>The <codeclass="docutils literal notranslate"><spanclass="pre">db_typeclass_path</span></code> is an important field. This is a python-style path and tells Evennia which subclass of <codeclass="docutils literal notranslate"><spanclass="pre">ObjectDB</span></code> is actually representing this entity. This is the core of Evennia’s <aclass="reference internal"href="Components/Typeclasses.html"><spanclass="doc std std-doc">Typeclass system</span></a>, which allows you to work with database entities using normal Python.</p>
<sectionid="from-database-to-python">
<h3>From database to Python<aclass="headerlink"href="#from-database-to-python"title="Permalink to this headline">¶</a></h3>
<p>Here we see the (somewhat simplified) Python class inheritance tree that you as an Evennia developer will see, along with the three instanced entities.</p>
<p><aclass="reference internal"href="Components/Objects.html"><spanclass="doc std std-doc">Objects</span></a> represent 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 <codeclass="docutils literal notranslate"><spanclass="pre">mygame/</span></code> folder you just import these and overload the things you want to modify. In this way, the <codeclass="docutils literal notranslate"><spanclass="pre">Crossbow</span></code> is modified to do the stuff only crossbows can do and <codeclass="docutils literal notranslate"><spanclass="pre">CastleRoom</span></code> adds whatever it is that is special about rooms in the castle.</p>
<p>When creating a new entity in-game, a new row will automatically be created in the database table and then <codeclass="docutils literal notranslate"><spanclass="pre">Trigger</span></code> will appear in-game! If we, in code, search the database for Trigger, we will get an instance of the <spanclass="xref myst">Character</span> class back - a Python object we can work with normally.</p>
<p>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. Read on.</p>
</section>
<sectionid="attributes">
<h3>Attributes<aclass="headerlink"href="#attributes"title="Permalink to this headline">¶</a></h3>
<p>The <aclass="reference internal"href="Components/Attributes.html"><spanclass="doc std std-doc">Attribute</span></a> is another class directly tied to the database behind the scenes. Each <codeclass="docutils literal notranslate"><spanclass="pre">Attribute</span></code> basically has a key, a value and a ForeignKey relation to another <codeclass="docutils literal notranslate"><spanclass="pre">ObjectDB</span></code>.</p>
<p>An <codeclass="docutils literal notranslate"><spanclass="pre">Attribute</span></code> serializes Python constructs into the database, meaning you can store basically any valid Python, like the dictionary of skills in this image. The “strength” and “skills” Attributes will henceforth be reachable directly from the <em>Trigger</em> 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.</p>
<divstyle="clear: right;"></div>
</section>
</section>
<sectionid="controlling-the-action">
<h2>Controlling the action<aclass="headerlink"href="#controlling-the-action"title="Permalink to this headline">¶</a></h2>
<p><em>Trigger</em> is most likely played by a human. This human connects to the game via one or more <aclass="reference internal"href="Components/Sessions.html"><spanclass="doc std std-doc">Sessions</span></a>, one for each client they connect with.</p>
<p>Their account on <codeclass="docutils literal notranslate"><spanclass="pre">mygame</span></code> is represented by a <aclass="reference internal"href="Components/Accounts.html"><spanclass="doc std std-doc">Account</span></a> entity. The <codeclass="docutils literal notranslate"><spanclass="pre">AccountDB</span></code> holds the password and other account info but has no existence in the game world. Through the <codeclass="docutils literal notranslate"><spanclass="pre">Account</span></code> entity, <codeclass="docutils literal notranslate"><spanclass="pre">Sessions</span></code> can control (“puppet”) one or more <codeclass="docutils literal notranslate"><spanclass="pre">Object</span></code> entities in-game.</p>
<p>In this figure, a user is connected to the game with three <codeclass="docutils literal notranslate"><spanclass="pre">Session</span></code>s simultaneously. They are logged in to their player <codeclass="docutils literal notranslate"><spanclass="pre">Account</span></code> named <em>Richard</em>. Through these <codeclass="docutils literal notranslate"><spanclass="pre">Session</span></code>s they are simultaneously puppeting the in-game entities <em>Trigger</em> and <em>Sir Hiss</em>. Evennia can be configured to allow or disallow a range of different <aclass="reference internal"href="Concepts/Connection-Styles.html"><spanclass="doc std std-doc">Connection Styles</span></a> like this.</p>
<sectionid="commands">
<h3>Commands<aclass="headerlink"href="#commands"title="Permalink to this headline">¶</a></h3>
<p>For users to be able to control their game entities and actually play the game, they need to be able to send <aclass="reference internal"href="Components/Commands.html"><spanclass="doc std std-doc">Commands</span></a>.</p>
<p>A <codeclass="docutils literal notranslate"><spanclass="pre">Command</span></code> can be made to represent anything a user can input actively to the game, such as the <codeclass="docutils literal notranslate"><spanclass="pre">look</span></code> command, <codeclass="docutils literal notranslate"><spanclass="pre">get</span></code>, <codeclass="docutils literal notranslate"><spanclass="pre">quit</span></code>, <codeclass="docutils literal notranslate"><spanclass="pre">emote</span></code> and so on.</p>
<p>Each <codeclass="docutils literal notranslate"><spanclass="pre">Command</span></code> 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 the above figure, the <codeclass="docutils literal notranslate"><spanclass="pre">DIKUCommand</span></code> parent class implements parsing of all the syntax common for all DIKU-style commands so <codeclass="docutils literal notranslate"><spanclass="pre">CmdLook</span></code> and others won’t have to.</p>
</section>
<sectionid="command-sets">
<h3>Command Sets<aclass="headerlink"href="#command-sets"title="Permalink to this headline">¶</a></h3>
<p>All Evennia Commands are are always joined together in <codeclass="docutils literal notranslate"><spanclass="pre">CommandSet</span></code>s. These are containers that can hold many <codeclass="docutils literal notranslate"><spanclass="pre">Command</span></code> instances. A given <codeclass="docutils literal notranslate"><spanclass="pre">Command</span></code> class can contribute instances to any number of <codeclass="docutils literal notranslate"><spanclass="pre">CommandSet</span></code>s. These sets are always associated with game entities.</p>
<p>In this figure, <em>Trigger</em> has received a <codeclass="docutils literal notranslate"><spanclass="pre">CommandSet</span></code> with a bunch of useful commands that he (and by extension his controlling <codeclass="docutils literal notranslate"><spanclass="pre">Account</span></code>/Player) can now use.</p>
<p><em>Trigger</em>’s <codeclass="docutils literal notranslate"><spanclass="pre">CommandSet</span></code> is only available to himself. In this figure we put a <codeclass="docutils literal notranslate"><spanclass="pre">CommandSet</span></code> with three commands on the Dungeon room. The room itself has no use for commands but we configure this set to affect those <em>inside it</em> instead. Note that we let these be <em>different versions</em> of these commands (hence the different color)! We’ll explain why below.</p>
<divstyle="clear: right;"></div>
</section>
<sectionid="merging-command-sets">
<h3>Merging Command Sets<aclass="headerlink"href="#merging-command-sets"title="Permalink to this headline">¶</a></h3>
<p>Multiple <codeclass="docutils literal notranslate"><spanclass="pre">CommandSet</span></code>s can be dynamically (and temporarily) merged together in a similar fashion as <aclass="reference external"href="https://en.wikipedia.org/wiki/Set_theory">Set Theory</a>, except the merge priority can be customized. In this figure we see a <em>Union</em>-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 <codeclass="docutils literal notranslate"><spanclass="pre">CommandSet</span></code> will be restored unharmed.</p>
<p>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 <codeclass="docutils literal notranslate"><spanclass="pre">look</span></code> command show only 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!</p>
<p>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.</p>
</section>
</section>
<sectionid="now-go-and-explore">
<h2>Now go and explore!<aclass="headerlink"href="#now-go-and-explore"title="Permalink to this headline">¶</a></h2>
<p>This is by no means a full list of Evennia features. But it should give you a bunch of interesting concepts to read more about.</p>
<p>You can find a lot more detail in the <aclass="reference internal"href="Components/Components-Overview.html"><spanclass="doc std std-doc">Core Components</span></a> and <aclass="reference internal"href="Concepts/Concepts-Overview.html"><spanclass="doc std std-doc">Core Concepts</span></a> sections of this manual. If you haven’t read it already, you should also check out the <aclass="reference internal"href="Evennia-Introduction.html"><spanclass="doc std std-doc">Evennia Introduction</span></a>.</p>
