All gamers (real people) that opens a game Session on Evennia are doing so through an object called Player. The Player object has no in-game representation, it represents a unique game account. In order to actually get on the game the Player must puppet an Object (normally a `Character`_).

Exactly how many Sessions can interact with a Player and its Puppets at once is determined by Evennia’s MULTISESSION_MODE setting.

Apart from storing login information and other account-specific data, the Player object is what is chatting on Channels. It is also a good place to store Permissions to be consistent between different in-game characters as well as configuration options. The Player object also has its own CmdSet, the PlayerCmdSet.

logged into default evennia, you can use the @ooc command to leave your current `character`_ and go into ooc mode. you are quite limited in this mode, basically it works like a simple chat program. It acts as a staging area for switching between Characters (if your game supports that) or as a safety mode if your Character gets deleted. Use @ic to attempt to puppet a Character.

Note that the Player object can and often do have a different set of Permissions from the Character they control. Normally you should put your permissions on the Player level - this will overrule permissions set on the Character level (unless @quell-ing is used).

How to create your own Player types

You will usually not want more than one Player typeclass for all new players (but you could in principle create a system that changes a player’s typeclass dynamically).

An Evennia Player is, per definition, a Python class that includes evennia.DefaultPlayer among its parents. In mygame/typeclasses/ there is an empty class ready for you to modify. Evennia defaults to using this (it inherits directly from DefaultPlayer).

Here’s an example of modifying the default Player class in code:

# in mygame/typeclasses/

from evennia import DefaultPlayer

class Player(DefaultPlayer):
    # [...]

        "this is called only once, when player is first created"
        self.db.real_name = None      # this is set later
        self.db.real_address = None   #       "
        self.db.config_1 = True       # default config
        self.db.config_2 = False      #       "
        self.db.config_3 = 1          #       "

        # ... whatever else our game needs to know

Reload the server with @reload.

… However, if you use examine *self (the asterisk makes you examine your Player object rather than your Character), you won’t see your new Attributes yet. This is because at_player_creation is only called the very first time the Player is called and your Player object already exists (any new Players that connect will see them though). To update yourself you need to make sure to re-fire the hook on all the Players you have already created. Here is an example of how to do this using @py:

@py [player.at_player_creation() for player in evennia.managers.players.all()]

You should now see the Attributes on yourself.

If you wanted Evennia to default to a completely different Player class located elsewhere, you must point Evennia to it. Add BASE_PLAYER_TYPECLASS to your settings file, and give the python path to your custom class as its value. By default this points to typeclasses.players.Player, the empty template we used above.

Properties on Players

Beyond those properties assigned to all typeclassed objects (see Typeclasses), the Player also has the following custom properties:

  • user - a unique link to a User Django object, representing the logged-in user.
  • obj - an alias for character.
  • name - an alias for user.username
  • sessions - a list of all connected Sessions (physical connections) this object listens to. The so-called session-id (used in many places) is found as a property sessid on each Session instance.
  • is_superuser (bool: True/False) - if this player is a superuser.

Special handlers:

  • cmdset - This holds all the current Commands of this Player. By default these are the commands found in the cmdset defined by settings.CMDSET_PLAYER.
  • nicks - This stores and handles Nicks, in the same way as nicks it works on Objects. For Players, nicks are primarily used to store custom aliases for Channels.

Selection of special methods (see evennia.DefaultPlayer for details):

  • get_puppet - get a currently puppeted object connected to the Player and a given session id, if any.
  • puppet_object - connect a session to a puppetable Object.
  • unpuppet_object - disconnect a session from a puppetable Object.
  • msg - send text to the Player
  • execute_cmd - runs a command as if this Player did it.
  • search - search for Players.