Additional Attack Skyrim Se

0 views

Skip to first unread message

Tatsuya Deals

unread,

Aug 3, 2024, 1:58:42 PM8/3/24

to ramolajo

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.

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)

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?

6745555--777640--Refactoring.png12001324 98 KB
We can separate the different proprieties in different ScriptableObjects instead of having one that has everything. This will allow us, for instance, to use health for not only the critters but also the main character.
Droppable will be also possible to reuse, I am thinking later when we add barrels that the character could destroy. The barrels will have health and droppable but not the NPC or Attack for instance.

If we change it this way, in the MonoBehaviour Critter attached to the different critters, instead of referencing one SO for everything, we can reference the different SOs needed and so on for the different characters that will need them.

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.)

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.

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?

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?

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?

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)

Yes we can use 2 roaming strategies: roaming around a central point (in this case we need to specify the radius) or around waypoints (in this case we need to specify an array of positions, and we can create a scriptable object to store the positions like a path pattern, that way we can use the same path for multiple critters or NPC).

For ChasingConfigSO thought to include it to NPCAgent but I think better not since NPCs will not need to chase the player or at least not all of them and all the time. So maybe we can separate the Chasing behavior in another MB script.

So as you can notice with this MBs scripts we can easily just attach them as components to the different characters depending on what we need.
So the pig chef, the critters and the barrels (or pots or anything we can break in the game) will have Damageable.
Everything that moves with the AI like the NPCs and critters will have the NPCAgent component.
Critters that move are for now the only ones who chase the player, so we can add the Chasing script to them.
Attack script that will replace the weapon script and has reference to the AttackConfigSO will be attached to the critters and the pig chef.

As a side note, with Ciro we were wondering if we will eventually incorporate the sound and visual effects in the state machine. You can notice that currently we have a Monobehaviour script called ProtagonistAudio on the pig chef. We are still discussing the advantages and disadvantages to moving sound and visuals to the state machine or keep them on the root. What are you thoughts on this?

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?

But personally, I am much in favour of eventually having 3 TransitionTables, one per type of critter. This would free us from the hacks that we have in place to make the plant not move, and will probably eliminate future hacks. At the same time, it opens the possibility to program the behaviour of (say) Rock Critter and Slime Critter in a completely different way.
For instance, maybe Slime Critter never rests, it always goes to the next waypoint. The Rock Critter instead might be doing very long idles, and then going for the next waypoint. Or maybe in the future we could make it jump, by having a jump state and playing the right animation/sound/etc. so it can move up and down Navmeshes.
For now, I would move forward with just 2 TransitionTables, one for the moving ones and one for the static (Plant).

We can still have some config stuff on the base object, like the items dropped, the health, etc. so we can create variants on individual GameObjects. But I strongly feel that if we made a state machine we should use it.

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?

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.