Python MUD/MUX/MUSH/MU* development system http://www.evennia.com
Find a file
2011-09-04 07:27:11 +00:00
contrib Trunk: Merged griatch-branch. This implements a new reload mechanism - splitting Evennia into two processes: Server and Portal with different tasks. Also cleans and fixes several bugs in script systems as well as introduces i18n (courtesy of raydeejay). 2011-09-03 10:22:19 +00:00
docs Adding a docs/requirements.txt for our pip/viritualenv users. 2010-11-22 15:33:19 +00:00
game Fixed typo. Changed reload argument for evennia.py to be 'reload' rather than 'restart'. 2011-09-03 15:10:28 +00:00
locale Trunk: Merged griatch-branch. This implements a new reload mechanism - splitting Evennia into two processes: Server and Portal with different tasks. Also cleans and fixes several bugs in script systems as well as introduces i18n (courtesy of raydeejay). 2011-09-03 10:22:19 +00:00
src Fixed bug in get command that let you pick something up several times. 2011-09-04 07:27:11 +00:00
__init__.py Added @mvattr command as per MUX (Issue 25). Cleaned up @set to give better feedback. Some minor cleanups. 2009-08-29 17:41:00 +00:00
CODING_STYLE Trunk: Merged griatch-branch. This implements a new reload mechanism - splitting Evennia into two processes: Server and Portal with different tasks. Also cleans and fixes several bugs in script systems as well as introduces i18n (courtesy of raydeejay). 2011-09-03 10:22:19 +00:00
INSTALL Trunk: Merged griatch-branch. This implements a new reload mechanism - splitting Evennia into two processes: Server and Portal with different tasks. Also cleans and fixes several bugs in script systems as well as introduces i18n (courtesy of raydeejay). 2011-09-03 10:22:19 +00:00
LICENSE Debugged and added @cpattr and @mvattr. Added unittest cases for all default commands for which they are suitable. Many small bug fixes as part of that. 2011-04-21 16:45:18 +00:00
README Trunk: Merged griatch-branch. This implements a new reload mechanism - splitting Evennia into two processes: Server and Portal with different tasks. Also cleans and fixes several bugs in script systems as well as introduces i18n (courtesy of raydeejay). 2011-09-03 10:22:19 +00:00
sitecustomize.py Trunk: Merged the Devel-branch (branches/griatch) into /trunk. This constitutes a major refactoring of Evennia. Development will now continue in trunk. See the wiki and the past posts to the mailing list for info. /Griatch 2010-08-29 18:46:58 +00:00
VERSION Updated the trunk version file from 'SVN-griatch-branch' to 'SVN-Alpha'. 2010-08-29 19:02:07 +00:00

