I’ve been recommended to switch to single script architecture, the reasoning is because the top games use that architecture.
I read Quenty’s Medium article but it does not make much sense to switch right now since I experience no problems whatsoever so far with my multi script architecture.
Correct me if I am wrong but: there does not seem to be any efficiency gains and if there is any it is minimal since multiple scripts can end execution if there is no loop that goes on forever anyway.
Multi script architecture is also battle tested for small games. I don’t have a huge game so it doesn’t make any sense for me to do something like this and I just don’t see the gains right now.
What am I missing??? Or do you think I am good to go? There’s quite a lot of games that use multi script architecture and they seem to be trotting along just fine. Let me know your thoughts on this!
Why would anyone recommend something like that and where did that “because the top games use that architecture” come from? No top game I know of runs on anything less than 10 scripts, with most running with hundreds of them. You’re locking yourself from ever being able to write multi-threaded code, and there are no performance gains, only potential losses and you could reach the variable limit. Also, good luck finding line 3076 whenever something goes wrong.
I think you are confused. Single script architecture means that the entire client / server is initiated by a single script. But that does not mean everything is in the same script, everything is split into module scripts.
Oh alright. That makes much more sense lol. Because I remember some people actually doing something like this for whatever reasoning their brain created.
To the OP. If you mean requiring multiple module scripts from a single client/server script as mentioned above, that’s how its done most often. But I’d recommend modifying it a bit by instead having one script enable the other scripts one-by-one. It allows you to properly use actors if you ever decide to do so.
I have separate scripts that handle separate module scripts (that has some kind of responsibility towards certain areas of the game). It allows me to delete, move scripts, and manipulate what the script executes on.
Is that the pattern you are talking about in your “actors” case?
Until Parallel Luau was introduced, I had been running my projects with only two scripts, one local and one server, not including default scripts. That is, ever since I read that article you mentioned, which remains very relevant today, if not even more so. The author, @Quenty, is a highly credible and respected individual in the community, and I believe it is a good advice.
In the article, he already mentions some of the advantages of single-script architecture (or at least minimizing the number of scripts). It’s revolves around building a high-level system of modules and components in relations, interacting with each other.
Modularity: Diving a system into modules.
Reusability: Components can be reused in different parts of the system.
Scalability: Components can be maintained and extended independently.
Strong OOP (object-oriented programming) support.
Easier communication between scripts.
More event-driven structures.
Modules higher in the hierarchy manage those lower in the hierarchy. As we delve deeper into the hierarchy, the tasks of the modules become more specific.
If you were to use Sleitnick’s Knit framework, you could think of this as a script requiring services, controllers, managers etc., further requiring other components and (might we term them) microservices, further requiring everything else they need. Shared data has its own modules and so forth.
There shouldn’t be a notable performance difference between a well-written stand-alone scripts and a well-written component. It’s more about organization and work-flow than performance, although single-script structure promotes handling multiple objects from a single “place”. We could say it promotes efficient handling of the game logic.
That’s fine!
Also, it’s more crucial to reach the goals you’ve set for yourself. The objective is usually to complete the game rather than revising it too much and attempting to make it perfect, because it undoubtedly never will be.
One advantage of the single-script architecture is planning and future-proofing. It can definitely help your experience become more scalable and easier for multiple devs to work on, but that doesn’t mean multi-script games are bad, which applies to a number of top games. If you prefer using multiple scripts, that’s alright, as long as it works for you. And maybe it would be a waste of time and motivation to make a transition in the current project.
Apocalypse Rising I utilizes multiple scripts, while version II adopted the new structure.
Of course, there are also games that successfully divide their code into a select few scripts for different areas and tasks, still relying on a lot of modules.
Actors refer to special objects in the context of Parallel Luau to delegate game logic between CPU cores; multi-threading requires a stand-alone script inside an actor.
Thank you for the well worded and articulated response. So, it seems like this is something that is more organizational-heavy as I thought and creating team cohesion (collaborating) for big teams.
It also seems like there are different ways to do the multi-script architecture and not just one way.
My conclusion is that it is a preference and depends on your game and how you organize and structure your codebase which will lead you to decide whether or not single script architecture is worth it to you.
In my case, I don’t think I will be switching any time soon. I think there are still quite a lot of things I could do with multi script architecture and I do not see any obstacles nor problems yet. I will keep using it since there are no problems.
I said this already but personally, I mostly rely on two main scripts. I obvisouly can’t speak for everyone though. There’s a bunch of seriously successful games applying different approaches. Sure, it’s important to consider how you do something, but it’s eventually about the final result (and possibly planning for what’s there yet to come).
Writing readable, maintainable, extensible… code is a pattern that isn’t rare among great games. And that usually includes some form of organization via modularity, hierarchy, logic delegation between components, compactness etc. Still, not every success story has so strictly few scripts.
For a short while I was using two main scripts but had a local script for each ScreenGui.
The simplest modularization example is probably an average obby with those lava parts or kill bricks. The worst is to have is a script in each one of them. Hard to maintain, poor performance. Much better to collect and handle them in one script. Next step could be handling them in a module script as part of a bigger picture. Maybe a script handling all obstacles could also require and manage this one. Perhaps this obstacle handler could be part of a class, for instance Obstacles. And suddenly, the whole logic is modularized, at some point ran by a script. Need to change something related to lava parts? Open up the relevant component.
I’m saying this from my limited experience. Maybe someone else comes with further advice.
