Official Combat system

Happy new year @Amel-Unity
Are we using any targeting system (https://zelda.fandom.com/wiki/Z-targeting)

 

Based on your feedback I started to build a proposal for the combat system, keeping as simple as possible. First, here is a short demo using plant critter:

Basically, I have just added attack input in Protagonist script like done for jump/extra action input which is next used in state machine to trigger animation and enabling weapon.

Next, a simple Weapon script has been created to hold the strength of the weapon and also an active state, that makes the weapon armful only during attack action and not when colliding with critter during walking/running states.



Next, Critter script has been enhanced from the initial version from https://github.com/UnityTechnologies/open-project-1/pull/241:
- _currentHealth to track health of the critter decreased during successful hit
- GetHit boolean to track in SM a success hit between a weapon and the critter
- Killed boolean to track in SM when _currentHeath of critter reaches zero

A logic when collision is detected to determine if the critter received an attack has been aslo added to Critter script:


The rest is just setting up SM for PigChef and PlantCritter using condition based on the new boolean or on timer and trigger actions (trigger animation, enable weapon, reset GetHit boolean when state exit)

I have opened a PR to ease the review of this combat system proposal:
https://github.com/UnityTechnologies/open-project-1/pull/292

Note: The usage of the frying pan as a weapon is just for fun

 

Thanks for your support!

Here is a new part of the system: Item dropping! First a quick demo:

To achieve this, Critter script has been updated to rely on a SO to describe the global data:


In addition to the data, CritterSO provides some functions to compute the item dropping result:


Just adding the instantiation of the collectable item in Critter script when the critter is dead.


The PR: https://github.com/UnityTechnologies/open-project-1/pull/299

 

Hello,

Playing with the combat system, I was thinking about emphasizing the fact the player has hit the critter by adding a color flashing on top of the animation (again a souvenir from me playing Zelda, Ocarina of Time ), do you think it make sense here?

 

Been following the attack changes, and I definitely felt that there wasn't enough emphasis on getting hit, but not just the enemies getting hit. I'd ask if we should do it for Hamlet as well, because when the critters fight back and nothing seems to happen to him, it doesn't feel as impactful, especially if there is no health bar (or is there? ).

 

Hi @Amel-Unity! That is great to see the PRs reviewed and merged!

Sure it makes lots of sense, I liked the idea to compose the behavior based on different SO following each section you have highlighted.

I would also refactor the code to move some of the logic from Critter script to the corresponding SO, not only the data, for instance the roaming destination computation and event the logic in the Update() method.
And add an interface to define a contract between Critter/NPC and SO to be able to change the roaming algo (ie roaming around starting point or roaming around a set of points, roaming along a defined path, etc.)

For attack, I think a refactor to move the reloading time from SM to the future AttackSO would be more flexible.

Regarding @Smurjo point, I was having a look at it, is it something that will be done by Unity core team or by a contribution? Currently I have the feeling that the "Getting Hit" animation for PigChef is the "Surprised" one, is it the case?

 

Sorry, actually I was referring to @shuttle127 post just above, about the player being hit by critters, linking Smurjo here was a mistake (both are so active! I wrote the name too quickly...)

About "Surprised" animation, just my opinion, but it seems a bit too painless reaction from the main character and a bit long too (maybe we can accelerate it a bit to solve this part)

 

Hi @Amel-Unity, thanks to have demoing of the combat system yesterday even if it is not finished! That was super cool

I guess it is good to add the details of the on-going PRs here in the forum.

First, as you perfectly said it is a WIP system, with incremental enhancements, each addition a mix of refactor and new things
So a first part of the refactor was to remove the logical code from Critter script that was just a hardcoded state machine based on the critter status (inAlert, attacking, getHit, isDead...), so moving the wiring of the inner logic to the FSM was much more cleaner and the logic itself can be hosted in FSM conditions and actions too.

But an important part, that we discussed and agreed on with @deivsky in the PR, is keeping the capability to define variant behaviors for each critter variant without having to duplicate the whole FSM table each time. To do so, instead of defining the characteristics in the condition/action of FSM they are put in separated config SO (split as suggested above) and associated on the Critter script to be able to switch from one config to another at a prefab level.
To illustrate this capability, you can think about having a plant critter in the glade dropping apple and banana, but another plant critter in the forest dropping ginger and mushrooms. But the FSM will be the same for both. Actually, at the end the FSM for critters might remain the same for all the types of critter, only the config will change their behavior.

Again based on your suggestion, I have split the config in different SO as following:

CritterConfigSO:
- Localized name of the Critter
- Max Health of the Critter

Discussion:
In the other PR, my suggestion is to handle player health with a HealthAnchor, 'a la' TransformAnchor, to track both the max health but also the current health of the player. Player being unique, it will useful to have it in a dedicated SO.
But not sure it worth to make it deriving from another SO just for max health property, no?

So, I know that both are not related here, what could be a good refactor here? Having a MaxHealthConfigSO only for the health and move the name in Critter script directly without having another SO?

AttackConfigSO:
- Attack strength
- Attack reload duration

Discussion:
In the refactor PR, this attack is attached to the Critter script, but to make it working to configure also the current player weapon, I was thinking of binding it to the weapon directly, does it make sense?

ChasingConfigSO:
- Chasing target anchor
- Chasing speed

DroppableRewardConfigSO:
- Drop scattering distance (how far the item are scattered on the floor from the enemy remains)
- Dropping reward strategy

Details on the dropping strategy configuration:
Just to explain the new logic, it is now possible to define a rate for multiple item drops when an enemy is killed.
For instance, you can define: First dropped item is 100% sure and it will be 50% apple or 50% banana. Second dropped item is 20% sure and it will be 100% smoothie, etc... if an item drop fail, the algo stops to look at the other potential additional drops.

GetHitEffectConfigSO:
- Effect Color
- Effect Duration
- Effect Speed (how many flashing cycle during the effect duration)

Simple flashing effect when getting hit which will play with the tinting color of the material. I know that impact effect should come soon and this one is an unplanned feature, but I feel it provides an interesting additional feedback to the player? What about doing the same on the PigChef?


RoamingAroundSpawingPositionConfigSO:
- Roaming Speed
- Roaming Distance
- Stop duration

Discussion:
Based on the livestream, I understand that another roaming strategy based on predefined way points could be useful in the project. I was thinking of having the capability to define multiple roaming strategy using polymorphism on the config SO and next in FSM action, check the type of config to decide which roaming logic to play. What do you think?

 

Note: I have pushed an update to the PR to add some abstractions and make the actions less dependent of Critter script.

Here is the proposal for the conifgSO split in a hierarchy of MB script:

MonoBehaviour
\/
NpcEntity (Localized name, MovementConfigSO)
\/
AttackableEntity (HealthConfigSO, GetHitEffectConfigSO, Expose internal state GetHit/IsDead and the Collider logic with a weapon)
\/
DroppingEntity (DroppableRewardConfigSO)
\/
Critter (AttackConfigSO, ChasingConfigSO)

And so "Protagonist" script is naturally inheriting from AttackableEntity, to get benefit automatically to the HealthConfig, GetHitEffect, Localized name)