Evennia README (http://evennia.com)
-------------- 

- Aug 2011 - split evennia into portal + server for better reload /Griatch
- May 2011 - all commands implemented, web client, contribs /Griatch
- Aug 2010 - evennia devel merged into trunk /Griatch
- May 2010 - merged ABOUT and README. Added Current status /Griatch
- < 2010 (earlier revisions)

Contents:
---------
- Version
- About Evennia
- Current Status
- Contact, Support and Development
- Directory structure
- Design Objectives
- The Components


Version
-------
Evennia Alpha SVN version

About Evennia
-------------

Evennia is a MUD/MUX/MU* server that aims to provide a functional
bare-bones base for developers. Some of our main features are: 

* Coded and extended using normal Python modules.
* Extensive web integration due to our use of Django. 
* Runs its own Twisted webserver. Comes with game website and ajax web-browser mud client. 
* Extensive current and potential connectivity and protocol-support through Twisted.
* Extremely easy-to-manipulate SQL database back-end via Django 
  (djangoproject.com)
* Powerful an extremely extendable bare-bones base system 

The essential points here are the web integration and the SQL backing via
Django. The Django framework has database abstraction abilities that give us
many features free, such as:

* The codebase will run transparently on MySQL, SQLite, or Postgres
* At the time of this document's writing, our SQL-backed application here
  contains 0 lines of SQL. Django's database abstraction layer is absolutely
  simple yet very powerful.
* For any model we outline for the server's use, we have the ability to
  more or less automatically generate a web-based admin interface for it with
  two lines of code. This lets you Create, Update, or Delete entries, as well
  limit permissions for those abilities.
* On the web-based side of things, features such as automatic form validation,
  abstraction of sessions and cookies, and access to whatever game data you
  desire are all attractive.  

See the INSTALL file for help on setting up and running Evennia. 


Current Status
--------------

Aug 2011:
Split Evennia into two processes: Portal and Server. After a lot of
work trying to get in-memory code-reloading to work, it's clear this
is not Python's forte - it's impossible to catch all exceptions,
especially in asynchronous code like this.  Trying to do so results in
hackish, flakey and unstable code. With the Portal-Server split, the
Server can simply be rebooted while players connected to the Portal
remain connected. The two communicates over twisted's AMP protocol.

May 2011: 
The new version of Evennia, originally hitting trunk in Aug2010, is
maturing. All commands from the pre-Aug version, including IRC/IMC2
support works again. An ajax web-client was added earlier in the year,
including moving Evennia to be its own webserver (no more need for 
Apache or django-testserver). Contrib-folder added. 

Aug 2010:
Evennia-griatch-branch is ready for merging with trunk. This marks a
rather big change in the inner workings of the server, such as the
introduction of TypeClasses and Scripts (as compared to the old
ScriptParents and Events) but should hopefully bring everything
together into one consistent package as code development continues.

May 2010:
Evennia is currently being heavily revised and cleaned from 
the years of gradual piecemeal development. It is thus in a very 
'Alpha' stage at the moment. This means that old code snippets
will not be backwards compatabile. Changes touch almost all
parts of Evennia's innards, from the way Objects are handled 
to Events, Commands and Permissions. 




Contact, Support and Development
-----------------------
This is still alpha software, but we try to give support best we can
if you have questions. Make a post to the mailing list or chat us up
on IRC. We also have a bug tracker if you want to report
bugs. Finally, if you are willing to help with the code work, we much
appreciate all help!  Visit either of the following resources:

* Evennia Webpage
  http://evennia.com
  
* Evennia manual (wiki)
  http://code.google.com/p/evennia/wiki/Index

* Evennia Code Page (See INSTALL text for installation)
  http://code.google.com/p/evennia/source/checkout

* Bug tracker 
  http://code.google.com/p/evennia/issues/list

* IRC channel 
  visit channel #evennia on the Freenode IRC network


Directory structure
-------------------
evennia
 |_______src
 |        |___(engine-related dirs)
 |        
 |_______game (start the server)
 |        |___gamesrc
 |              |___(game-related dirs)
 | 
 |_______contrib 

The two main directories you will spend most of your time in
are src/ and game/ (probably mostly game/). 

Basically src contains everything related to 
running the gritty stuff behind the scenes. Unless you are an
Evennia developer you should normally make sure never to edit 
things in src/, since this is where we push new revisions that
may overwrite your changes when you update. You will however 
need to have a good feeling for the resources supplied by 
the functions in src, since accessing them correctly is the key 
to making your dream game come true. 

If src/ is the Evennia developer's domain, the game/ directory 
on the other hand contains YOUR game. This is where you will 
define and extend the commands, objects and systems of Evennia
to make your dream game. game/ contains the main server settings
and the actual evennia executable to start things. game/gamesrc/
holds all the templates for creating objects in your virtual world. 

contrib/ contains optional code snippets. These are potentially useful
but deemed to be too game-specific to be part of the server itself.
Modules in contrib are not used unless you yourself decide to import
and use them.

With this little first orientation, you should head into the online 
Evennia wiki documentation to get going with the codebase. 


Design Objectives
-----------------
1) To create a barebones MU* server that serves as a great foundation
for capable admins to craft their own respective games. It is not the
intention to provide a full-fledged, ready-to-run base, rather Evennia
is offering the means to make such games.

2) Development of games on Evennia must be easy for anyone with some
degree of Python experience. Building needs to be easy, and per-room,
per-object, and environmental customizations need to be simple to
do. This is handled by use of normal Python classes transparently
abstracting and wrapping the SQL backend. The user should not need to 
use SQL or even know Django to any greater extent. 

3) The server must utilize SQL as a storage back-end to allow for web->game
integration through Django. 

The Components
--------------
Python (Including the SQL driver of your choice)
  |-Twisted (http://twistedmatrix.com)
  |-SQL (MySQL, SQLite, Postgresql)
  |-Django (http://djangoproject.com)

Evennia is built on top of Twisted, a networking engine that handles a lot
of the guts and lower-level socket stuff for us.

Serving as our storage medium, SQL allows for very simple code in many cases, and
can lead to a game being a lot more scalable due to the inherent speed of
most modern SQL servers. Another extremely important benefit is that by
storing everything in SQL, we make the entire game accessible from other
means, such as a website. Which leads us to the next component.

Django is perhaps one of the most interesting introductions to the codebase.
 Django is technically a Python web framework, but it also includes a great 
data modeling and database abstraction module. This means that things like 
Players or Objects can be represented by a very short class, then related to one 
another. This allows us to add, remove, delete, and manipulate things in our database
very easily. Another huge benefit is the admin interface that Django more
or less automatically generates for us. Instead of a bunch of clunky admin
commands, you can fire up your web browser and administer pretty much 
everything from there, although equivalent in-game commands may be offered.

The possibilities for developing your game's website are nearly endless with
this tandem of MU* server, SQL, and Django.