Something that has always fascinated yet confused me is this practice of using as little scripts as possible or only using one script, a god script. No, I’m not talking about the fact that these games are typically modularised, that’s unimportant. Modularised games can be found in god-script, minimalist and standard hierarchies.
What is this practice of using as few scripts as possible and why do developers strive to do it? It never made much sense to me to dump all of the game’s code into a single script and modularise everything else.
For reference, I’m trying to understand why developers use (2) a minimalist game structure and if it’s any better than (1) my current game structure.
I don’t really see it as a practice but as of how people like writing there code.
I do it because I don’t want to spend 5 Minutes looking for one script.
It’s purely preference. However, I do think that most programmers would appreciate organization, so having 80 separate scripts for tasks that would probably be better together is a big “No” from me (that includes module scripts).
Not to spam your thread, but I would like to point out you have some misconceptions on “god” scripts:
One error stops your whole game, rather than an isolated bug
Not necessarily. You can utilize pcall() to catch errors and handle them accordingly.
Have to scroll through potentially thousands of lines of code
Admittedly, when I tried making a game with one master script, this was a huge annoyance. But if you keep things organized, it isn’t that bad. Now, if the script editor breaks for some reason… Yeah it’s horrible.
Conflictions and complications
Using functions and local variables solves the conflictions issue. In fact, it was nice to have my variables in one script because it saved a lot of time typing. I can’t really think of any complications that can emerge with one script that can’t emerge with multiple.
Collaborator comfortability
As I said in my original comment, this really comes down to preference. I personally don’t mind one script for everything so long as it is organized. In fact, it can be better than having multiple when I know whatever I’m looking for will be in that script.
I find that using pcall for a majority of your code is bad practice. pcall is good for wrapping around error-bound code but that can easily be a large section of your code or an external library causing it. And by God, it’s unsightly to see pcall being used improperly by wrapping entire chunks.
There’s also the case of a core script erroring. Not a Roblox one, yours. What then? Yes, you can catch the error and prevent it from terminating your thread with pcall, but that doesn’t mean much if your game can only function subpar or not at all without that block working. It denies the usefulness of the pcall for that specific chunk.
That’s all to counteract really. I can see logic in the rest of your points and it’s been quite insightful.
I also think pcall is ugly, but I still think error handling with one script, while not being necessary, is relatively straightforward.
If a core script breaks, I would first “fix” the game, then terminate the thread and reload the original script on a new one. That’s just the best way I can think of to handle such a problem. A problem on that scale could still happen with multiple scripts too.
It makes it way easier to fix bugs. For instance, you have 100 monsters, each with their own script to damage the player. Next thing you know, you made a small, easy to fix error in the scripts. Now, instead of just fixing the error in the “God-Script”, you have to fix a the errors in your 100 monsters. Its more efficient to make a God-Script.
I don’t think you understand the point of this thread nor what I’m talking about. Consolidating the behaviour of a certain gameplay element to a class or handler is not the same thing as running an entire game off of a single script with supporting modules.
I wholeheartedly disagree that bug fixing with a God script is easier. I’d rather not scroll through thousands of lines to find an error. In that regard, isolating bugs and such has been discussed above. If you would like to provide a detailed explanation as to how you find God scripts easier to fix, I’d appreciate it.
I also do not agree with your statement about how God scripts are supposedly efficient. This entire thread seeks to understand what the fancy for running games with a single script is but telling me that it’s efficient without a detailed explanation doesn’t do anything for me. It’s an empty point.
A single Script or LocalScript per-environment is not necessarily a “god script.” Oftentimes games which do this have most (if not all) of their game logic written in modules (objects or components), which the Script or LocalScript can then call into. These modules do not contain bits of reusable code in this case! This leads to the next point:
The Hollywood principle: “don’t call us, we’ll call you” (a.k.a. inversion of control). This pattern typically involves a framework which both instantiates and handles the lifetime of objects/components, rather than these objects/components doing so by themselves. The point of doing this is to get highly modularized, decoupled code. Multiple scripts per environment would not only be unnecessary in this context, but would also encourage the programmer to handle instantiation/lifetime outside of the framework (which is a mistake).
A single entry point. Although Lua doesn’t have the concept of a main(), it is much easier to reason about the flow of the program when it all begins at one place in the code. If you’ve got lots of stuff happening simultaneously, and all this stuff is in different scripts, it can be pretty difficult to figure out exactly what will happen and when (this also opens the door wider for race conditions).