You can create an instance of
TPlayer and assign to
This provides various features:
It keeps track of player life, owned items and more.
It automatically updates some navigation methods based on whether player in swimming, dead etc.
By default player is also a central enemy of all hostile creatures
CastleCreatures unit. This is configurable (by
Note that the player instance is not necessary for basic 3D navigation
(the only thing really necessary is a camera, which is automatically created and
To load a Player do this:
uses ..., CastlePlayer; var Viewport: TCastleViewport; Level: TLevel; Player: TPlayer; begin Viewport := TCastleViewport.Create(Application); Viewport.FullSize := true; Window.Controls.InsertFront(Viewport); Level := TLevel.Create(Application); Level.Viewport := Viewport; Player := TPlayer.Create(Application); Level.Player := Player; Level.Load(...); end;
Player is a descendant of
which means that you can add
additional 3D objects as it's children, like
Player.Add(Some3DObject). These 3D objects will always be rendered
relative to the player, so they will move along with the player. This
is an easy way to add 3D weapon models and similar things to your
display. Although, for weapons, we actually handle it automatically
for you, using
But you can also add/remove additional 3D objects this way
(e.g. a 3D torch that is held by the player).
As an additional feature, all 3D objects that are children of player
will be rendered on top of other 3D world. This means that even
if you 3D weapon model is large (like a long sword pointing out from
camera), it will never go "inside the wall". You can turn this feature
Aside from special
TPlayer.RenderOnTop behavior, the 3D objects
that are children of player are rendered and processed just like all other 3D
stuff. For example, they can be animated by the
Note that the player 3D objects do not make the player
collision sphere (aka camera radius) larger. If you want to make the
collision sphere larger, you can do it by placing a
node in a level 3D file, and adjusting the 1st item of
field — it determines the camera radius.
for an example VRML/X3D configuring the player.
There is an alternative way to place things relative to player view:
use X3D ProximitySensor node. See
in our demo VRML/X3D models for a simple example how to code it in X3D. This allows you to place
the 3D things that are relative to player inside a larger X3D file,
together e.g. with normal level geometry (which may be an advantage or
disadvantage, depending on what you want). The disadvantage is that we do
not implement layers in X3D now, so such geometry will overlap with 3D
level geometry (unless it will always fit within camera radius).
Sometimes it's nice to give content creators a way to modify player
behavior without touching the game source code.
To allow this you can load player configuration by
TPlayer.LoadFromFile method. See creating player data for a sample and documentation how player configuration file looks like.
Copyright Michalis Kamburelis and Castle Game Engine Contributors.
This webpage is also open-source and we welcome pull requests to improve it.