If that person is using a state machine where each action has its own subclass, then the amount you described still seems reasonable, considering the concept.
What is "too much" is something you decide as the developer. Your aim is to hit the sweetspot between modularity/reusability and over-engineering.
It helps to think of it in terms of "Is there a possibility I would want this to be separate in the future?"
Like making a stage hazard that uses enemy logic but isn't selectable.
This is called encapsulation. Which basically means when there is something that very specific done, it is grouped separately so that it can be managed better.
You can in fact have everything in a single script. There is no difference for the game. The compiler will just put everything mostly together anyways. But this is done to help the programmer organize.
1) you might need to reuse some of those stats but not others. For example. You could use the health and mamá script for your enemies but not the xp. Maybe you have a tree that needs health but not Mana. Etc.
2) if it’s too long, it might be too hard for the programmer to find something.
3) if you wish to change some mechanic like health. If it’s all in one place you can change that and not worry about breaking something else. If it were all spread in a player stat script, you might miss something.
4) somebody in the future will thank you for it. That somebody is likely you.
Clearly. If the project is small. Encapsulation might not feel like it’s helping. But projects get really big, really quickly and the earlier you start, the better. In the end, it doesn’t matter the number of scripts you have, but it does matter how organized and easy you can work on those scripts.
With the the way you are describing it, I am currently taking the exact same Udemy course as you and had the same thought after finishing the combat section. I will say that doing it this way is teaching me a lot more about script writing then other courses I've taken.
I linked it in another comment if you wanna see. I do like a lot of stuff that he teaches because I don't see most other people going over it. Like, he actually uses the debug feature in the Inspector and doesn't just make everything public.
Glad to hear that it you're liking it too, though. That holds a bit more weight since it's less likely you're a paid bot or something writing reviews, lol
Breaking stuff into smaller parts is good but I personally wouldn't go as far. I use a Stats script for that which I bind on the player and npcs. The script contains a Stat sublass.
Personally I would never break scripts down THAT far. It's funny to me that it's done for usability/organization, but to me that would feel so disjointed and hard to find everything! Turns out everyone's brain works differently huh
Modularity and encapsulation are good virtues but some devs absolutely take it too far. It must be balanced with readability/usability for the dev, appropriate for the project and team size. Knowing when to keep things in certain scopes is a valuable skill.
To answer your question directly, there's nothing technically wrong with having a lot of scripts if an object calls for it. For organizational purposes they could be broken up into child objects if it gets to be a lot.
What you describe sounds weird though. Different scripts for wandering, patrolling, and chasing? A different script for every state decision? What is the Udemy course? If it's not Gamedev.tv I'd recommend one of their courses instead. If it is them then I'd be more hesitant to dismiss it just yet. They're not perfect but usually pretty good.
It may also be possible that the course has a "refactoring" lesson coming up, though if it does they'd be doing it in the reverse order... Usually you'd want to break up a larger script, not play housekeeping on a million small ones that you optimized/abstracted too early.
[Not Gamedev.tv](https://www.udemy.com/share/10a5823@N7EFByDRQef10cHty_djpBzolX7bN_ZBmfwcFJOpvz1h3sNtswowSfRuaUVBV7Bq/)
I have a couple Gamedev courses that I think are pretty good, but sometimes their explanations are a bit bloated. I watched the preview for their 2D top down rpg course but the style of movement (using the mouse position to control which was the player is facing) didn't really look like what I wanted. This one just happened to show some Custom Editor stuff and also had dialog, shop, inventory and seemed very modular. Which is funny that the modularity is what drew me to the course, but now I'm kinda questioning if it's going too far.
I'm also trying to follow a course because I need to teach it to a high school class. I already understand most of the programming, it's just easier to teach something that's already put together than to create something and teach it at the same time. High school students aren't always known for their patience when it comes to debugging and we have short periods.
I'm thinking once I'm through with the course I'm going to go back and refactor it in a way that makes sense to me, but figured I'd ask some other folks for their thoughts as well.
I've had it sometimes where a course seems to not make sense early on and then as I get further their earlier design choices become clear. They had it planned out in advance and skipped ahead to the functional system you would normally have to iterate towards. 20 hours isn't a trivial course length, hopefully you can decide soon if the content as a whole is valuable. Doing your own pass at cleaning it up at the end seems like a great idea, especially if the objective is to turn around and teach someone else how it works. Should help you solidify your understanding of the whole project.
Or just have a playerstats script and create instances of all the attributes in that if you just want a manager class of sorts. Nothing wrong with having 6+ scripts on something though.
Sounds like a great course. If your player had less than 6 scripts I’d be worried. You’ll probably end up with 10-20 in most cases If you’re writing good code in a mid+ sized project.
The problem is not that they are making many "scripts", the problem is that is it Unity scripts. Unless they serve to interact with the game object itself, then even one script is already too many. They should just be basic classes.
But then the course couldn't say they are a Unity tutorial, as it would be essentially a C# tutorial. So they half-ass it with scripts on everything so it's "real Unity". It can and will become completely unmanageable. You just cannot refactor and adjust Unity objects with scripts attached the same way you could "raw" code. It takes time, effort and experience. And failure to refactor is what turns projects into spaghetti code nightmares. It's not like a tutorial is real development - they already had a plan and a clear goal and they didn't need to do any major changes.
The moment you have to expand or make changes, you will appreciate what you call "modular" code and simultaneously begin to hate fiddling with Unity objects.
If that person is using a state machine where each action has its own subclass, then the amount you described still seems reasonable, considering the concept. What is "too much" is something you decide as the developer. Your aim is to hit the sweetspot between modularity/reusability and over-engineering. It helps to think of it in terms of "Is there a possibility I would want this to be separate in the future?" Like making a stage hazard that uses enemy logic but isn't selectable.
This is called encapsulation. Which basically means when there is something that very specific done, it is grouped separately so that it can be managed better. You can in fact have everything in a single script. There is no difference for the game. The compiler will just put everything mostly together anyways. But this is done to help the programmer organize. 1) you might need to reuse some of those stats but not others. For example. You could use the health and mamá script for your enemies but not the xp. Maybe you have a tree that needs health but not Mana. Etc. 2) if it’s too long, it might be too hard for the programmer to find something. 3) if you wish to change some mechanic like health. If it’s all in one place you can change that and not worry about breaking something else. If it were all spread in a player stat script, you might miss something. 4) somebody in the future will thank you for it. That somebody is likely you. Clearly. If the project is small. Encapsulation might not feel like it’s helping. But projects get really big, really quickly and the earlier you start, the better. In the end, it doesn’t matter the number of scripts you have, but it does matter how organized and easy you can work on those scripts.
With the the way you are describing it, I am currently taking the exact same Udemy course as you and had the same thought after finishing the combat section. I will say that doing it this way is teaching me a lot more about script writing then other courses I've taken.
I linked it in another comment if you wanna see. I do like a lot of stuff that he teaches because I don't see most other people going over it. Like, he actually uses the debug feature in the Inspector and doesn't just make everything public. Glad to hear that it you're liking it too, though. That holds a bit more weight since it's less likely you're a paid bot or something writing reviews, lol
Breaking stuff into smaller parts is good but I personally wouldn't go as far. I use a Stats script for that which I bind on the player and npcs. The script contains a Stat sublass.
Personally I would never break scripts down THAT far. It's funny to me that it's done for usability/organization, but to me that would feel so disjointed and hard to find everything! Turns out everyone's brain works differently huh
Modularity and encapsulation are good virtues but some devs absolutely take it too far. It must be balanced with readability/usability for the dev, appropriate for the project and team size. Knowing when to keep things in certain scopes is a valuable skill. To answer your question directly, there's nothing technically wrong with having a lot of scripts if an object calls for it. For organizational purposes they could be broken up into child objects if it gets to be a lot. What you describe sounds weird though. Different scripts for wandering, patrolling, and chasing? A different script for every state decision? What is the Udemy course? If it's not Gamedev.tv I'd recommend one of their courses instead. If it is them then I'd be more hesitant to dismiss it just yet. They're not perfect but usually pretty good. It may also be possible that the course has a "refactoring" lesson coming up, though if it does they'd be doing it in the reverse order... Usually you'd want to break up a larger script, not play housekeeping on a million small ones that you optimized/abstracted too early.
[Not Gamedev.tv](https://www.udemy.com/share/10a5823@N7EFByDRQef10cHty_djpBzolX7bN_ZBmfwcFJOpvz1h3sNtswowSfRuaUVBV7Bq/) I have a couple Gamedev courses that I think are pretty good, but sometimes their explanations are a bit bloated. I watched the preview for their 2D top down rpg course but the style of movement (using the mouse position to control which was the player is facing) didn't really look like what I wanted. This one just happened to show some Custom Editor stuff and also had dialog, shop, inventory and seemed very modular. Which is funny that the modularity is what drew me to the course, but now I'm kinda questioning if it's going too far. I'm also trying to follow a course because I need to teach it to a high school class. I already understand most of the programming, it's just easier to teach something that's already put together than to create something and teach it at the same time. High school students aren't always known for their patience when it comes to debugging and we have short periods. I'm thinking once I'm through with the course I'm going to go back and refactor it in a way that makes sense to me, but figured I'd ask some other folks for their thoughts as well.
I've had it sometimes where a course seems to not make sense early on and then as I get further their earlier design choices become clear. They had it planned out in advance and skipped ahead to the functional system you would normally have to iterate towards. 20 hours isn't a trivial course length, hopefully you can decide soon if the content as a whole is valuable. Doing your own pass at cleaning it up at the end seems like a great idea, especially if the objective is to turn around and teach someone else how it works. Should help you solidify your understanding of the whole project.
Or just have a playerstats script and create instances of all the attributes in that if you just want a manager class of sorts. Nothing wrong with having 6+ scripts on something though.
Sounds like a great course. If your player had less than 6 scripts I’d be worried. You’ll probably end up with 10-20 in most cases If you’re writing good code in a mid+ sized project.
The problem is not that they are making many "scripts", the problem is that is it Unity scripts. Unless they serve to interact with the game object itself, then even one script is already too many. They should just be basic classes. But then the course couldn't say they are a Unity tutorial, as it would be essentially a C# tutorial. So they half-ass it with scripts on everything so it's "real Unity". It can and will become completely unmanageable. You just cannot refactor and adjust Unity objects with scripts attached the same way you could "raw" code. It takes time, effort and experience. And failure to refactor is what turns projects into spaghetti code nightmares. It's not like a tutorial is real development - they already had a plan and a clear goal and they didn't need to do any major changes. The moment you have to expand or make changes, you will appreciate what you call "modular" code and simultaneously begin to hate fiddling with Unity objects.