mirror of
https://github.com/evennia/evennia.git
synced 2026-03-16 21:06:30 +01:00
382 lines
22 KiB
Markdown
382 lines
22 KiB
Markdown
# Glossary
|
|
|
|
|
|
This explains common recurring terms used in the Evennia docs. It will be expanded as needed.
|
|
|
|
- _[account](./Glossary.md#account)_ - the player's account on the game
|
|
- _[admin-site](./Glossary.md#admin-site)_ - the Django web page for manipulating the database
|
|
- _[attribute](./Glossary.md#attribute)_ - persistent, custom data stored on typeclasses
|
|
- _[channel](./Glossary.md#channel)_ - game communication channels
|
|
- _[character](./Glossary.md#character)_ - the player's avatar in the game, controlled from
|
|
_[account](./Glossary.md#account)_
|
|
- _[contrib](./Glossary.md#contrib)_ - a term used for optional code contributed by the community.
|
|
- _[core](./Glossary.md#core)_ - a term used for the code distributed with Evennia proper
|
|
- _[django](./Glossary.md#django)_ - web framework Evennia uses for database access and web integration
|
|
- _[field](./Glossary.md#field)_ - a _[typeclass](./Glossary.md#typeclass)_ property representing a database
|
|
column
|
|
- _[git](./Glossary.md#git)_ - the version-control system we use
|
|
- _[github](./Glossary.md#github)_ - the online hosting of our source code
|
|
- _[migrate](./Glossary.md#migrate)_ - updating the database schema
|
|
- _[multisession mode`](#multisession-mode)_ - a setting defining how users connect to Evennia
|
|
- _[object](./Glossary.md#object)_ - Python instance, general term or in-game
|
|
_[typeclass](./Glossary.md#typeclass)_
|
|
- _[pip](./Glossary.md#pip)_ - the Python installer
|
|
- _player_ - the human connecting to the game with their client
|
|
- _[puppet](./Glossary.md#puppet)_ - when an [account](./Glossary.md#account) controls an in-game
|
|
[object](./Glossary.md#object)
|
|
- _[property](./Glossary.md#property)_ - a python property
|
|
- _evenv_ - see _[virtualenv](./Glossary.md#virtualenv)_
|
|
- _[repository](./Glossary.md#repository)_ - a store of source code + source history
|
|
- _[script](./Glossary.md#script)_ - a building block for custom storage, systems and time-keepint
|
|
- _[session](./Glossary.md#session)_ - represents one client connection
|
|
- _[ticker](./Glossary.md#ticker)_ - Allows to run events on a steady 'tick'
|
|
- _[twisted](./Glossary.md#twisted)_ - networking engine responsible for Evennia's event loop and
|
|
communications
|
|
- _[typeclass](./Glossary.md#typeclass)_ - Evennia's database-connected Python class
|
|
- _upstream_ - see _[github](./Glossary.md#github)_
|
|
- _[virtualenv](./Glossary.md#virtualenv)_ - a Python program and way to make an isolated Python install
|
|
|
|
|
|
---
|
|
|
|
## _account_
|
|
|
|
The term 'account' refers to the [player's](./Glossary.md#account) unique account on the game. It is
|
|
represented by the `Account` [typeclass](./Glossary.md#typeclass) and holds things like email, password,
|
|
configuration etc.
|
|
|
|
When a player connects to the game, they connect to their account. The account has *no*
|
|
representation in the game world. Through their Account they can instead choose to
|
|
[puppet](./Glossary.md#puppet) one (or more, depending on game mode) [Characters](./Glossary.md#character) in
|
|
the game.
|
|
|
|
In the default [multisession mode](Components/Sessions.md#multisession-mode) of Evennia, you immediately start
|
|
puppeting a Character with the same name as your Account when you log in - mimicking how older
|
|
servers used to work.
|
|
|
|
## _admin-site_
|
|
|
|
This usually refers to [Django's](./Glossary.md#django) *Admin site* or database-administration web page
|
|
([link to Django docs](https://docs.djangoproject.com/en/2.1/ref/contrib/admin/)). The admin site is
|
|
an automatically generated web interface to the database (it can be customized extensively). It's
|
|
reachable from the `admin` link on the default Evennia website you get with your server.
|
|
|
|
## _attribute_
|
|
|
|
The term _Attribute_ should not be confused with ([properties](./Glossary.md#property) or
|
|
[fields](./Glossary.md#field). The `Attribute` represents arbitrary pieces of data that can be attached
|
|
to any [typeclassed](./Glossary.md#typeclass) entity in Evennia. Attributes allows storing new persistent
|
|
data on typeclasses without changing their underlying database schemas.
|
|
[Read more about Attributes here](Components/Attributes.md).
|
|
|
|
## _channel_
|
|
|
|
A _Channel_ refers to an in-game communication channel. It's an entity that people subscribe to and
|
|
which re-distributes messages between all subscribers. Such subscribers default to being
|
|
[Accounts](./Glossary.md#account), for out-of-game communication but could also be [Objects (usually
|
|
Characters)](./Glossary.md#character) if one wanted to adopt Channels for things like in-game walkie-
|
|
talkies or phone systems. It is represented by the `Channel` typeclass. [You can read more about the
|
|
comm system here](Components/Channels.md).
|
|
|
|
## _character_
|
|
|
|
The _Character_ is the term we use for the default avatar being [puppeted](./Glossary.md#puppet) by the
|
|
[account](./Glossary.md#account) in the game world. It is represented by the `Character` typeclass (which
|
|
is a child of [Object](./Glossary.md#object)). Many developers use children of this class to represent
|
|
monsters and other NPCs. You can [read more about it here](Components/Objects.md#subclasses-of-object).
|
|
|
|
## _django_
|
|
|
|
[Django](https://www.djangoproject.com/) is a professional and very popular Python web framework,
|
|
similar to Rails for the Ruby language. It is one of Evennia's central library dependencies (the
|
|
other one is [Twisted](./Glossary.md#twisted)). Evennia uses Django for two main things - to map all
|
|
database operations to Python and for structuring our web site.
|
|
|
|
Through Django, we can work with any supported database (SQlite3, Postgres, MySQL ...) using generic
|
|
Python instead of database-specific SQL: A database table is represented in Django as a Python class
|
|
(called a *model*). An Python instance of such a class represents a row in that table.
|
|
|
|
There is usually no need to know the details of Django's database handling in order to use Evennia -
|
|
it will handle most of the complexity for you under the hood using what we call
|
|
[typeclasses](./Glossary.md#typeclass). But should you need the power of Django you can always get it.
|
|
Most commonly people want to use "raw" Django when doing more advanced/custom database queries than
|
|
offered by Evennia's [default search functions](Howtos/Beginner-Tutorial/Part1/Searching-Things.md). One will then need
|
|
to read about Django's _querysets_. Querysets are Python method calls on a special form that lets
|
|
you build complex queries. They get converted into optimized SQL queries under the hood, suitable
|
|
for your current database. [Here is our tutorial/explanation of Django queries](Tutorial-Searching-
|
|
For-Objects#queries-in-django).
|
|
|
|
> By the way, Django (and Evennia) does allow you to fall through and send raw SQL if you really
|
|
want to. It's highly unlikely to be needed though; the Django database abstraction is very, very
|
|
powerful.
|
|
|
|
The other aspect where Evennia uses Django is for web integration. On one end Django gives an
|
|
infrastructure for wiring Python functions (called *views*) to URLs: the view/function is called
|
|
when a user goes that URL in their browser, enters data into a form etc. The return is the web page
|
|
to show. Django also offers templating with features such as being able to add special markers in
|
|
HTML where it will insert the values of Python variables on the fly (like showing the current player
|
|
count on the web page). [Here is one of our tutorials on wiring up such a web page](Add-a-simple-
|
|
new-web-page). Django also comes with the [admin site](./Glossary.md#admin-site), which automatically
|
|
maps the database into a form accessible from a web browser.
|
|
|
|
## _core_
|
|
|
|
This term is sometimes used to represent the main Evennia library code suite, *excluding* its
|
|
[contribs](./Glossary.md#contrib) directory. It can sometimes come up in code reviews, such as
|
|
|
|
> Evennia is game-agnostic but this feature is for a particular game genre. So it does not belong in
|
|
core. Better make it a contrib.
|
|
|
|
## _contrib_
|
|
|
|
Game-specific code and examples are distributed in evennia's [contribs/](Contribs/Contribs-Overview.md) folder.
|
|
This is game-specific, optional code created by the Evennia community.
|
|
|
|
## _field_
|
|
|
|
A _field_ or _database field_ in Evennia refers to a [property](./Glossary.md#property) on a
|
|
[typeclass](./Glossary.md#typeclass) directly linked to an underlying database column. Only a few fixed
|
|
properties per typeclass are database fields but they are often tied to the core functionality of
|
|
that base typeclass (for example [Objects](./Glossary.md#object) store its location as a field). In all
|
|
other cases, [attributes](./Glossary.md#attribute) are used to add new persistent data to the typeclass.
|
|
[Read more about typeclass properties here](Components/Typeclasses.md#about-typeclass-properties).
|
|
|
|
## _git_
|
|
|
|
[Git](https://git-scm.com/) is a [version control](https://en.wikipedia.org/wiki/Version_control)
|
|
tool. It allows us to track the development of the Evennia code by dividing it into units called
|
|
*commits*. A 'commit' is sort of a save-spot - you save the current state of your code and can then
|
|
come back to it later if later changes caused problems. By tracking commits we know what 'version'
|
|
of the code we are currently using.
|
|
|
|
Evennia's source code + its source history is jointly called a [repository](./Glossary.md#repository).
|
|
This is centrally stored at our online home on [GitHub](./Glossary.md#github). Everyone using or
|
|
developing Evennia makes a 'clone' of this repository to their own computer - everyone
|
|
automatically gets everything that is online, including all the code history.
|
|
|
|
> Don't confuse Git and [GitHub](./Glossary.md#github). The former is the version control system. The
|
|
latter is a website (run by a company) that allows you to upload source code controlled by Git for
|
|
others to see (among other things).
|
|
|
|
Git allows multiple users from around the world to efficiently collaborate on Evennia's code: People
|
|
can make local commits on their cloned code. The commits they do can then be uploaded to GitHub and
|
|
reviewed by the Evennia lead devs - and if the changes look ok they can be safely *merged* into the
|
|
central Evennia code - and everyone can *pull* those changes to update their local copies.
|
|
|
|
Developers using Evennia often uses Git on their own games in the same way - to track their changes
|
|
and to help collaboration with team mates. This is done completely independently of Evennia's Git
|
|
usage.
|
|
|
|
Common usage (for non-Evennia developers):
|
|
- `git clone <github-url>` - clone an online repository to your computer. This is what you do when
|
|
you 'download' Evennia. You only need to do this once.
|
|
- `git pull` (inside local copy of repository) - sync your local repository with what is online.
|
|
|
|
> Full usage of Git is way beyond the scope of this glossary. See
|
|
[Tutorial - version control](Coding/Version-Control.md) for more info and links to the Git documentation.
|
|
|
|
## _migrate_
|
|
|
|
This term is used for upgrading the database structure (it's _schema_ )to a new version. Most often
|
|
this is due to Evennia's [upstream](./Glossary.md#github) schema changing. When that happens you need to
|
|
migrate that schema to the new version as well. Once you have used [git](./Glossary.md#git) to pull the
|
|
latest changes, just `cd` into your game dir and run
|
|
|
|
evennia migrate
|
|
|
|
That should be it (see [virtualenv](./Glossary.md#virtualenv) if you get a warning that the `evennia`
|
|
command is not available). See also [Updating your game](Coding/Updating-Your-Game.md) for more details.
|
|
|
|
> Technically, migrations are shipped as little Python snippets of code that explains which database
|
|
actions must be taken to upgrade from one version of the schema to the next. When you run the
|
|
command above, those snippets are run in sequence.
|
|
|
|
## _multisession mode_
|
|
|
|
This term refers to the `MULTISESSION_MODE` setting, which has a value of 0 to 3. The mode alters
|
|
how players can connect to the game, such as how many Sessions a player can start with one account
|
|
and how many Characters they can control at the same time. It is [described in detail
|
|
here](Components/Sessions.md#multisession-mode).
|
|
|
|
## _github_
|
|
|
|
[Github](https://github.com/evennia) is where Evennia's source code and documentation is hosted.
|
|
This online [repository](./Glossary.md#repository) of code we also sometimes refer to as _upstream_.
|
|
|
|
GitHub is a business, offering free hosting to Open-source projects like Evennia. Despite the
|
|
similarity in name, don't confuse GitHub the website with [Git](./Glossary.md#git), the versioning
|
|
system. Github hosts Git [repositories](./Glossary.md#repository) online and helps with collaboration and
|
|
infrastructure. Git itself is a separate project.
|
|
|
|
## _object_
|
|
|
|
In general Python (and other [object-oriented languages](https://en.wikipedia.org/wiki/Object-
|
|
oriented_programming)), an `object` is what we call the instance of a *class*. But one of Evennia's
|
|
core [typeclasses](./Glossary.md#typeclass) is also called "Object". To separate these in the docs we
|
|
try to use `object` to refer to the general term and capitalized `Object` when we refer to the
|
|
typeclass.
|
|
|
|
The `Object` is a typeclass that represents all *in-game* entities, including
|
|
[Characters](./Glossary.md#character), rooms, trees, weapons etc. [Read more about Objects here](Components/Objects.md).
|
|
|
|
## _pip_
|
|
|
|
_[pip](https://pypi.org/project/pip/)_ comes with Python and is the main tool for installing third-
|
|
party Python packages from the web. Once a python package is installed you can do `import
|
|
<packagename>` in your Python code.
|
|
|
|
Common usage:
|
|
- `pip install <package-name>` - install the given package along with all its dependencies.
|
|
- `pip search <name>` - search Python's central package repository [PyPi](https://pypi.org/) for a
|
|
package of that name.
|
|
- `pip install --upgrade <package_name>` - upgrade a package you already have to the latest version.
|
|
- `pip install <packagename>==1.5` - install exactly a specific package version.
|
|
- `pip install <folder>` - install a Python package you have downloaded earlier (or cloned using
|
|
git).
|
|
- `pip install -e <folder>` - install a local package by just making a soft link to the folder. This
|
|
means that if the code in `<folder>` changes, the installed Python package is immediately updated.
|
|
If not using `-e`, one would need to run `pip install --upgrade <folder>` every time to make the
|
|
changes available when you import this package into your code. Evennia is installed this way.
|
|
|
|
For development, `pip` is usually used together with a [virtualenv](./Glossary.md#virtualenv) to install
|
|
all packages and dependencies needed for a project in one, isolated location on the hard drive.
|
|
|
|
## _puppet_
|
|
|
|
An [account](./Glossary.md#account) can take control and "play as" any [Object](./Glossary.md#object). When
|
|
doing so, we call this _puppeting_, (like [puppeteering](https://en.wikipedia.org/wiki/Puppeteer)).
|
|
Normally the entity being puppeted is of the [Character](./Glossary.md#character) subclass but it does
|
|
not have to be.
|
|
|
|
## _property_
|
|
|
|
A _property_ is a general term used for properties on any Python object. The term also sometimes
|
|
refers to the `property` built-in function of Python ([read more here](https://www.python-
|
|
course.eu/python3_properties.php)). Note the distinction between properties,
|
|
[fields](./Glossary.md#field) and [Attributes](./Glossary.md#attribute).
|
|
|
|
## _repository_
|
|
|
|
A _repository_ is a version control/[git](./Glossary.md#git) term. It represents a folder containing
|
|
source code plus its versioning history.
|
|
|
|
> In Git's case, that history is stored in a hidden folder `.git`. If you ever feel the need to look
|
|
into this folder you probably already know enough Git to know why.
|
|
|
|
The `evennia` folder you download from us with `git clone` is a repository. The code on
|
|
[GitHub](./Glossary.md#github) is often referred to as the 'online repository' (or the _upstream_
|
|
repository). If you put your game dir under version control, that of course becomes a repository as
|
|
well.
|
|
|
|
## _script_
|
|
|
|
When we refer to _Scripts_, we generally refer to the `Script` [typeclass](Components/Typeclasses.md). Scripts are
|
|
the mavericks of Evennia - they are like [Objects](./Glossary.md#object) but without any in-game
|
|
existence. They are useful as custom places to store data but also as building blocks in persistent
|
|
game systems. Since the can be initialized with timing capabilities they can also be used for long-
|
|
time persistent time keeping (for fast updates other types of timers may be better though).
|
|
[Read more about Scripts here](Components/Scripts.md)
|
|
|
|
## _session_
|
|
|
|
A [Session](Components/Sessions.md) is a Python object representing a single client connection to the server. A
|
|
given human player could connect to the game from different clients and each would get a Session
|
|
(even if you did not allow them to actually log in and get access to an
|
|
[account](./Glossary.md#account)).
|
|
|
|
Sessions are _not_ [typeclassed](./Glossary.md#typeclass) and has no database persistence. But since they
|
|
always exist (also when not logged in), they share some common functionality with typeclasses that
|
|
can be useful for certain game states.
|
|
|
|
## _tag_
|
|
|
|
A [Tag](Components/Tags.md) is used to group and categorize other database entitiess together in an efficient way
|
|
so they can be efficiently searched later.
|
|
|
|
## _ticker_
|
|
|
|
The [Ticker handler](Components/TickerHandler.md) runs Evennia's optional 'ticker' system. In other engines, such
|
|
as [DIKU](https://en.wikipedia.org/wiki/DikuMUD), all game events are processed only at specific
|
|
intervals called 'ticks'. Evennia has no such technical limitation (events are processed whenever
|
|
needed) but using a fixed tick can still be useful for certain types of game systems, like combat.
|
|
Ticker Handler allows you to emulate any number of tick rates (not just one) and subscribe actions
|
|
to be called when those ticks come around.
|
|
|
|
## _typeclass_
|
|
|
|
The [typeclass](Components/Typeclasses.md) is an Evennia-specific term. A typeclass allows developers to work with
|
|
database-persistent objects as if they were normal Python objects. It makes use of specific
|
|
[Django](./Glossary.md#django) features to link a Python class to a database table. Sometimes we refer to
|
|
such code entities as _being typeclassed_.
|
|
|
|
Evennia's main typeclasses are [Account](./Glossary.md#account), [Object](./Glossary.md#object),
|
|
[Script](./Glossary.md#script) and [Channel](./Glossary.md#channel). Children of the base class (such as
|
|
[Character](./Glossary.md#character)) will use the same database table as the parent, but can have vastly
|
|
different Python capabilities (and persistent features through [Attributes](./Glossary.md#attribute) and
|
|
[Tags](./Glossary.md#tag). A typeclass can be coded and treated pretty much like any other Python class
|
|
except it must inherit (at any distance) from one of the base typeclasses. Also, creating a new
|
|
instance of a typeclass will add a new row to the database table to which it is linked.
|
|
|
|
The [core](./Glossary.md#core) typeclasses in the Evennia library are all named `DefaultAccount`,
|
|
`DefaultObject` etc. When you initialize your [game dir] you automatically get empty children of
|
|
these, called `Account`, `Object` etc that you can start working with.
|
|
|
|
## _twisted_
|
|
|
|
[Twisted](https://twistedmatrix.com/trac/) is a heavy-duty asynchronous networking engine. It is one
|
|
of Evennia's two major library dependencies (the other one is [Django](./Glossary.md#django)). Twisted is
|
|
what "runs" Evennia - it handles Evennia's event loop. Twisted also has the building blocks we need
|
|
to construct network protocols and communicate with the outside world; such as our MUD-custom
|
|
version of Telnet, Telnet+SSL, SSH, webclient-websockets etc. Twisted also runs our integrated web
|
|
server, serving the Django-based website for your game.
|
|
|
|
## _virtualenv_
|
|
|
|
The standard [virtualenv](https://virtualenv.pypa.io/en/stable/) program comes with Python. It is
|
|
used to isolate all Python packages needed by a given Python project into one folder (we call that
|
|
folder `evenv` but it could be called anything). A package environment created this way is usually
|
|
referred to as "a virtualenv". If you ever try to run the `evennia` program and get an error saying
|
|
something like "the command 'evennia' is not available" - it's probably because your virtualenv is
|
|
not 'active' yet (see below).
|
|
|
|
Usage:
|
|
|
|
- `python3.10 -m venv evenv` - initialize a new virtualenv-folder `evenv` in the current
|
|
location. You can call this whatever you like. The Python-version you use for this call will be the one used
|
|
for everything inside the virtualenv.
|
|
- `source evenv/bin/activate` (linux/mac) or `evenv\Scripts\activate`(windows) - this activates the
|
|
virtualenv.
|
|
- `deactivate` - turn off the currently activated virtualenv.
|
|
|
|
A virtualenv is 'activated' only for the console/terminal it was started in, but it's safe to
|
|
activate the same virtualenv many times in different windows if you want. Once activated, all Python
|
|
packages now installed with [pip](./Glossary.md#pip) will install to `evenv` rather than to a global
|
|
location like `/usr/local/bin` or `C:\Program Files`.
|
|
|
|
> Note that if you have root/admin access you *could* install Evennia globally just fine, without
|
|
using a virtualenv. It's strongly discouraged and considered bad practice though. Experienced Python
|
|
developers tend to rather create one new virtualenv per project they are working on, to keep the
|
|
varying installs cleanly separated from one another.
|
|
|
|
When you execute Python code within this activated virtualenv, *only* those packages installed
|
|
within will be possible to `import` into your code. So if you installed a Python package globally on
|
|
your computer, you'll need to install it again in your virtualenv.
|
|
|
|
> Virtualenvs *only* deal with Python programs/packages. Other programs on your computer couldn't
|
|
care less if your virtualenv is active or not. So you could use `git` without the virtualenv being
|
|
active, for example.
|
|
|
|
When your virtualenv is active you should see your console/terminal prompt change to
|
|
|
|
(evenv) ...
|
|
|
|
... or whatever name you gave the virtualenv when you initialized it.
|
|
|
|
> We sometimes say that we are "in" the virtualenv when it's active. But just to be clear - you
|
|
never have to actually `cd` into the `evenv` folder. You can activate it from anywhere and will
|
|
still be considered "in" the virtualenv wherever you go until you `deactivate` or close the
|
|
console/terminal.
|
|
|
|
So, when do you *need* to activate my virtualenv? If the virtualenv is not active, none of the Python
|
|
packages/programs you installed in it will be available to you. So at a minimum, *it needs to be
|
|
activated whenever you want to use the `evennia` command* for any reason.
|