Smart Entities Documentation

Smart Entities

List of smart entities:

• Smart Object (SO)
• Quest Smart Object (QSO)
• Smart Area (SA)
• NPCs

Smart entities are a subset of regular CryEngine entities. Normal entities can execute their own LUA script (unlike brushes for example) and can be linked with AI links. Smart entities are entities which can hold a brain and execute another scripting tool - modular behavior trees (MBT). A number of standard entities (stash, Geom Entity etc.) can be turned into a smart object by setting a Smart Object brain definition to them in the entity properties. Example: a smart stash can send AI messages to another smart object upon closure.

There only small but significant differences between the types of Smart Entites:

• Smart Objects:
  Always feature an OnUpdate subbrain which is continually executed
  Can hold the definitions of requestable behavior trees
  May feature OnRequest and OnRelease subbrains. These are executed when somebody calls or closes a behavior held by the SO
  Cannot move or execute animations (in MBT – a stash can still run an open/close animation in its LUA script)
• Quest Smart Object
  Functionally the same but automatically communicates with the Quest System.
• Smart Area
  Same possibilities and limitation as Smart Object
  Additionally, it has a volume and thus may feature OnEnter and OnExit subbrains and you can also ask whether some entity is inside or outside of its boundaries
• NPCs (that also includes animals)
  Cannot hold behaviors
  Can hold custom subbrains for special purposes
  Can move, can execute animations, and can manipulate items and smart objects (can also run an animation on a slave smart object)

A smart entity cannot execute any MBT until you set a brain definition to it. Brains are created in XGEN NPC Editor.

 

Smart Area hierarchy

Smart Areas must have a clear hierarchy and cannot intersect. Some critical systems require a basic hierarchies of these Smart Areas (listed are the brain names, not area entity names):

System Land-City-Home:

• sa_land (only 1 global area, must cover a the entire level)
  • sa_location (optional)
    • sa_city (there can be several separate cities)
      • ​​​​​​​'​​​​​​​sa_court (optional)
        • a work area (any work area like sa_smithy, sa_pub etc.)
        • sa_home (there can be several separate home under sa_city or directly under sa_land)

This system automates a lot of things about NPC’s life - their home, work, fun, distant travels, closest relevant points, propagation of reputation etc. It also influences ownership and some data fed to the crime system.

Crime district system:

• sa_crimeDisctrictRoot (only one global area, must cover the entire level)
  • sa_crimeDistrict (there can be several separate crime districts)

This systems sets up guards and jails, controls angriness levels and its spatial distribution, and tells the NPCs, who want to report a crime, where to go.

These 2 hierarchies are not directly interdependent but their areas must never intersect. It is a good practice to always contain sa_city within sa_crimeDistrict within sa_location.