I begin the journey to show the Gameplay Ability System for Unity to the general public (or atleast to the ones that find the itch page) and let them test it.

Everything or almost everything that I'm going to say here is already written in the page "What is Unity Gameplay Ability System?" of the documentation but writting it here again helps me reinforce a little the contents. 

This project/package/framework/groupofscripts is born from my experience working with the Unreal Engine this last year for my former job. After 6 or 7 years working with Unity, finding the GameplayAbilitySystem in Unreal Engine was more or less a shock. A framework ready to use with all the things necessary to have interactions and mofications of values, mechanics, flags (GameplayTags) without having to think about it was amazing. How many times have I (or any of you) tried to make a prototype or a game and only thinks about the inmediate problems only? How to move, how to attack, etc. But after some time and development you want to have the posibility of changing the jump height or the movement speed and it's back to the drawing board to redesign a little bit the code so you can now access and change those values. And this pattern repeats at least 3 o 4 times more until you decide to make the stats its own class with methods to use and modify. But then how do you know which is the original value? How many buffs and debuffs does the player (or enemy) have? This type problems (and many others) are normal and an everyday thing so finding the GameplayAbilitySystem and seeing how it provided a solution from the get go made me think.

Unity is an engine that doesn't hold your hand to much when you start a project. It doesn't have a Character prefab ready to be controlled with its physics or other ways of movement (CharacterController for example) nor it has a model for you to make yours. It hasn't a Camera set to follow things, it doesn't even have Cinemachine installed from the beginning. The ability to create a Save file for your project is relegated to the PlayerPrefs but there is not a consensus about if it is really the best way to save a game. In a way I appreciate the freedom to make things like I want to but at the same time I've always felt like a explorer finding how to make the aforementioned Save System in the best way possible or the controller for the character. It's true that once you made a couple of them it's easy to replicate but you never know if something will be different this time.

With all this thoughts in my mind I decided to try and make a Gameplay Ability System for Unity so I could have a basic framework agnostic to the type of project that I could make in the future. Yes, I'll need to make my own Save System and PlayerController but I will have a framework ready to let me change the speed of my character from the very beginning. This package/framework/groupofscripts will allow me to focus more in the mechanics of the game instead of the "And now how do I access the Health in the enemy when I hit him with the weapon?". I can simply focus in the "How do I make the combat?" instead and let the Gameplay Ability System for Unity take care of the effects of the hit. In the same way I can let the Gameplay Ability System for Unity take care of changing my stats when I get some kind of buff or character progression. All this will free me to focus on the mechanics of the project.

The project/package/framework/groupofscripts doesn't have networking functionality. I don't know anything about the networking capabilities of Unity so there are no plans in the future to implement the online component. Never say never but I'm not saying maybe either. Let's first see how this thing evolve and once it's developed and tested enough we can think about expanding the scope.

With the origin and motivation for this project/package/framework/groupofscripts out of the way, now I can talk a little more of its current features:

• Ability System Component: The Ability System Component is the cornerstone script of the whole system. This is the component that you would search for and use to interact with the whole system. It has all the methods needed to interact with the Gameplay Ability System for Unity. There is a prefab already made and ready to use inside the package. You only need to add as a child of the gameobject you want to interact with and its ready to work.
• Attributes: This are variables used to store the values used in the project by your mechanics. The Attributes are organized in Attribute Sets to allow a grater level of granularity, reusability and of course organization. This Attributes are the ones that the Gameplay Ability System for Unity interact with to use and modify during the gameplay (for example the movement speed or the strength of your attack).
• GameplayTags: This are simple strings that have a hierarchical organization inside the project. You can use them to evaluate and change the state of the game. You can think of this as dynamic booleans as you can ask the Ability System Component if it contains a GameplayTag in particular so you can change how to interact with it.
• GameplayEffects: This are scriptable objects assets that are used to interact with the GamplayTags and the Attributes. The GameplayEffects have a lot of customization so you can change how long they last, how many things they change, how often the made the changes, if other GameplayEffects can interrupt or remove them, etc. Every change you want to do in relation to the Gameplay Ability System for Unity should be done using GameplayEffects.
• GameplayAbilities: The GameplayAbilities are the scriptable objects in which you implement the mechanics of your project and how they interact with the Gameplay Ability System for Unity. You can create a GameplayAbility that let's your character jump and the only things that it does is changing the position of the character. Or you can create a GameplayAbility that makes the player sprint and apply a GameplayEffect that drains the stamina Attribute while in use.

As you can see, the Gameplay Ability System for Unity has the necessary features to start implementing mechanics and game concepts without problems. As a prototype/early release there are still features to implement and some polish to do in the ones already implemented, so let's see what I have in mind for future releases (in no particular order) :

• GameplayCues: GameplayCues are FX (visual o sound) that are automatically triggered when a GameplayEffect is applied. This allows you to have clearly defined FX for your GameplayEffects without having to fiddle and connect different assets between them. The only thing needed to make them work is use them in tandem with GameplayTags to identified and trigger them. 
• DebugShowGameplayEffects: Show a list of GameplayEffects currently applied to the Ability System Component selected.
• DebugShowGameplayAbilities: Show a list of GameplayAbilities currently granted to the Ability System Component selected.
• Refactor of GameplayAbility Tags section: Right now the GameplayAbility asset has a section with AbilityTags, Owner Required Tags, Owner Blocking Tags and Cancel Abilities with Tags. I want to remove that section and implement a list in which you can add what functionality you want the GameplayAbility to have depending on the GameplayTags selected.
• GameplayEffectsHandles: Once a GameplayEffect is applied you don't have access to it until it is finished so you cannot know the state of the GameplayEffect to show or control things like their remaining duration. I want to implement a reference to the GameplayEffects that are applied so they can be monitored by other systems that are not the Gameplay Ability System for Unity.
• GameplayAbilitiesHandles: Once a GameplayAbility is activated you may not know the state of that GameplayAbility (if it's a instanced one) until it ends. This situation doesn't let you know things like remaining cooldown, internal values that you want to represent and other things. I want to implement a reference to the GameplayAbility that are activated or triggered so they can be monitored by other systems that are not the Gameplay Ability System for Unity.

And with that I think I don't have anything more to say. This is the first post of what I hope will be a list of improvements and features that I want to implement and the feedback that I recevied from whoever wants to try and use this package/framework/groupofscripts for their prototypes, projects, hobbies, jams or whatever they want to use.

Graypath