Alacrity Conditions
Conditions serve as the intricate logic gates within the Alacrity engine, shaping the behavior of buffs and modifiers in response to specific triggers and constraints. As a foundational component of Alacrity's entity and attribute management, conditions add a layer of precision and control, enabling you to create nuanced gameplay experiences.
In this chapter we delve into the technical underpinnings of conditions within the Alacrity library. We explore how conditions are defined, the diverse ways they can be employed, and their pivotal role in tailoring the impact of buffs and modifiers on game entities.
Understanding Conditions
Conditions allows you to define and model how and when buff and modifiers should be applied to entities.
At its core, a condition in Alacrity represents a logical statement or test
that evaluates to either true or false. Conditions act as filters,
allowing buffs and modifiers to affect entities only when specific criteria
are met. These criteria can encompass a wide range of factors, from attribute
values and entity tags to complex mathematical expressions.
Alacrity's flexible condition system accommodates a variety of use cases, whether you need to implement conditional abilities, environmental effects, or intricate attribute interactions. By crafting conditions with precision, you can achieve fine-grained control over how your game mechanics respond to different in-game situations.
The Triple Role of Conditions
Conditions are versatile in their application, serving three primary roles:
1. Buff Triggers
Conditions act as a gatekeepers for buffs, determining when and on which entities these effects take effect. Buffs can specify conditions that must be satisfied before they are applied. This allows you to create spells, status effects, passives or item bonuses that only activate under specific circumstances, enhancing the strategic depth of your game.
2. Modifier Filters
Modifiers, which alter attribute values, can also leverage conditions to fine tune their impact. Conditions applied to modifiers dictate when these modifiers come into play. Modifiers can target entities and attributes selectively, ensuring that attributes adjustments align with your desired gameplay mechanics and designs.
3. Propagation Trigger
Similar to Buff triggers, Propagations can make use of conditions to determine if a buff effect should propagate to other entities related with the entity that the buff is being activated on. This, together with the entity's tagging system allow you to create intricate effects that are shared with other entities in the relation tree when specific conditions are satisfied.
Conditions Expression Language
Alacrity's condition system leverages the versatile Lua language expression syntax that empowers you to craft complex logical statements. You can utilize mathematical operators, relational comparison, and logical operators to construct intricate conditions. The expressive power of Lua allows for the creation of conditions that adapt to the dynamic nature of your game.
Condition Workflow
Throughout this chapter, we will explore the lifecycle of conditions within Alacrity, from their definition to practical implementation. We will illustrate how conditions can be authored programmatically using both Rust and Lua APIs, as well as declarative using Alacrity Lua Specs.
By the end of this chapter, you will have the knowledge and tools to harness the full potential of conditions within Alacrity. You will be equipped to design sophisticated buff systems, attribute interactions, and gameplay mechanics that respond intelligently to the evolving state of your game world.
Let's embark on a technical journey into the realm of conditions within the Alacrity library, where precision meets gameplay depth.
Anatomy of a Condition
A Condition is represented by the Condition struct in Alacrity, and it is
the cornerstone of creating conditional behaviors for your buffs. Let's
dissect the components of this data structure.
| Field | Type | Mandatory? |
|---|---|---|
| id | UUID | yes |
| blueprint | String | no |
| expression | String | yes |
| description | String | yes |
| logical_operator | bool | yes |
| version | String | no |
ID
A universally unique identifier (UUID) is assigned to each Condition. This ID distinguishes one Condition from another, ensuring each condition is unique.
The ID aids in referencing and managing conditions throughout the Alacrity system.
💡 Tip
For additional guidance about how to properly generate these IDs please, refer to the Generating UUIDs guide.
Blueprint
The blueprint field holds the original blueprint of the Condition. Blueprints act as templates for creating condition instances.
Blueprints enable the reusability of conditions across multiple buffs and modifiers.
Expression
The heart of the Condition, the expression defines the logical criteria that must
be met for the condition to evaluate to either true or false.
Expressions can encompass various conditionals, such as attributes comparisons, mathematical calculations and logical operations. They determine the condition's behavior.
ℹ️ Tip
You can check the Expressions section of this chapter if you want to know more in depth details about Alacrity's conditional system expressions.
Description
The condition description provides of human readable explanation of the condition's purpose and requirements.
Descriptions enhance code readability and facilitate debugging by providing context to developers.
Logical Operator
The logical operator output field specifies whether the condition must evaluate
to true or false for its criteria to be met.
Logical operators enable you to create conditions that trigger buffs and modifiers under specific circumstances, enhancing gameplay dynamics.
ℹ️ Tip
You can check the Logical Operator section on this chapter if you want to know more in depth details about conditions logical operators.
Version
The version field denotes the current version of the condition. Version ensure compatibility and allow for updates or modifications to conditions over time.