<h1>Evennia for Diku Users<aclass="headerlink"href="#evennia-for-diku-users"title="Permalink to this headline">¶</a></h1>
<p>Evennia represents a learning curve for those who used to code on
<aclass="reference external"href="https://en.wikipedia.org/wiki/DikuMUD">Diku</a> type MUDs. While coding in Python is easy if you
already know C, the main effort is to get rid of old C programming habits. Trying to code Python the
way you code C will not only look ugly, it will lead to less optimal and harder to maintain code.
Reading Evennia example code is a good way to get a feel for how different problems are approached
in Python.</p>
<p>Overall, Python offers an extensive library of resources, safe memory management and excellent
handling of errors. While Python code does not run as fast as raw C code does, the difference is not
all that important for a text-based game. The main advantages of Python are an extremely fast
development cycle and easy ways to create game systems. Doing the same with C can take many times
more code and be harder to make stable and maintainable.</p>
<sectionid="core-differences">
<h2>Core Differences<aclass="headerlink"href="#core-differences"title="Permalink to this headline">¶</a></h2>
<ulclass="simple">
<li><p>As mentioned, the main difference between Evennia and a Diku-derived codebase is that Evennia is
written purely in Python. Since Python is an interpreted language there is no compile stage. It is
modified and extended by the server loading Python modules at run-time. It also runs on all computer
platforms Python runs on (which is basically everywhere).</p></li>
<li><p>Vanilla Diku type engines save their data in custom <em>flat file</em> type storage solutions. By
contrast, Evennia stores all game data in one of several supported SQL databases. Whereas flat files
have the advantage of being easier to implement, they (normally) lack many expected safety features
and ways to effectively extract subsets of the stored data. For example, if the server loses power
while writing to a flatfile it may become corrupt and the data lost. A proper database solution is
not susceptible to this - at no point is the data in a state where it cannot be recovered. Databases
are also highly optimized for querying large data sets efficiently.</p></li>
</ul>
</section>
<sectionid="some-familiar-things">
<h2>Some Familiar Things<aclass="headerlink"href="#some-familiar-things"title="Permalink to this headline">¶</a></h2>
<p>Diku expresses the character object referenced normally by:</p>
<p><codeclass="docutils literal notranslate"><spanclass="pre">struct</span><spanclass="pre">char</span><spanclass="pre">ch*</span></code> then all character-related fields can be accessed by <codeclass="docutils literal notranslate"><spanclass="pre">ch-></span></code>. In Evennia, one must
pay attention to what object you are using, and when you are accessing another through back-
handling, that you are accessing the right object. In Diku C, accessing character object is normally
<divclass="highlight-c notranslate"><divclass="highlight"><pre><span></span><spanclass="cm">/* creating pointer of both character and room struct */</span>
<p>As an example for creating Commands in Evennia via the <codeclass="docutils literal notranslate"><spanclass="pre">from</span><spanclass="pre">evennia</span><spanclass="pre">import</span><spanclass="pre">Command</span></code> the character
object that calls the command is denoted by a class property as <codeclass="docutils literal notranslate"><spanclass="pre">self.caller</span></code>. In this example
<codeclass="docutils literal notranslate"><spanclass="pre">self.caller</span></code> is essentially the ‘object’ that has called the Command, but most of the time it is an
Account object. For a more familiar Diku feel, create a variable that becomes the account object as:</p>
<h2>Emulating Evennia to Look and Feel Like A Diku/ROM<aclass="headerlink"href="#emulating-evennia-to-look-and-feel-like-a-diku-rom"title="Permalink to this headline">¶</a></h2>
<p>To emulate a Diku Mud on Evennia some work has to be done before hand. If there is anything that all
coders and builders remember from Diku/Rom days is the presence of VNUMs. Essentially all data was
saved in flat files and indexed by VNUMs for easy access. Evennia has the ability to emulate VNUMS
to the extent of categorising rooms/mobs/objs/trigger/zones[…] into vnum ranges.</p>
<p>Evennia has objects that are called Scripts. As defined, they are the ‘out of game’ instances that
exist within the mud, but never directly interacted with. Scripts can be used for timers, mob AI,
and even stand alone databases.</p>
<p>Because of their wonderful structure all mob, room, zone, triggers, etc… data can be saved in
independently created global scripts.</p>
<p>Here is a sample mob file from a Diku Derived flat file.</p>
<p>This is a very ‘caveman’ example, but it gets the idea across. You can use the keys in the
<codeclass="docutils literal notranslate"><spanclass="pre">mob_db.vnums</span></code> to act as the mob vnum while the rest contains the data.</p>
<p>Much simpler to read and edit. If you plan on taking this route, you must keep in mind that by
default evennia ‘looks’ at different properties when using the <codeclass="docutils literal notranslate"><spanclass="pre">look</span></code> command for instance. If you
create an instance of this mob and make its <codeclass="docutils literal notranslate"><spanclass="pre">self.key</span><spanclass="pre">=</span><spanclass="pre">1</span></code>, by default evennia will say:</p>
