Keywords

EntityCall

A common means for remote interaction with entities at the script layer (see also: allClients, otherClients, clientEntity).

The EntityCall object is implemented very simply at the C++ layer. It only contains the entity's ID, destination address, entity type, and EntityCall type. When a user requests a remote interaction, the underlying system first finds the entity definition by entity type,

checks the user input data according to the entity definition, and if the check passes, the underlying system packs the data and sends it to the destination. The destination process unpacks it according to the protocol and finally calls the script layer.

Note: EntityCall can only call methods declared in its corresponding def file, and cannot access entity properties or any other information.

An entity can contain up to three parts:

client: When the entity includes a client part (usually a player), the server can access the entity's client (EntityCall) property.

base: When part of the entity is created on Baseapp, in non-current Baseapp you can access the entity's base (EntityCall) property.

cell: When part of the entity is created on Cellapp, in non-current Cellapp you can access the entity's cell (EntityCall) property.

Example:

Define a client remote method in Avatar.def:

<ClientMethods>
    <hello>
    </hello>
</ClientMethods>

client\Avatar.py

class Avatar:
    def hello(self):
        print("hello")

In the Debug page input box of the GUIConsole tool (please check the process to debug in the list on the left first):

First, find the player entity (Avatar) ID in the server Baseapp log, then get the player entity (Avatar) or EntityCall by entity ID:

>>> KBEngine.entities[PlayerID].client.hello()

At this point, the client's log file will output "hello", and a remote call process is completed.

KBE_ROOT

This is a KBEngine environment variable that describes the root directory where KBEngine is located.

KBE_RES_PATH

This is a KBEngine environment variable that describes the resource directory that the KBEngine engine can read.

KBE_HYBRID_PATH

This is a KBEngine environment variable that describes the directory where the KBEngine engine executable is located.

entities.xml

All valid entity types on the server must be registered here. The engine will sequentially load the entity description information from here during initialization.

kbengine_defaults.xml

Default server configuration. Here, users can modify the configuration of all components such as cellapp, baseapp, loginapp, etc.

Note: You may often need to upgrade the engine. Modifying this file directly may cause conflicts during upgrades, and it is also not suitable for multiple projects in the same KBEngine environment.

It is recommended to override and modify in kbengine.xml; you only need to rewrite the parts you want to change in the xml according to the format.

kbengine.xml

Server configuration. Here, users can modify the configuration of all components such as cellapp, baseapp, loginapp, etc.

For details, please refer to kbengine_defaults.xml

Entity

An entity is defined as the most basic object on the server, similar to Python's base object.

When do you need to define an entity?

See http://www.kbengine.org/docs/programming/entitydef.html

entity

See: Entity

View

Each client entity connected to the server will have a View, which is similar to a viewport, allowing the client to receive events within its View.

View is related to space, and each View can have an independent size range.

Note: The space described here is an abstract concept and does not necessarily need to be bound to the concept of physical space (except for MMORPGs). For example, in a card game's core gameplay, players in a room can be considered to be in a logical space.

Events include: entity movement, client-broadcasted property changes, death and destruction, etc.

Witness

Witness.

Only cell entities bound with Witness can have an effective View. In other words, witness is a cell proxy for the client, and cellapp continuously synchronizes information within the View to the client via Witness.

When a server NPC is witnessed, the entity's onWitness callback is called. The server can use this feature to reduce CPU consumption. When an entity is not witnessed, you can stop any of its behaviors.

Space

Space. KBEngine allocates a space on cellapp, which is isolated from other spaces. View, traps, entity collisions, etc., only affect each other within the current space.

What a space actually is is defined by the user. It can be a scene, instance, room, etc.

Space

See: Space

cell

cell has two different meanings in the documentation.

Usually, if describing the Entity.cell property, it actually refers to the entity's CellEntityCall.

If describing cell on cellapp, it usually refers to a part of a space. When cellapp performs load balancing, a space may be divided into N parts, each called a cell, and each cell is maintained by a different process.

base

Usually refers to the Base entity on baseapp or a BaseEntityCall pointing to the Base entity, for example: Entity.base.

client

Usually refers to the client or an EntityCall pointing to the client entity, for example: Entity.client.

cellapp

The cellapp process is mainly responsible for position-related game logic, View, AI, scene rooms, etc.

See: cellapp

baseapp

The baseapp process is mainly responsible for communication with the client, position-independent game logic (guild manager, chat system, game lobby, leaderboard, etc.), archiving and backup, etc.

See: baseapp

real

Refers to an entity on a cell, which truly exists on the current cell (there is a type of entity that is just a shadow broadcast from another cell, see: ghost).

ghost

This type of entity is actually a boundary shadow entity produced by the cellapp dynamic load balancing mechanism, which divides a complete space into N parts and assigns them to cells in different processes for maintenance.

Because space is divided into multiple regions, there are boundaries. To make the client unaware of the existence of boundaries, each cell synchronizes entities within a certain range of its boundary area to the neighboring cell, so that entities in the boundary area can interact with those in the neighboring boundary area. Only part of the data of such entities is synchronized (CELL_PUBLIC and other cell-broadcasted properties).

Non-ghost entities are called real entities.

vector3

Describes and manages a vector in 3D space.

It has x, y, and z properties representing different axes.

Example usage in script:

import Math 
v = Math.Vector3()