States and Inheritance
Last updated
Was this helpful?
Last updated
Was this helpful?
State behavior can be a little confusing when combined with inheritance. This article discusses how states and inheritance work together and things you should be aware of in your project when using States with Screens/Entities that inherit from other Screens/Entities.
Every category in your project creates a class in generated code. For example, consider a Bullet entity with a category BulletAppearance.
The generated includes a class called BulletAppearance with properties matching the variables assigned in the FRB Editor.
If a category is added to a derived screen or entity, FlatRedBall checks if the same-named category exists in the base screen or entity. If the derived category matches the name of a category in the base, then this category is created as a derived class from the base category. Derived categories can be used to add additional states to the base.
For example, consider a base entity Bullet and a derived entity named BulletDerived each with a category named BulletAppearance.
BulletDerived defines a class named BulletAppearance which inherits from the base BulletAppearance class.
The derived entity includes a property that is of the derived type, so derived instances can assign this property in code.
The derived entity can add additional states to the category, but it cannot overwrite existing states. If a new state is added with the same name as a state in the base class, FlatRedBall marks it as an error by coloring the name text.