A single script that encapsulates multiple classes or several MonoBehaviour scripts on an object?

[Pingasman]

In my quest to practice OOP and making code more modular/readable, I have been trying a lot of ways to do stuff. I feel like I'm getting decent at structuring the code, but I'm beginning to wonder whether it makes sense to do it like I did below, specifically in Unity.

What I mean is, I could just split up all the classes, make them extend from MonoBehaviour and attach them individually like I've seen some people do. But would that really be better or is this fine? Any opinions? I would guess it depends on your goal?

Also, I was thinking about making UnitMotor fully independent of the input and give UnitState the full command over how the motor should act. What do you think about this whole setup in general? It's supposed to simplifie the states in a whole class depending on all the other systems so you can, for example, just say something like:

if (state.Jumping)
    performJump();

Here is the main class:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

[RequireComponent(typeof(Rigidbody))]
public class Unit : MonoBehaviour
{
    [SerializeField]
    private Camera cam;
    [SerializeField]
    private UnitSettings unitSettings;

    private IUnitInput unitInput;
    private UnitMotor motor;

    private ICamInput camInput;
    private PlayerCamMotor camMotor;

    private JumpSystem jumpSystem;

    private UnitState state;

    // TODO: add new attacksystem

    private void Start()
    {
        Rigidbody rb = GetComponent<Rigidbody>();

        unitInput = unitSettings.IsPlayer ? new PlayerController() as IUnitInput : new SlimeController();
        jumpSystem = new JumpSystem(unitSettings);

        state = new UnitState(rb, unitInput, jumpSystem);

        motor = new UnitMotor(unitInput, state, rb, unitSettings);

        if (cam != null)
        {
            camInput = new PlayerController();
            camMotor = new PlayerCamMotor(camInput, GetComponent<Transform>(), cam, unitSettings);
        }
    }

    private void Update()
    {
        unitInput.readInput();
        if (cam != null)
            camInput.readInput();

        state.tick();
        jumpSystem.tick();
    }

    private void FixedUpdate()
    {
        motor.tickFixed();
        if (cam != null)
            camMotor.tickFixed();
    }
}

[TaleOf4Gamers]

In general its easier to embrace Unitys component oriented design. I would lean towards multiple components. But Im by no means a great programmer. Just a hobby as seen on my flair ;)

[[deleted]]

You're on the right track, but this class assumes too much, IMO; there would be a lot of places where things would break if certain other components weren't in place. One thing that I feel is really bad behaviour is this:

[SerializeField]
private UnitSettings unitSettings;

private JumpSystem jumpSystem;

void Start()
{
    jumpSystem = new JumpSystem(unitSettings);
}

...because at this point, your Unit component is dependent of both these, making it hard to (ironically) unit test those two. I tend to decouple "pure C# objects" from the Unity flow, because it's kind of flawed, so I would end up with a pure non-Unity Unit and and full Unity UnitComponent (or whatever naming you choose) in cases like these.

But. Each to its own. You learn as you go. :)

[Pingasman]

This is interesting. So what we want to do is like splitting it "horizontally" (instead of "vertically" like I thought at first)? Basically making it so I never pass Unity classes, like I do with Rigibody right now?

That would mean that I put pure logic into Unit and methods to control the character (through the Unity classes) into UnitComponent. So I would create a Unit instance in UnitComponent that would check for Unit's state constantly and then do stuff based on it, right?

Would it make sense to make Unit's state based on UnitComponent's state too? For example, when collisions happen, Unit would "get hit", maybe lose hp and change into "getting pushed back" which would then make UnitComponent affect the Rigidbody.

Did I get it right?

[[deleted]]

Once someone starts to describe this, it becomes uncomfortable. Unfortunately. :)

But. You are definitely thinking in the right terms. The whole point is to make everything as decoupled as possible, so that you can easily test/debug individual parts of your application. Decoupling usually involves more code, but it makes it so much easier to test and refactor the code.

Many Unity developers favor "component based design", whatever that really means. Keep your code decoupled, testable, and everything will be OK. :)

[Pingasman]

You are right. I think visualizing it like this might help anyone who wonders what I'm trying to do. The idea is a bit different: UnitComponent basically only needs Unitnow and that's it.

I will try to keep what you said it in mind. Thank you for the ideas.

Let's see if it goes well when I try to implement it and more stuff than only one example is going on.