Later, "NPC" could inherit from NpcEntity and "Breakable Pot" from DroppingEntity

ActionsSO and ConditionSO from FSM are now relying on these EntityClass to get the config so they can be reuse for FSM of NPC/Pot/Protagonist/Critter without having to duplicate the logic and fetch child class Critter or Protagonist.

Note 2: Abstraction has been allso added on the roaming part. There is now an empty parent class for the config MovementConfigSO and different implementation (StaticMovementConfigSO and RoamingAroundSpawningPositionConfigSO) and on the FSM action side there is one NpcMovementStrategyActionSO which will build the right IMovementActionStrategy implementation based on the type of the config (RoamingAroundSpawningPositionActionStrategy or StaticMovementStrategy)

Later it will be possible to easily add a new strategy for the patrolling over waypoints.

 

Honestly, I really like the state machine to define the behaviour of the characters. It is like a backbone to plug incrementally new things.
But I am not sure it is good to wire things related to the timing of animation like sound effect. I have the feeling that triggering event from the animation is easier and more accurate to configure such things. I am actually thinking of moving the "weapon" enabling from state machine to animation event to fine tune when in the attack animation the weapon is armful and not just from the start to the end of the animation. I guess we could do the same in the state machine using delay and duration, but not sure it will be as accurate in case of lagging during the attack.

Yes, so my approach is to define a unique as generic as possible state machine for all critters to avoid having to maintain several tables. Next having the configuration SO that will fine tune the behaviour for each of them. And the good thing also, it will allow to change the behaviour slightly between the same type of critter, for instance, green slime critter is roaming around a center and stop, read one without stopping always moving and blue one is patrolling following waypoints.
For the plant critter actually there are checks in FSM actions/conditions to ensure a NavMeshAgent is defined before going further with the movement so even if it's state machines are the same for all critters it will not run the part related to roaming or chasing if it is not needed.

That is fine indeed, but just to understand, currently the weapon (attack) is attached to the cane for the player, it allows to identify the collider responsible for the damage. Do I understand properly when you said attached to the pig chef that it should be moved from the cane to the chef? In this case how differentiate the collider from the cane from any other collider defined on the chef?

Otherwise I am completely fine with all your comments, I will update the PR accordingly. Thanks a lot for this detailed review! Have a good GGJ weekend!

UPDATE: PR updated!

 

Hi @cirocontinisio, it makes totally sense. Indeed having one state machine table per type of critter might be more reasonable. Actually currently I am just having the feeling they will be not different enough to do the split and maintain the states in double. But definitely it would offer more flexibility at the end. And not sure it will be that heavy to maintain them.

And sorry for my confusion on the last part, we were actually perfectly aligned from the beginning

So regarding what has to be made based on your comment:
- Split the transition table to have one for the plant, one for the slime
- Keep the usage of variant configuration for health, attack, drop rate, get hit effect (I guess it will make sense to customize it for each slime critter variant)
- Integrate the roaming strategy and configuration directly in the FSM action without injecting the strategy via the config
- Integrate the chasing config in the FSM action

 

