Alternatives to inheritance - unity3d

Question

I am working in Unity 3d and I made a player script. Now I want to have different kinds of players but they all have the same movement behaviour. Since my object in inheriting from Monobehaviour I can't inherit from something else. How would I solve this, because I don't want to have to redo every player later on when I change something about the movement. I can solve it with namespaces but is that a good solution?

Answer 1

You have basically two options:
Create an abstract Player class, that inherits from MonoBehaviour, implementing only the movement. Then let the concrete player classes (e.g. Wizard or Warrior) inherit from it and handle the specific locig in those
Create a Player class and use the "Strategy-" (and maybe "Factory-") "Pattern", to create different types of players (you may also read up on "composition over inheritance")
An implementation of the first approach might look like this:
public abstract class Player : MonoBehaviour
{
public void Move() { /* Movement logic here */ }
public abstract void Attack(MonoBehaviour target);
}
public class Wizard : Player
{
public void Attack(MonoBehaviour target) { /* Attack logic for a wizard here */ }
}
public class Warrior : Player
{
public void Attack(MonoBehaviour target) { /* Attack logic for a warrior here */ }
}
// ---
// How to create players
var wizard = new Wizard();
var warrior = new Warrior();
And for the second approach:
public interface IAttack
{
public void Attack(MonoBehaviour target);
}
public class WizardAttack : IAttack
{
public void Attack(MonoBehaviour target) { /* Wizard attack logic here*/ }
}
public class WarriorAttack : IAttack
{
public void Attack(MonoBehaviour target) { /* Warrior attack logic here*/ }
}
public class Player : MonoBehaviour
{
private IAttack attack;
public Player(IAttack attack)
{
this.attack = attack;
}
public void Move() { /* Movement logic here */ }
public void Attack(MonoBehaviour target)
{
this.attack.Attack(target);
}
}
// ---
// How to create players
var warrior = new Player(new WarriorAttack());
var wizard = new Player(new WizardAttack());
As you can see, the second approach gives you a lot more flexibility, because you're of course not limited to having only an "attack strategy", but can create as many different ones as you like and - more importantly - combine them in any way imaginable. You could even "outsource" the movement logic into its own strategy and change it on the fly. For example, when the player picked up a power up. With inheritance, you would really struggle to have a Priest, which might combine traits of a Warrior and Wizard.
This also fits in nicely with how Unity was designed; that is, combining different components (e.g. Rigidbodies and Renderers) for increased functionality.
As for solving it with namespaces: How? Namespaces are nothing more as a way to organize code and avoid naming collisions. They don't solve the problem of having duplicate code.

Answer 2

solution for you is to use aggregation instead of inheritance. Unity very good support Entity Component System paradigm. To not duplicate check this thread
http://answers.unity3d.com/questions/669643/entity-component-system.html.
There is a ready framework to work with ECS for unity, you can check out to get a better idea of approach:
https://github.com/andoowhy/EgoCS
https://github.com/sschmid/Entitas-CSharp
I haven't use any of those, but I hope it helps to get into it. I would really recommend to go with it, regardless of the way you will implement it.
Just start thinking in a way of components, which mean if you have a several types of players, only difference is which components they construct of. Then you can have a movement component and use it on every player ;)

Answer 3

You can achieve this by simple and easy way by making a separate MoveScript, which will only have the move behaviour that is same for all players. Other variable behaviours you can write separate script (WizardScript and WarriorScript). So there will be two scripts on all players one MoveScript and one script (WizardScript and WarriorScript) related to their specific behaviour.

Answer 4

Sounds like a good time to use the strategy design pattern.
But first, let's generalize the players.
public abstract class Player : Monobehaviour
{
protected PlayerMovementStrategy moveStrategy;
protected void Start()
{
moveStrategy = new SimplePlayerMovementStrategy(this);
}
protected void Update()
{
moveStrategy.UpdateMethod();
}
protected void MoveTo(Vector3 location)
{
moveStrategy.MoveTo(location);
}
}
Obviously, from this we can create different types of players:
public class Archer : Player
{
//...
}
And how will the PlayerMovementStrategy class look like?
public abstract class PlayerMovementStrategy
{
protected Player _player;
public PlayerMovementStrategy(Player player_)
{
_player = player_;
}
public abstract void UpdateMethod();
public abstract void MoveTo(Vector3 location);
}
For an example:
public class SimplePlayerMovementStrategy : PlayerMovementStrategy
{
protected bool _move;
protected Vector3 _destination;
public SimplePlayerMovementStrategy(Player player_) : base(player_)
{
_move = false;
_destination = Vector3.Zero;
}
public override void UpdateMethod()
{
if (_move)
{
//_player.transform.position..
}
if (destinationReached) _move = false;
}
public override void MoveTo(Vector3 location)
{
_destination = location;
_move = true;
}
}
The advantage here is that you can write new movement strategy classes (that should confirm to PlayerMovementStrategy) and just assign them to your player class, whilst your MoveTo() method in your player class is completely controlled by whichever derived movement strategy you assigned it.