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
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
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
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/players.py there is an empty class ready for you
to modify. Evennia defaults to using this (it inherits directly from
Here’s an example of modifying the default Player class in code:
# in mygame/typeclasses/players.py from evennia import DefaultPlayer class Player(DefaultPlayer): # [...] at_player_creation(self): "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
… 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
@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_TYPECLASSto 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
UserDjango object, representing the logged-in user.
obj- an alias for
name- an alias for
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
sessidon each Session instance.
is_superuser(bool: True/False) - if this player is a superuser.
cmdset- This holds all the current Commands of this Player. By default these are the commands found in the cmdset defined by
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
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.