Hello!
I’m trying to make a game with different parts being managed and I’ve come across an issue.
My game will be like an obby with different sections in it, with each section containing moving parts that will be spawned and destroyed at different times.
Here’s a screenshot for an outline of a section:
My question is simple, what’s the best way to handle multiple sections?
Would it be to make multiple scripts for each section? or should I have a master script that creates coroutines for each individual section?
For instance if I go with coroutines and have 3 sections, the master script will create a coroutine for each section which has it’s own while loop that terminates when the game is over (meaning the parts will stop moving and no new parts will spawn in each section).
Im looking at this from an efficiency standpoint, what’s less server-intensive, with my second priority being difficulty of implementation.
Thanks for the feedback
Go for coroutines since using separated scripts is just messy. Running multiple coroutines at the same time shouldn’t lag your game unless you use way too many of them.
I am pretty sure that’s up to you, both run in multiple threads and result pretty much the same.
Whatever is easier for you to use, do it.
When using multiple scripts, the master script is not too long and hard to read, and everything is divided into a short code that’s simple to read and change.
One advantage when using coroutines and a master script, you can easily make changes, so you don’t have to go through lots of scripts. But that’s only if the script is general enough, and not too specific for each section.
Just keep in mind, not everything needs a new thread. For example:
A kill part, is simply a connection, you don’t have to create a new thread just to create the connection.
You can, but it’s unneseccary
I would personally use a ModuleScript in as a class to represent a section, in an OOP manner, and have the section objects managed by another module, which would most likely be some kind of singleton that owns the game loop. There are other, equally-valid ways to architect a game, but for someone who comes from a C++/Java app development background, that is what would be natural for me to implement.
