Lua Tables (to define Specs)

Alacrity allows game designers and developers to define game entities using declarative syntax in Lua. This means that game entities are defined using tables that describe their properties and behavior, rather than being hard-coded into the game's source code.

To define an entity using declarative syntax, start by creating a Lua table that contains the entity's properties. The table should have the following keys:

blueprint_id: A unique identifier for the entity in the specs.
id: An optional ID to give to any instance of this blueprint (unless explicitely override while calling `new`)
name: The name of the entity.
description: A description of the entity.
tags: A table of tags that describe the entity. Tags are used to classify entities and group them together.
attributes: A table of attributes that describe the entity's state. Attributes can be used to represent the entity's physical characteristics, such as its strength, speed or any other that should be modified by buffs.
properties: A table of properties that describe the entity's properties. Properties can be used to represent the entity's type, level, or any other property that shouldn't be modified by buffs.
buffs: A table of buffs that affect the entity. Buffs modify the entity's attributes or behavior in some way.
version: The version number of the entity definition.

Each of these keys should have a value that reflects the entity's properties. For example, the attributes key should have a table of attributes that describe the entity's sate, such as its speed or strength. Each attribute should have a name and a value.

Similarly, the properties key should have a table of properties that describe the entity's properties, such as its type or level. Each property should have a name and a value.

The tags key should have a table of tags that describe the entity. Each tag should have a name and a value.

The buffs key should have a table of buffs that affect the entity. Each buff can be either a string representing the unique identifier of a predefined buff (that is, a buff defined in the specs), or a table that describes a new embedded buff (that is, a buff that will only exist on this entity instance and doesn't exists in the specs themselves). In the case of

an embedded buffs, each one of the tables should have the following keys:

id: A unique identifier for the buff.
name: The name of the buff.
description: A description of the buff.
effect_id: The identifier of the effect that the buff applies.
modifiers: A table of attribute modifiers that the buff applies.
conditions: A table of conditions that must be met for the buff to be applied.
effect_stack_policy: The policy for stacking effects of the buff.
effect_stack_limit: The maximum number of stacked effects for the buff.
expiration: The duration of the buff in seconds. Set to 0 for a permanent buff.
stack_policy: The policy for stacking buffs.
stack_limit: The maximum number of stacked buffs.
version: The version number of the buff definition.

Once you have defined the entity using declarative syntax, you can use it in your game by just by instantiting it using its unique ID. You can then manipulate the entity and its properties using the Alacrity engine's Rust or Lua APIs.

Do no worry much about the details for now, we will extend this information in great detail in later chapters.