I am in the process of refactoring a game of mine, which involves hosting the codebase on GitHub. Naturally this means I can’t bring along an instance hierarchy with me and all I will be able to do is have scripts up on GitHub. File uploads won’t work, I intend to integrate the repository with Rojo.
So, question’s the title. Are there any negative technical implications on instancing initial components at run time? For example, my scripts may need quite a few remotes and bindables to function so the server script will create, parent and handle server-side work in regards to those.
The alternative is keeping everything in Studio and having my remotes or bindables available from the get go. This defeats the purpose of moving to GitHub because I’ll just be maintaining two copies of the codebase which will quickly develop into a headache.
I’d prefer not to keep things in Studio because of petty problems like the code editor being annoying with tabbing/comments/intellisense/etc and tooling that I’d like for code collaboration without giving developers access to the game and so I can take advantage of version control to audit changes and revert them as needed.
If having my remotes and bindables in the DataModel on publish is better than creating them from a script, yeah I’ll be sad and just have to root back to everything in Studio, but it’s not worth the tooling if it butchers productivity and technical efficiency.
Did my own research and got a semi-conclusive answer. Also found out that PlayerGui implicitly exists on the client, so now I need to go back to all my loading screens and remove WaitForChild from them!
So while I am still lacking information and need to perform replication tests sometime along with given information, the answer is yes, there are some implications about instancing components versus having them available in the DataModel. The argument here is static vs dynamic.
When my remotes and events and whatnot are already available in Studio, these are static instances and fall under the initial replication snapshot. When my scripts are actively generating instances even just to set up the components it needs to run, these are dynamic instances.
Client scripts need to exercise caution when accessing dynamically generated instances because their availability is not guaranteed (falls under general replication that occurs during run time). That means breaking out WaitForChild on an absurd amount of items depending on how large the codebase gets. Static instances, however, are more likely (or guaranteed) to be available right away.
What I’ve learned from this all is that my current refactor attempts are not worth hosting on GitHub and I should reserve that more for when I have a framework going. There’s a very great difference between a framework making these instances against independent scripts doing it.
For example, my framework of choice for my next refactor attempts is Crazyman32’s Aero Game Framework. As a framework, Aero contains event registration and setups as part of its initialisation process, so all I do is write code and Aero will take care of events and instance creation for me. I thus only have to be concerned about writing code and using the API to make events.
Thanks to anyone who held an interest in this topic: be it if you did a bit of research, tried to think of an answer to reply here with or if you just viewed. I’ve found my own answer so I won’t need much more input unless you’d like to share information relevant to the topic.