You define your own base state type to suit your needs. IState only has the bare minimum of members required for an FSM so you don't need to implement unneeded functions in basic scenarios and StateMachine lets you manage states on-demand rather than pre-registering them all with their own Keys. The system does no more than necessary to enforce the state change rules so it has extremely good performance. The Animancer.FSM was designed to achieve the following goals: Goal See Changing States page for more information. Used for accessing the previous and next state during the IState methods. The main core of the system is made up of 3 scripts: ScriptĪn interface with two properties ( CanEnterState and CanExitState) that determine whether a particular state change will be allowed and two methods ( OnEnterState and OnExitState) which notify the state when such a change occurs.īasically just a reference to an IState with methods for accessing it and trying to change the state according to the properties in that interface. There are plenty of other FSM systems available online (including on the Unity Asset Store), or if you're interested in implementing your own system Unity has a tutorial series about building a Pluggable AI With Scriptable Objects which could easily be adapted for other purposes. They work well together, but you can easily use one without the other if you want to. That's why Animancer's FSM system is entirely separate from the animation system. Many of the problems with Unity's Animator Controller system come from the fact that it is both an animation system and a state machine system combined, which limits its usefulness for either task. But a character often has many states such as idle, walk, run, jump, fall, attack, and so on, therefore a FSM will often be a good choice for managing that behaviour. For example, a treasure chest can either be open or closed that's only two states so you might not bother setting up a full FSM for something that simple. Switch ( Finite State Machine (often abbreviated as " State Machine" or " FSM") is a system which manages the current state of an object and the other states it can be in. public enum ElementType Īnd DoDamage() can use a switch statement to split out different behaviours for each type, without comparing them against a cached reference: foreach (var damageInfo in Damage) Invert the dependency, so instead of DoDamage() handling the special characteristics for each element, that behaviour instead lives in the element data, and DoDamage() can ask the element to apply its special effects on its behalf, without needing to know which element is which.Ĭreate an abstraction, where DoDamage() doesn't need to know about specific elements, just common categories of damage response. There are a few ways we can respond to this:Īccept that new elements will always require new code anyway, and hard-code the set of elements into an enumeration that's easy to check against. Now even if you can add a new element purely with data, you still need code changes to imbue it with its special characteristics. You might even be able to ship new elements in bonus content packs or mods.īut by checking for specific elements explicitly inside your DoDamage() function, you lose those benefits. in data as ScriptableObjects is that you can add/remove/update the collection of elements with pure data changes - no new code, refactoring, or re-compilation required. One of the advantages of defining your elements/damage types/etc. Is there any better way I can check for equality without having to use editor set references? Seems to me to be a huge downside of ScriptableObjects. What I would like to do is check what type of Element damage I am currently iterating in order to apply different modifiers, I know this can be done through setting up editor references and comparing against them, but that would require far too much editor setup each time and seems to me using a simple enum while less flexible would be less work overall(even to change in future).Įven setting all the references one time on a globally accessible class, removes the modularity/easy extensibility of using ScriptableObjects in the first place. OnHitObject?.Invoke(this, otherHealth.gameObject, position) private IEnumerator DoDamage(WeaponAttack attack, Health otherHealth, Vector3 position) Public DamageInfo(float damage, Element damageType)Įlsewhere in my code on the weapon I have my DoDamage function. A rather simple question, how do you check equality of a scriptable object without references?įor example, I have a weapon class that holds a list of damage types the weapon deals, which consists of a float and a ScriptableObject class (Element).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |