Longer Monobehavior vs More Monobehaviors (Secondarily, looking for feedback)

As a preface, I’ve only begun a few weeks ago. I was learning C++, until I downloaded Unity about 2 weeks ago and saw that C++ is not included in the list for Monobehaviors. I’ve since moved over to C#. While studying C++ for that short span, one of the key things that was spoken of in the books and tutorials I watched was that a function should be able able to be summarized without saying “and”. Example: It makes the player jump vs It makes the player jump, and then applies gravity.

With this being said, I spent several hours today fixing my jump script. I noticed by the end of it, that it was rather long. I also noticed, that it seemed like there was a delay when I hit W that wasn’t there before (unless my mind made it up!). So, I decided to split the script in to two Monobehaviors. One that added upward force to my object, and one that would apply gravity on a timer system to allow for longer/higher jumps if W was held down. It appeared as if the delay vanished.

So, my question is, should monobehaviors be treated with the same mindset, as a good function? Or is it situational? Or does it not really matter?

Here is the script I am referring to, I’m sorry if anything isn’t standard as far as the commenting and placement of things go, however I find this the easiest way to read my own scripting.

using UnityEngine;
using System.Collections;

[RequireComponent (typeof (JumpGravity))]

public class JumpBase : MonoBehaviour {



	private float distToGround;
	private JumpGravity jumpGravity;

	//To allow for slopes
	public float skin = 0.25f;
	
	//Height of jump
	public float jumpHeight = 15f;


	void Start(){
		// get the distance to ground
		distToGround = collider.bounds.extents.y;
		jumpGravity = GetComponent<JumpGravity>();


	}//Start close

	//Is the player grounded?
	bool IsGrounded() {
		return Physics.Raycast(transform.position, -Vector3.up, distToGround + skin);
	}//Grounded Close
	
	void FixedUpdate () {
	
		if (Input.GetKeyDown(KeyCode.W)  IsGrounded ()){
			rigidbody.AddForce(0f, jumpHeight * 100, 0f);
}//Jump origin close


		if (IsGrounded () == false  jumpGravity.keyDown == false){
			rigidbody.AddForce(Physics.gravity * rigidbody.mass * 3f * 2f);
}//Normal Gravity Close

		if (IsGrounded ()) {
			jumpGravity.timer = 0f;
		}//If grounded, reset


}//FixedUpdate Close
}

and the other script associated with it

using UnityEngine;
using System.Collections;

public class JumpGravity : MonoBehaviour {
	
	[HideInInspector]
	public bool keyDown = false;

	[HideInInspector]
	public float timer;
	
	
	private float gravityMult =3f;
	private float timerMin = 0.001f;
	private float timerMax = .6f;
	
	
	void FixedUpdate () {
		
		if (Input.GetKeyDown (KeyCode.W)) {
			keyDown = true;
		}//if close
		
		else if (Input.GetKeyUp (KeyCode.W)) {
			keyDown = false;		
		}//Else if close
		
		if (keyDown == true) {
			timer += Time.deltaTime;	
		}//Timer set close
		
		if (timer > timerMin  timer < timerMax  keyDown == true) {
			rigidbody.AddForce(Physics.gravity * rigidbody.mass * gravityMult);	
		}// If timer is greater than min, less than max and holding w key
		
		if (timer > timerMax  keyDown == true) {
			rigidbody.AddForce(Physics.gravity * rigidbody.mass * gravityMult * 2f);
		}//If timer is greater than max, holding w key
		
		if (keyDown == false  timer > .001f) {
			rigidbody.AddForce(Physics.gravity * rigidbody.mass * gravityMult * 2f );
		}//If timer is greater than min, not holding key, and in air
		
}//FixedUpdate close
}//Monobehavior close

Frankly, in this case, I don’t see why you would split it into two classes. Splitting those two “actions” into method/fuctions? Sure, that would make sense.

However, you should split into different classes only when it make senses to do so. Will “JumpGravity” and “JumpBase” be mixed with other behaviours? You declared that JumpBase requires JumpGravity… Does another MonoBehaviour requires JumpGravity? If not, maybe it should be a single class. Or maybe it could be a parent class. If those two always work with each other, and never alone, they might be better merged.

The only reason I had done that, is so that the force added on the Y axis would not suffer from any delay, as I felt it added a very minor delay when it was combined. This may have been for entirely other reasons, as I’ve said I’m quite new at this. So the logic would be that it would add the force when W was pushed, and not have much else to worry about. However, when it’s combined, in to one class* it had a lot of other script to get around to before checking to see if W was pushed. Also, I don’t believe they will be mixed with other behaviors, though it’s entirely possible. This is simply a learning project for me so far.

That makes no sense and it was most likely a bug in your code.