So I've been working on a state machine for a player character in a Unity game, and thought a hierarchical system would work well. However, I'm having some trouble getting methods to traverse the inheritance chain. If someone could point out my mistake for me, I'd greatly appreciate it.
Here's my PlayerScript : Monobehavior script:
public PlayerState State;
public void Start() {
State = new StoppedState();
State.Enter(this);
}
public void Update() {
State.Update(this);
}
And here are the PlayerStates:
public class PlayerState {
public virtual PlayerState Update(PlayerScript player) {
Debug.Log("Blorp");
return null;
}
public virtual void Enter(PlayerScript player) {}
}
public class LowPriorityState : PlayerState {
public new virtual PlayerState Update(PlayerScript player) {
Debug.Log("Blop");
PlayerState newState = base.Update(player);
//Do state stuff, determine if state should change
return newState;
}
}
public class StoppedState : LowPriorityState {
public override PlayerState Update(PlayerScript player) {
Debug.Log("Blip");
PlayerState newState = base.Update(player);
//Do state stuff, determine if state should change
return newState;
}
public override void Enter(PlayerScript player) {
Debug.Log("Entered Stopped State");
}
}
The expected output after 1 frame is:
Entered Stopped State
Blip
Blop
Blorp
but instead I'm getting:
Entered Stopped State
Blorp
...which is completely baffling, because it's clearly using the overridden "Enter" method but not using the overridden "Update" method. Does anyone know what I'm doing wrong and how to fix it?
The "new" modifier is used to hide a method of the base class and create a completely new method. This way, if the variable is of type BaseClass, it will call the method in the base class, and if the variable is of type DerivedClass, it will call the method in the derived class.
So in the LowPriorityState you are creating a new method, not overriding the one from PlayerState. So your field State of type PlayerState will continue to call the method from the base class.
And then you override this new method in StoppedState, but as your field State is of type PlayerState, it continues to call the method from the base class.
So just replace the new keyword with override.
Related
I have a pretty basic understanding of inheritance and so when using it there are a few moments like this where I find it difficult to understand what's fully happening and it probably doesn't help that I'm most likely not using it properly.
Anyways though I have these 3 classes
public abstract class EffectBase
{
public enum EffectType
{
harm,
help,
self
}
public EffectType type;
public float duration;
public void Activate()
{
Debug.Log("Activating effect");
ApplyEffect();
}
public abstract void ApplyEffect();
public abstract void End();
}
public class Player : MonoBehaviour
{
public List<EffectBase> effects = new List<EffectBase>();
void Update()
{
if (Input.GetKeyDown("q"))
{
Debug.Log("Q pressed");
AddEffect(new SpeedEffect());
}
}
public void AddEffect(EffectBase effect)
{
Debug.Log("Adding effect");
effects.Add(effect);
effect.Activate();
}
}
public class SpeedEffect : EffectBase
{
public override void ApplyEffect()
{
Debug.Log("Speed effect applied");
}
public override void End()
{
Debug.Log("Speed effect ended");
}
}
When I call the AddEffect method I pass a new instance of SpeedEffect (I think it's an instance) as the parameter and then in the AddEffect method I call the Activate method from it, however, in the SpeedEffect class, it doesn't have or override that method so I'm assuming it goes to the base class which does have it and continues and now here's where I get confused in the Activate method it calls the ApplyEffect method, but how does it know to call the one in the SpeedEffect class?
Despite not having an override for Activate() that method still exists in the SpeedEffect class, you just didn't need to write any code for it since its the same code so theres no need to duplicate it.
The code for Activate() calls the ApplyEffect() method for whatever class its being called from. In this case: EffectBase.Activate() and SpeedEffect.Activate() have the same code in terms of reading it, but they are not the same; EffectBase.ApplyEffect() and SpeedEffect.ApplyEffect() are two different methods and each are called from their respective classes.
I'm working on a hobby project in Unity. I have MonoBehaviour scripts for my characters that use component objects for each behavior the character has. When I create new characters, I inherit a new class from the base class for whichever component behaves differently.
When certain triggers occur, I send characters back to their initial state by calling a Reset() method exposed by the base class that sets fields back to their initial values. I'm wondering how to send that call down through the inheritance chain. Right now, the base class has a protected virtual ChildReset() that gets called in Reset() and does nothing by default. If child classes have fields to reset, they override this method. It feels like a really awkward way of doing it.
I like the idea of implementing something similar to the messaging system Unity uses. If a monobehavior doesn't use the Update() message, then the class just doesn't define an update. It eliminates unnecessary calls. I have no idea how I would do something like that.
Any thought invested in this is much appreciated! I've written out the way my project is structured below just in case these details are useful for answers.
public class Character : MonoBehaviour
{
private Motion motionController;
private Interaction characterInteractionController;
//etc
private void Update()
{
motionController.DoStuff();
characterInteractionController.DoStuff();
}
private void Reset()
{
motionController.Reset();
characterInteractionController.Reset();
}
private void OnEnable() => ResetTrigger.OnReset += Reset;
private void OnDisable() => ResetTrigger.OnReset -= Reset;
}
public class Motion : Component {}
public class Interaction : Component {}
public abstract class Component
{
public void Reset()
{
/* set fields to default values */
ChildReset();
}
protected virtual void ChildReset() { }
public abstract void DoStuff();
}
There is no need to send a call down through the inheritance chain. You do not have two different objects. An object of the child class contains everything declared in the base class. Why not directly make Reset() virtual?
public abstract class Character : MonoBehaviour
{
public virtual void Reset()
{
...
}
}
public class ChildCharacter : Character
{
// If ChildCharacter has stuff to reset, override this method, otherwise don't!
public override void Reset()
{
base.Reset(); // Call this to reset stuff from the base class.
//TODO: reset child stuff.
}
}
If Reset is overridden in the child class, then calling Reset will call ChildCharacter.Reset() even if called on a variable statically typed as Character.
Character c = new ChildCharacter();
c.Reset(); // calls ChildCharacter.Reset() when overridden
If Reset is not overridden in the child class, then calling Reset will call Character.Reset() even if called on a ChildCharacter.
ChildCharacter child = new ChildCharacter();
child.Reset(); // calls Character.Reset() when not overridden.
I'm not really sure how to describe it exactly so let me show you what is going on.
I have a PlayerControls script which looks like this (note: I stripped everything except for the necessities).
namespace Player.Controls {
internal class PlayerControls: MonoBehaviour {
public bool IsClimbing { get; private set; } = false;
public bool IsGrounded { get; private set; } = false;
}
}
These variables are set in this class depending if the player is climbing/touching the ground. This script resides on the "Player" GameObject in the scene.
I have another script called PlayerControllerwhich looks like this
using Player.Controls;
public class PlayerController: Singleton<PlayerController> {
internal PlayerStats stats = new PlayerStats();
//PlayerStats nested class (see below)
}
The Singleton class only checks if the generic type is null, if it is, it will use FindObjectOfType to get an instance. This script also resides on the "Player" GameObject.
Inside the PlayerController class, I have a nested class called PlayerStats. It looks like this
internal class PlayerStats : PlayerControls {
public new bool IsClimbing { get { return base.IsClimbing; } }
public new bool IsGrounded { get { return base.IsGrounded; } }
}
Notice this nested class in inheriting from PlayerControls.
The idea is that the PlayerControls class in inaccessible to all other classes except for PlayerController, and any information I want to obtain regarding the player can be obtained by getting the player's instance (via the singleton) and accessing the PlayerStats variable.
For example, assuming the variable inside Singleton which holds the instance is called Instance, one could do PlayerController.Instance.stats.IsClimbing; Everything works as expected, except for one thing.
In the Awake method of the PlayerController class, I do this
private void Awake() {
Debug.LogFormat("In PlayerController Awake(). Is PlayerController.stats null? {0}",
(stats.Equals(null) ? "Yes" : "No"));
Debug.LogFormat("IsClimbing : {0}", stats.IsClimbing);
}
In the output window, it prints
In PlayerController Awake(). Is PlayerController.stats null? Yes
IsClimbing : False
If I also put the same IsClimbing debug in the Update() method, the value is correct for when I start climbing.
So, finally, my question, how can I access the variables of the PlayerStats class with the stats variable if stats is null? I thought it may have been somehow calling straight to the PlayerControls properties, so I changed their names, removed the new inside of PlayerStats and even put a debug statement inside one of the properties inside PlayerStats, and it definitely gets called. For example,public bool IsClimbing { get { Debug.Log("Called IsClimbing inside PlayerStats."); return base.Climbing; } }
If it is getting called and working properly, how can it be null? I asked my professor and he doesn't seem to know why either. What is really going on here?
Edit:
As requested, the Singleton class:
public abstract class Singleton<T>: MonoBehaviour where T : MonoBehaviour {
private static T instance;
public static T Instance {
get {
if(instance == null) {
instance = FindObjectOfType<T>();
}
return instance;
}
}
}
Here is an image of the console output.
Digging around on the Unity forums it appears that the Equals method has been overridden (on Object which MonoBehaviour eventually derives from) which is why comparing a MonoBehaviour to null is not giving you what you might expect. The answer I link to suggests code like this is more appropriate:
stats == null || stats.Equals(null)
I wish to know if there is room for changing a variable's accessibility during runtime in Unity C#? The reason I want this is to hide unnecessary public variables when my script uses another state. I tried some dynamic variables, but I get errors that it can't be found.
I have that springDistance but I want to use it only when the state of the trapType is springOut.
Some code:
public class SpringTrap : MonoBehaviour
{
private Transform objectToMove;
// Use this for initialization
public enum TypeOfTrap
{
springOut
}
[Tooltip("Set the type of trap here to use.")]
public TypeOfTrap trapType = TypeOfTrap.springOut;
public float springDistance;
void Start ()
{
objectToMove = transform.FindChild("ObjectsToAnimate");
}
void OnTriggerEnter2D(Collider2D other)
{
if (other.gameObject.CompareTag("Player"))
{
//if the player has entered the danger zone
switch (trapType)
{
case TypeOfTrap.springOut:
break;
}
}
}
IEnumerator SpringOut(float springDistance)
{
float deltaDist = 0.0f;
while(deltaDist < springDistance)
{
objectToMove.position +=
}
}
}
Manipulation of the inspector is done with custom editor scripts. There you can display things, e.g. based on conditions.
Here is an example that does a very similar thing to the requested (displaying different things based on an enum field):
http://answers.unity3d.com/questions/417837/change-inspector-variables-depending-on-enum.html
An easier way to do what you are trying to achieve is to create an abstract trap class and then subclass different types of traps.
The abstract trap class handles collisions and then calls the abstract method Trigger.
public abstract class Trap : MonoBehaviour {
void OnTriggerEnter2D(Collider2D other)
{
if (other.gameObject.CompareTag("Player"))
Trigger(other.transform);
}
protected abstract void Trigger (Transform victim);
}
A spring trap can then be easily created by extending Trap and overriding the Trigger method.
public class SpringTrap : Trap {
public float SpringDistance;
protected override void Trigger (Transform victim) {
victim.position += Vector3.up * SpringDistance;
}
}
Now you don't have to worry about hiding irrelevant properties based on trap type because the only properties that will appear in the inspector are those you add to that variation of trap.
So I have this code: Variables:
enum gameState
{
gameLoading,
mainMenu,
gameOptions,
levelSelect,
gamePlaying,
gameOver
}
In the Update() method:
if (CurrentGameState == gameState.gameLoading)
{
if (Keyboard.GetState().IsKeyDown(Keys.E))
{
graphics.ToggleFullScreen(); //?
}
graphics.ApplyChanges();
}
...
//gameState.gameLoading logic
if (Keyboard.GetState().IsKeyDown(Keys.Enter))
CurrentGameState = gameState.mainMenu;
So what I want is to have Enter pressed in gameState.gameLoading and both resolution is fullscreen and the gameState is equal to mainMenu. When in gameState.mainMenu the resolution can't be changed from fullscreen to windowed by pressing enter. How to achieve this? Maybe using list?
I think you should have different classes for any gameState if they need to have different behaviours. This will ensure you that each Update affect only its own gameState.
Since you've already decided what the states of your game are, why don't use the State Machine design pattern to control your input handling behaviour?
This pattern's agenda is to delegate the work from the actual object to its states. What you do is create a class with an Update() method for each state like pinckerman suggested, and enter all the input handling + state transition logic there. You can find an example here: http://sourcemaking.com/design_patterns/state.
When I use it, I detach the context from it's states and transitions completly by using an abstract state class and inherit from it. This makes it easier to change the state machine if needed.
Here is a quick example:
public class Context
{
private GameState state;
public void Update()
{
state.Update();
}
public void ChangeState(GameState nextState)
{
state = nextState;
}
}
public abstract class GameState
{
protected Context context;
public virtual void Update()
{
// some basic implementation if you want.
}
}
public class GameLoadingState : GameState
{
public override void Update()
{
// Handle key presses.
context.ChaneState(new MainMenuState(context));
}
}
public class MainMenuState : GameState
{
public override void Update()
{
// Handle key presses in some other way.
// Change state if needed.
}
}
Again, if you don't like the implementation of the passive context, you can change it to be more active.
Hope this helps!