The issue I have is simple I am rather new to code architecture and I was wondering how I should create a player movement script that is capable of using many different forms of movement such as rigidbody or transform. I decided to just use a base class and use inheritance for scripts that needed to use the movement scripts. Now an issue arises I had no idea how to create a AirAndGround movement script I originally made the AirAndGround movement script take 2 base class movement references and then had the script handle turning them on and off it worked really well and I liked this approach but it really made no sense in the editor. Could someone give me another suggestion on how to do this in unity while having the AirAndGround movement class not have to implement movement as to follow single responsibility principle.
Hi there,
It might help to briefly explain what each of these classes is doing to help understand why you separated and suggest an alternative approach.
Well this is me working on my own I decide to split up the classes like this. So pretty much the air and ground movement class is supposed to handle 2 different movement scripts and turn them on and off accordingly. Each movement script implements the interface iMovement so the air and ground movement class takes 2 iMovement interfaces i set it up like this so that i can have any movement script put onto it. To create a very modular movement system. I don’t really see another way to do this but I am not happy with the way this looks in the inspector having each seperate movement script be a component seems very very counter productive. The only other option I can see is having scripttable objects be the movement scripts but then i would loose the drag and drop reference that scripts have so i couldn’t drag a rigidbody onto one of their fields. Basically I used this system to make it so I don’t have to keep making new air and ground movement scripts for each different type.I do really like this system though its just hard to implement in the unity enviroment. One other option I can see is inheritance I may give that a crack. Although it would be a bit less modular
Hmm, so modularity wise it makes a lot of sense to me. Your issue as I understand it, is that you have to add 4 scripts to each object in the editor?
Here is a thought. I think you could stick with the current class breakdown, but have the Air and Ground Movement class generate the new classes using GameObject.AddComponent.
Then I recommend using the constructor or creating a Setup method, and pass the rigidbody to the other classes from the Air and Ground Movement class.
This has a number of advantages.
- You only have to add the one script to each component.
- You have ready made references to the other components as you generate them.
- You only have to drag and drop the rigidbody reference once.
- You guarantee that each time you use the Air and Ground Movement class, it has all the other iMovement classes as well.
Let me know if that makes sense.
While that could be one solution it still requires the additional components I was hoping there could be a way without using 2 additional components for it as it wouldn’t seem to make much sense.
From a pure C# perspective, you could make the sub classes pure C# classes, and not inherit from monobehaviour. If they are not monobehaviours, you could make instances of them without them having to be components. However, then you lose the enable/disable functionality and other advantages of monoBehaviours, like GetComponent etc. You would have to store your own references to them in variables and maybe use boolean flags instead of enable/disable.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.