38 lines
1.7 KiB
Markdown
38 lines
1.7 KiB
Markdown
# Gameplay Ability System Decision
|
|
|
|
Decision: defer Unreal's Gameplay Ability System for the MVP.
|
|
|
|
Agrarian should not adopt GAS during version 0.01 or the early version 0.1
|
|
survival foundation. The current project already has focused replicated
|
|
components for survival, inventory, crafting, resources, building placement,
|
|
time, weather, interaction, and early movement modifiers. Those systems are
|
|
small, readable, and directly aligned with the immediate playable MVP.
|
|
|
|
GAS is useful for games with many networked abilities, buffs, cooldowns,
|
|
attribute effects, prediction needs, tags, and reusable gameplay effects. That
|
|
will probably matter later for Agrarian when character skills, injuries,
|
|
illnesses, professions, equipment, medicine, combat, aging, and long-term
|
|
condition effects become more complex.
|
|
|
|
For now, adding GAS would increase setup cost, content complexity, debugging
|
|
surface, and onboarding burden before the project has enough gameplay variety
|
|
to benefit from it.
|
|
|
|
Guideline:
|
|
|
|
- Keep MVP survival systems implemented through explicit C++ components and
|
|
Blueprint assets.
|
|
- Keep future stat/effect code modular enough that it can migrate into GAS if
|
|
the need becomes clear.
|
|
- Revisit GAS after version 0.1 once combat, skills, injuries, medicine,
|
|
profession bonuses, equipment effects, and replicated long-term status
|
|
modifiers are better defined.
|
|
|
|
Revisit trigger:
|
|
|
|
- The project has many recurring timed effects, buffs, debuffs, cooldowns, or
|
|
ability activations that are becoming duplicated across systems.
|
|
- Multiplayer prediction for ability-style actions becomes important.
|
|
- Designers need data-driven effect stacking, gameplay tags, and reusable
|
|
effect authoring more than hand-coded component behavior.
|