Thanks for the quick feedback a Saturday evening! I am integrating these changes in the first PR right now, so, it should be fine to have a final review after my next commit

 

PR Updated!

To ease the review:
Here are the new structure of SO folder:

SO
|-> StateMachine

|-> Config: The SO to be able to configure attack, drop rate, get hit effect and health
|-> Critters

|-> Actions: Common actions independent from the type of critter (Animator Attack Trigger, Drop reward,...)
|-> Conditions: Common conditions, (is getting hit, is getting killed, etc)
|-> PlantCritter: Where the Plant Critter transition table is

|-> Actions: Specific Plant Critter actions
|-> Conditions: Specific Plant Critter actions
|-> States: All Plant Critter states (all states are duplicated to make the tables fully independent)​

|-> SlimeRockCritter: Where the Plant Critter transition table is

|-> Actions: Specific Moving Critter actions
|-> Conditions: Specific Moving Critter actions
|-> States: All Moving Critter states​

Now, roaming config is in a native FSM action SO: RoamingAroundSpawningPositionActionSO and the stop between two roaming destination is control by a standard TimeElapsedConditionSO





and, chasing config also (ChasingTargetActionSO):

 

Would you prefer one PR for all the combat system on-going enhancements or keeping them separated as they are?
(Combat characteristics and player getHit/GetKilled integration)
Because, the second one will need some refactors after the first one is merged

 

Hi the "Right to Kill" fanatics!


Following the first PR merged, the second on going PR (https://github.com/UnityTechnologies/open-project-1/pull/326) to enable the critters to hit and kill the player has been updated.
To enable the reverse part of the combat system, it was mainly adding states (GettingHit, Dying and Killed) to PigChef table with existing actions based on generic controller like Damageable

On the critter side, the attack area has been added using Attack script and a collider:
Plant Critter:

Slime Critter:


As mentioned in the PR, I have introduced an hacky piece of code in the action destroying a game object (DestroyEntitySO).

Code (CSharp):

1.  
2. public override void OnStateEnter()
3.     {
4.         // Hack to force Collider Exit to be triggered before destroying an object.
5.         _gameObject.transform.position += - Vector3.up * 1000;
6.         GameObject.Destroy(_gameObject, 0.1f);
7.     }
8.  

This piece of code is moving the object out of the world before destroying it after a delay. I used this trick to force for instance PigChef to trigger collider exit on the different critter detectors (zone detectors) because if the PigChef is destroyed right away, the critter remains in Fighting mode, biking the air over and over.
Another solution might be to change the ZoneTriggerController from using OnTriggerEnter/OnTriggerExit by using OnTriggerStay, but I am a bit concerned by the impact on perf, I guess this one is executed on each frame. What do you think?

Finally, in this PR, to implement a quick re-spawning of the player when killed by a critter, a new action to raise a VoidEventChannel has been added. And by just raising the OnSceneReady VoidEventChannelSO, it respawn the player at the latest level entrypoint. It might be a temporary solution. I guess this part has a dependency on your new card regarding properly handling the respawn of the player when going out of the playable area.

Next, following the addition of this card: https://open.codecks.io/unity-open-...n/card/19v-implement-second-canehit-animation

Here a new PR! https://github.com/UnityTechnologies/open-project-1/pull/352

This PR is starting from the previous one, assuming that it might be merged soon

The proposed solution for this one was to wire the new animation in PigChef animator and change the CaneHit trigger to isAttacking boolean. While this boolean is true, the player is chaining the attacks playing the two animations in a loop.
Next, to control this boolean, the input reader has been updated to capture the attack started and cancelled input.

On the FSM side, just one particular decision I made, is that when chaining the attacks, the state is just remaining on Attack state.

Finally, a change I wanted to introduce as explain earlier is the move of the attack armful period control from FSM action to animation event adding a new controller at root level (Attacker) providing public methods to enable/disable attack.

A short demo of all these enhancements:

 

Is this more or less what you had in mind?



I created a particle system with trails whose width increases over the trail (creating the spikes). The particle system shape is a cone so that the spikes come out toward one direction.

In the Codeck card, the sample picture shows some spikes going with the direction, but when I do that the spikes go through the character and can't be seen. One of the pictures does have the spikes going against the direction, which is what I did.

 

I'd like to take a stab at fixing this, but in some preliminary tests to resolve the issue with an upper body avatar mask I have run into a couple problems with how the character rig is set up at runtime. Using the avatar mask I made for the Pig Chef's upper body, I was able to fix the issue where the character slides while attacking, but unfortunately, the following bug happens with the arms as the cane is swung:

I believe this is due to the upper body avatar mask being unable to communicate with the custom IK system that is in place for the character's hands, but I am not quite sure how I would go about solving something like that. Anyone got any ideas?

 

Heya, I made a post about the impact effect not realizing it was already being discussed here. Also, did not realize @redcurry79 was already working on it, my bad dude! Happy to let you handle it =)

Also, happy to rework what I've done to use the smash bros style 'hand animated' billboarded sprite, like ciro mentioned in his post above.