Flight.example.mp4
Idea of the project was to see if i can mimic movement type that is normally achieved by rigidbody physics, using only object's transform. I did not know what i'm gonna achieve in the end, but i think it turned out to be pretty fun and arcade-like movement system. All visuals are free assets from Unity assetstore.
- Original project with heavy skybox and spaceship assets (316MB in total).
- Lightweight project with smaller size assets (44MB in total).
- W/S to speed up or slow down
- Q/E to roll
- Mouse to change pitch/yaw
When several components are meant to be on the same GameObject (in this case its flying controls for ship), personally i like to break down all the necessary scripts into separate self-contained parts, in order to make this player controller-related code more manageable and sustainable, and set up easy communication between components.
Ship script represents whole player structure and works like a parent for other player components: if necessary, all data (e.g. player velocity, input info) is meant to go through it, and every player class has a reference to Ship script just in case. This way it's much easier to work with scripts because every class is responsible for only one thing and you always know where you can get a reference.
However, this approach has obvious downsides: for instance, scripts still need to know about each other (only they reference one another through their parent rather than directly). Because of that, i feel like this component structure is fine for smaller projects - it reduces cross-component dependencies a lot in comparsion to doing everything in one file, but it probably won't work for big and scalable ones.
Thanks to John Stejskal for the overview of this practice.