Question Multiple Scripts or a big one?

Hi,
Pease, I want to know what is better: one big script as a component of the player containing all of its features (movement, attributes, animation, ...) or different scripts for each one of these features?

 

Without going to the extreme, I favour separate scripts for the different features, it keeps things more easily maintainable and makes it so that they can potentially be reused in other places too.

As an example of how I might separate some things and not others depending on the circumstances; in the game I'm working on now, I have a movement controller, which receives input from an input manager class.

The movement controller doesn't directly move anything though, it has a reference to a movement engine asset, which depending on the input sent to the movement controller, actually performs the movement.

This means that to change the behaviour of the movement controller, I can simply switch in a different engine asset at any time, for example to change from walking to flying. The input manager and movement controller remain the same, but the resulting movement is completely different.

I can also reuse the movement controller on something like NPCs. Because the movement controller isn't responsible for reading input, I can send it automatically generated inputs that govern how to move the NPC.

However, because animation is very closely tied to movement, I let the movement controller also manage the animations. I may consider changing this at a later stage if I decide it becomes too unwieldy.

At the end of the day though, you just need to try different approaches and find out what works best for the project you're working on.

 

One or many scripts does not matter.

What matters is that you understand what you are doing. Pay special attention to Step #2 below:

Tutorials and example code are great, but keep this in mind to maximize your success and minimize your frustration:

How to do tutorials properly, two (2) simple steps to success:

Step 1. Follow the tutorial and do every single step of the tutorial 100% precisely the way it is shown. Even the slightest deviation (even a single character!) generally ends in disaster. That's how software engineering works. Every step must be taken, every single letter must be spelled, capitalized, punctuated and spaced (or not spaced) properly, literally NOTHING can be omitted or skipped.

Fortunately this is the easiest part to get right: Be a robot. Don't make any mistakes.
BE PERFECT IN EVERYTHING YOU DO HERE!!

If you get any errors, learn how to read the error code and fix your error. Google is your friend here. Do NOT continue until you fix your error. Your error will probably be somewhere near the parenthesis numbers (line and character position) in the file. It is almost CERTAINLY your typo causing the error, so look again and fix it.

Step 2. Go back and work through every part of the tutorial again, and this time explain it to your doggie. See how I am doing that in my avatar picture? If you have no dog, explain it to your house plant. If you are unable to explain any part of it, STOP. DO NOT PROCEED. Now go learn how that part works. Read the documentation on the functions involved. Go back to the tutorial and try to figure out WHY they did that. This is the part that takes a LOT of time when you are new. It might take days or weeks to work through a single 5-minute tutorial. Stick with it. You will learn.

Step 2 is the part everybody seems to miss. Without Step 2 you are simply a code-typing monkey and outside of the specific tutorial you did, you will be completely lost. If you want to learn, you MUST do Step 2.

Of course, all this presupposes no errors in the tutorial. For certain tutorial makers (like Unity, Brackeys, Imphenzia, Sebastian Lague) this is usually the case. For some other less-well-known content creators, this is less true. Read the comments on the video: did anyone have issues like you did? If there's an error, you will NEVER be the first guy to find it.

Beyond that, Step 3, 4, 5 and 6 become easy because you already understand!

 

Like many things in programming it's very much dependent on your requirements. Each approach has advantages and disadvantages. I tossed the question at ChatGPT asking it for a list of pros and cons and it came up with the following (bold is my additions):

Spoiler: Pros and Cons of One Script

Pros:

1. Centralization: Everything related to the player is located in one place, which may simplify the search for specific functionality.
2. Direct access: All variables and methods are readily available without needing to interface between different scripts.
3. Unity: If you're coding in an engine like Unity, it may result in less overhead because Unity's message-passing system can slow things down when used extensively. It's referring to SendMessage() and BroadcastMessage() which are slow.

Cons:

1. Complexity: A large script can become difficult to navigate and understand, especially for new team members or when returning to the project after a break.
2. Difficulty in Debugging: Bugs may be harder to isolate and fix, as they could be caused by any part of a large and complex script.
3. Decreased Flexibility: Changes to one part of the script may inadvertently affect other parts, increasing the risk of introducing bugs.
4. Violation of Single Responsibility Principle: In software engineering, it's often beneficial for each module or component to have one specific role or responsibility. A script that tries to do everything violates this principle.

Spoiler: Pros and Cons of Multiple Scripts

Pros:

1. Modularity: Each script has a specific role, making the code easier to understand and maintain. This aligns with the Single Responsibility Principle of software engineering.
2. Easier Debugging: If a bug arises, it may be easier to isolate and fix because you can look at the specific script responsible for the malfunctioning feature.
3. Reusability: Components can be reused across different entities in the game. For instance, a "movement" script could potentially be used for multiple character types.
4. Easier Collaboration: If you're working with a team, different scripts allow multiple people to work on different features without stepping on each other's toes.

Cons:

1. Dependency Management: You need to ensure all scripts are appropriately linked and dependencies are managed, which can become complex.
2. Performance: If you're using a game engine like Unity, having many separate scripts might have a performance impact due to Unity's message-passing system. Again it's referring to SendMessage() and BroadcastMessage().
3. Overhead of Communication: Scripts will need to communicate with each other to coordinate the overall behavior of the player, and implementing this communication can be a challenge.

 

I prefer a large one for a complex entity like the player, and small ones for most everything else (except maybe a GameManager, depending on the game). They can get a bit unwieldy, but careful naming of variables and methods helps a lot. I'd also rather have to scroll a bit than jump from one script to another, plus code folding makes navigating a large script easy. For example, there might be a couple dozen tag checks for what the player collides with...easy to fold that large method once it's done.

Of course, some modularity can be lost with large scripts. But for a specialty script like a player character, I imagine most of it could be re-used with some modifications for other games. And the methods themselves could be quite modular and re-usable, just maybe not the entire script as-is.

Bottom line: it's up to you, there are lots of ways to approach it.

 

There is a general rule of thumb in programming called The Single Responsibility Principle that states you should break your modules of code down so that they handle only 'one thing'. Of course this is more than a little vague as 'one thing's can be broken down any number of ways. But my personal preference is to pick an exact gameplay purpose and only program that for my script.

For example, my Health script does one thing. Track max health and current health and make sure current never exceeds max and that a death event is posted if it ever hits zero or less. What it DOESN'T do is handle any combat calculations, reset the game, disable controls, change animations, play sounds, or in any way affect any other aspect of gameplay. In this way I can recycle my Health component in many different projects and in many different ways. It can be the health for a player or NPC. It can be the durability of an item or prop in the world such as a door. It can be used in single player and multiplayer games. And it doesn't require me to bring a bunch of other code and features into every project in which I use it other than some general purpose messaging systems that I always use anyway.